GCC 4.9 considered evil

GCC 4.9 considered evil

[Gary Thomas]

I've found that the latest GCC doesn't work very well, at
least not on ARM (and obviously other architectures as well [1])
When I build Google Chromium browser for my i.MX boards using
GCC-4.9.x, no pages can be rendered - massive bloodshed and
failures are shown on the console.  If I use the older GCC 4.8.2,
everything else the same, all is well.

Here's my configuration:
BB_VERSION        = "1.23.1"
BUILD_SYS         = "x86_64-linux"
NATIVELSBSTRING   = "Ubuntu-13.10"
TARGET_SYS        = "arm-amltd-linux-gnueabi"
MACHINE           = "teton-p0382"
DISTRO            = "amltd"
DISTRO_VERSION    = "1.6+snapshot-20140812"
TUNE_FEATURES     = "arm armv7a vfp neon callconvention-hard cortexa9"
TARGET_FPU        = "vfp-neon"
meta              = "master:86afd7eb7c679eb065706137f28f44248f3fbc5a"
meta-amltd        = "master:899529b4184dc9e3e291e7fcdbbf157233db056d"
meta-teton-imx6-p0382 = "master:9188e2f8fafd203c95dcd7a3c79cb38a1568e9b5"
meta-fsl-arm      = "master:b0cf5c78c5f98c5977ae556d331e7495648f154c"
meta-fsl-arm-extra = "master:12e560967b7136222c325d11633295fe3a0c701c"
meta-browser      = "master:da93c8e386133a15eff1414d9307c8f2c7a44787"

Should this be filed as a bug?  I don't have much data other than it
simply breaks (and chrome is not the easiest thing to debug!).  Other
applications seem OK, but I am loathe to trust it...

I'm going to hold onto GCC-4.8.x for my $DISTRO at least (and I hope
it doesn't vanish like 4.7.x did too quickly).

[1] http://slashdot.org/story/14/07/27/1838219/linus-torvalds-gcc-490-seems-to-be-terminally-broken

Note: I've also tried this on qemux86 (a totally different
architecture) and chrome bombs just as badly!

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: GCC 4.9 considered evil

[Khem Raj]

On Wed, Aug 13, 2014 at 2:24 PM, Gary Thomas <gary@mlbassoc.com> wrote:
> I've found that the latest GCC doesn't work very well, at
> least not on ARM (and obviously other architectures as well [1])
> When I build Google Chromium browser for my i.MX boards using
> GCC-4.9.x, no pages can be rendered - massive bloodshed and
> failures are shown on the console.  If I use the older GCC 4.8.2,
> everything else the same, all is well.
>
> Here's my configuration:
> BB_VERSION        = "1.23.1"
> BUILD_SYS         = "x86_64-linux"
> NATIVELSBSTRING   = "Ubuntu-13.10"
> TARGET_SYS        = "arm-amltd-linux-gnueabi"
> MACHINE           = "teton-p0382"
> DISTRO            = "amltd"
> DISTRO_VERSION    = "1.6+snapshot-20140812"
> TUNE_FEATURES     = "arm armv7a vfp neon callconvention-hard cortexa9"
> TARGET_FPU        = "vfp-neon"
> meta              = "master:86afd7eb7c679eb065706137f28f44248f3fbc5a"
> meta-amltd        = "master:899529b4184dc9e3e291e7fcdbbf157233db056d"
> meta-teton-imx6-p0382 = "master:9188e2f8fafd203c95dcd7a3c79cb38a1568e9b5"
> meta-fsl-arm      = "master:b0cf5c78c5f98c5977ae556d331e7495648f154c"
> meta-fsl-arm-extra = "master:12e560967b7136222c325d11633295fe3a0c701c"
> meta-browser      = "master:da93c8e386133a15eff1414d9307c8f2c7a44787"
>
> Should this be filed as a bug?  I don't have much data other than it
> simply breaks (and chrome is not the easiest thing to debug!).  Other
> applications seem OK, but I am loathe to trust it...

You need to provide more info to get any traction on this. If you can
narrow it down more that will be helpful.

>
> I'm going to hold onto GCC-4.8.x for my $DISTRO at least (and I hope
> it doesn't vanish like 4.7.x did too quickly).
>
> [1]
> http://slashdot.org/story/14/07/27/1838219/linus-torvalds-gcc-490-seems-to-be-terminally-broken
>

thats probably unrelated to what you are seeing.

> Note: I've also tried this on qemux86 (a totally different
> architecture) and chrome bombs just as badly!
>
> --
> ------------------------------------------------------------
> Gary Thomas                 |  Consulting for the
> MLB Associates              |    Embedded world
> ------------------------------------------------------------
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-core

Re: GCC 4.9 considered evil

[Otavio Salvador]

On Wed, Aug 13, 2014 at 6:24 PM, Gary Thomas <gary@mlbassoc.com> wrote:
> I've found that the latest GCC doesn't work very well, at
> least not on ARM (and obviously other architectures as well [1])
> When I build Google Chromium browser for my i.MX boards using
> GCC-4.9.x, no pages can be rendered - massive bloodshed and
> failures are shown on the console.  If I use the older GCC 4.8.2,
> everything else the same, all is well.
>
> Here's my configuration:
> BB_VERSION        = "1.23.1"
> BUILD_SYS         = "x86_64-linux"
> NATIVELSBSTRING   = "Ubuntu-13.10"
> TARGET_SYS        = "arm-amltd-linux-gnueabi"
> MACHINE           = "teton-p0382"
> DISTRO            = "amltd"
> DISTRO_VERSION    = "1.6+snapshot-20140812"
> TUNE_FEATURES     = "arm armv7a vfp neon callconvention-hard cortexa9"
> TARGET_FPU        = "vfp-neon"
> meta              = "master:86afd7eb7c679eb065706137f28f44248f3fbc5a"
> meta-amltd        = "master:899529b4184dc9e3e291e7fcdbbf157233db056d"
> meta-teton-imx6-p0382 = "master:9188e2f8fafd203c95dcd7a3c79cb38a1568e9b5"
> meta-fsl-arm      = "master:b0cf5c78c5f98c5977ae556d331e7495648f154c"
> meta-fsl-arm-extra = "master:12e560967b7136222c325d11633295fe3a0c701c"
> meta-browser      = "master:da93c8e386133a15eff1414d9307c8f2c7a44787"
>
> Should this be filed as a bug?  I don't have much data other than it
> simply breaks (and chrome is not the easiest thing to debug!).  Other
> applications seem OK, but I am loathe to trust it...
>
> I'm going to hold onto GCC-4.8.x for my $DISTRO at least (and I hope
> it doesn't vanish like 4.7.x did too quickly).
>
> [1]
> http://slashdot.org/story/14/07/27/1838219/linus-torvalds-gcc-490-seems-to-be-terminally-broken
>
> Note: I've also tried this on qemux86 (a totally different
> architecture) and chrome bombs just as badly!

I confirm that GCC 4.9 does NOT work for Chromium 35. At this moment I
am not aware of any fix for it.

IIRC the Chromium 37 works though.

-- 
Otavio Salvador                             O.S. Systems
http://www.ossystems.com.br        http://code.ossystems.com.br
Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750

Re: GCC 4.9 considered evil

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 2759 bytes --]

On Wednesday, August 13, 2014, Otavio Salvador <otavio@ossystems.com.br>
wrote:

> On Wed, Aug 13, 2014 at 6:24 PM, Gary Thomas <gary@mlbassoc.com
> <javascript:;>> wrote:
> > I've found that the latest GCC doesn't work very well, at
> > least not on ARM (and obviously other architectures as well [1])
> > When I build Google Chromium browser for my i.MX boards using
> > GCC-4.9.x, no pages can be rendered - massive bloodshed and
> > failures are shown on the console.  If I use the older GCC 4.8.2,
> > everything else the same, all is well.
> >
> > Here's my configuration:
> > BB_VERSION        = "1.23.1"
> > BUILD_SYS         = "x86_64-linux"
> > NATIVELSBSTRING   = "Ubuntu-13.10"
> > TARGET_SYS        = "arm-amltd-linux-gnueabi"
> > MACHINE           = "teton-p0382"
> > DISTRO            = "amltd"
> > DISTRO_VERSION    = "1.6+snapshot-20140812"
> > TUNE_FEATURES     = "arm armv7a vfp neon callconvention-hard cortexa9"
> > TARGET_FPU        = "vfp-neon"
> > meta              = "master:86afd7eb7c679eb065706137f28f44248f3fbc5a"
> > meta-amltd        = "master:899529b4184dc9e3e291e7fcdbbf157233db056d"
> > meta-teton-imx6-p0382 = "master:9188e2f8fafd203c95dcd7a3c79cb38a1568e9b5"
> > meta-fsl-arm      = "master:b0cf5c78c5f98c5977ae556d331e7495648f154c"
> > meta-fsl-arm-extra = "master:12e560967b7136222c325d11633295fe3a0c701c"
> > meta-browser      = "master:da93c8e386133a15eff1414d9307c8f2c7a44787"
> >
> > Should this be filed as a bug?  I don't have much data other than it
> > simply breaks (and chrome is not the easiest thing to debug!).  Other
> > applications seem OK, but I am loathe to trust it...
> >
> > I'm going to hold onto GCC-4.8.x for my $DISTRO at least (and I hope
> > it doesn't vanish like 4.7.x did too quickly).
> >
> > [1]
> >
> http://slashdot.org/story/14/07/27/1838219/linus-torvalds-gcc-490-seems-to-be-terminally-broken
> >
> > Note: I've also tried this on qemux86 (a totally different
> > architecture) and chrome bombs just as badly!
>
> I confirm that GCC 4.9 does NOT work for Chromium 35. At this moment I
> am not aware of any fix for it.


Again Its a broad brush statement. Something concrete is needed if
some.action is to taken

>
> IIRC the Chromium 37 works though.
>
>
Well then its less chance.that someone will fix 35

> --
> Otavio Salvador                             O.S. Systems
> http://www.ossystems.com.br        http://code.ossystems.com.br
> Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750
> --
> _______________________________________________
> Openembedded-core mailing list
> Openembedded-core@lists.openembedded.org <javascript:;>
> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>

[-- Attachment #2: Type: text/html, Size: 4185 bytes --]

Re: GCC 4.9 considered evil

[Carlos Rafael Giani]

[-- Attachment #1: Type: text/plain, Size: 4020 bytes --]

On 08/14/2014 02:46 AM, Khem Raj wrote:
>
>
> On Wednesday, August 13, 2014, Otavio Salvador 
> <otavio@ossystems.com.br <mailto:otavio@ossystems.com.br>> wrote:
>
>     On Wed, Aug 13, 2014 at 6:24 PM, Gary Thomas <gary@mlbassoc.com
>     <javascript:;>> wrote:
>     > I've found that the latest GCC doesn't work very well, at
>     > least not on ARM (and obviously other architectures as well [1])
>     > When I build Google Chromium browser for my i.MX boards using
>     > GCC-4.9.x, no pages can be rendered - massive bloodshed and
>     > failures are shown on the console.  If I use the older GCC 4.8.2,
>     > everything else the same, all is well.
>     >
>     > Here's my configuration:
>     > BB_VERSION        = "1.23.1"
>     > BUILD_SYS         = "x86_64-linux"
>     > NATIVELSBSTRING   = "Ubuntu-13.10"
>     > TARGET_SYS        = "arm-amltd-linux-gnueabi"
>     > MACHINE           = "teton-p0382"
>     > DISTRO            = "amltd"
>     > DISTRO_VERSION    = "1.6+snapshot-20140812"
>     > TUNE_FEATURES     = "arm armv7a vfp neon callconvention-hard
>     cortexa9"
>     > TARGET_FPU        = "vfp-neon"
>     > meta              =
>     "master:86afd7eb7c679eb065706137f28f44248f3fbc5a"
>     > meta-amltd        =
>     "master:899529b4184dc9e3e291e7fcdbbf157233db056d"
>     > meta-teton-imx6-p0382 =
>     "master:9188e2f8fafd203c95dcd7a3c79cb38a1568e9b5"
>     > meta-fsl-arm      =
>     "master:b0cf5c78c5f98c5977ae556d331e7495648f154c"
>     > meta-fsl-arm-extra =
>     "master:12e560967b7136222c325d11633295fe3a0c701c"
>     > meta-browser      =
>     "master:da93c8e386133a15eff1414d9307c8f2c7a44787"
>     >
>     > Should this be filed as a bug?  I don't have much data other than it
>     > simply breaks (and chrome is not the easiest thing to debug!).
>      Other
>     > applications seem OK, but I am loathe to trust it...
>     >
>     > I'm going to hold onto GCC-4.8.x for my $DISTRO at least (and I hope
>     > it doesn't vanish like 4.7.x did too quickly).
>     >
>     > [1]
>     >
>     http://slashdot.org/story/14/07/27/1838219/linus-torvalds-gcc-490-seems-to-be-terminally-broken
>     >
>     > Note: I've also tried this on qemux86 (a totally different
>     > architecture) and chrome bombs just as badly!
>
>     I confirm that GCC 4.9 does NOT work for Chromium 35. At this moment I
>     am not aware of any fix for it.
>
>
> Again Its a broad brush statement. Something concrete is needed if 
> some.action is to taken
>
>
>     IIRC the Chromium 37 works though.
>
>
> Well then its less chance.that someone will fix 35
>
>     --
>     Otavio Salvador                             O.S. Systems
>     http://www.ossystems.com.br http://code.ossystems.com.br
>     Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750
>     --
>     _______________________________________________
>     Openembedded-core mailing list
>     Openembedded-core@lists.openembedded.org <javascript:;>
>     http://lists.openembedded.org/mailman/listinfo/openembedded-core
>
>
>


The problem is that narrowing down is very difficult, since the problems 
manifest themselves as seemingly random stack corruptions. I have tried 
to dig into it, but got nowhere. Pointers suddenly became null for no 
apparent reason, or were corrupted, free() calls failed, values on the 
stack suddenly changed without being modified by the code etc.

I wouldn't rule out that Linus Torvald's find isn't the cause here. Look 
at this part of his message:

"The x86-64 ABI specifies a 128-byte red-zone under the stack pointer, 
and this is ok by that limit. It looks like it's illegal (136 > 128), 
but the fact is, we've had four "pushq"s to update %rsp since loading 
the frame pointer, so it's just *barely* legal with the red-zoning."

Perhaps gcc is pushing further outside of the red zone bounds, thus 
causing the problems. No idea how to check for that at the moment though.

[-- Attachment #2: Type: text/html, Size: 6825 bytes --]

Re: GCC 4.9 considered evil

[Peter A. Bigot]

[-- Attachment #1: Type: text/plain, Size: 4637 bytes --]

On 08/14/2014 03:12 AM, Carlos Rafael Giani wrote:
> On 08/14/2014 02:46 AM, Khem Raj wrote:
>>
>>
>> On Wednesday, August 13, 2014, Otavio Salvador 
>> <otavio@ossystems.com.br <mailto:otavio@ossystems.com.br>> wrote:
>>
>>     On Wed, Aug 13, 2014 at 6:24 PM, Gary Thomas <gary@mlbassoc.com
>>     <javascript:;>> wrote:
>>     > I've found that the latest GCC doesn't work very well, at
>>     > least not on ARM (and obviously other architectures as well [1])
>>     > When I build Google Chromium browser for my i.MX boards using
>>     > GCC-4.9.x, no pages can be rendered - massive bloodshed and
>>     > failures are shown on the console.  If I use the older GCC 4.8.2,
>>     > everything else the same, all is well.
>>     >
>>     > Here's my configuration:
>>     > BB_VERSION        = "1.23.1"
>>     > BUILD_SYS         = "x86_64-linux"
>>     > NATIVELSBSTRING   = "Ubuntu-13.10"
>>     > TARGET_SYS        = "arm-amltd-linux-gnueabi"
>>     > MACHINE           = "teton-p0382"
>>     > DISTRO            = "amltd"
>>     > DISTRO_VERSION    = "1.6+snapshot-20140812"
>>     > TUNE_FEATURES     = "arm armv7a vfp neon callconvention-hard
>>     cortexa9"
>>     > TARGET_FPU        = "vfp-neon"
>>     > meta              =
>>     "master:86afd7eb7c679eb065706137f28f44248f3fbc5a"
>>     > meta-amltd        =
>>     "master:899529b4184dc9e3e291e7fcdbbf157233db056d"
>>     > meta-teton-imx6-p0382 =
>>     "master:9188e2f8fafd203c95dcd7a3c79cb38a1568e9b5"
>>     > meta-fsl-arm      =
>>     "master:b0cf5c78c5f98c5977ae556d331e7495648f154c"
>>     > meta-fsl-arm-extra =
>>     "master:12e560967b7136222c325d11633295fe3a0c701c"
>>     > meta-browser      =
>>     "master:da93c8e386133a15eff1414d9307c8f2c7a44787"
>>     >
>>     > Should this be filed as a bug?  I don't have much data other
>>     than it
>>     > simply breaks (and chrome is not the easiest thing to debug!).
>>      Other
>>     > applications seem OK, but I am loathe to trust it...
>>     >
>>     > I'm going to hold onto GCC-4.8.x for my $DISTRO at least (and I
>>     hope
>>     > it doesn't vanish like 4.7.x did too quickly).
>>     >
>>     > [1]
>>     >
>>     http://slashdot.org/story/14/07/27/1838219/linus-torvalds-gcc-490-seems-to-be-terminally-broken
>>     >
>>     > Note: I've also tried this on qemux86 (a totally different
>>     > architecture) and chrome bombs just as badly!
>>
>>     I confirm that GCC 4.9 does NOT work for Chromium 35. At this
>>     moment I
>>     am not aware of any fix for it.
>>
>>
>> Again Its a broad brush statement. Something concrete is needed if 
>> some.action is to taken
>>
>>
>>     IIRC the Chromium 37 works though.
>>
>>
>> Well then its less chance.that someone will fix 35
>>
>>     --
>>     Otavio Salvador                             O.S. Systems
>>     http://www.ossystems.com.br http://code.ossystems.com.br
>>     Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750
>>     --
>>     _______________________________________________
>>     Openembedded-core mailing list
>>     Openembedded-core@lists.openembedded.org <javascript:;>
>>     http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>
>>
>>
>
>
> The problem is that narrowing down is very difficult, since the 
> problems manifest themselves as seemingly random stack corruptions. I 
> have tried to dig into it, but got nowhere. Pointers suddenly became 
> null for no apparent reason, or were corrupted, free() calls failed, 
> values on the stack suddenly changed without being modified by the 
> code etc.
>
> I wouldn't rule out that Linus Torvald's find isn't the cause here. 
> Look at this part of his message:
>
> "The x86-64 ABI specifies a 128-byte red-zone under the stack pointer, 
> and this is ok by that limit. It looks like it's illegal (136 > 128), 
> but the fact is, we've had four "pushq"s to update %rsp since loading 
> the frame pointer, so it's just *barely* legal with the red-zoning."
>
> Perhaps gcc is pushing further outside of the red zone bounds, thus 
> causing the problems. No idea how to check for that at the moment though.

Simplest would be to apply the upstream fix to Yocto's gcc and see if 
that helps.  You'd want commit 556537c4ad0df4cbebb74197bb2bdea75cf5dd35 
from git://gcc.gnu.org/git/gcc.git.  (The patch went into gcc-4_9-branch 
one day after 4.9.1 was released.)

I'd add it to the current set but ATT Khem and I both have pending 
patches that touch the same gcc files, so it'd just increase the conflicts.

Peter

>
>


[-- Attachment #2: Type: text/html, Size: 7715 bytes --]

Re: GCC 4.9 considered evil

[Carlos Rafael Giani]

[-- Attachment #1: Type: text/plain, Size: 5489 bytes --]

On 08/14/2014 10:22 AM, Peter A. Bigot wrote:
> On 08/14/2014 03:12 AM, Carlos Rafael Giani wrote:
>> On 08/14/2014 02:46 AM, Khem Raj wrote:
>>>
>>>
>>> On Wednesday, August 13, 2014, Otavio Salvador 
>>> <otavio@ossystems.com.br <mailto:otavio@ossystems.com.br>> wrote:
>>>
>>>     On Wed, Aug 13, 2014 at 6:24 PM, Gary Thomas <gary@mlbassoc.com
>>>     <javascript:;>> wrote:
>>>     > I've found that the latest GCC doesn't work very well, at
>>>     > least not on ARM (and obviously other architectures as well [1])
>>>     > When I build Google Chromium browser for my i.MX boards using
>>>     > GCC-4.9.x, no pages can be rendered - massive bloodshed and
>>>     > failures are shown on the console.  If I use the older GCC 4.8.2,
>>>     > everything else the same, all is well.
>>>     >
>>>     > Here's my configuration:
>>>     > BB_VERSION        = "1.23.1"
>>>     > BUILD_SYS         = "x86_64-linux"
>>>     > NATIVELSBSTRING   = "Ubuntu-13.10"
>>>     > TARGET_SYS        = "arm-amltd-linux-gnueabi"
>>>     > MACHINE           = "teton-p0382"
>>>     > DISTRO            = "amltd"
>>>     > DISTRO_VERSION    = "1.6+snapshot-20140812"
>>>     > TUNE_FEATURES     = "arm armv7a vfp neon callconvention-hard
>>>     cortexa9"
>>>     > TARGET_FPU        = "vfp-neon"
>>>     > meta              =
>>>     "master:86afd7eb7c679eb065706137f28f44248f3fbc5a"
>>>     > meta-amltd        =
>>>     "master:899529b4184dc9e3e291e7fcdbbf157233db056d"
>>>     > meta-teton-imx6-p0382 =
>>>     "master:9188e2f8fafd203c95dcd7a3c79cb38a1568e9b5"
>>>     > meta-fsl-arm      =
>>>     "master:b0cf5c78c5f98c5977ae556d331e7495648f154c"
>>>     > meta-fsl-arm-extra =
>>>     "master:12e560967b7136222c325d11633295fe3a0c701c"
>>>     > meta-browser      =
>>>     "master:da93c8e386133a15eff1414d9307c8f2c7a44787"
>>>     >
>>>     > Should this be filed as a bug?  I don't have much data other
>>>     than it
>>>     > simply breaks (and chrome is not the easiest thing to debug!).
>>>      Other
>>>     > applications seem OK, but I am loathe to trust it...
>>>     >
>>>     > I'm going to hold onto GCC-4.8.x for my $DISTRO at least (and
>>>     I hope
>>>     > it doesn't vanish like 4.7.x did too quickly).
>>>     >
>>>     > [1]
>>>     >
>>>     http://slashdot.org/story/14/07/27/1838219/linus-torvalds-gcc-490-seems-to-be-terminally-broken
>>>     >
>>>     > Note: I've also tried this on qemux86 (a totally different
>>>     > architecture) and chrome bombs just as badly!
>>>
>>>     I confirm that GCC 4.9 does NOT work for Chromium 35. At this
>>>     moment I
>>>     am not aware of any fix for it.
>>>
>>>
>>> Again Its a broad brush statement. Something concrete is needed if 
>>> some.action is to taken
>>>
>>>
>>>     IIRC the Chromium 37 works though.
>>>
>>>
>>> Well then its less chance.that someone will fix 35
>>>
>>>     --
>>>     Otavio Salvador                             O.S. Systems
>>>     http://www.ossystems.com.br http://code.ossystems.com.br
>>>     Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750
>>>     --
>>>     _______________________________________________
>>>     Openembedded-core mailing list
>>>     Openembedded-core@lists.openembedded.org <javascript:;>
>>>     http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>>
>>>
>>>
>>
>>
>> The problem is that narrowing down is very difficult, since the 
>> problems manifest themselves as seemingly random stack corruptions. I 
>> have tried to dig into it, but got nowhere. Pointers suddenly became 
>> null for no apparent reason, or were corrupted, free() calls failed, 
>> values on the stack suddenly changed without being modified by the 
>> code etc.
>>
>> I wouldn't rule out that Linus Torvald's find isn't the cause here. 
>> Look at this part of his message:
>>
>> "The x86-64 ABI specifies a 128-byte red-zone under the stack 
>> pointer, and this is ok by that limit. It looks like it's illegal 
>> (136 > 128), but the fact is, we've had four "pushq"s to update %rsp 
>> since loading the frame pointer, so it's just *barely* legal with the 
>> red-zoning."
>>
>> Perhaps gcc is pushing further outside of the red zone bounds, thus 
>> causing the problems. No idea how to check for that at the moment though.
>
> Simplest would be to apply the upstream fix to Yocto's gcc and see if 
> that helps.  You'd want commit 
> 556537c4ad0df4cbebb74197bb2bdea75cf5dd35 from 
> git://gcc.gnu.org/git/gcc.git.  (The patch went into gcc-4_9-branch 
> one day after 4.9.1 was released.)
>
> I'd add it to the current set but ATT Khem and I both have pending 
> patches that touch the same gcc files, so it'd just increase the 
> conflicts.
>
> Peter
>
>>
>>
>
>
>



To further elaborate, the Chromium developers know about problems with 
GCC 4.9. Here is an example: 
https://code.google.com/p/chromium/issues/detail?id=385729

Note that while a build of Chromium 37 works, I've had internal compiler 
errors happen. I actually had to re-run the run.do_compile script about 
30 times until the build finished (the ICE's happen only sometimes, so 
repeated attempts at compiling eventually yields a result.)

Thanks for the link. I'll try it out when I have the time. Aside from 
that, I recommend to keep the GCC 4.8 recipes for the time being. At 
least they should not be removed as quickly as the 4.7 ones.

[-- Attachment #2: Type: text/html, Size: 9665 bytes --]

Re: GCC 4.9 considered evil

[Peter A. Bigot]

[-- Attachment #1: Type: text/plain, Size: 6052 bytes --]

On 08/14/2014 03:24 AM, Carlos Rafael Giani wrote:
> On 08/14/2014 10:22 AM, Peter A. Bigot wrote:
>> On 08/14/2014 03:12 AM, Carlos Rafael Giani wrote:
>>> On 08/14/2014 02:46 AM, Khem Raj wrote:
>>>>
>>>>
>>>> On Wednesday, August 13, 2014, Otavio Salvador 
>>>> <otavio@ossystems.com.br <mailto:otavio@ossystems.com.br>> wrote:
>>>>
>>>>     On Wed, Aug 13, 2014 at 6:24 PM, Gary Thomas <gary@mlbassoc.com
>>>>     <javascript:;>> wrote:
>>>>     > I've found that the latest GCC doesn't work very well, at
>>>>     > least not on ARM (and obviously other architectures as well [1])
>>>>     > When I build Google Chromium browser for my i.MX boards using
>>>>     > GCC-4.9.x, no pages can be rendered - massive bloodshed and
>>>>     > failures are shown on the console.  If I use the older GCC 4.8.2,
>>>>     > everything else the same, all is well.
>>>>     >
>>>>     > Here's my configuration:
>>>>     > BB_VERSION        = "1.23.1"
>>>>     > BUILD_SYS         = "x86_64-linux"
>>>>     > NATIVELSBSTRING   = "Ubuntu-13.10"
>>>>     > TARGET_SYS        = "arm-amltd-linux-gnueabi"
>>>>     > MACHINE           = "teton-p0382"
>>>>     > DISTRO            = "amltd"
>>>>     > DISTRO_VERSION    = "1.6+snapshot-20140812"
>>>>     > TUNE_FEATURES     = "arm armv7a vfp neon callconvention-hard
>>>>     cortexa9"
>>>>     > TARGET_FPU        = "vfp-neon"
>>>>     > meta              =
>>>>     "master:86afd7eb7c679eb065706137f28f44248f3fbc5a"
>>>>     > meta-amltd        =
>>>>     "master:899529b4184dc9e3e291e7fcdbbf157233db056d"
>>>>     > meta-teton-imx6-p0382 =
>>>>     "master:9188e2f8fafd203c95dcd7a3c79cb38a1568e9b5"
>>>>     > meta-fsl-arm      =
>>>>     "master:b0cf5c78c5f98c5977ae556d331e7495648f154c"
>>>>     > meta-fsl-arm-extra =
>>>>     "master:12e560967b7136222c325d11633295fe3a0c701c"
>>>>     > meta-browser      =
>>>>     "master:da93c8e386133a15eff1414d9307c8f2c7a44787"
>>>>     >
>>>>     > Should this be filed as a bug?  I don't have much data other
>>>>     than it
>>>>     > simply breaks (and chrome is not the easiest thing to
>>>>     debug!).  Other
>>>>     > applications seem OK, but I am loathe to trust it...
>>>>     >
>>>>     > I'm going to hold onto GCC-4.8.x for my $DISTRO at least (and
>>>>     I hope
>>>>     > it doesn't vanish like 4.7.x did too quickly).
>>>>     >
>>>>     > [1]
>>>>     >
>>>>     http://slashdot.org/story/14/07/27/1838219/linus-torvalds-gcc-490-seems-to-be-terminally-broken
>>>>     >
>>>>     > Note: I've also tried this on qemux86 (a totally different
>>>>     > architecture) and chrome bombs just as badly!
>>>>
>>>>     I confirm that GCC 4.9 does NOT work for Chromium 35. At this
>>>>     moment I
>>>>     am not aware of any fix for it.
>>>>
>>>>
>>>> Again Its a broad brush statement. Something concrete is needed if 
>>>> some.action is to taken
>>>>
>>>>
>>>>     IIRC the Chromium 37 works though.
>>>>
>>>>
>>>> Well then its less chance.that someone will fix 35
>>>>
>>>>     --
>>>>     Otavio Salvador                             O.S. Systems
>>>>     http://www.ossystems.com.br http://code.ossystems.com.br
>>>>     Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750
>>>>     --
>>>>     _______________________________________________
>>>>     Openembedded-core mailing list
>>>>     Openembedded-core@lists.openembedded.org <javascript:;>
>>>>     http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>>>
>>>>
>>>>
>>>
>>>
>>> The problem is that narrowing down is very difficult, since the 
>>> problems manifest themselves as seemingly random stack corruptions. 
>>> I have tried to dig into it, but got nowhere. Pointers suddenly 
>>> became null for no apparent reason, or were corrupted, free() calls 
>>> failed, values on the stack suddenly changed without being modified 
>>> by the code etc.
>>>
>>> I wouldn't rule out that Linus Torvald's find isn't the cause here. 
>>> Look at this part of his message:
>>>
>>> "The x86-64 ABI specifies a 128-byte red-zone under the stack 
>>> pointer, and this is ok by that limit. It looks like it's illegal 
>>> (136 > 128), but the fact is, we've had four "pushq"s to update %rsp 
>>> since loading the frame pointer, so it's just *barely* legal with 
>>> the red-zoning."
>>>
>>> Perhaps gcc is pushing further outside of the red zone bounds, thus 
>>> causing the problems. No idea how to check for that at the moment 
>>> though.
>>
>> Simplest would be to apply the upstream fix to Yocto's gcc and see if 
>> that helps.  You'd want commit 
>> 556537c4ad0df4cbebb74197bb2bdea75cf5dd35 from 
>> git://gcc.gnu.org/git/gcc.git.  (The patch went into gcc-4_9-branch 
>> one day after 4.9.1 was released.)
>>
>> I'd add it to the current set but ATT Khem and I both have pending 
>> patches that touch the same gcc files, so it'd just increase the 
>> conflicts.
>>
>> Peter
>>
>>>
>>>
>>
>>
>>
>
>
>
> To further elaborate, the Chromium developers know about problems with 
> GCC 4.9. Here is an example: 
> https://code.google.com/p/chromium/issues/detail?id=385729

For what little comfort it might give, that one turns out to be a bug in 
Chromium that was exposed by GCC 4.9, not a GCC 4.9 bug. "Still, the 
root issue exists on every branch and it's sheer chance that most builds 
don't appear to be affected."

> Note that while a build of Chromium 37 works, I've had internal 
> compiler errors happen. I actually had to re-run the run.do_compile 
> script about 30 times until the build finished (the ICE's happen only 
> sometimes, so repeated attempts at compiling eventually yields a result.)
>
> Thanks for the link. I'll try it out when I have the time. Aside from 
> that, I recommend to keep the GCC 4.8 recipes for the time being. At 
> least they should not be removed as quickly as the 4.7 ones.

I'm adding the twisted-Torvalds'-knickers patch to both gcc 4.8 and 4.9 
in my gcc series.

Peter

[-- Attachment #2: Type: text/html, Size: 10512 bytes --]

Re: GCC 4.9 considered evil

[Gary Thomas]

On 2014-08-14 04:02, Peter A. Bigot wrote:
> On 08/14/2014 03:24 AM, Carlos Rafael Giani wrote:
>> On 08/14/2014 10:22 AM, Peter A. Bigot wrote:
>>> On 08/14/2014 03:12 AM, Carlos Rafael Giani wrote:
>>>> On 08/14/2014 02:46 AM, Khem Raj wrote:
>>>>>
>>>>>
>>>>> On Wednesday, August 13, 2014, Otavio Salvador <otavio@ossystems.com.br <mailto:otavio@ossystems.com.br>> wrote:
>>>>>
>>>>>     On Wed, Aug 13, 2014 at 6:24 PM, Gary Thomas <gary@mlbassoc.com <javascript:;>> wrote:
>>>>>     > I've found that the latest GCC doesn't work very well, at
>>>>>     > least not on ARM (and obviously other architectures as well [1])
>>>>>     > When I build Google Chromium browser for my i.MX boards using
>>>>>     > GCC-4.9.x, no pages can be rendered - massive bloodshed and
>>>>>     > failures are shown on the console.  If I use the older GCC 4.8.2,
>>>>>     > everything else the same, all is well.
>>>>>     >
>>>>>     > Here's my configuration:
>>>>>     > BB_VERSION        = "1.23.1"
>>>>>     > BUILD_SYS         = "x86_64-linux"
>>>>>     > NATIVELSBSTRING   = "Ubuntu-13.10"
>>>>>     > TARGET_SYS        = "arm-amltd-linux-gnueabi"
>>>>>     > MACHINE           = "teton-p0382"
>>>>>     > DISTRO            = "amltd"
>>>>>     > DISTRO_VERSION    = "1.6+snapshot-20140812"
>>>>>     > TUNE_FEATURES     = "arm armv7a vfp neon callconvention-hard cortexa9"
>>>>>     > TARGET_FPU        = "vfp-neon"
>>>>>     > meta              = "master:86afd7eb7c679eb065706137f28f44248f3fbc5a"
>>>>>     > meta-amltd        = "master:899529b4184dc9e3e291e7fcdbbf157233db056d"
>>>>>     > meta-teton-imx6-p0382 = "master:9188e2f8fafd203c95dcd7a3c79cb38a1568e9b5"
>>>>>     > meta-fsl-arm      = "master:b0cf5c78c5f98c5977ae556d331e7495648f154c"
>>>>>     > meta-fsl-arm-extra = "master:12e560967b7136222c325d11633295fe3a0c701c"
>>>>>     > meta-browser      = "master:da93c8e386133a15eff1414d9307c8f2c7a44787"
>>>>>     >
>>>>>     > Should this be filed as a bug?  I don't have much data other than it
>>>>>     > simply breaks (and chrome is not the easiest thing to debug!).  Other
>>>>>     > applications seem OK, but I am loathe to trust it...
>>>>>     >
>>>>>     > I'm going to hold onto GCC-4.8.x for my $DISTRO at least (and I hope
>>>>>     > it doesn't vanish like 4.7.x did too quickly).
>>>>>     >
>>>>>     > [1]
>>>>>     > http://slashdot.org/story/14/07/27/1838219/linus-torvalds-gcc-490-seems-to-be-terminally-broken
>>>>>     >
>>>>>     > Note: I've also tried this on qemux86 (a totally different
>>>>>     > architecture) and chrome bombs just as badly!
>>>>>
>>>>>     I confirm that GCC 4.9 does NOT work for Chromium 35. At this moment I
>>>>>     am not aware of any fix for it.
>>>>>
>>>>>
>>>>> Again Its a broad brush statement. Something concrete is needed if some.action is to taken
>>>>>
>>>>>
>>>>>     IIRC the Chromium 37 works though.
>>>>>
>>>>>
>>>>> Well then its less chance.that someone will fix 35
>>>>>
>>>>>     --
>>>>>     Otavio Salvador                             O.S. Systems
>>>>>     http://www.ossystems.com.br http://code.ossystems.com.br
>>>>>     Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750
>>>>>     --
>>>>>     _______________________________________________
>>>>>     Openembedded-core mailing list
>>>>>     Openembedded-core@lists.openembedded.org <javascript:;>
>>>>>     http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>>>>
>>>>>
>>>>>
>>>>
>>>>
>>>> The problem is that narrowing down is very difficult, since the problems manifest themselves as seemingly random stack corruptions. I have tried to dig into it, but got
>>>> nowhere. Pointers suddenly became null for no apparent reason, or were corrupted, free() calls failed, values on the stack suddenly changed without being modified by the code etc.
>>>>
>>>> I wouldn't rule out that Linus Torvald's find isn't the cause here. Look at this part of his message:
>>>>
>>>> "The x86-64 ABI specifies a 128-byte red-zone under the stack pointer, and this is ok by that limit. It looks like it's illegal (136 > 128), but the fact is, we've had four
>>>> "pushq"s to update %rsp since loading the frame pointer, so it's just *barely* legal with the red-zoning."
>>>>
>>>> Perhaps gcc is pushing further outside of the red zone bounds, thus causing the problems. No idea how to check for that at the moment though.
>>>
>>> Simplest would be to apply the upstream fix to Yocto's gcc and see if that helps.  You'd want commit 556537c4ad0df4cbebb74197bb2bdea75cf5dd35 from
>>> git://gcc.gnu.org/git/gcc.git.  (The patch went into gcc-4_9-branch one day after 4.9.1 was released.)
>>>
>>> I'd add it to the current set but ATT Khem and I both have pending patches that touch the same gcc files, so it'd just increase the conflicts.
>>>
>>> Peter
>>>
>>>>
>>>>
>>>
>>>
>>>
>>
>>
>>
>> To further elaborate, the Chromium developers know about problems with GCC 4.9. Here is an example: https://code.google.com/p/chromium/issues/detail?id=385729
>
> For what little comfort it might give, that one turns out to be a bug in Chromium that was exposed by GCC 4.9, not a GCC 4.9 bug. "Still, the root issue exists on every branch and
> it's sheer chance that most builds don't appear to be affected."
>
>> Note that while a build of Chromium 37 works, I've had internal compiler errors happen. I actually had to re-run the run.do_compile script about 30 times until the build finished
>> (the ICE's happen only sometimes, so repeated attempts at compiling eventually yields a result.)
>>
>> Thanks for the link. I'll try it out when I have the time. Aside from that, I recommend to keep the GCC 4.8 recipes for the time being. At least they should not be removed as
>> quickly as the 4.7 ones.
>
> I'm adding the twisted-Torvalds'-knickers patch to both gcc 4.8 and 4.9 in my gcc series.
>
> Peter
>

Fair enough.  I'm glad that I'm not the only one seeing such
issues (although I seem to have been the first to kick the hornet's
nest!).  My comments were not so much for "please fix this" as
they were "buyer beware".  I've seen problems with other tools
when built with GCC 4.9, e.g. midori also fails pretty badly on
at least one target but seems OK when built with 4.8, so for now
I'm sticking with the older compiler.

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: GCC 4.9 considered evil

[Martin Jansa]

[-- Attachment #1: Type: text/plain, Size: 13124 bytes --]

On Thu, Aug 14, 2014 at 10:24:29AM +0200, Carlos Rafael Giani wrote:
> On 08/14/2014 10:22 AM, Peter A. Bigot wrote:
> > On 08/14/2014 03:12 AM, Carlos Rafael Giani wrote:
> >> On 08/14/2014 02:46 AM, Khem Raj wrote:
> >>>
> >>>
> >>> On Wednesday, August 13, 2014, Otavio Salvador 
> >>> <otavio@ossystems.com.br <mailto:otavio@ossystems.com.br>> wrote:
> >>>
> >>>     On Wed, Aug 13, 2014 at 6:24 PM, Gary Thomas <gary@mlbassoc.com
> >>>     <javascript:;>> wrote:
> >>>     > I've found that the latest GCC doesn't work very well, at
> >>>     > least not on ARM (and obviously other architectures as well [1])
> >>>     > When I build Google Chromium browser for my i.MX boards using
> >>>     > GCC-4.9.x, no pages can be rendered - massive bloodshed and
> >>>     > failures are shown on the console.  If I use the older GCC 4.8.2,
> >>>     > everything else the same, all is well.
> >>>     >
> >>>     > Here's my configuration:
> >>>     > BB_VERSION        = "1.23.1"
> >>>     > BUILD_SYS         = "x86_64-linux"
> >>>     > NATIVELSBSTRING   = "Ubuntu-13.10"
> >>>     > TARGET_SYS        = "arm-amltd-linux-gnueabi"
> >>>     > MACHINE           = "teton-p0382"
> >>>     > DISTRO            = "amltd"
> >>>     > DISTRO_VERSION    = "1.6+snapshot-20140812"
> >>>     > TUNE_FEATURES     = "arm armv7a vfp neon callconvention-hard
> >>>     cortexa9"
> >>>     > TARGET_FPU        = "vfp-neon"
> >>>     > meta              =
> >>>     "master:86afd7eb7c679eb065706137f28f44248f3fbc5a"
> >>>     > meta-amltd        =
> >>>     "master:899529b4184dc9e3e291e7fcdbbf157233db056d"
> >>>     > meta-teton-imx6-p0382 =
> >>>     "master:9188e2f8fafd203c95dcd7a3c79cb38a1568e9b5"
> >>>     > meta-fsl-arm      =
> >>>     "master:b0cf5c78c5f98c5977ae556d331e7495648f154c"
> >>>     > meta-fsl-arm-extra =
> >>>     "master:12e560967b7136222c325d11633295fe3a0c701c"
> >>>     > meta-browser      =
> >>>     "master:da93c8e386133a15eff1414d9307c8f2c7a44787"
> >>>     >
> >>>     > Should this be filed as a bug?  I don't have much data other
> >>>     than it
> >>>     > simply breaks (and chrome is not the easiest thing to debug!).
> >>>      Other
> >>>     > applications seem OK, but I am loathe to trust it...
> >>>     >
> >>>     > I'm going to hold onto GCC-4.8.x for my $DISTRO at least (and
> >>>     I hope
> >>>     > it doesn't vanish like 4.7.x did too quickly).
> >>>     >
> >>>     > [1]
> >>>     >
> >>>     http://slashdot.org/story/14/07/27/1838219/linus-torvalds-gcc-490-seems-to-be-terminally-broken
> >>>     >
> >>>     > Note: I've also tried this on qemux86 (a totally different
> >>>     > architecture) and chrome bombs just as badly!
> >>>
> >>>     I confirm that GCC 4.9 does NOT work for Chromium 35. At this
> >>>     moment I
> >>>     am not aware of any fix for it.
> >>>
> >>>
> >>> Again Its a broad brush statement. Something concrete is needed if 
> >>> some.action is to taken
> >>>
> >>>
> >>>     IIRC the Chromium 37 works though.
> >>>
> >>>
> >>> Well then its less chance.that someone will fix 35
> >>>
> >>>     --
> >>>     Otavio Salvador                             O.S. Systems
> >>>     http://www.ossystems.com.br http://code.ossystems.com.br
> >>>     Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750
> >>>     --
> >>>     _______________________________________________
> >>>     Openembedded-core mailing list
> >>>     Openembedded-core@lists.openembedded.org <javascript:;>
> >>>     http://lists.openembedded.org/mailman/listinfo/openembedded-core
> >>>
> >>>
> >>>
> >>
> >>
> >> The problem is that narrowing down is very difficult, since the 
> >> problems manifest themselves as seemingly random stack corruptions. I 
> >> have tried to dig into it, but got nowhere. Pointers suddenly became 
> >> null for no apparent reason, or were corrupted, free() calls failed, 
> >> values on the stack suddenly changed without being modified by the 
> >> code etc.
> >>
> >> I wouldn't rule out that Linus Torvald's find isn't the cause here. 
> >> Look at this part of his message:
> >>
> >> "The x86-64 ABI specifies a 128-byte red-zone under the stack 
> >> pointer, and this is ok by that limit. It looks like it's illegal 
> >> (136 > 128), but the fact is, we've had four "pushq"s to update %rsp 
> >> since loading the frame pointer, so it's just *barely* legal with the 
> >> red-zoning."
> >>
> >> Perhaps gcc is pushing further outside of the red zone bounds, thus 
> >> causing the problems. No idea how to check for that at the moment though.
> >
> > Simplest would be to apply the upstream fix to Yocto's gcc and see if 
> > that helps.  You'd want commit 
> > 556537c4ad0df4cbebb74197bb2bdea75cf5dd35 from 
> > git://gcc.gnu.org/git/gcc.git.  (The patch went into gcc-4_9-branch 
> > one day after 4.9.1 was released.)
> >
> > I'd add it to the current set but ATT Khem and I both have pending 
> > patches that touch the same gcc files, so it'd just increase the 
> > conflicts.
> >
> > Peter
> >
> >>
> >>
> >
> >
> >
> 
> 
> 
> To further elaborate, the Chromium developers know about problems with 
> GCC 4.9. Here is an example: 
> https://code.google.com/p/chromium/issues/detail?id=385729
> 
> Note that while a build of Chromium 37 works, I've had internal compiler 
> errors happen. I actually had to re-run the run.do_compile script about 
> 30 times until the build finished (the ICE's happen only sometimes, so 
> repeated attempts at compiling eventually yields a result.)
> 
> Thanks for the link. I'll try it out when I have the time. Aside from 
> that, I recommend to keep the GCC 4.8 recipes for the time being. At 
> least they should not be removed as quickly as the 4.7 ones.

You're not seeing this with 37* chromium builds?

It's repeated in all world builds for some time.

| /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-ld.gold: warning: hidden symbol 'sqlite3_mprintf' in obj/third_party/sqlite/libsqlite3.a(obj/third_party/sqlite/amalgamation/sqlite.sqlite3.o) is referenced by DSO /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/qemux86-64/usr/lib/../lib/libsoftokn3.so
| /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-ld.gold: warning: hidden symbol 'sqlite3_exec' in obj/third_party/sqlite/libsqlite3.a(obj/third_party/sqlite/amalgamation/sqlite.sqlite3.o) is referenced by DSO /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/qemux86-64/usr/lib/../lib/libsoftokn3.so
| /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-ld.gold: warning: hidden symbol 'sqlite3_free' in obj/third_party/sqlite/libsqlite3.a(obj/third_party/sqlite/amalgamation/sqlite.sqlite3.o) is referenced by DSO /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/qemux86-64/usr/lib/../lib/libsoftokn3.so
| /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-ld.gold: warning: hidden symbol 'sqlite3_reset' in obj/third_party/sqlite/libsqlite3.a(obj/third_party/sqlite/amalgamation/sqlite.sqlite3.o) is referenced by DSO /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/qemux86-64/usr/lib/../lib/libsoftokn3.so
| /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-ld.gold: warning: hidden symbol 'sqlite3_finalize' in obj/third_party/sqlite/libsqlite3.a(obj/third_party/sqlite/amalgamation/sqlite.sqlite3.o) is referenced by DSO /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/qemux86-64/usr/lib/../lib/libsoftokn3.so
| /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-ld.gold: warning: hidden symbol 'sqlite3_close' in obj/third_party/sqlite/libsqlite3.a(obj/third_party/sqlite/amalgamation/sqlite.sqlite3.o) is referenced by DSO /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/qemux86-64/usr/lib/../lib/libsoftokn3.so
| /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-ld.gold: warning: hidden symbol 'sqlite3_step' in obj/third_party/sqlite/libsqlite3.a(obj/third_party/sqlite/amalgamation/sqlite.sqlite3.o) is referenced by DSO /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/qemux86-64/usr/lib/../lib/libsoftokn3.so
| /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-ld.gold: warning: hidden symbol 'sqlite3_column_int' in obj/third_party/sqlite/libsqlite3.a(obj/third_party/sqlite/amalgamation/sqlite.sqlite3.o) is referenced by DSO /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/qemux86-64/usr/lib/../lib/libsoftokn3.so
| /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-ld.gold: warning: hidden symbol 'sqlite3_prepare_v2' in obj/third_party/sqlite/libsqlite3.a(obj/third_party/sqlite/amalgamation/sqlite.sqlite3.o) is referenced by DSO /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/qemux86-64/usr/lib/../lib/libsoftokn3.so
| /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-ld.gold: warning: hidden symbol 'sqlite3_bind_blob' in obj/third_party/sqlite/libsqlite3.a(obj/third_party/sqlite/amalgamation/sqlite.sqlite3.o) is referenced by DSO /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/qemux86-64/usr/lib/../lib/libsoftokn3.so
| /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-ld.gold: warning: hidden symbol 'sqlite3_bind_int' in obj/third_party/sqlite/libsqlite3.a(obj/third_party/sqlite/amalgamation/sqlite.sqlite3.o) is referenced by DSO /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/qemux86-64/usr/lib/../lib/libsoftokn3.so
| /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-ld.gold: warning: hidden symbol 'sqlite3_bind_text' in obj/third_party/sqlite/libsqlite3.a(obj/third_party/sqlite/amalgamation/sqlite.sqlite3.o) is referenced by DSO /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/qemux86-64/usr/lib/../lib/libsoftokn3.so
| /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-ld.gold: warning: hidden symbol 'sqlite3_open' in obj/third_party/sqlite/libsqlite3.a(obj/third_party/sqlite/amalgamation/sqlite.sqlite3.o) is referenced by DSO /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/qemux86-64/usr/lib/../lib/libsoftokn3.so
| /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-ld.gold: warning: hidden symbol 'sqlite3_busy_timeout' in obj/third_party/sqlite/libsqlite3.a(obj/third_party/sqlite/amalgamation/sqlite.sqlite3.o) is referenced by DSO /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/qemux86-64/usr/lib/../lib/libsoftokn3.so
| /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-ld.gold: warning: hidden symbol 'sqlite3_column_bytes' in obj/third_party/sqlite/libsqlite3.a(obj/third_party/sqlite/amalgamation/sqlite.sqlite3.o) is referenced by DSO /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/qemux86-64/usr/lib/../lib/libsoftokn3.so
| /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-ld.gold: warning: hidden symbol 'sqlite3_column_blob' in obj/third_party/sqlite/libsqlite3.a(obj/third_party/sqlite/amalgamation/sqlite.sqlite3.o) is referenced by DSO /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/qemux86-64/usr/lib/../lib/libsoftokn3.so
| /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-ld.gold: warning: hidden symbol 'sqlite3_file_control' in obj/third_party/sqlite/libsqlite3.a(obj/third_party/sqlite/amalgamation/sqlite.sqlite3.o) is referenced by DSO /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/qemux86-64/usr/lib/../lib/libsoftokn3.so
| /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-ld.gold: warning: hidden symbol 'sqlite3_temp_directory' in obj/third_party/sqlite/libsqlite3.a(obj/third_party/sqlite/amalgamation/sqlite.sqlite3.o) is referenced by DSO /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/qemux86-64/usr/lib/../lib/libsoftokn3.so
| /home/jenkins/oe/world/shr-core/tmp-eglibc/sysroots/x86_64-linux/usr/bin/x86_64-oe-linux/x86_64-oe-linux-ld.gold: error: treating warnings as errors
| collect2: error: ld returned 1 exit status
| ninja: build stopped: subcommand failed.
| WARNING: exit code 1 from a shell command.
| ERROR: Function failed: do_compile (log file is located at /home/jenkins/oe/world/shr-core/tmp-eglibc/work/core2-64-oe-linux/chromium/37.0.2062.0-r0/temp/log.do_compile.14955)
NOTE: recipe chromium-37.0.2062.0-r0: task do_compile: Failed

-- 
Martin 'JaMa' Jansa     jabber: Martin.Jansa@gmail.com

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 188 bytes --]

Re: GCC 4.9 considered evil

[Carlos Rafael Giani]

[-- Attachment #1: Type: text/plain, Size: 5277 bytes --]

On 08/14/2014 10:22 AM, Peter A. Bigot wrote:
> On 08/14/2014 03:12 AM, Carlos Rafael Giani wrote:
>> On 08/14/2014 02:46 AM, Khem Raj wrote:
>>>
>>>
>>> On Wednesday, August 13, 2014, Otavio Salvador 
>>> <otavio@ossystems.com.br <mailto:otavio@ossystems.com.br>> wrote:
>>>
>>>     On Wed, Aug 13, 2014 at 6:24 PM, Gary Thomas <gary@mlbassoc.com
>>>     <javascript:;>> wrote:
>>>     > I've found that the latest GCC doesn't work very well, at
>>>     > least not on ARM (and obviously other architectures as well [1])
>>>     > When I build Google Chromium browser for my i.MX boards using
>>>     > GCC-4.9.x, no pages can be rendered - massive bloodshed and
>>>     > failures are shown on the console.  If I use the older GCC 4.8.2,
>>>     > everything else the same, all is well.
>>>     >
>>>     > Here's my configuration:
>>>     > BB_VERSION        = "1.23.1"
>>>     > BUILD_SYS         = "x86_64-linux"
>>>     > NATIVELSBSTRING   = "Ubuntu-13.10"
>>>     > TARGET_SYS        = "arm-amltd-linux-gnueabi"
>>>     > MACHINE           = "teton-p0382"
>>>     > DISTRO            = "amltd"
>>>     > DISTRO_VERSION    = "1.6+snapshot-20140812"
>>>     > TUNE_FEATURES     = "arm armv7a vfp neon callconvention-hard
>>>     cortexa9"
>>>     > TARGET_FPU        = "vfp-neon"
>>>     > meta              =
>>>     "master:86afd7eb7c679eb065706137f28f44248f3fbc5a"
>>>     > meta-amltd        =
>>>     "master:899529b4184dc9e3e291e7fcdbbf157233db056d"
>>>     > meta-teton-imx6-p0382 =
>>>     "master:9188e2f8fafd203c95dcd7a3c79cb38a1568e9b5"
>>>     > meta-fsl-arm      =
>>>     "master:b0cf5c78c5f98c5977ae556d331e7495648f154c"
>>>     > meta-fsl-arm-extra =
>>>     "master:12e560967b7136222c325d11633295fe3a0c701c"
>>>     > meta-browser      =
>>>     "master:da93c8e386133a15eff1414d9307c8f2c7a44787"
>>>     >
>>>     > Should this be filed as a bug?  I don't have much data other
>>>     than it
>>>     > simply breaks (and chrome is not the easiest thing to debug!).
>>>      Other
>>>     > applications seem OK, but I am loathe to trust it...
>>>     >
>>>     > I'm going to hold onto GCC-4.8.x for my $DISTRO at least (and
>>>     I hope
>>>     > it doesn't vanish like 4.7.x did too quickly).
>>>     >
>>>     > [1]
>>>     >
>>>     http://slashdot.org/story/14/07/27/1838219/linus-torvalds-gcc-490-seems-to-be-terminally-broken
>>>     >
>>>     > Note: I've also tried this on qemux86 (a totally different
>>>     > architecture) and chrome bombs just as badly!
>>>
>>>     I confirm that GCC 4.9 does NOT work for Chromium 35. At this
>>>     moment I
>>>     am not aware of any fix for it.
>>>
>>>
>>> Again Its a broad brush statement. Something concrete is needed if 
>>> some.action is to taken
>>>
>>>
>>>     IIRC the Chromium 37 works though.
>>>
>>>
>>> Well then its less chance.that someone will fix 35
>>>
>>>     --
>>>     Otavio Salvador                             O.S. Systems
>>>     http://www.ossystems.com.br http://code.ossystems.com.br
>>>     Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750
>>>     --
>>>     _______________________________________________
>>>     Openembedded-core mailing list
>>>     Openembedded-core@lists.openembedded.org <javascript:;>
>>>     http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>>
>>>
>>>
>>
>>
>> The problem is that narrowing down is very difficult, since the 
>> problems manifest themselves as seemingly random stack corruptions. I 
>> have tried to dig into it, but got nowhere. Pointers suddenly became 
>> null for no apparent reason, or were corrupted, free() calls failed, 
>> values on the stack suddenly changed without being modified by the 
>> code etc.
>>
>> I wouldn't rule out that Linus Torvald's find isn't the cause here. 
>> Look at this part of his message:
>>
>> "The x86-64 ABI specifies a 128-byte red-zone under the stack 
>> pointer, and this is ok by that limit. It looks like it's illegal 
>> (136 > 128), but the fact is, we've had four "pushq"s to update %rsp 
>> since loading the frame pointer, so it's just *barely* legal with the 
>> red-zoning."
>>
>> Perhaps gcc is pushing further outside of the red zone bounds, thus 
>> causing the problems. No idea how to check for that at the moment though.
>
> Simplest would be to apply the upstream fix to Yocto's gcc and see if 
> that helps.  You'd want commit 
> 556537c4ad0df4cbebb74197bb2bdea75cf5dd35 from 
> git://gcc.gnu.org/git/gcc.git.  (The patch went into gcc-4_9-branch 
> one day after 4.9.1 was released.)
>
> I'd add it to the current set but ATT Khem and I both have pending 
> patches that touch the same gcc files, so it'd just increase the 
> conflicts.
>
> Peter

Are you sure this is the right patch? Commit message:

[PATCH] 2014-07-17  Richard Biener  <rguenther@suse.de>

         PR rtl-optimization/61801
         * sched-deps.c (sched_analyze_2): For ASM_OPERANDS and
         ASM_INPUT don't set reg_pending_barrier if it appears in a
         debug-insn.

It does not apply cleanly on gcc in either master or master-next . 
Patching ChangeLog fails. I will try to use it with the ChangeLog patch 
part omitted.

[-- Attachment #2: Type: text/html, Size: 9296 bytes --]

Re: GCC 4.9 considered evil

[Peter A. Bigot]

[-- Attachment #1: Type: text/plain, Size: 6083 bytes --]

On 08/14/2014 01:14 PM, Carlos Rafael Giani wrote:
> On 08/14/2014 10:22 AM, Peter A. Bigot wrote:
>> On 08/14/2014 03:12 AM, Carlos Rafael Giani wrote:
>>> On 08/14/2014 02:46 AM, Khem Raj wrote:
>>>>
>>>>
>>>> On Wednesday, August 13, 2014, Otavio Salvador 
>>>> <otavio@ossystems.com.br <mailto:otavio@ossystems.com.br>> wrote:
>>>>
>>>>     On Wed, Aug 13, 2014 at 6:24 PM, Gary Thomas <gary@mlbassoc.com
>>>>     <javascript:;>> wrote:
>>>>     > I've found that the latest GCC doesn't work very well, at
>>>>     > least not on ARM (and obviously other architectures as well [1])
>>>>     > When I build Google Chromium browser for my i.MX boards using
>>>>     > GCC-4.9.x, no pages can be rendered - massive bloodshed and
>>>>     > failures are shown on the console.  If I use the older GCC 4.8.2,
>>>>     > everything else the same, all is well.
>>>>     >
>>>>     > Here's my configuration:
>>>>     > BB_VERSION        = "1.23.1"
>>>>     > BUILD_SYS         = "x86_64-linux"
>>>>     > NATIVELSBSTRING   = "Ubuntu-13.10"
>>>>     > TARGET_SYS        = "arm-amltd-linux-gnueabi"
>>>>     > MACHINE           = "teton-p0382"
>>>>     > DISTRO            = "amltd"
>>>>     > DISTRO_VERSION    = "1.6+snapshot-20140812"
>>>>     > TUNE_FEATURES     = "arm armv7a vfp neon callconvention-hard
>>>>     cortexa9"
>>>>     > TARGET_FPU        = "vfp-neon"
>>>>     > meta              =
>>>>     "master:86afd7eb7c679eb065706137f28f44248f3fbc5a"
>>>>     > meta-amltd        =
>>>>     "master:899529b4184dc9e3e291e7fcdbbf157233db056d"
>>>>     > meta-teton-imx6-p0382 =
>>>>     "master:9188e2f8fafd203c95dcd7a3c79cb38a1568e9b5"
>>>>     > meta-fsl-arm      =
>>>>     "master:b0cf5c78c5f98c5977ae556d331e7495648f154c"
>>>>     > meta-fsl-arm-extra =
>>>>     "master:12e560967b7136222c325d11633295fe3a0c701c"
>>>>     > meta-browser      =
>>>>     "master:da93c8e386133a15eff1414d9307c8f2c7a44787"
>>>>     >
>>>>     > Should this be filed as a bug?  I don't have much data other
>>>>     than it
>>>>     > simply breaks (and chrome is not the easiest thing to
>>>>     debug!).  Other
>>>>     > applications seem OK, but I am loathe to trust it...
>>>>     >
>>>>     > I'm going to hold onto GCC-4.8.x for my $DISTRO at least (and
>>>>     I hope
>>>>     > it doesn't vanish like 4.7.x did too quickly).
>>>>     >
>>>>     > [1]
>>>>     >
>>>>     http://slashdot.org/story/14/07/27/1838219/linus-torvalds-gcc-490-seems-to-be-terminally-broken
>>>>     >
>>>>     > Note: I've also tried this on qemux86 (a totally different
>>>>     > architecture) and chrome bombs just as badly!
>>>>
>>>>     I confirm that GCC 4.9 does NOT work for Chromium 35. At this
>>>>     moment I
>>>>     am not aware of any fix for it.
>>>>
>>>>
>>>> Again Its a broad brush statement. Something concrete is needed if 
>>>> some.action is to taken
>>>>
>>>>
>>>>     IIRC the Chromium 37 works though.
>>>>
>>>>
>>>> Well then its less chance.that someone will fix 35
>>>>
>>>>     --
>>>>     Otavio Salvador                             O.S. Systems
>>>>     http://www.ossystems.com.br http://code.ossystems.com.br
>>>>     Mobile: +55 (53) 9981-7854            Mobile: +1 (347) 903-9750
>>>>     --
>>>>     _______________________________________________
>>>>     Openembedded-core mailing list
>>>>     Openembedded-core@lists.openembedded.org <javascript:;>
>>>>     http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>>>
>>>>
>>>>
>>>
>>>
>>> The problem is that narrowing down is very difficult, since the 
>>> problems manifest themselves as seemingly random stack corruptions. 
>>> I have tried to dig into it, but got nowhere. Pointers suddenly 
>>> became null for no apparent reason, or were corrupted, free() calls 
>>> failed, values on the stack suddenly changed without being modified 
>>> by the code etc.
>>>
>>> I wouldn't rule out that Linus Torvald's find isn't the cause here. 
>>> Look at this part of his message:
>>>
>>> "The x86-64 ABI specifies a 128-byte red-zone under the stack 
>>> pointer, and this is ok by that limit. It looks like it's illegal 
>>> (136 > 128), but the fact is, we've had four "pushq"s to update %rsp 
>>> since loading the frame pointer, so it's just *barely* legal with 
>>> the red-zoning."
>>>
>>> Perhaps gcc is pushing further outside of the red zone bounds, thus 
>>> causing the problems. No idea how to check for that at the moment 
>>> though.
>>
>> Simplest would be to apply the upstream fix to Yocto's gcc and see if 
>> that helps.  You'd want commit 
>> 556537c4ad0df4cbebb74197bb2bdea75cf5dd35 from 
>> git://gcc.gnu.org/git/gcc.git.  (The patch went into gcc-4_9-branch 
>> one day after 4.9.1 was released.)
>>
>> I'd add it to the current set but ATT Khem and I both have pending 
>> patches that touch the same gcc files, so it'd just increase the 
>> conflicts.
>>
>> Peter
>
> Are you sure this is the right patch? Commit message:
>
> [PATCH] 2014-07-17  Richard Biener <rguenther@suse.de>
>
>         PR rtl-optimization/61801
>         * sched-deps.c (sched_analyze_2): For ASM_OPERANDS and
>         ASM_INPUT don't set reg_pending_barrier if it appears in a
>         debug-insn.
>
> It does not apply cleanly on gcc in either master or master-next . 
> Patching ChangeLog fails. I will try to use it with the ChangeLog 
> patch part omitted.

Yes, I'm sure.  That's the bug referenced in Torvald's Linux commit 
working around the rant-inducing behavior.

Unmodified upstream patches for gcc never apply cleanly because they are 
based on unreleased versions with ChangeLog entries that aren't present 
in the released versions.  The V2 series I just sent includes the patch 
directly from upstream gcc-4_8-branch and gcc-4_9-branch, with ChangeLog 
pieces stripped.

Note that there's no reason to believe this will make chromium 35 any 
more stable, but it might avert issues people running unpatched Linux 
kernels could run into.

Peter

[-- Attachment #2: Type: text/html, Size: 10149 bytes --]