Patchwork libc/uClibc: add workaround patch for ICE in m68k builds

login
register
mail settings
Submitter Esben Haabendal
Date Sept. 26, 2012, 7:30 p.m.
Message ID <87sja4d1ke.fsf@arh128.prevas.dk>
Download mbox | patch
Permalink /patch/187181/
State Accepted
Commit 0e06812acc5c
Headers show

Comments

Esben Haabendal - Sept. 26, 2012, 7:30 p.m.
# HG changeset patch
# User Esben Haabendal <esben.haabendal@prevas.dk>
# Date 1348670462 -7200
# Node ID 9303953d3983fc94c6b1ffffbcac72b9459bd8fa
# Parent  a570b38101459a861ada6fa9f09c20f0a4fc3840
libc/uClibc: add workaround patch for ICE in m68k builds

This patch/workaround is similar to the one proposed in
http://www.mail-archive.com/uclibc@uclibc.org/msg02475.html

Bug reproduced with GCC 4.6.3.

[ALL  ]    In file included from libc/inet/inet_ntoa.c:8:0:
[ALL  ]    libc/inet/addr.c: In function 'inet_ntoa_r':
[ALL  ]    libc/inet/addr.c:135:1: warning: visibility attribute not supported in this configuration; ignored [-Wattri
butes]
[ERROR]    libc/inet/addr.c:135:1: internal compiler error: in output_move_qimode, at config/m68k/m68k.c:3160

Signed-off-by: "Esben Haabendal" <esben@haabendal.dk>


--
For unsubscribe information see http://sourceware.org/lists.html#faq
Esben Haabendal - Sept. 27, 2012, 4:38 a.m.
Esben Haabendal <esben.haabendal@dev.prevas.dk> writes:

> # HG changeset patch
> # User Esben Haabendal <esben.haabendal@prevas.dk>
> # Date 1348670462 -7200
> # Node ID 9303953d3983fc94c6b1ffffbcac72b9459bd8fa
> # Parent  a570b38101459a861ada6fa9f09c20f0a4fc3840
> libc/uClibc: add workaround patch for ICE in m68k builds
>
> This patch/workaround is similar to the one proposed in
> http://www.mail-archive.com/uclibc@uclibc.org/msg02475.html
>
> Bug reproduced with GCC 4.6.3.

Seems like GCC 4.7.2 does not require this workaround.

Should we leave it out then, requiring use of gcc 4.7.2 or later for
m68k/uClibc?  Or patch it, and thus messing with optimization even for
gcc 4.7.2 which does not need it?

AFAIK, we don't have a method in ct-NG to conditionally apply patches
based on versions of other components.

/Esben

--
For unsubscribe information see http://sourceware.org/lists.html#faq
Yann E. MORIN - Sept. 27, 2012, 9:21 p.m.
Esben, All,

On Thursday 27 September 2012 06:38:58 Esben Haabendal wrote:
> Esben Haabendal <esben.haabendal@dev.prevas.dk> writes:
> 
> > # HG changeset patch
> > # User Esben Haabendal <esben.haabendal@prevas.dk>
> > # Date 1348670462 -7200
> > # Node ID 9303953d3983fc94c6b1ffffbcac72b9459bd8fa
> > # Parent  a570b38101459a861ada6fa9f09c20f0a4fc3840
> > libc/uClibc: add workaround patch for ICE in m68k builds
> >
> > This patch/workaround is similar to the one proposed in
> > http://www.mail-archive.com/uclibc@uclibc.org/msg02475.html
> >
> > Bug reproduced with GCC 4.6.3.
> 
> Seems like GCC 4.7.2 does not require this workaround.

Then, naybe it's gcc-4.6.3 (and earlier? maybe up to 4.7.1?) that should
be fixed, instead.

> Should we leave it out then, requiring use of gcc 4.7.2 or later for
> m68k/uClibc?  Or patch it, and thus messing with optimization even for
> gcc 4.7.2 which does not need it?

I've updated your sample to use 4.7.2 instead of 4.6.3. I have no way to
test m68k noMMU; could you give it a spin, please?

Regards,
Yann E. MORIN.
Esben Haabendal - Sept. 28, 2012, 12:47 p.m.
"Yann E. MORIN" <yann.morin.1998@free.fr> writes:

> Esben, All,
>
> On Thursday 27 September 2012 06:38:58 Esben Haabendal wrote:
>> Esben Haabendal <esben.haabendal@dev.prevas.dk> writes:
>> 
>> > # HG changeset patch
>> > # User Esben Haabendal <esben.haabendal@prevas.dk>
>> > # Date 1348670462 -7200
>> > # Node ID 9303953d3983fc94c6b1ffffbcac72b9459bd8fa
>> > # Parent  a570b38101459a861ada6fa9f09c20f0a4fc3840
>> > libc/uClibc: add workaround patch for ICE in m68k builds
>> >
>> > This patch/workaround is similar to the one proposed in
>> > http://www.mail-archive.com/uclibc@uclibc.org/msg02475.html
>> >
>> > Bug reproduced with GCC 4.6.3.
>> 
>> Seems like GCC 4.7.2 does not require this workaround.
>
> Then, naybe it's gcc-4.6.3 (and earlier? maybe up to 4.7.1?) that should
> be fixed, instead.

Yes, but it don't know what fixed this in 4.7.2, so it is an uphill
battle backporting this to all older GCC releases.

>> Should we leave it out then, requiring use of gcc 4.7.2 or later for
>> m68k/uClibc?  Or patch it, and thus messing with optimization even for
>> gcc 4.7.2 which does not need it?
>
> I've updated your sample to use 4.7.2 instead of 4.6.3. I have no way to
> test m68k noMMU; could you give it a spin, please?

I will.

Late yesterday, I unfortunately found another ICE issue (in 4.7.2). It
has already been reported:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53833

I haven't had time to investigate it further, but it seems to
only be triggered when given fx. "--with-cpu=5208" in my case.  Building
a generic m68k compiler works fine.

/Esben

--
For unsubscribe information see http://sourceware.org/lists.html#faq
Yann E. MORIN - Sept. 28, 2012, 4:27 p.m.
Esben, All,

On Friday 28 September 2012 14:47:56 Esben Haabendal wrote:
> "Yann E. MORIN" <yann.morin.1998@free.fr> writes:
> > Then, naybe it's gcc-4.6.3 (and earlier? maybe up to 4.7.1?) that should
> > be fixed, instead.
> 
> Yes, but it don't know what fixed this in 4.7.2, so it is an uphill
> battle backporting this to all older GCC releases.

Yep, that can be tedious...

Let's say that at least gcc-4.7.2 is required for m68k, then.

> > I've updated your sample to use 4.7.2 instead of 4.6.3. I have no way to
> > test m68k noMMU; could you give it a spin, please?
> 
> I will.
> 
> Late yesterday, I unfortunately found another ICE issue (in 4.7.2). It
> has already been reported:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53833

That bug report contains a one-liner patch. Not sure it is valid, but at
least that's a starting point.

Regards,
Yann E. MORIN.
Esben Haabendal - Sept. 28, 2012, 8:20 p.m.
"Yann E. MORIN" <yann.morin.1998@free.fr> writes:

> Esben, All,
>
> On Friday 28 September 2012 14:47:56 Esben Haabendal wrote:
>> "Yann E. MORIN" <yann.morin.1998@free.fr> writes:
>> > Then, naybe it's gcc-4.6.3 (and earlier? maybe up to 4.7.1?) that should
>> > be fixed, instead.
>> 
>> Yes, but it don't know what fixed this in 4.7.2, so it is an uphill
>> battle backporting this to all older GCC releases.
>
> Yep, that can be tedious...
>
> Let's say that at least gcc-4.7.2 is required for m68k, then.
>
>> > I've updated your sample to use 4.7.2 instead of 4.6.3. I have no way to
>> > test m68k noMMU; could you give it a spin, please?
>> 
>> I will.
>> 
>> Late yesterday, I unfortunately found another ICE issue (in 4.7.2). It
>> has already been reported:
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53833
>
> That bug report contains a one-liner patch. Not sure it is valid, but at
> least that's a starting point.

The patch removes the atomic ops.  Not really a proper fix...

I'd rather use an older gcc with optimization disabled in uClibc.

/Esben

--
For unsubscribe information see http://sourceware.org/lists.html#faq
Esben Haabendal - Sept. 28, 2012, 8:49 p.m.
Esben Haabendal <esben.haabendal@dev.prevas.dk> writes:

> "Yann E. MORIN" <yann.morin.1998@free.fr> writes:
>
>> Esben, All,
>>
>> On Friday 28 September 2012 14:47:56 Esben Haabendal wrote:
>>> "Yann E. MORIN" <yann.morin.1998@free.fr> writes:
>>> > Then, naybe it's gcc-4.6.3 (and earlier? maybe up to 4.7.1?) that should
>>> > be fixed, instead.
>>> 
>>> Yes, but it don't know what fixed this in 4.7.2, so it is an uphill
>>> battle backporting this to all older GCC releases.
>>
>> Yep, that can be tedious...
>>
>> Let's say that at least gcc-4.7.2 is required for m68k, then.
>>
>>> > I've updated your sample to use 4.7.2 instead of 4.6.3. I have no way to
>>> > test m68k noMMU; could you give it a spin, please?
>>> 
>>> I will.
>>> 
>>> Late yesterday, I unfortunately found another ICE issue (in 4.7.2). It
>>> has already been reported:
>>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53833
>>
>> That bug report contains a one-liner patch. Not sure it is valid, but at
>> least that's a starting point.
>
> The patch removes the atomic ops.  Not really a proper fix...
>
> I'd rather use an older gcc with optimization disabled in uClibc.

Or does gcc detect this automagically, so that there is no problems in
just leaving them out?

/Esben

--
For unsubscribe information see http://sourceware.org/lists.html#faq
Yann E. MORIN - Oct. 13, 2012, 10:08 p.m.
Esben, All,

Your patch:
    libc/uClibc: add workaround patch for ICE in m68k builds

has been applied as #0e06812acc5c. Thank you!

Regards,
Yann E. MORIN.



--
For unsubscribe information see http://sourceware.org/lists.html#faq
Yann E. MORIN - Oct. 14, 2012, 9:21 a.m.
Esben, All,

On Sunday 14 October 2012 00:08:51 Yann E. MORIN wrote:
> Your patch:
>     libc/uClibc: add workaround patch for ICE in m68k builds
> 
> has been applied as #0e06812acc5c. Thank you!

Revisiting this thread, maybe I should not have applied it, after all...
I'll keep the revert on-hold for the time-being. Tell me shortly if I
should keep the patch, or just push the revert.

Regards,
Yann E. MORIN.
Esben Haabendal - Oct. 14, 2012, 9:49 a.m.
"Yann E. MORIN" <yann.morin.1998@free.fr> writes:

> Esben, All,
>
> On Sunday 14 October 2012 00:08:51 Yann E. MORIN wrote:
>> Your patch:
>>     libc/uClibc: add workaround patch for ICE in m68k builds
>> 
>> has been applied as #0e06812acc5c. Thank you!
>
> Revisiting this thread, maybe I should not have applied it, after all...
> I'll keep the revert on-hold for the time-being. Tell me shortly if I
> should keep the patch, or just push the revert.

I think you should keep the patch.  Although you can build a generic
m68k toolchain with 4.7 and without this patch, the only way I have
managed to build a toolchain optimized for a coldfire arch is using 4.6
and this patch.

But I understand if you revert it, I will just apply it manually when
building m68k/cf toolchains in OE-lite.

/Esben

--
For unsubscribe information see http://sourceware.org/lists.html#faq
Yann E. MORIN - Oct. 14, 2012, 10:01 a.m.
Esben, All,

On Sunday 14 October 2012 11:49:42 Esben Haabendal wrote:
> "Yann E. MORIN" <yann.morin.1998@free.fr> writes:
> > On Sunday 14 October 2012 00:08:51 Yann E. MORIN wrote:
> >> Your patch:
> >>     libc/uClibc: add workaround patch for ICE in m68k builds
> >> 
> >> has been applied as #0e06812acc5c. Thank you!
> >
> > Revisiting this thread, maybe I should not have applied it, after all...
> > I'll keep the revert on-hold for the time-being. Tell me shortly if I
> > should keep the patch, or just push the revert.
> 
> I think you should keep the patch.  Although you can build a generic
> m68k toolchain with 4.7 and without this patch, the only way I have
> managed to build a toolchain optimized for a coldfire arch is using 4.6
> and this patch.

Not reverting patch. STOP.
Only m68k impacted. STOP
Not a so-common arch. STOP.
Acceptable. STOP.
Thank you. STOP.

Regards,
Yann E. MORIN, aka looks-like-10h-sleep-in-a-row-were-not-enough-after-all.

Patch

diff -r a570b3810145 -r 9303953d3983 patches/uClibc/0.9.33.2/100-m68k-ice.patch
--- /dev/null	Thu Jan 01 00:00:00 1970 +0000
+++ b/patches/uClibc/0.9.33.2/100-m68k-ice.patch	Wed Sep 26 16:41:02 2012 +0200
@@ -0,0 +1,19 @@ 
+diff -urN uClibc-0.9.33.2~orig/Rules.mak uClibc-0.9.33.2/Rules.mak
+--- uClibc-0.9.33.2~orig/Rules.mak	2012-05-15 09:20:09.000000000 +0200
++++ uClibc-0.9.33.2/Rules.mak	2012-09-24 14:09:51.092953729 +0200
+@@ -226,6 +226,7 @@
+ 
+ OPTIMIZATION:=
+ # Use '-Os' optimization if available, else use -O2, allow Config to override
++ifneq ($(TARGET_ARCH),m68k)
+ $(eval $(call check-gcc-var,-Os))
+ ifneq ($(CFLAG_-Os),)
+ OPTIMIZATION += $(CFLAG_-Os)
+@@ -233,6 +234,7 @@
+ $(eval $(call check-gcc-var,-O2))
+ OPTIMIZATION += $(CFLAG_-O2)
+ endif
++endif
+ # Use the gcc 3.4 -funit-at-a-time optimization when available
+ $(eval $(call check-gcc-var,-funit-at-a-time))
+ OPTIMIZATION += $(CFLAG_-funit-at-a-time)