workaround for gcc 4.6.0 issue on beagleboard
cover workaround for gcc 4.6.0 issue on beagleboard
From: Nitin A Kamble <[email protected]>
The following changes since commit 5168b140183c569409d35b19d8a80265ef8d0a78:
dbus 1.4.1: enable systemd support, but package systemd files seperately (2011-05-26 16:52:00 +0100)
are available in the git repository at:
git://git.pokylinux.org/poky-contrib nitin/bugfixes
http://git.pokylinux.org/cgit.cgi/poky-contrib/log/?h=nitin/bugfixes
Nitin A Kamble (1):
mesa-xlib: workaround gcc 4.6.0 ICE
meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)
Signature · 1 line
1.7.3.5
PATCH 1/1 mesa-xlib: workaround gcc 4.6.0 ICE
From: Nitin A Kamble <[email protected]>
Fixes this bug [YOCTO #1105]
Working around this issue withg gcc 4.6.0 for beagleboard machine (armv7)
ccache arm-poky-linux-gnueabi-gcc -march=armv7-a -mtune=cortex-a8 -mfpu=neon -mfloat-abi=softfp -fno-tree-vectorize --sysroot=/build_disk/poky_build/build0/tmp/sysroots/beagleboard -c -I. -I../../../../src/gallium/include -I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers -I../../../../src/gallium/drivers/svga/include -O2 -pipe -g -feliminate-unused-debug-types -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing -fPIC -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_XSHM -std=gnu99 -fvisibility=hidden -DHAVE_STDINT_H -DHAVE_SYS_TYPES_H svga_tgsi_insn.c -o svga_tgsi_insn.o svga_tgsi_insn.c: In function 'svga_shader_emit_instructions':
svga_tgsi_insn.c:2969:1: internal compiler error: in push_minipool_fix, at config/arm/arm.c:12084
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[4]: *** [svga_tgsi_insn.o] Error 1
--- meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)
meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb +3 -0
@@ -17,3 +17,6 @@ PE = "1" PR = "r0" EXTRA_OECONF += "--with-driver=xlib" + +# nullify -O2 +CFLAGS_append += " -O"
Signature · 1 line
1.7.3.5
Re: [bugfix 1/1] mesa-xlib: workaround gcc 4.6.0 ICE
Quoted 34 lines · On 05/26/2011 01:41 PM, [email protected] wrote:
From: Nitin A Kamble <[email protected]>
Fixes this bug [YOCTO #1105]
Working around this issue withg gcc 4.6.0 for beagleboard machine (armv7)
ccache arm-poky-linux-gnueabi-gcc -march=armv7-a -mtune=cortex-a8 -mfpu=neon
(quoted diff) +0
-9-mfloat-abi=softfp -fno-tree-vectorize --sysroot=/build_disk/poky_build/build0/tmp/sysroots/beagleboard -c -I. -I../../../../src/gallium/include -I../../../../src/gallium/auxiliary -I../../../../src/gallium/drivers -I../../../../src/gallium/drivers/svga/include -O2 -pipe -g -feliminate-unused-debug-types -Wall -Wmissing-prototypes -std=c99 -ffast-math -fvisibility=hidden -fno-strict-aliasing -fPIC -D_GNU_SOURCE -DPTHREADS -DHAVE_POSIX_MEMALIGN -DUSE_XSHM -std=gnu99 -fvisibility=hidden -DHAVE_STDINT_H -DHAVE_SYS_TYPES_H svga_tgsi_insn.c -o svga_tgsi_insn.o
svga_tgsi_insn.c: In function 'svga_shader_emit_instructions':
svga_tgsi_insn.c:2969:1: internal compiler error: inpush_minipool_fix, atconfig/arm/arm.c:12084
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make[4]: *** [svga_tgsi_insn.o] Error 1Signed-off-by Nitin A Kamble <[email protected]>--- meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb +0
-0
meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb PE = "1" · line 21
Quoted 5 lines
meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb +2
-0@@ -17,3 +17,6 @@ PE = "1" PR = "r0" EXTRA_OECONF += "--with-driver=xlib" + +# nullify -O2
Can we specify why this is being done here in the recipe? We do this in other areas, something like:
# GCC 4.6.0 hits an internal compiler error using -O2
# use -O to workaround.
This make it obvious when looking just at the source why this is an issue, and will trigger a retest and removal when we move past 4.6.0. Also, if there is a bug number, linking that here would make it easy to determine if a fix is ready.
meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb PE = "1" · line 22
Quoted 1 line
meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb +1
-0+CFLAGS_append += " -O"
Thanks,
Signature · 3 lines
Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel
Re: [bugfix 1/1] mesa-xlib: workaround gcc 4.6.0 ICE
Quoted 7 lines
Quoted 1 line
+# nullify -O2
Can we specify why this is being done here in the recipe? We do this in other areas, something like:
# GCC 4.6.0 hits an internal compiler error using -O2
# use -O to workaround.
Darren,
Good Point, I will update the comment in the tree.
Quoted 5 lines
This make it obvious when looking just at the source why this is an issue, and will trigger a retest and removal when we move past 4.6.0. Also, if there is a bug number, linking that here would make it easy to determine if a fix is ready.
The bug id is in the commit message. Maybe the create_pull_request can create the clickable URLs in the email based on that information.
Thanks,
Nitin
Quoted 9 lines
Quoted 2 lines
+CFLAGS_append += " -O"
Thanks,
--
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel
Re: [bugfix 1/1] mesa-xlib: workaround gcc 4.6.0 ICE
In reply to [email protected]Quoted 9 lines · On Thu, 2011-05-26 at 13:41 -0700, [email protected] wrote:
--- meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb | 3 +++ 1 files changed, 3 insertions(+), 0 deletions(-)meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb +0
-0
meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb PE = "1" · line 22
Quoted 6 lines
meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb +3
-0@@ -17,3 +17,6 @@ PE = "1" PR = "r0" EXTRA_OECONF += "--with-driver=xlib" + +# nullify -O2 +CFLAGS_append += " -O"
I talked about this on IRC but simply put, no way.
The problem is:
a) Arm specific
b) determined now to be armv7 specific
c) gcc version specific
and the fix should reflect this.
So ideally when we select gcc 4.6 in tcmode-default.inc we should add something there which adds a work around for mesa-xlib.
I've suggested something like:
TARGET_CC_ARCH_arm_pn-mesa-xlib := "${@'${TARGET_CC_ARCH}'.replace('armv7','armv5')}"
which whilst ugly, should do what we need it to.
Cheers,
Richard
Re: [bugfix 1/1] mesa-xlib: workaround gcc 4.6.0 ICE
Quoted 28 lines · Richard Purdie
Quoted 12 lines · On Thu, 2011-05-26 at 13:41 -0700, [email protected] wrote:
---
meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb | 3 +++1 files changed, 3 insertions(+), 0 deletions(-)meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb +0
-0@@ -17,3 +17,6 @@ PE = "1"PR = "r0"
EXTRA_OECONF += "--with-driver=xlib"
meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb PE = "1" · line 22
Quoted 3 lines
meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb +3
-0+ +# nullify -O2 +CFLAGS_append += " -O"I talked about this on IRC but simply put, no way.
The problem is:
a) Arm specific
b) determined now to be armv7 specific
c) gcc version specificand the fix should reflect this.
Quoted 9 lines
So ideally when we select gcc 4.6 in tcmode-default.inc we should add something there which adds a work around for mesa-xlib.
I've suggested something like:
TARGET_CC_ARCH_arm_pn-mesa-xlib := "${@'${TARGET_CC_ARCH}'.replace('armv7','armv5')}"
which whilst ugly, should do what we need it to.
I agree with this solution however ugly it may look like. We may document it to explain
the ugliness
Quoted 11 lines
Cheers,
Richard
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [bugfix 1/1] mesa-xlib: workaround gcc 4.6.0 ICE
Quoted 47 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Khem Raj
Sent: Thursday, May 26, 2011 5:37 PM
To: Patches and discussions about the oe-core layer
Subject: Re: [OE-core] [bugfix 1/1] mesa-xlib: workaround gcc 4.6.0 ICEQuoted 7 lines · Richard Purdie
Review
Quoted 5 lines · On Thu, 2011-05-26 at 13:41 -0700, [email protected] wrote:
---
meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb | 3 +++1 files changed, 3 insertions(+), 0 deletions(-)(quoted diff) +0
-0b/meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb
Quoted 19 lines
meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb PE = "1" · line 22
Quoted 10 lines
index b77df2c..051bd72 100644
meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb +0
-0@@ -17,3 +17,6 @@ PE = "1"PR = "r0"
EXTRA_OECONF += "--with-driver=xlib"
meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb +3
-0+ +# nullify -O2 +CFLAGS_append += " -O"I talked about this on IRC but simply put, no way.
The problem is:
a) Arm specific
b) determined now to be armv7 specific
c) gcc version specificQuoted 8 lines
and the fix should reflect this.
So ideally when we select gcc 4.6 in tcmode-default.inc we should add something there which adds a work around for mesa-xlib.
I've suggested something like:
TARGET_CC_ARCH_arm_pn-mesa-xlib :=
Quoted 8 lines
"${@'${TARGET_CC_ARCH}'.replace('armv7','armv5')}"
Quoted 3 lines
which whilst ugly, should do what we need it to.
I agree with this solution however ugly it may look like. We may document it to explain
the ugliness
This commit wentin yocto branch http://git.pokylinux.org/cgit/cgit.cgi/poky/commit/?id=9bccbc5fbc71b331911b558a2ba15e0a6d0046b4
With this documentation:
+# Temporary workaround for gcc 4.6.0 ICE with beagleboard
+# gcc bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47719
+TARGET_CC_ARCH_arm_pn-mesa-xlib := "${@'${TARGET_CC_ARCH}'.replace('armv7-a','armv5')}" +
Thanks,
Nitin
Quoted 17 lines
Quoted 12 lines
Cheers,
Richard
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Re: [bugfix 1/1] mesa-xlib: workaround gcc 4.6.0 ICE
In reply to Richard PurdieOp 27 mei 2011, om 01:33 heeft Richard Purdie het volgende geschreven:
Quoted 28 lines · On Thu, 2011-05-26 at 13:41 -0700, [email protected] wrote:
Quoted 13 lines
---
meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb | 3 +++1 files changed, 3 insertions(+), 0 deletions(-)meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb +0
-0@@ -17,3 +17,6 @@ PE = "1"PR = "r0"
EXTRA_OECONF+= "--with-driver=xlib"meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb PE = "1" · line 22
Quoted 3 lines
meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb +3
-0+ +# nullify -O2 +CFLAGS_append += " -O"I talked about this on IRC but simply put, no way.
The problem is:
a) Arm specific
b) determined now to be armv7 specific
c) gcc version specificand the fix should reflect this.
Quoted 8 lines
So ideally when we select gcc 4.6 in tcmode-default.inc we should add something there which adds a work around for mesa-xlib.
I've suggested something like:
TARGET_CC_ARCH_arm_pn-mesa-xlib := "${@'${TARGET_CC_ARCH}'.replace('armv7','armv5')}"
which whilst ugly, should do what we need it to.
So how do I opt out of that? I don't use gcc 4.6 and suddenly mesa gets compiled for a suboptimal architecture.
Re: [bugfix 1/1] mesa-xlib: workaround gcc 4.6.0 ICE
Quoted 10 lines · Koen Kooi
Op 27 mei 2011, om 01:33 heeft Richard Purdie het volgende geschreven:
Quoted 6 lines · On Thu, 2011-05-26 at 13:41 -0700, [email protected] wrote:
I've suggested something like:
TARGET_CC_ARCH_arm_pn-mesa-xlib := "${@'${TARGET_CC_ARCH}'.replace('armv7','armv5')}"
which whilst ugly, should do what we need it to.
So how do I opt out of that? I don't use gcc 4.6 and suddenly mesa gets compiled for a suboptimal architecture.
Good question. I guess you're just changing the gcc version but using the rest of that file?
This is a tricky problem as we do want to include that for anyone using gcc 4.6 as otherwise things break but as you say, can't impact someone using that file but changing its values.
I guess the solution will be to turn it into anonymous python checking if we're:
* using gcc 4.6
* building for arm
* using armv7 optimisations
* building mesa-xlib
The other way is to add a conditional to that statement on the gcc version variable which is perhaps going to be easiest.
Cheers,
Richard
Re: [bugfix 1/1] mesa-xlib: workaround gcc 4.6.0 ICE
Quoted 7 lines · Richard Purdie
Good question. I guess you're just changing the gcc version but using the rest of that file?
This is a tricky problem as we do want to include that for anyone using gcc 4.6 as otherwise things break but as you say, can't impact someone using that file but changing its values.
Quoted 8 lines
I guess the solution will be to turn it into anonymous python checking if we're:
* using gcc 4.6
* building for arm
* using armv7 optimisations
* building mesa-xlib
Can we not just patch gcc to fix the ice? That seems like it would be the best answer.
If that's difficult for some reason, and downgrading gcc isn't an option either for whatever reason, then it seems like the right thing is going to be to get mesa-xlib's do_configure() to sort it out.
I'm not sure that anonymous python is going to work since there is no particularly good and reliable method of determining ahead of time what version of gcc is going to end up being used for the build.
p.
Re: [bugfix 1/1] mesa-xlib: workaround gcc 4.6.0 ICE
Quoted 20 lines · Phil Blundell
Quoted 7 lines · Richard Purdie
Good question. I guess you're just changing the gcc version but using the rest of that file?
This is a tricky problem as we do want to include that for anyone using gcc 4.6 as otherwise things break but as you say, can't impact someone using that file but changing its values.
Quoted 8 lines
I guess the solution will be to turn it into anonymous python checking if we're:
* using gcc 4.6
* building for arm
* using armv7 optimisations
* building mesa-xlibCan we not just patch gcc to fix the ice? That seems like it would be the best answer.
Quoted 7 lines
If that's difficult for some reason, and downgrading gcc isn't an option either for whatever reason, then it seems like the right thing is going to be to get mesa-xlib's
do_configure()to sort it out.I'm not sure that anonymous python is going to work since there is no particularly good and reliable method of determining ahead of time what version of gcc is going to end up being used for the build.
I was thinking of the GCCVERSION variable which is used in that same file and is probably a valid thing to do in this specific case.
Anyhow, it looks like we have a fix for the ICE (Nitin confirmed it builds) which is much perferred and I'm going to wait for that, thanks :)
Richard
Re: [bugfix 1/1] mesa-xlib: workaround gcc 4.6.0 ICE
In reply to Richard PurdieQuoted 9 lines · Richard Purdie
I talked about this on IRC but simply put, no way.
The problem is:
a) Arm specific
b) determined now to be armv7 specific
c) gcc version specificand the fix should reflect this.
From a fairly superficial look at the crash I suspect you probably want something like:
arm.md renamed from arm.md~ +3 -1
@@ -4213,7 +4213,9 @@ uxth%?\\t%0, %1 ldr%(h%)\\t%0, %1" [(set_attr "type" "alu_shift,load_byte") - (set_attr "predicable" "yes")] + (set_attr "predicable" "yes") + (set_attr "pool_range" "*,256") + (set_attr "neg_pool_range" "*,244")] ) (define_insn "*arm_zero_extendhisi2addsi"
It also looks like this could happen on ARMv6 as well, for what that's worth, though I haven't tested to see whether it actually does or not.
p.
Re: [bugfix 1/1] mesa-xlib: workaround gcc 4.6.0 ICE
Phil,
With your patch gcc 4.6.0 is not hitting the internal compiler error for this particular case. I could not do runtime testing as I don't have the hw. IMO This is a good patch to send to gcc upstream.
Thanks,
Nitin
Quoted 47 lines
-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of Phil Blundell
Sent: Friday, May 27, 2011 8:07 AM
To: Patches and discussions about the oe-core layer
Subject: Re: [OE-core] [bugfix 1/1] mesa-xlib: workaround gcc 4.6.0 ICEQuoted 9 lines · Richard Purdie
I talked about this on IRC but simply put, no way.
The problem is:
a) Arm specific
b) determined now to be armv7 specific
c) gcc version specificand the fix should reflect this.
From a fairly superficial look at the crash I suspect you probably want something like:
arm.md renamed from arm.md~ +3
-1@@ -4213,7 +4213,9 @@ uxth%?\\t%0, %1 ldr%(h%)\\t%0, %1" [(set_attr "type" "alu_shift,load_byte") - (set_attr "predicable" "yes")] + (set_attr "predicable" "yes") + (set_attr "pool_range" "*,256") + (set_attr "neg_pool_range" "*,244")] ) (define_insn "*arm_zero_extendhisi2addsi"It also looks like this could happen on ARMv6 as well, for what that's worth, though I haven't tested to see whether it actually does or not.
p.
_______________________________________________
Openembedded-core mailing list
[email protected]
http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core