| Submitter | Nitin A Kamble |
|---|---|
| Date | May 26, 2011, 8:41 p.m. |
| Message ID | <03152273cac84eef23738c5f26c45b082194284f.1306442263.git.nitin.a.kamble@intel.com> |
| Download | mbox | patch |
| Permalink | /patch/4837/ |
| State | New, archived |
| Headers | show |
Comments
On 05/26/2011 01:41 PM, nitin.a.kamble@intel.com wrote: > From: Nitin A Kamble <nitin.a.kamble@intel.com> > > 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 > > Signed-off-by: Nitin A Kamble <nitin.a.kamble@intel.com> > --- > meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb | 3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb b/meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb > index b77df2c..051bd72 100644 > --- a/meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb > +++ b/meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb > @@ -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. > +CFLAGS_append += " -O" Thanks,
> > +# 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. > > 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 > > > +CFLAGS_append += " -O" > > Thanks, > > -- > Darren Hart > Intel Open Source Technology Center > Yocto Project - Linux Kernel
On Thu, 2011-05-26 at 13:41 -0700, nitin.a.kamble@intel.com wrote: > --- > meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb | 3 +++ > 1 files changed, 3 insertions(+), 0 deletions(-) > > diff --git a/meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb b/meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb > index b77df2c..051bd72 100644 > --- a/meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb > +++ b/meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb > @@ -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
On Thu, May 26, 2011 at 4:33 PM, Richard Purdie <richard.purdie@linuxfoundation.org> wrote: > On Thu, 2011-05-26 at 13:41 -0700, nitin.a.kamble@intel.com wrote: > >> --- >> meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb | 3 +++ >> 1 files changed, 3 insertions(+), 0 deletions(-) >> >> diff --git a/meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb b/meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb >> index b77df2c..051bd72 100644 >> --- a/meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb >> +++ b/meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb >> @@ -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. > I agree with this solution however ugly it may look like. We may document it to explain the ugliness > Cheers, > > Richard > > > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core >
> -----Original Message----- > From: openembedded-core-bounces@lists.openembedded.org > [mailto:openembedded-core-bounces@lists.openembedded.org] 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 ICE > > On Thu, May 26, 2011 at 4:33 PM, Richard Purdie > <richard.purdie@linuxfoundation.org> wrote: > > On Thu, 2011-05-26 at 13:41 -0700, nitin.a.kamble@intel.com wrote: > > > >> --- > >> meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb | 3 +++ > >> 1 files changed, 3 insertions(+), 0 deletions(-) > >> > >> diff --git a/meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb > b/meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb > >> index b77df2c..051bd72 100644 > >> --- a/meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb > >> +++ b/meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb > >> @@ -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. > > > > 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 > > > Cheers, > > > > Richard > > > > > > > > _______________________________________________ > > Openembedded-core mailing list > > Openembedded-core@lists.openembedded.org > > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core > > > > _______________________________________________ > Openembedded-core mailing list > Openembedded-core@lists.openembedded.org > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core
Op 27 mei 2011, om 01:33 heeft Richard Purdie het volgende geschreven: > On Thu, 2011-05-26 at 13:41 -0700, nitin.a.kamble@intel.com wrote: > >> --- >> meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb | 3 +++ >> 1 files changed, 3 insertions(+), 0 deletions(-) >> >> diff --git a/meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb b/meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb >> index b77df2c..051bd72 100644 >> --- a/meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb >> +++ b/meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb >> @@ -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. So how do I opt out of that? I don't use gcc 4.6 and suddenly mesa gets compiled for a suboptimal architecture.
On Fri, 2011-05-27 at 09:14 +0200, Koen Kooi wrote: > Op 27 mei 2011, om 01:33 heeft Richard Purdie het volgende geschreven: > > > On Thu, 2011-05-26 at 13:41 -0700, nitin.a.kamble@intel.com 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
On Fri, 2011-05-27 at 09:54 +0100, Richard Purdie wrote: > 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 > 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.
On Fri, 2011-05-27 at 10:30 +0100, Phil Blundell wrote: > On Fri, 2011-05-27 at 09:54 +0100, Richard Purdie wrote: > > 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 > > > > 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. 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
Patch
diff --git a/meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb b/meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb index b77df2c..051bd72 100644 --- a/meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb +++ b/meta/recipes-graphics/mesa/mesa-xlib_7.10.2.bb @@ -17,3 +17,6 @@ PE = "1" PR = "r0" EXTRA_OECONF += "--with-driver=xlib" + +# nullify -O2 +CFLAGS_append += " -O"