Re: libcpp/C FE source range patch committed (r230331).

[David Malcolm <dmalcolm at redhat dot com>]

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.