Sorry this took a while to get to, but things got a bit busy here when everyone
came back from vacation. I believe I've managed to pull out all the shared
changes and addresses the feedback to them from our v3 submission. I've
included ChangeLog entries for all of them, which I wouldn't usually do but I'm
doing here just to make sure they're OK -- I managed to screw the ChangeLog
entries up a handful of times in binutils and GCC, so I figure because it's a
slightly different set of people here it's worth sending them out as part of
the patches.
I've run these through build-many-glibcs.py, and while they're not 100% clean I
think the failures are just problems in my build environment. I'm getting two
failures during the compilers stage, which trigger a bunch of UNRESOLVEDs
during the glibcs stage. The m68k compiler fails with an ICE
0x638eb5 emit_library_call_value_1
/scratch/palmer/work/20171220-glibc_upstream/topdir/src/gcc/gcc/calls.c:4974
0x63cfbe emit_library_call_value(rtx_def*, rtx_def*, libcall_type, machine_mode, int, ...)
/scratch/palmer/work/20171220-glibc_upstream/topdir/src/gcc/gcc/calls.c:5168
0x8ce358 expand_atomic_compare_and_swap(rtx_def**, rtx_def**, rtx_def*, rtx_def*, rtx_def*, bool, memmodel, memmodel)
/scratch/palmer/work/20171220-glibc_upstream/topdir/src/gcc/gcc/optabs.c:6245
0x627c64 expand_builtin_compare_and_swap
/scratch/palmer/work/20171220-glibc_upstream/topdir/src/gcc/gcc/builtins.c:5527
0x62f301 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
/scratch/palmer/work/20171220-glibc_upstream/topdir/src/gcc/gcc/builtins.c:7093
0x725c9c expand_expr_real_1(tree_node*, rtx_def*, machine_mode, expand_modifier, rtx_def**, bool)
/scratch/palmer/work/20171220-glibc_upstream/topdir/src/gcc/gcc/expr.c:10850
0x72e650 store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool, tree_node*)
/scratch/palmer/work/20171220-glibc_upstream/topdir/src/gcc/gcc/expr.c:5569
0x72f39f expand_assignment(tree_node*, tree_node*, bool)
/scratch/palmer/work/20171220-glibc_upstream/topdir/src/gcc/gcc/expr.c:5338
0x647b3a expand_call_stmt
/scratch/palmer/work/20171220-glibc_upstream/topdir/src/gcc/gcc/cfgexpand.c:2656
0x647b3a expand_gimple_stmt_1
/scratch/palmer/work/20171220-glibc_upstream/topdir/src/gcc/gcc/cfgexpand.c:3571
0x647b3a expand_gimple_stmt
/scratch/palmer/work/20171220-glibc_upstream/topdir/src/gcc/gcc/cfgexpand.c:3737
0x649530 expand_gimple_basic_block
/scratch/palmer/work/20171220-glibc_upstream/topdir/src/gcc/gcc/cfgexpand.c:5744
0x64db4e execute
/scratch/palmer/work/20171220-glibc_upstream/topdir/src/gcc/gcc/cfgexpand.c:6357
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
/scratch/palmer/work/20171220-glibc_upstream/topdir/src/gcc/libgcc/static-object.mk:17: recipe for target 'linux-atomic.o' failed
make[3]: *** [linux-atomic.o] Error 1
and the sparc compiler fails with a #error that actually comes from a glibc
header file
In file included from /scratch/palmer/work/20171220-glibc_upstream/topdir/install/compilers/sparc64-linux-gnu/sysroot/usr/include/bits/libio.h:520:0,
from /scratch/palmer/work/20171220-glibc_upstream/topdir/install/compilers/sparc64-linux-gnu/sysroot/usr/include/stdio.h:41,
from /scratch/palmer/work/20171220-glibc_upstream/topdir/src/gcc/libgcc/../gcc/tsystem.h:87,
from /scratch/palmer/work/20171220-glibc_upstream/topdir/src/gcc/libgcc/libgcc2.c:27:
/scratch/palmer/work/20171220-glibc_upstream/topdir/install/compilers/sparc64-linux-gnu/sysroot/usr/include/bits/libio-ldbl.h:20:3: error: #error "Never include <bits/libio-ldbl.h> directly; use <libio.h>
instead."
# error "Never include <bits/libio-ldbl.h> directly; use <libio.h> instead."
^~~~~
Makefile:491: recipe for target '_negdi2.o' failed
make[5]: *** [_negdi2.o] Error 1
This SPARC one might actually be an glibc bug, but I can't figure out why it
would work for other people and not for me -- looking at stdio.h, it does
appear to directly include bits/libio.h
This is happening even without my patches, so I don't think they're related.
Here's the error log from build-many-glibcs.py:
$ cat compilers-master.log | grep -v ^PASS
FAIL: compilers-m68k-linux-gnu-coldfire gcc-first build
UNRESOLVED: compilers-m68k-linux-gnu-coldfire gcc-first install
UNRESOLVED: compilers-m68k-linux-gnu-coldfire glibc m68k-linux-gnu-coldfire rm
UNRESOLVED: compilers-m68k-linux-gnu-coldfire glibc m68k-linux-gnu-coldfire mkdir
UNRESOLVED: compilers-m68k-linux-gnu-coldfire glibc m68k-linux-gnu-coldfire copy-rm
UNRESOLVED: compilers-m68k-linux-gnu-coldfire glibc m68k-linux-gnu-coldfire copy-mkdir
UNRESOLVED: compilers-m68k-linux-gnu-coldfire glibc m68k-linux-gnu-coldfire copy
UNRESOLVED: compilers-m68k-linux-gnu-coldfire glibc m68k-linux-gnu-coldfire configure
UNRESOLVED: compilers-m68k-linux-gnu-coldfire glibc m68k-linux-gnu-coldfire build
UNRESOLVED: compilers-m68k-linux-gnu-coldfire glibc m68k-linux-gnu-coldfire install
UNRESOLVED: compilers-m68k-linux-gnu-coldfire glibc m68k-linux-gnu-coldfire mkdir-lib
UNRESOLVED: compilers-m68k-linux-gnu-coldfire gcc rm
UNRESOLVED: compilers-m68k-linux-gnu-coldfire gcc mkdir
UNRESOLVED: compilers-m68k-linux-gnu-coldfire gcc configure
UNRESOLVED: compilers-m68k-linux-gnu-coldfire gcc build
UNRESOLVED: compilers-m68k-linux-gnu-coldfire gcc install
UNRESOLVED: compilers-m68k-linux-gnu-coldfire done
FAIL: compilers-sparc64-linux-gnu gcc build
UNRESOLVED: compilers-sparc64-linux-gnu gcc install
UNRESOLVED: compilers-sparc64-linux-gnu done
If someone has a known-good environment in which build-many-glibcs.py I can try
to replicate it, but I don't think either of these patches could caused these
failures.
These are running through build-many-glibcs.py again (with "--strip") just to
be sure, but assuming the failures above aren't a problem I'm OK to commit them
this weekend.
Sorry, again, this is all so last minute!
[PATCH 1/4] Add RISC-V dynamic relocations to elf.h
[PATCH 2/4] Allow make-link-multidir to make subdirectories
[PATCH 3/4] Add linux-4.15 VDSO hash for RISC-V
[PATCH 4/4] Strip shared objects in subdirectories of lib