Since the last set of libffi changes, for about 10 days, bootstrap fails on i386-unknown-freebsd10.0: libtool: compile: /scratch2/tmp/gerald/OBJ-0124-0939/./gcc/xgcc -B/scratch2/tmp /gerald/OBJ-0124-0939/./gcc/ -B/home/gerald/gcc-ref10-i386/i386-unknown-freebsd1 0.1/bin/ -B/home/gerald/gcc-ref10-i386/i386-unknown-freebsd10.1/lib/ -isystem /h ome/gerald/gcc-ref10-i386/i386-unknown-freebsd10.1/include -isystem /home/gerald /gcc-ref10-i386/i386-unknown-freebsd10.1/sys-include -DHAVE_CONFIG_H -I. -I/scra tch2/tmp/gerald/gcc-HEAD/libffi -I. -I/scratch2/tmp/gerald/gcc-HEAD/libffi/inclu de -Iinclude -I/scratch2/tmp/gerald/gcc-HEAD/libffi/src -I. -I/scratch2/tmp/gera ld/gcc-HEAD/libffi/include -Iinclude -I/scratch2/tmp/gerald/gcc-HEAD/libffi/src -g -O2 -MT src/x86/sysv.lo -MD -MP -MF src/x86/.deps/sysv.Tpo -c /scratch2/tmp/g erald/gcc-HEAD/libffi/src/x86/sysv.S -fPIC -DPIC -o src/x86/.libs/sysv.o /scratch2/tmp/gerald/gcc-HEAD/libffi/src/x86/sysv.S: Assembler messages: /scratch2/tmp/gerald/gcc-HEAD/libffi/src/x86/sysv.S:864: Error: junk at end of l ine, first unrecognized character is `@' /scratch2/tmp/gerald/gcc-HEAD/libffi/src/x86/sysv.S:886: Error: junk at end of l ine, first unrecognized character is `@' /scratch2/tmp/gerald/gcc-HEAD/libffi/src/x86/sysv.S:898: Error: junk at end of l ine, first unrecognized character is `@' /scratch2/tmp/gerald/gcc-HEAD/libffi/src/x86/sysv.S:910: Error: junk at end of l ine, first unrecognized character is `@' /scratch2/tmp/gerald/gcc-HEAD/libffi/src/x86/sysv.S:938: Error: junk at end of l ine, first unrecognized character is `@' /scratch2/tmp/gerald/gcc-HEAD/libffi/src/x86/sysv.S:950: Error: junk at end of l ine, first unrecognized character is `@' /scratch2/tmp/gerald/gcc-HEAD/libffi/src/x86/sysv.S:964: Error: junk at end of l ine, first unrecognized character is `@' /scratch2/tmp/gerald/gcc-HEAD/libffi/src/x86/sysv.S:983: Error: junk at end of l ine, first unrecognized character is `@' /scratch2/tmp/gerald/gcc-HEAD/libffi/src/x86/sysv.S:1007: Error: junk at end of line, first unrecognized character is `@' Makefile:1177: recipe for target 'src/x86/sysv.lo' failed gmake[4]: *** [src/x86/sysv.lo] Error 1 gmake[4]: Leaving directory '/scratch2/tmp/gerald/OBJ-0124-0939/i386-unknown-fre ebsd10.1/libffi'
What errors do you get on echo '.text; foo: nop; .data; .long foo-.; .text' > conftest.s gcc -c conftest.s (i.e. why HAVE_AS_X86_PCREL isn't defined for you)?
I built GCC configured --without-libgcj --without-libffi and the result works just fine on your testcase: % ~/gcc-ref10-i386/bin/gcc -c conftest.s In case this provide some insight, here the same with gcc -v: % ~/gcc-ref10-i386/bin/gcc -v -c conftest.s Using built-in specs. COLLECT_GCC=/home/gerald/gcc-ref10-i386/bin/gcc Target: i386-unknown-freebsd10.1 Configured with: /scratch2/tmp/gerald/gcc-HEAD/configure --prefix=/home/gerald/gcc-ref10-i386 --disable-libgcj --without-libffi --with-gmp=/home/gerald/10-i386 --with-as=/home/gerald/10-i386/bin/as --with-ld=/home/gerald/10-i386/bin/ld Thread model: posix gcc version 5.0.0 20150125 (experimental) (GCC) COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=generic' '-march=i486' /home/gerald/10-i386/bin/as -v -o conftest.o conftest.s GNU assembler version 2.23.2 (i386-portbld-freebsd10.0) using BFD version (GNU Binutils) 2.23.2 COMPILER_PATH=/home/gerald/gcc-ref10-i386/libexec/gcc/i386-unknown-freebsd10.1/5.0.0/:/home/gerald/gcc-ref10-i386/libexec/gcc/i386-unknown-freebsd10.1/5.0.0/:/home/gerald/gcc-ref10-i386/libexec/gcc/i386-unknown-freebsd10.1/:/home/gerald/gcc-ref10-i386/lib/gcc/i386-unknown-freebsd10.1/5.0.0/:/home/gerald/gcc-ref10-i386/lib/gcc/i386-unknown-freebsd10.1/ LIBRARY_PATH=/home/gerald/gcc-ref10-i386/lib/gcc/i386-unknown-freebsd10.1/5.0.0/:/home/gerald/gcc-ref10-i386/lib/gcc/i386-unknown-freebsd10.1/5.0.0/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-c' '-mtune=generic' '-march=i486' When I build with just --disable-libgcj, the bootstrap also succeeds. It is when I build without this that bootstrap fails in the manner described above.
Can you look at libffi's config.log if it is clear why the test failed then?
Created attachment 34584 [details] OBJ-0126-1523/i386-unknown-freebsd10.1/libffi/config.log I did not find the respective check, but let me attach OBJ-0126-1523/i386-unknown-freebsd10.1/libffi/config.log
configure.host has i?86-*-freebsd* | i?86-*-openbsd*) TARGET=X86_FREEBSD; TARGETDIR=x86 ;; and configure.ac has if test x$TARGET = xX86 || test x$TARGET = xX86_WIN32 || test x$TARGET = xX86_64; then ... It is a mismatch.
Created attachment 34585 [details] An untested patch Try this.
I guess the question is why the freebsd specific code (freebsd.S etc.) has been removed, if it is really not needed anymore, or if it got due to a mistake.
(In reply to Jakub Jelinek from comment #7) > I guess the question is why the freebsd specific code (freebsd.S etc.) has > been removed, if it is really not needed anymore, or if it got due to a > mistake. Richard should be able to answer this: commit b21ec1ce783f09335c0e6c6f96ccc7e89da5a1b4 Author: Richard Henderson <rth@twiddle.net> Date: Wed Nov 5 10:15:25 2014 +0100 x86: Rewrite closures Move everything into sysv.S, removing win32.S and freebsd.S. Handle all abis with a single ffi_closure_inner function. Move complexity of the raw THISCALL trampoline into assembly instead of the trampoline itself. Only push the context for the REGISTER abi; let the rest
(In reply to Jakub Jelinek from comment #7) > I guess the question is why the freebsd specific code (freebsd.S etc.) has > been removed, if it is really not needed anymore, or if it got due to a > mistake. freebsd.S and win32.S were merged with sysv.S. There were very few differences between them.
(In reply to H.J. Lu from comment #6) That will probably break small structure return. See case FFI_TYPE_STRUCT: #ifndef X86 /* ??? This should be a different ABI rather than an ifdef. */ if (cif->rtype->size == 1) flags = X86_RET_STRUCT_1B; else if (cif->rtype->size == 2) flags = X86_RET_STRUCT_2B; else if (cif->rtype->size == 4) flags = X86_RET_INT32; else if (cif->rtype->size == 8) flags = X86_RET_INT64; else #endif
Fixed in r220222.