* Re: [bugfix 1/1] mesa-xlib: workaround gcc 4.6.0 ICE
2011-05-26 23:33 ` Richard Purdie
@ 2011-05-27 0:37 ` Khem Raj
2011-05-27 1:03 ` Kamble, Nitin A
2011-05-27 7:14 ` Koen Kooi
2011-05-27 15:06 ` Phil Blundell
2 siblings, 1 reply; 13+ messages in thread
From: Khem Raj @ 2011-05-27 0:37 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
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
>
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bugfix 1/1] mesa-xlib: workaround gcc 4.6.0 ICE
2011-05-27 0:37 ` Khem Raj
@ 2011-05-27 1:03 ` Kamble, Nitin A
0 siblings, 0 replies; 13+ messages in thread
From: Kamble, Nitin A @ 2011-05-27 1:03 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
> -----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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bugfix 1/1] mesa-xlib: workaround gcc 4.6.0 ICE
2011-05-26 23:33 ` Richard Purdie
2011-05-27 0:37 ` Khem Raj
@ 2011-05-27 7:14 ` Koen Kooi
2011-05-27 8:54 ` Richard Purdie
2011-05-27 15:06 ` Phil Blundell
2 siblings, 1 reply; 13+ messages in thread
From: Koen Kooi @ 2011-05-27 7:14 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bugfix 1/1] mesa-xlib: workaround gcc 4.6.0 ICE
2011-05-27 7:14 ` Koen Kooi
@ 2011-05-27 8:54 ` Richard Purdie
2011-05-27 9:30 ` Phil Blundell
0 siblings, 1 reply; 13+ messages in thread
From: Richard Purdie @ 2011-05-27 8:54 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bugfix 1/1] mesa-xlib: workaround gcc 4.6.0 ICE
2011-05-27 8:54 ` Richard Purdie
@ 2011-05-27 9:30 ` Phil Blundell
2011-05-27 17:11 ` Richard Purdie
0 siblings, 1 reply; 13+ messages in thread
From: Phil Blundell @ 2011-05-27 9:30 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bugfix 1/1] mesa-xlib: workaround gcc 4.6.0 ICE
2011-05-27 9:30 ` Phil Blundell
@ 2011-05-27 17:11 ` Richard Purdie
0 siblings, 0 replies; 13+ messages in thread
From: Richard Purdie @ 2011-05-27 17:11 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bugfix 1/1] mesa-xlib: workaround gcc 4.6.0 ICE
2011-05-26 23:33 ` Richard Purdie
2011-05-27 0:37 ` Khem Raj
2011-05-27 7:14 ` Koen Kooi
@ 2011-05-27 15:06 ` Phil Blundell
2011-05-27 17:13 ` Kamble, Nitin A
2 siblings, 1 reply; 13+ messages in thread
From: Phil Blundell @ 2011-05-27 15:06 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* Re: [bugfix 1/1] mesa-xlib: workaround gcc 4.6.0 ICE
2011-05-27 15:06 ` Phil Blundell
@ 2011-05-27 17:13 ` Kamble, Nitin A
0 siblings, 0 replies; 13+ messages in thread
From: Kamble, Nitin A @ 2011-05-27 17:13 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
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
^ permalink raw reply [flat|nested] 13+ messages in thread