[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/47951] [4.6 Regression] web.c:union_match_dups segmentation fault for bfin

[Stuart.Henderson at analog dot com]

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

--- Comment #1 from Stu Stuart.Henderson at analog dot com 2011-03-11 
12:16:40 UTC ---
Created attachment 23626
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23626
First attempt to fix seg fault

The attached patch fixes the problem and my testing hasn't shown any
problems, but i currently don't have much confidence in it.  Could someone take
a look and give me some pointers?
thanks,
Stu

[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/47951] New: [4.6 Regression] web.c:union_match_dups segmentation fault for bfin

[Stuart.Henderson at analog dot com]

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

   Summary: [4.6 Regression] web.c:union_match_dups segmentation
fault for bfin
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: stuart.hender...@analog.com


bfin-uclinux fails to build libgfortran due to a seg fault in union_match_dups
in web.c

Looks like this is the blackfin version of:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43742

which was caused by:
http://gcc.gnu.org/viewcvs?view=revisionrevision=158187

i'm not sure what the guilty pattern is though.

/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
-DHAVE_CONFIG_H -I. -I/home/shender/gnu/toolchain/gcc-4.6/libgfortran
-iquote/home/shender/gnu/toolchain/gcc-4.6/libgfortran/io
-I/home/shender/gnu/toolchain/gcc-4.6/libgfortran/../gcc
-I/home/shender/gnu/toolchain/gcc-4.6/libgfortran/../gcc/config -I../.././gcc
-D_GNU_SOURCE -std=gnu99 -ftree-vectorize -funroll-loops -g -O1 -c
/home/shender/gnu/toolchain/gcc-4.6/libgfortran/generated/matmul_i1.c -o
matmul_i1.o
/home/shender/gnu/toolchain/gcc-4.6/libgfortran/generated/matmul_i1.c: In
function ‘matmul_i1’:
/home/shender/gnu/toolchain/gcc-4.6/libgfortran/generated/matmul_i1.c:374:1:
internal compiler error: Segmentation fault

[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: unassig...@gcc.gnu.org
ReportedBy: stuart.hender...@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.