Patchwork [bugfix,1/1] mesa-xlib: workaround gcc 4.6.0 ICE

login
register
mail settings
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

Nitin A Kamble - May 26, 2011, 8:41 p.m.
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(-)
Darren Hart - May 26, 2011, 9:16 p.m.
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,
Nitin A Kamble - May 26, 2011, 9:22 p.m.
> > +# 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
Richard Purdie - May 26, 2011, 11:33 p.m.
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
Khem Raj - May 27, 2011, 12:37 a.m.
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
>
Nitin A Kamble - May 27, 2011, 1:03 a.m.
> -----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
Koen Kooi - May 27, 2011, 7:14 a.m.
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.
Richard Purdie - May 27, 2011, 8:54 a.m.
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
Phil Blundell - May 27, 2011, 9:30 a.m.
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.
Richard Purdie - May 27, 2011, 5:11 p.m.
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"