On Sat, 2015-11-14 at 09:50 -0500, David Edelsohn wrote:
> This patch causes numerous new testsuite failure on AIX caused by the
> compiler crashing during compilation, e.g.
>
> gcc.c-torture/execute/20020206-1.c
>
> in GCC libcpp
>
> 991 linemap_assert (line >= LINEMAPS_MACRO_LOWEST_LOCATION (set));
>
> (gdb) where
> #0 _Z11fancy_abortPKciS0_ (
> file=0x11296dc0
> <_GLOBAL__F__ZN9text_info9set_rangeEj12source_rangeb+3056>
> "/nasfarm/edelsohn/src/src/libcpp/line-map.c", line=991,
> function=0x11296f30
> <_GLOBAL__F__ZN9text_info9set_rangeEj12source_rangeb+3424>
> "linemap_macro_map_lookup")
> at /nasfarm/edelsohn/src/src/gcc/diagnostic.c:1332
> #1 0x100169b4 in _Z14linemap_lookupP9line_mapsj (set=0x70000000, line=991)
> at /nasfarm/edelsohn/src/src/libcpp/line-map.c:991
> #2 0x100188f8 in
> _Z40linemap_unwind_to_first_non_reserved_locP9line_mapsjPPK8line_map
> (set=0x70000000, loc=991, map=0x0)
> at /nasfarm/edelsohn/src/src/libcpp/line-map.c:1629
> #3 0x100753c8 in _ZL17expand_location_1jb (loc=889323520,
> expansion_point_p=false) at /nasfarm/edelsohn/src/src/gcc/input.c:158
> #4 0x10076488 in _Z48linemap_client_expand_location_to_spelling_pointj (
> loc=991) at /nasfarm/edelsohn/src/src/gcc/input.c:751
> #5 0x10019928 in _ZN13rich_location9add_rangeEjjb (this=0x2ff21cd8,
> start=991, finish=889323520, show_caret_p=true)
> at /nasfarm/edelsohn/src/src/libcpp/line-map.c:2012
> #6 0x10019a54 in _ZN13rich_locationC2EP9line_mapsj (this=0x2ff21cd8,
> set=0x3df, loc=287928112)
> at /nasfarm/edelsohn/src/src/libcpp/line-map.c:2024
> #7 0x1000ed84 in _Z7warningiPKcz (opt=164,
> gmsgid=0x11488d18
> <_GLOBAL__F__Z20prepare_call_addressP9tree_nodeP7rtx_defS2-
> _PS2_ii+3752> "function call has aggregate value")
> at /nasfarm/edelsohn/src/src/gcc/diagnostic.c:1003
> #8 0x1067ebac in _Z11expand_callP9tree_nodeP7rtx_defi (exp=0x700dcf20,
> target=0x700ec080, ignore=0) at /nasfarm/edelsohn/src/src/gcc/calls.c:2476
> #9 0x10406858 in
> _Z18expand_expr_real_1P9tree_nodeP7rtx_def12machine_mode15expand_modifierPS2_b
> (exp=0x700dcf20, target=0x700ec080, tmode=BLKmode,
> modifier=EXPAND_NORMAL, alt_rtl=0x17, inner_reference_p=false)
> at /nasfarm/edelsohn/src/src/gcc/expr.c:10581
> #10 0x104158c0 in _Z22store_expr_with_boundsP9tree_nodeP7rtx_defibbS0_ (
> exp=0x700dcf20, target=0x700ec080, call_param_p=0, nontemporal=false,
> reverse=false, btarget=0x700df058)
> at /nasfarm/edelsohn/src/src/gcc/expr.c:5405
> #11 0x104178fc in _Z17expand_assignmentP9tree_nodeS0_b (to=0x700df058,
> from=0x700dcf20, nontemporal=false)
> at /nasfarm/edelsohn/src/src/gcc/expr.c:5174
> #12 0x106f67b4 in _ZL18expand_gimple_stmtP6gimple (stmt=0x7000e240)
> at /nasfarm/edelsohn/src/src/gcc/cfgexpand.c:6278
> #13 0x106f87d8 in _ZL25expand_gimple_basic_blockP15basic_block_defb (
> bb=0x700c7740, disable_tail_calls=false)
> at /nasfarm/edelsohn/src/src/gcc/cfgexpand.c:5679
> #14 0x106ffbf4 in _ZN12_GLOBAL__N_111pass_expand7executeEP8function (
> this=0x11296dc0
> <_GLOBAL__F__ZN9text_info9set_rangeEj12source_rangeb+3056>,
> fun=0x70009138) at /nasfarm/edelsohn/src/src/gcc/cfgexpand.c:6291
I attempted to reproduce this on gcc111 (powerpc-ibm-aix7.1.3.0)
../src/configure --disable-bootstrap --with-gmp=/opt/cfarm/gmp-latest
--with-mpfr=/opt/cfarm/mpfr-latest --with-mpc=/opt/cfarm/mpc-latest
with latest trunk (r230384).
I saw only one ICE within "make check-gcc", when running
gcc.c-torture/execute/scal-to-vec1.c; specifically:
/home/dmalcolm/gcc-build/build/gcc/xgcc \
-B/home/dmalcolm/gcc-build/build/gcc/ \
/home/dmalcolm/gcc-build/src/gcc/testsuite/gcc.c-torture/execute/scal-to-vec1.c
\
-fno-diagnostics-show-caret -fdiagnostics-color=never \
-O0 -w -lm -o ./scal-to-vec1.exe
and this shows the same assertion failure as your report.
I was able to reproduce that ICE at will under gdb; from what I could
tell from gdb, a seemingly valid location is passed in to warning_at,
but at warning_at, the 32-bit value is seemingly corrupt, and this
eventually leads to an assertion failure in the new code. The warning
is then discarded (OPT_Wvector_operation_performance). I can't tell yet
if the data is corrupt, or if gdb is somehow getting confused about the
values as I go up and down the callstack (or indeed if I am), but it's
getting late here.
