[bugfix 0/1] workaround for gcc 4.6.0 issue on beagleboard

[bugfix 0/1] workaround for gcc 4.6.0 issue on beagleboard

[nitin.a.kamble]

From: Nitin A Kamble <nitin.a.kamble@intel.com>

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(-)

-- 
1.7.3.5

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

[nitin.a.kamble]

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
+CFLAGS_append += " -O"
-- 
1.7.3.5

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

[Darren Hart]

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,

-- 
Darren Hart
Intel Open Source Technology Center
Yocto Project - Linux Kernel

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

[Kamble, Nitin A]

> > +# 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

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

[Richard Purdie]

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

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

[Khem Raj]

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
>

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

[Kamble, Nitin A]

> -----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

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

[Koen Kooi]

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.

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

[Richard Purdie]

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

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

[Phil Blundell]

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.

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

[Phil Blundell]

On Fri, 2011-05-27 at 00:33 +0100, Richard Purdie wrote:
> 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.

From a fairly superficial look at the crash I suspect you probably want
something like:

--- arm.md~	2011-05-27 15:18:31.916926254 +0100
+++ arm.md	2011-05-27 15:31:57.331525688 +0100
@@ -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

[Richard Purdie]

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

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

[Kamble, Nitin A]

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


> -----Original Message-----
> From: openembedded-core-bounces@lists.openembedded.org
> [mailto:openembedded-core-bounces@lists.openembedded.org] 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 ICE
> 
> On Fri, 2011-05-27 at 00:33 +0100, Richard Purdie wrote:
> > 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.
> 
> From a fairly superficial look at the crash I suspect you probably want
> something like:
> 
> --- arm.md~	2011-05-27 15:18:31.916926254 +0100
> +++ arm.md	2011-05-27 15:31:57.331525688 +0100
> @@ -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
> Openembedded-core@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-core