[Bug bootstrap/47779] New: Problem cross-compiling trunk for bfin

[Bug bootstrap/47779] New: Problem cross-compiling trunk for bfin

[Stuart.Henderson at analog dot com]

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

           Summary: Problem cross-compiling trunk for bfin
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: bootstrap
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: Stuart.Henderson@analog.com


I'm seeing a failure cross-compiling trunk for Blackfin (bfin-uclinux) with
uClibc, and it doesn't appear to have worked for quite some time.  My system is
x86_64-suse-linux, although that shouldn't be relevant in this case.

The first problem I'm seeing is when building unwind-dw2.c.

After installing target/uclibc headers for the sysroot, I configure gcc:

/home/shender/gnu/toolchain/gcc-4.6/configure --build=x86_64-unknown-linux-gnu
--host=x86_64-unknown-linux-gnu --target=bfin-uclinux
--prefix=/home/shender/gnu/toolchain/bfin-uclinux --disable-libstdcxx-pch
--with-sysroot=/home/shender/gnu/toolchain/bfin-uclinux/bfin-uclinux/runtime
--enable-threads=posix --enable-languages=c --disable-threads
--disable-libmudflap --disable-libgomp --disable-shared
--enable-clocale=generic --disable-symvers --disable-libssp --disable-libffi
--disable-libgcj --enable-version-specific-runtime-libs --enable-__cxa_atexit

and then make, which fails with:

/home/shender/gnu/toolchain/gcc_build-4.6/./gcc/xgcc
-B/home/shender/gnu/toolchain/gcc_build-4.6/./gcc/
-B/home/shender/gnu/toolchain/bfin-uclinux/bfin-uclinux/bin/
-B/home/shender/gnu/toolchain/bfin-uclinux/bfin-uclinux/lib/ -isystem
/home/shender/gnu/toolchain/bfin-uclinux/bfin-uclinux/include -isystem
/home/shender/gnu/toolchain/bfin-uclinux/bfin-uclinux/sys-include    -g -O2
-mcpu=bf532-none -O2  -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall
-Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition  -isystem ./include  -fpic -g  -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED -fno-stack-protector   -I. -I. -I../../.././gcc
-I/home/shender/gnu/toolchain/gcc-4.6/libgcc
-I/home/shender/gnu/toolchain/gcc-4.6/libgcc/.
-I/home/shender/gnu/toolchain/gcc-4.6/libgcc/../gcc
-I/home/shender/gnu/toolchain/gcc-4.6/libgcc/../include  -DHAVE_CC_TLS
-DUSE_EMUTLS -o unwind-dw2.o -MT unwind-dw2.o -MD -MP -MF unwind-dw2.dep
-fexceptions -c /home/shender/gnu/toolchain/gcc-4.6/libgcc/../gcc/unwind-dw2.c
In file included from
/home/shender/gnu/toolchain/bfin-uclinux/bfin-uclinux/sys-include/ucontext.h:25:0,
                 from
/home/shender/gnu/toolchain/bfin-uclinux/bfin-uclinux/sys-include/signal.h:351,
                 from
/home/shender/gnu/toolchain/gcc-4.6/libgcc/../gcc/config/bfin/linux-unwind.h:31,
                 from
/home/shender/gnu/toolchain/gcc-4.6/libgcc/../gcc/unwind-dw2.c:333:
/home/shender/gnu/toolchain/bfin-uclinux/bfin-uclinux/sys-include/sys/ucontext.h:39:3:
error: expected identifier before numeric constant
make[4]: *** [unwind-dw2.o] Error 1
make[4]: Leaving directory
`/home/shender/gnu/toolchain/gcc_build-4.6/bfin-uclinux/bf532-none/libgcc'
make[3]: *** [multi-do] Error 1
make[3]: Leaving directory
`/home/shender/gnu/toolchain/gcc_build-4.6/bfin-uclinux/libgcc'
make[2]: *** [all-multi] Error 2
make[2]: Leaving directory
`/home/shender/gnu/toolchain/gcc_build-4.6/bfin-uclinux/libgcc'
make[1]: *** [all-target-libgcc] Error 2
make[1]: Leaving directory `/home/shender/gnu/toolchain/gcc_build-4.6'
make: *** [all] Error 2



The problem seems to be caused by a change in the generation of tm.h in the
following check in:

r160579 | rsandifo | 2010-06-10 21:23:43 +0100 (Thu, 10 Jun 2010) | 7 lines
gcc/
    * configure.ac (tm_include_list): Add insn-constants.h.
    * configure: Regenerate.
    * Makefile.in (GTM_H): Move insn-constants.h here from...
    (TM_H): ...here.
    * mkconfig.sh: Remove special handling for insn-constants.h.

The change moves the inclusion of "insn-constants.h" from being conditional on:
#if defined IN_GCC && !defined GENERATOR_FILE && !defined USED_FOR_TARGET
to just:
#if defined IN_GCC

This causes insn-constants.h to be included here which defines various register
macros that can then clash with the enum (of registers in the gregset_t array)
in uClibc's sys/ucontext.h.

Although I've only hit this with bfin, it seems like it could easily hit other
architectures.

[Bug bootstrap/47779] Problem cross-compiling trunk for bfin

[Stuart.Henderson at analog dot com]

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

--- Comment #1 from Stu <Stuart.Henderson at analog dot com> 2011-03-09 10:45:07 UTC ---
Created attachment 23592
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23592
first attempt to fix bug #47779

[Bug bootstrap/47779] Problem cross-compiling trunk for bfin

[Stuart.Henderson at analog dot com]

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

--- Comment #2 from Stu <Stuart.Henderson at analog dot com> 2011-03-09 10:47:33 UTC ---
oops, missed the comment field, sorry.

To get the ball rolling, this is a first attempt to fix the bug.  Taking Ian
Lance Taylor's advice:
>I doubt there is a clean way to solve this.  Probably the simplest way
>is to rename the conflicting constants in gcc/config/bfin/*.
I have simply changed the constants from the REG_x form to the more common
x_REG form.

Does this seem reasonable?

[Bug target/47779] Problem cross-compiling trunk for bfin

[bernds at gcc dot gnu.org]

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

Bernd Schmidt <bernds at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bernds at gcc dot gnu.org

--- Comment #3 from Bernd Schmidt <bernds at gcc dot gnu.org> 2011-03-10 12:01:57 UTC ---
Maybe ucontext.h should only define these context ifdef __USE_GNU? That's what
i386 and x86_64 appear to do.

[Bug target/47779] Problem cross-compiling trunk for bfin

[Stuart.Henderson at analog dot com]

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

--- Comment #4 from Stu <Stuart.Henderson at analog dot com> 2011-03-11 11:26:04 UTC ---
(In reply to comment #3)
> Maybe ucontext.h should only define these context ifdef __USE_GNU? That's what
> i386 and x86_64 appear to do.

Hi Bernd,
Unfortunately __USE_GNU is defined at this point, so that doesn't appear to be
what's preventing the problem there.  i386 seems to use REG_x in gcc and x_REG
in uClibc, which avoids it.

[Bug target/47779] Problem cross-compiling trunk for bfin

[jsm28 at gcc dot gnu.org]

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

--- Comment #5 from Joseph S. Myers <jsm28 at gcc dot gnu.org> 2011-04-07 18:54:14 UTC ---
The real problem is that a large pile of logically host-only definitions are
included in tm.h for the target, and the real (but hard) fix would be to stop
target code from including tm.h (instead including a much more limited
libgcc-tm.h with only target-required definitions from libgcc/config/).

http://gcc.gnu.org/wiki/Top-Level_Libgcc_Migration

[Bug target/47779] Problem cross-compiling trunk for bfin

[pinskia at gcc dot gnu.org]

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

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |build
             Target|                            |bfin-uclinux
           Severity|major                       |normal

[Bug target/47779] Problem cross-compiling trunk for bfin

[wbx at openadk dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47779

Waldemar Brodkorb <wbx at openadk dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |wbx at openadk dot org

--- Comment #6 from Waldemar Brodkorb <wbx at openadk dot org> ---
Hi,

The bug still exist with latest GCC Git version.
What can be done to fix it? Should it be better fixed in uClibc?

best regards
 Waldemar