I have an aarch64-linux-gnu build tree with a glibc checkout from about a month ago (revision 1400983e04d7b4b5a92db79ab27b0d0ec7d8bdef) that has started giving a SEGV when building argp/argp-help.c. I tracked it down to this GCC commit: r217852 | belagod | 2014-11-20 05:58:23 -0800 (Thu, 20 Nov 2014) | 17 lines 2014-11-20 Tejas Belagod <tejas.belagod@arm.com> gcc/ * config/aarch64/aarch64-protos.h (aarch64_classify_symbol): Fixup prototype. * config/aarch64/aarch64.c (aarch64_expand_mov_immediate, aarch64_cannot_force_const_mem, aarch64_classify_address, aarch64_classify_symbolic_expression): Fixup call to aarch64_classify_symbol. (aarch64_classify_symbol): Add range-checking for symbol + offset addressing for tiny and small models. testsuite/ * gcc.target/aarch64/symbol-range.c: New. * gcc.target/aarch64/symbol-range-tiny.c: New. Here's the info from running the debugger on cc1. Program received signal SIGSEGV, Segmentation fault. plus_constant (mode=DImode, x=0xf78e1f30, c=144, inplace=<optimized out>, inplace@entry=false) at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/explow.c:120 120 if (memory_address_p (GET_MODE (tem), XEXP (tem, 0))) (gdb) print debug_rtx(x) (mem/u/c:DI (symbol_ref/u:DI ("*.LC39") [flags 0x2]) [4 S8 A64]) $6 = void (gdb) print tem $7 = (rtx) 0x0 (gdb) bt #0 plus_constant (mode=DImode, x=0xf78e1f30, c=144, inplace=<optimized out>, inplace@entry=false) at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/explow.c:120 #1 0x082e2db3 in init_alias_analysis () at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/alias.c:2966 #2 0x08b59682 in cse_main (nregs=<optimized out>, f=<optimized out>) at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/cse.c:6597 #3 0x08b5a5ec in rest_of_handle_cse2 () at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/cse.c:7528 #4 (anonymous namespace)::pass_cse2::execute (this=0x92c99c8) at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/cse.c:7581 #5 0x0868ca49 in execute_one_pass (pass=pass@entry=0x92c99c8) at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/passes.c:2311 #6 0x0868cf16 in execute_pass_list_1 (pass=0x92c99c8) at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/passes.c:2363 #7 0x0868cf26 in execute_pass_list_1 (pass=0x92c93c8, pass@entry=0x92c7288) at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/passes.c:2364 #8 0x0868cf72 in execute_pass_list (fn=0xf7933dac, pass=0x92c7288) at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/passes.c:2374 #9 0x08367a5d in cgraph_node::expand (this=this@entry=0xf794cd20) at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/cgraphunit.c:1773 #10 0x083692ff in expand_all_functions () at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/cgraphunit.c:1909 #11 symbol_table::compile (this=this@entry=0xf7c3b000) at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/cgraphunit.c:2263 #12 0x0836ae3d in symbol_table::finalize_compilation_unit (this=0xf7c3b000) at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/cgraphunit.c:2340 #13 0x081ec3a4 in c_write_global_declarations () at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/c/c-decl.c:10777 #14 0x0874fdce in compile_file () at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/toplev.c:584 #15 0x081d1823 in do_compile () at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/toplev.c:2041 #16 toplev::main (this=this@entry=0xffffcfff, argc=argc@entry=103, argv=argv@entry=0xffffd0b4) at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/toplev.c:2138 #17 0x081d2175 in main (argc=103, argv=0xffffd0b4) at /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/main.c:38 Hopefully this is enough info to track it down? Seems clear that something in the bad patch started causing force_const_mem to return NULL in this case and the call site in plus_mem is not expecting that.
I was able to build glibc just with Friday's GCC sources with glibc as of Friday too.
>Hopefully this is enough info to track it down? We need the preprocessed source really.
Created attachment 34225 [details] preprocessor output (gzipped) Preprocessor output attached.
In case it's also relevant, my GCC was configured with: Configured with: /scratch/sandra/aarch64-fsf/src/gcc-mainline/configure --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=aarch64-linux-gnu --enable-threads --disable-libmudflap --disable-libssp --disable-libstdcxx-pch --with-march=armv8-a --disable-libsanitizer --with-gnu-as --with-gnu-ld --enable-languages=c,c++ --enable-shared --enable-lto --enable-symvers=gnu --enable-__cxa_atexit --with-glibc-version=2.21 --disable-nls --prefix=/scratch/sandra/aarch64-fsf/install --disable-shared --disable-threads --disable-libssp --disable-libgomp --without-headers --with-newlib --disable-decimal-float --disable-libffi --disable-libquadmath --disable-libitm --disable-libatomic --enable-languages=c --with-sysroot=/scratch/sandra/aarch64-fsf/install/aarch64-linux-gnu/libc --with-gmp=/scratch/sandra/aarch64-fsf/obj/pkg-mainline-0-aarch64-linux-gnu/fsf-mainline-0-aarch64-linux-gnu.extras/host-libs-i686-pc-linux-gnu/usr --with-mpfr=/scratch/sandra/aarch64-fsf/obj/pkg-mainline-0-aarch64-linux-gnu/fsf-mainline-0-aarch64-linux-gnu.extras/host-libs-i686-pc-linux-gnu/usr --with-mpc=/scratch/sandra/aarch64-fsf/obj/pkg-mainline-0-aarch64-linux-gnu/fsf-mainline-0-aarch64-linux-gnu.extras/host-libs-i686-pc-linux-gnu/usr --with-host-libstdcxx='-static-libgcc -Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --with-isl=/scratch/sandra/aarch64-fsf/obj/pkg-mainline-0-aarch64-linux-gnu/fsf-mainline-0-aarch64-linux-gnu.extras/host-libs-i686-pc-linux-gnu/usr --with-cloog=/scratch/sandra/aarch64-fsf/obj/pkg-mainline-0-aarch64-linux-gnu/fsf-mainline-0-aarch64-linux-gnu.extras/host-libs-i686-pc-linux-gnu/usr --disable-libgomp --disable-libitm --disable-libatomic --disable-libssp --enable-poison-system-directories --with-build-time-tools=/scratch/sandra/aarch64-fsf/install/aarch64-linux-gnu/bin --with-build-time-tools=/scratch/sandra/aarch64-fsf/install/aarch64-linux-gnu/bin SED=sed Thread model: single gcc version 5.0.0 20141120 (experimental) (GCC)
Works for me with current trunk GCC and recent glibc as well. By the way, what are the compile options? I tried -O2
This reproduces it for me; my build is at r217852. $ aarch64-linux-gnu-gcc argp-help.i -c -O2 argp-help.c: In function '_help': argp-help.c:1684:1: internal compiler error: Segmentation fault 0x874f9b0 crash_signal /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/toplev.c:359 0x8406cfb plus_constant(machine_mode, rtx_def*, long long, bool) /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/explow.c:120 0x82e2db2 init_alias_analysis() /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/alias.c:2966 0x8b59681 cse_main /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/cse.c:6597 0x8b5a5eb rest_of_handle_cse2 /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/cse.c:7528 0x8b5a5eb execute /scratch/sandra/aarch64-fsf/src/gcc-mainline/gcc/cse.c:7581 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See <http://gcc.gnu.org/bugs.html> for instructions. When I have a chance, I'll see if I can dig up some more information out of the debugger and/or reduce the testcase enough to allow setting some breakpoints.
Hmmmm. I'm not sure why there's trouble in reproducing the failure, but looking at this some more, it seems like we have a problem with this code fragment from force_const_mem in varasm.c: /* If we're not allowed to drop X into the constant pool, don't. */ if (targetm.cannot_force_const_mem (mode, x)) return NULL_RTX; and the code at the call site in plus_constant in explow.c: tem = force_const_mem (GET_MODE (x), tem); if (memory_address_p (GET_MODE (tem), XEXP (tem, 0))) return tem; which is clearly not expecting force_const_mem to return null. Guarding the reference in the conditional like if (tem && memory_address_p (GET_MODE (tem), XEXP (tem, 0))) ... fixes the SEGV, but a quick look shows that there are a lot of other uses of force_const_mem that expect it to return a non-null value, with no checking. So, probably this has nothing to do with the specific change in r217852, but has been a lurking bug for a long time, and it needs more than a band-aid on this one particular call site.
Hi Sandra, I'm unable to reproduce this SEGV with a x-build of aarch64-linux-gcc/native gcc with -O2 on the attached prepocessed test case. Are there any other options I'm missing?
Waiting on this one - no one seems to be able to reproduce this.
What host compiler are you using? I am running into a similar issue (though I have not reproduced it myself; only in an automated build) with the host compiler from RedHat EL5 (after backporting this patch to our GCC 4.7 tree) but if I use the one from Debian 5, it works.
(In reply to Andrew Pinski from comment #10) > What host compiler are you using? I am running into a similar issue (though > I have not reproduced it myself; only in an automated build) with the host > compiler from RedHat EL5 (after backporting this patch to our GCC 4.7 tree) > but if I use the one from Debian 5, it works. gcc version 4.8.2 (Ubuntu 4.8.2-19ubuntu1)
I'm using a 4.7.3 based gcc as the host compiler (built from one of our own CodeBench release branches). Regardless of whether the actual failure is reproducible, if you look at the code I pointed at in comment 7, there is clearly a bug here: if force_const_mem returns NULL, GCC will crash, not just here but in several other places as well.
(In reply to Sandra Loosemore from comment #12) > I'm using a 4.7.3 based gcc as the host compiler (built from one of our own > CodeBench release branches). > > Regardless of whether the actual failure is reproducible, if you look at the > code I pointed at in comment 7, there is clearly a bug here: if > force_const_mem returns NULL, GCC will crash, not just here but in several > other places as well. I tried with a build of cross aarch64-linux-gnu with 4.7.4 as the host compiler and my gcc sources at HEAD and r217852 of trunk, but no luck! :-(
Also, I'm unable to build x-gcc with glibc at 1400983e04d7b4b5a92db79ab27b0d0ec7d8bdef due to an error: bin-trunk-linux/obj/glibc/intl/hash-string.os plural.c:182:5: error: conflicting types for ‘__gettextparse’ int __gettextparse (void); ^ In file included from plural.y:35:0: plural-exp.h:97:23: note: previous declaration of ‘__gettextparse’ was here # define PLURAL_PARSE __gettextparse so, I tried with an earlier version(c5684fdb2badfda3bd6e973e5f933272e39e9590), but still no luck.
Ok, I was finally able to trace this down, This is a 32bit vs 64bit host compiler difference. The problem is with: if (SYMBOL_REF_WEAK (x) || INTVAL (offset) < (HOST_WIDE_INT) -4294967263 || INTVAL (offset) > (HOST_WIDE_INT) 4294967264) This really should be something like: if (SYMBOL_REF_WEAK (x) || INTVAL (offset) < (HOST_WIDE_INT) -4294967263LL || INTVAL (offset) > (HOST_WIDE_INT) 4294967264LL)
Perhaps better as: if (SYMBOL_REF_WEAK (x) || !IN_RANGE (INTVAL (x), HOST_WIDE_INT_C (-4294967263), HOST_WIDE_INT_C (4294967264))) ?
Andrew, are you going to post the patch? I think it is pretty obvious...
Author: belagod Date: Mon Feb 2 15:54:59 2015 New Revision: 220348 URL: https://gcc.gnu.org/viewcvs?rev=220348&root=gcc&view=rev Log: 2015-02-02 Tejas Belagod <tejas.belagod@arm.com> Andrew Pinski <pinskia@gcc.gnu.org> Jakub Jelinek <jakub@gcc.gnu.org> PR target/64231 * config/aarch64/aarch64.c (aarch64_classify_symbol): Fix large integer typing for small model. Use IN_RANGE. Modified: trunk/gcc/ChangeLog trunk/gcc/config/aarch64/aarch64.c
Fixed as r220348.
Author: clyon Date: Wed Apr 15 08:11:56 2015 New Revision: 222119 URL: https://gcc.gnu.org/viewcvs?rev=222119&root=gcc&view=rev Log: 2015-04-15 Christophe Lyon <christophe.lyon@linaro.org> Backport from trunk r220348. 2015-02-02 Tejas Belagod <tejas.belagod@arm.com> Andrew Pinski <pinskia@gcc.gnu.org> Jakub Jelinek <jakub@gcc.gnu.org> PR target/64231 * config/aarch64/aarch64.c (aarch64_classify_symbol): Fix large integer typing for small model. Use IN_RANGE. Modified: branches/linaro/gcc-4_9-branch/gcc/ChangeLog.linaro branches/linaro/gcc-4_9-branch/gcc/config/aarch64/aarch64.c