GCC 4.3 fails to build glibc(-intermediate)

GCC 4.3 fails to build glibc(-intermediate)

[Enric Balletbò i Serra]

Hi,

I have the same problem, but at this moment I don't have idea about solution.

Regards,
 Enric Balletbo i Serra

On Wed, May 7, 2008 at 7:33 AM, Matthijs van de Water
matthijs.van.de.water at gmail.com wrote:

> Hi,
>
> I'm trying to get an ARM EABI build based on gcc 4.3 working. I'm not
> having much luck with that so-far.
>
> The build fails at glibc-internal (tried both 2.6.1 and 2.7) with an
> internal compiler error:
> ../iconv/skeleton.c: In function '__gconv_transform_ucs4_internal':
> ../iconv/skeleton.c:801: internal compiler error: Segmentation fault
>
> Am I missing something? Any ideas?
>
> Regards,
>
> Matthijs van de Water
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>



-- 
Enric Balletbò i Serra

Re: GCC 4.3 fails to build glibc(-intermediate)

[Khem Raj]

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

On Thu, 2008-05-22 at 16:11 +0200, Enric Balletbò i Serra wrote:
> Hi,
> 
> I have the same problem, but at this moment I don't have idea about solution.
> 
> Regards,
>  Enric Balletbo i Serra
> 
> On Wed, May 7, 2008 at 7:33 AM, Matthijs van de Water
> matthijs.van.de.water at gmail.com wrote:
> 
> > Hi,
> >
> > I'm trying to get an ARM EABI build based on gcc 4.3 working. I'm not
> > having much luck with that so-far.
> >
> > The build fails at glibc-internal (tried both 2.6.1 and 2.7) with an
> > internal compiler error:
> > ../iconv/skeleton.c: In function '__gconv_transform_ucs4_internal':
> > ../iconv/skeleton.c:801: internal compiler error: Segmentation fault
> >
> > Am I missing something? Any ideas?

if you can create a preprocessed file from skeleton.c and commandline
options to reproduce this ICE that will be helpful.

-Khem

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 196 bytes --]

Re: GCC 4.3 fails to build glibc(-intermediate)

[Rolf Leggewie]

Enric Balletbò i Serra wrote:
> I have the same problem, but at this moment I don't have idea about solution.

I am also experiencing similar problems for a spitz build.  The problem
started to appear about a week ago.
f2497299e919cb94e12fc8690a709479451e5510 still builds fine.  I think the
most likely candidates that triggered this problem are to be found among
the changes to gcc that were made after that revision.  I see changes
from koen and RP in the commit-ml.  It would be nice if the people who
understand this stuff took a look to spot a possible regression.  I will
try and narrow the revision down further.

http://oss.leggewie.org/wip/f2497299e919cb94e12fc8690a709479451e5510_vs_HEAD.txt

Re: GCC 4.3 fails to build glibc(-intermediate)

[Khem Raj]

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

On Thu, 2008-05-22 at 20:24 +0200, Rolf Leggewie wrote:
> Enric Balletbò i Serra wrote:
> > I have the same problem, but at this moment I don't have idea about solution.
> 
> I am also experiencing similar problems for a spitz build.  The problem
> started to appear about a week ago.
> f2497299e919cb94e12fc8690a709479451e5510 still builds fine.  I think the
> most likely candidates that triggered this problem are to be found among
> the changes to gcc that were made after that revision.  I see changes
> from koen and RP in the commit-ml.  It would be nice if the people who
> understand this stuff took a look to spot a possible regression.  I will
> try and narrow the revision down further.
> 
> http://oss.leggewie.org/wip/f2497299e919cb94e12fc8690a709479451e5510_vs_HEAD.txt

Looking at this file. I dont see any obvious problem unless you are
using armv7a and angstrom-2008.1

in this changeset the preferred gcc version has been changed from 
4.2.3+csl-arm-2008q1-126 to 4.2.1+csl-arm-2007q3-53

Otherwise these changes look only like new gcc recipe has been added and
no common code is modified which could affect gcc 4.3

glibc changes also seems specific to armv7a



> 
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 196 bytes --]

Re: GCC 4.3 fails to build glibc(-intermediate)

[Rolf Leggewie]

Khem Raj wrote:
> in this changeset the preferred gcc version has been changed from 
> 4.2.3+csl-arm-2008q1-126 to 4.2.1+csl-arm-2007q3-53

yet, this is the one introducing the breakage.
860bccc90a045f54a0fd143d4759959d43643350 breaks, its ancestor
6f13b55b6143b51806ac9213c2d9af80e5be34bd builds still fine.

Re: GCC 4.3 fails to build glibc(-intermediate)

[Rolf Leggewie]

Let's continue this discussion in
http://bugs.openembedded.net/show_bug.cgi?id=4288

Re: GCC 4.3 fails to build glibc(-intermediate)

[Khem Raj]

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

On Thu, 2008-05-22 at 16:11 +0200, Enric Balletbò i Serra wrote:
> Hi,
> 
> I have the same problem, but at this moment I don't have idea about solution.

I could reproduce this problem as well. I also tried to reduce the
issue. It is an ICE in GCC and I have made a small testcase which I am
able to reproduce on gcc-4_3-branch I have reported a gcc bug(PR36350)
for it  Meanwhile you can remove -frename-registers optimization pass
and ICE should go away.

Something like this might work around for glibc

Index: libc/iconv/Makefile
===================================================================
--- libc.orig/iconv/Makefile	2008-05-27 23:50:05.000000000 -0700
+++ libc/iconv/Makefile	2008-05-27 23:54:43.000000000 -0700
@@ -38,6 +38,8 @@
 CFLAGS-gconv_simple.c = -DSTATIC_GCONV
 endif
 
+CFLAGS-gconv_simple.c += -fno-rename-registers
+
 vpath %.c ../locale/programs ../intl
 
 iconv_prog-modules = iconv_charmap charmap charmap-dir linereader \


Thanks

-Khem

> 
> Regards,
>  Enric Balletbo i Serra
> 
> On Wed, May 7, 2008 at 7:33 AM, Matthijs van de Water
> matthijs.van.de.water at gmail.com wrote:
> 
> > Hi,
> >
> > I'm trying to get an ARM EABI build based on gcc 4.3 working. I'm not
> > having much luck with that so-far.
> >
> > The build fails at glibc-internal (tried both 2.6.1 and 2.7) with an
> > internal compiler error:
> > ../iconv/skeleton.c: In function '__gconv_transform_ucs4_internal':
> > ../iconv/skeleton.c:801: internal compiler error: Segmentation fault
> >
> > Am I missing something? Any ideas?
> >
> > Regards,
> >
> > Matthijs van de Water
> >
> > _______________________________________________
> > Openembedded-devel mailing list
> > Openembedded-devel at lists.openembedded.org
> > http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> >
> 
> 
> 

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 196 bytes --]

Re: GCC 4.3 fails to build glibc(-intermediate)

[Koen Kooi]

Khem Raj wrote:
> On Thu, 2008-05-22 at 16:11 +0200, Enric Balletbò i Serra wrote:
>> Hi,
>>
>> I have the same problem, but at this moment I don't have idea about solution.
>
> I could reproduce this problem as well. I also tried to reduce the
> issue. It is an ICE in GCC and I have made a small testcase which I am
> able to reproduce on gcc-4_3-branch I have reported a gcc bug(PR36350)
> for it  Meanwhile you can remove -frename-registers optimization pass
> and ICE should go away.

And now I know why I wasn't seeing the ICE when using gcc 4.3.0: I 
turned off -frename-registers and -ftree-vectorize for armv7a 
completely, since gcc threw an ICE....

regards,

Koen


>
> Something like this might work around for glibc
>
> Index: libc/iconv/Makefile
> ===================================================================
> --- libc.orig/iconv/Makefile	2008-05-27 23:50:05.000000000 -0700
> +++ libc/iconv/Makefile	2008-05-27 23:54:43.000000000 -0700
> @@ -38,6 +38,8 @@
>   CFLAGS-gconv_simple.c = -DSTATIC_GCONV
>   endif
>
> +CFLAGS-gconv_simple.c += -fno-rename-registers
> +
>   vpath %.c ../locale/programs ../intl
>
>   iconv_prog-modules = iconv_charmap charmap charmap-dir linereader \
>
>
> Thanks
>
> -Khem
>
>> Regards,
>>   Enric Balletbo i Serra
>>
>> On Wed, May 7, 2008 at 7:33 AM, Matthijs van de Water
>> matthijs.van.de.water at gmail.com wrote:
>>
>>> Hi,
>>>
>>> I'm trying to get an ARM EABI build based on gcc 4.3 working. I'm not
>>> having much luck with that so-far.
>>>
>>> The build fails at glibc-internal (tried both 2.6.1 and 2.7) with an
>>> internal compiler error:
>>> ../iconv/skeleton.c: In function '__gconv_transform_ucs4_internal':
>>> ../iconv/skeleton.c:801: internal compiler error: Segmentation fault
>>>
>>> Am I missing something? Any ideas?
>>>
>>> Regards,
>>>
>>> Matthijs van de Water
>>>
>>> _______________________________________________
>>> Openembedded-devel mailing list
>>> Openembedded-devel at lists.openembedded.org
>>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>>>
>>
>>
>>
>> ------------------------------------------------------------------------
>>
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel

Re: GCC 4.3 fails to build glibc(-intermediate)

[Matthijs van de Water]

On Wed, May 28, 2008 at 9:01 AM, Khem Raj <raj.khem@gmail.com> wrote:
> I could reproduce this problem as well. I also tried to reduce the
> issue. It is an ICE in GCC and I have made a small testcase which I am
> able to reproduce on gcc-4_3-branch I have reported a gcc bug(PR36350)
> for it  Meanwhile you can remove -frename-registers optimization pass
> and ICE should go away.

I've 'solved' this in my local GCC 4.3 builds by patching GCC with the
patch in the following bug-report:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35964

After that GLIBC was building fine (for me).

The only other issues I had were in the Linux kernel (needs a small
patch to be compilable with GCC 4.3) and in opkg (which chokes on
-Wall -Werror with an array bounds check). I've patched opkg by
disabling the -Wall -Werror, because I couldn't find the problem in
the code (maybe this new GCC 4.3 warning is wrong sometimes).

One of these days I'll gather my GCC 4.3 patches and put them in
Bugzilla, but the above sums up the most important things I think.

Regards, Matthijs

Re: GCC 4.3 fails to build glibc(-intermediate)

[Rolf Leggewie]

Matthijs van de Water wrote:
> One of these days I'll gather my GCC 4.3 patches and put them in
> Bugzilla

Please do!

Re: GCC 4.3 fails to build glibc(-intermediate)

[Matthijs van de Water]

Did anyone working with GCC 4.3 have any problems with the C++
compiler in the SDK?

With the current setup, my include path search order is such that for
instance the <cstdlib> header is trying to #include_next<stdlib.h>,
which fails because the normal include paths precede the C++ include
paths.
If I change the #include_next to #include the headers work fine, but
that is obviously no solution. It looks like this is broken for all
sysroot builds, because the compiler will put the sysroot include
before the C++ ones and get rid of any duplicates.

Did anyone see this before? Any suggestions? I think I can solve this
by changing back to --enable-cheaders=c_std instead of c_global (which
was the default previously and which is why pre-4.3 toolchains work
fine for me), but I'm not sure of the implications of that.

Regards,

Matthijs

--enable-cheaders=OPTION

    This allows the user to define the approach taken for C header
compatibility with C++. Options are c, c_std, and c_global. These
correspond to the source directory's include/c, include/c_std, and
include/c_global, and may also include include/c_compatibility. The
default is c_global.

Re: GCC 4.3 fails to build glibc(-intermediate)

[Koen Kooi]

Matthijs van de Water wrote:
> Did anyone working with GCC 4.3 have any problems with the C++
> compiler in the SDK?
>
> With the current setup, my include path search order is such that for
> instance the<cstdlib>  header is trying to #include_next<stdlib.h>,
> which fails because the normal include paths precede the C++ include
> paths.
> If I change the #include_next to #include the headers work fine, but
> that is obviously no solution. It looks like this is broken for all
> sysroot builds, because the compiler will put the sysroot include
> before the C++ ones and get rid of any duplicates.
>
> Did anyone see this before?

I did see that before as well.

> Any suggestions? I think I can solve this
> by changing back to --enable-cheaders=c_std instead of c_global (which
> was the default previously and which is why pre-4.3 toolchains work
> fine for me), but I'm not sure of the implications of that.

Maybe we try something like this:

--- packages/gcc/gcc-4.3.0.inc  7dac0d4ea94fbc3071cf13542d7afc9c97598920
+++ packages/gcc/gcc-4.3.0.inc  d4ceae7672f475a16184235ac603437f86c3079e
@@ -68,5 +68,5 @@ JAVA = ""
  FORTRAN = ""
  JAVA = ""

-EXTRA_OECONF_BASE = " --enable-libssp --disable-bootstrap 
--disable-libgomp --disable-libmudflap"
+EXTRA_OECONF_BASE = "  --enable-cheaders=c_std --enable-libssp 
--disable-bootstrap --disable-libgomp --disable-libmudflap"

============================================================
--- packages/gcc/gcc-cross_4.3.0.bb 
1ed2f60e65e1b09e4a5637ab29c85ad02338061f
+++ packages/gcc/gcc-cross_4.3.0.bb 
cc76abacb299b51bb7da2b6bc0a6f7bec093ebeb
@@ -7,6 +7,12 @@ SRC_URI_append_fail-fast = " file://zeck

  SRC_URI_append_fail-fast = " file://zecke-no-host-includes.patch;patch=1 "

-EXTRA_OECONF += "--disable-libunwind-exceptions 
--with-mpfr=${STAGING_DIR_NATIVE}${layout_exec_prefix}"
+EXTRA_OECONF += "  --enable-cheaders=c_std 
--disable-libunwind-exceptions 
--with-mpfr=${STAGING_DIR_NATIVE}${layout_exec_prefix}"


regards,

Koen


>
> Regards,
>
> Matthijs
>
> --enable-cheaders=OPTION
>
>      This allows the user to define the approach taken for C header
> compatibility with C++. Options are c, c_std, and c_global. These
> correspond to the source directory's include/c, include/c_std, and
> include/c_global, and may also include include/c_compatibility. The
> default is c_global.

Re: GCC 4.3 fails to build glibc(-intermediate)

[Khem Raj]

Koen Kooi wrote:
> Matthijs van de Water wrote:
>> Did anyone working with GCC 4.3 have any problems with the C++
>> compiler in the SDK?
>>
>> With the current setup, my include path search order is such that for
>> instance the<cstdlib>  header is trying to #include_next<stdlib.h>,
>> which fails because the normal include paths precede the C++ include
>> paths.
>> If I change the #include_next to #include the headers work fine, but
>> that is obviously no solution. It looks like this is broken for all
>> sysroot builds, because the compiler will put the sysroot include
>> before the C++ ones and get rid of any duplicates.
>>
>> Did anyone see this before?
> 
> I did see that before as well.

I was seeing this too while compiling libusb. However when I did not use --with-gxx-headers option
and did not move the headers manually to STAGING_DIR this worked even with c_global scope.


> 
>> Any suggestions? I think I can solve this
>> by changing back to --enable-cheaders=c_std instead of c_global (which
>> was the default previously and which is why pre-4.3 toolchains work
>> fine for me), but I'm not sure of the implications of that.
> 
> Maybe we try something like this:
> 
> --- packages/gcc/gcc-4.3.0.inc  7dac0d4ea94fbc3071cf13542d7afc9c97598920
> +++ packages/gcc/gcc-4.3.0.inc  d4ceae7672f475a16184235ac603437f86c3079e
> @@ -68,5 +68,5 @@ JAVA = ""
>  FORTRAN = ""
>  JAVA = ""
> 
> -EXTRA_OECONF_BASE = " --enable-libssp --disable-bootstrap
> --disable-libgomp --disable-libmudflap"
> +EXTRA_OECONF_BASE = "  --enable-cheaders=c_std --enable-libssp
> --disable-bootstrap --disable-libgomp --disable-libmudflap"
> 
> ============================================================
> --- packages/gcc/gcc-cross_4.3.0.bb
> 1ed2f60e65e1b09e4a5637ab29c85ad02338061f
> +++ packages/gcc/gcc-cross_4.3.0.bb
> cc76abacb299b51bb7da2b6bc0a6f7bec093ebeb
> @@ -7,6 +7,12 @@ SRC_URI_append_fail-fast = " file://zeck
> 
>  SRC_URI_append_fail-fast = " file://zecke-no-host-includes.patch;patch=1 "
> 
> -EXTRA_OECONF += "--disable-libunwind-exceptions
> --with-mpfr=${STAGING_DIR_NATIVE}${layout_exec_prefix}"
> +EXTRA_OECONF += "  --enable-cheaders=c_std
> --disable-libunwind-exceptions
> --with-mpfr=${STAGING_DIR_NATIVE}${layout_exec_prefix}"

Adding this option worked for me and I could build console-image.

> 
> 
> regards,
> 
> Koen
> 
> 
>>
>> Regards,
>>
>> Matthijs
>>
>> --enable-cheaders=OPTION
>>
>>      This allows the user to define the approach taken for C header
>> compatibility with C++. Options are c, c_std, and c_global. These
>> correspond to the source directory's include/c, include/c_std, and
>> include/c_global, and may also include include/c_compatibility. The
>> default is c_global.
> 
> 
> 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
> 

GCC 4.3 fails to build glibc(-intermediate)

[Matthijs van de Water]

Hi,

I'm trying to get an ARM EABI build based on gcc 4.3 working. I'm not
having much luck with that so-far.

The build fails at glibc-internal (tried both 2.6.1 and 2.7) with an
internal compiler error:
../iconv/skeleton.c: In function '__gconv_transform_ucs4_internal':
../iconv/skeleton.c:801: internal compiler error: Segmentation fault

Am I missing something? Any ideas?

Regards,

Matthijs van de Water

Re: GCC 4.3 fails to build glibc(-intermediate)

[Khem Raj]

any compiler ICE is a compiler problem. You can reduce the testcase and may
file a bug in gcc bugzilla.

Khem

On Wed, May 7, 2008 at 7:33 AM, Matthijs van de Water <
matthijs.van.de.water@gmail.com> wrote:

> Hi,
>
> I'm trying to get an ARM EABI build based on gcc 4.3 working. I'm not
> having much luck with that so-far.
>
> The build fails at glibc-internal (tried both 2.6.1 and 2.7) with an
> internal compiler error:
> ../iconv/skeleton.c: In function '__gconv_transform_ucs4_internal':
> ../iconv/skeleton.c:801: internal compiler error: Segmentation fault
>
> Am I missing something? Any ideas?
>
> Regards,
>
> Matthijs van de Water
>
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/openembedded-devel
>

Re: GCC 4.3 fails to build glibc(-intermediate)

[Matthijs van de Water]

On Wed, May 7, 2008 at 6:21 PM, Khem Raj <raj.khem@gmail.com> wrote:
> any compiler ICE is a compiler problem. You can reduce the testcase and may
>  file a bug in gcc bugzilla.
Yeah, but since nobody else (says Google) seems to have this problem,
I'm wondering what exotic settings I'm using that causes this.
Koen Kooi also does not mention this problem in his gcc-4.3 progress
report of a while back, so I assumed that I was doing something wrong.

Re: GCC 4.3 fails to build glibc(-intermediate)

[Leon Woestenberg]

Matthijs,
Hello Matthijs,

On Wed, May 7, 2008 at 7:02 PM, Matthijs van de Water
<matthijs.van.de.water@gmail.com> wrote:
> On Wed, May 7, 2008 at 6:21 PM, Khem Raj <raj.khem@gmail.com> wrote:
>  > any compiler ICE is a compiler problem. You can reduce the testcase and may
>  >  file a bug in gcc bugzilla.
>  ...
>  I'm wondering what exotic settings I'm using that causes this.
> ...

*Any* compiler ICE is a compiler problem. :-)

The GCC people may be interested in your (exotic or not) settings and
a test case.


Otherwise, this bug may be lurking in there for quite some time.

Regards,
-- 
Leon