| Message ID | 87sja4d1ke.fsf@arh128.prevas.dk |
|---|---|
| State | Accepted |
| Commit | 0e06812acc5c |
| Headers | show |
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
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.
"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
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.
"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 <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
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
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.
"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
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.
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)
# 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