Linaro GCC 4.6-2011.06-0 gets ICE when compiling bionic's libm

Michael Hope wasn't able to reproduce this with a plain gcc-linaro-4.6-2011.06.

The "--disable-libquadmath" switch that the Linaro Android folks are using does not seem to be related. If it's omitted a configure test of the target libiberty would fail as described here: https://bugs.launchpad.net/gcc-linaro/+bug/809435 . With HP's patch applied and libquadmath enabled the ICE remains.

Can you capture a core and get a backtrace with gdb? And test with -O0 to see if the SEGV goes away? I have encountered a segfaulting null-pointer-reference optimizer bug in fold_stmt_1(), which I haven't filed yet (the testcase is almost 80K lines and probably not something I can post publicly as-is) but have worked around. (Patch at https://github.com/mkedwards/crosstool-ng/blob/master/patches/gcc/linaro-4.6-bzr/1008-handle-statement-removal.patch)

@Michael - thanks for the hint! It won't segfault with -Os and -O0 but with -O1, -O2 and -O3. I think it's something different. I haven't get a chance to take a closer look. I'll attach a core file and a backtrace. But I haven't figured you how to build the Android GCC with -g yet.

Program received signal SIGSEGV, Segmentation fault.
0x0824ffd6 in multiple_reg_loc_descriptor ()
(gdb) bt
#0 0x0824ffd6 in multiple_reg_loc_descriptor ()
#1 0x0824fdc8 in reg_loc_descriptor ()
#2 0x08252a31 in loc_descriptor ()
#3 0x08252b41 in loc_descriptor ()
#4 0x0825355d in dw_loc_list_1 ()
#5 0x08253d55 in dw_loc_list ()
#6 0x082548cd in loc_list_from_tree ()
#7 0x08257b3a in add_location_or_const_value_attribute ()
#8 0x0825cab2 in gen_variable_die ()
#9 0x0825f391 in gen_decl_die ()
#10 0x0825e7d6 in process_scope_var ()
#11 0x0825e814 in decls_for_scope ()
#12 0x0825c0af in gen_subprogram_die ()
#13 0x0825f1bf in gen_decl_die ()
#14 0x0825fac5 in dwarf2out_decl ()
#15 0x0825faf6 in dwarf2out_function_decl ()
#16 0x082b06a9 in rest_of_handle_final ()
#17 0x083b5643 in execute_one_pass ()
#18 0x083b57ff in execute_pass_list ()
#19 0x083b581b in execute_pass_list ()
#20 0x083b581b in execute_pass_list ()
#21 0x084c9e20 in tree_rest_of_compilation ()
#22 0x086507e4 in cgraph_expand_function ()
#23 0x08650993 in cgraph_expand_all_functions ()
#24 0x08650fc4 in cgraph_optimize ()
#25 0x0864f729 in cgraph_finalize_compilation_unit ()
#26 0x0812d5c5 in c_write_global_declarations ()
#27 0x084751d8 in compile_file ()
#28 0x08476e10 in do_compile ()
#29 0x08476f62 in toplev_main ()
#30 0x081a5c13 in main ()

It might be a ARM specific bug in the ARM backend that implements TARGET_DWARF_REGISTER_SPAN target hook http://gcc.gnu.org/onlinedocs/gccint/Exception-Region-Output.html#index-TARGET_005fDWARF_005fREGISTER_005fSPAN-4599 . See: arm.c:arm_dwarf_register_span() (starts at line 22533)

The gcc/dwarf2out.c:reg_loc_descriptor() calls the target hook like this (line 13355):
regs = targetm.dwarf_register_span (rtl);

The input is:
  (gdb) p debug_rtx (rtl)
  (reg:SI 95 d16 [orig:149 lx ] [149])

The output is an empty array:
  (gdb) p debug_rtx (regs)
  (parallel [])

I'll attach a small patch that solves the ICE but it would be great if one of the more experienced GCC developers could have a look at this ICE too. There could be a better way to fix this.

The above patch prevents the ICE but also has the effect of not having the correct DWARF info. So, this is not an upstreamable fix for this bug.

GCC calls the ARM backend (arm_dwarf_register_span) with:
  (gdb) p debug_rtx (rtl)
  (reg:SI 95 d16 [orig:149 lx ] [149])

Wich mean we have SI mode in register d16. So, the mode size is 4 that gets devided by 8 which is zero and leads to the ICE. That code isn't really prepared to handle this case. It works if the mode size is a multiple of eight which is likely to happen for the operands of some NEON instruction. However, according to arm_hard_regno_mode_ok() SI more and d16 seems to be an illegal combination. Now, the question is how did we get there.

I've uploaded a debuggable cc1 executable (-O0 -ggdb) to http://people.linaro.org/~kwerner/809768-cc1.tar.bz2 . The .i file, the cmd line to reproduce the ICE and the backtrace is also included.

A binary toolchain with the 809768-workaround.patch applied can be found at http://people.linaro.org/~kwerner/linaro-4.6-toolchain-install.tar.bz2 . This is mainly for testing purposes for the Linaro Android folks.

The (reg:SI 95 d16 [orig:149 lx ] [149]) is generated by the cprop_hardreg pass substituting d16 for r2 inside a var_location debug insn.

Of course, the regcprop.c code does perform the usual back-end checks:

static bool
mode_change_ok (enum machine_mode orig_mode, enum machine_mode new_mode,
                unsigned int regno ATTRIBUTE_UNUSED)
{
  if (GET_MODE_SIZE (orig_mode) < GET_MODE_SIZE (new_mode))
    return false;

#ifdef CANNOT_CHANGE_MODE_CLASS
  return !REG_CANNOT_CHANGE_MODE_P (regno, orig_mode, new_mode);
#endif

  return true;
}

However, in Linaro GCC 4.6, the REG_CANNOT_CHANGE_MODE_P check does not prohibit the change from DFmode to SImode in register 95 (d16), even though HARD_REGNO_MODE_OK would reject SImode in d16.

This seems an inconsistency in the back-end. This looks to have been introduced via a backport from mainline of the following patch:

http://gcc.gnu.org/ml/gcc-patches/2011-03/msg01631.html

2011-05-05 Richard Sandiford <email address hidden>

       gcc/
       Backport from mainline:

       2011-03-25 Richard Sandiford <email address hidden>

       * config/arm/arm.h (CANNOT_CHANGE_MODE_CLASS): Restrict FPA_REGS
       case to VFPv1.

Richard, any thoughts? Should CANNOT_CHANGE_MODE_CLASS accept modes in registers that are not accepted by HARD_REGNO_MODE_OK? If not, should regcprop.c check both macros?

Uli, Thanks for your thorough analysis!
I can confirm that the ICE does not occur with the old CANNOT_CHANGE_MODE_CLASS macro.

Ulrich Weigand <email address hidden> writes:
> The (reg:SI 95 d16 [orig:149 lx ] [149]) is generated by the
> cprop_hardreg pass substituting d16 for r2 inside a var_location debug
> insn.
>
> Of course, the regcprop.c code does perform the usual back-end checks:
>
> static bool
> mode_change_ok (enum machine_mode orig_mode, enum machine_mode new_mode,
> unsigned int regno ATTRIBUTE_UNUSED)
> {
> if (GET_MODE_SIZE (orig_mode) < GET_MODE_SIZE (new_mode))
> return false;
>
> #ifdef CANNOT_CHANGE_MODE_CLASS
> return !REG_CANNOT_CHANGE_MODE_P (regno, orig_mode, new_mode);
> #endif
>
> return true;
> }

We ought to be checking HARD_REGNO_MODE_OK as well. That's required
for correctness even on targets for which CANNOT_CHANGE_MODE_CLASS
is not defined.

CANNOT_CHANGE_MODE_CLASS is designed to be used in cases where mode
changes aren't allowed even though the old and new registers are
valid as far as HARD_REGNO_MODE_OK is concerned.

Richard

The fault doesn't seem to occur on a 64 bit host with a 64 bit GCC. It does occur on a 64 bit host with the default 32 bit GCC that linaro-build.sh tries to build.

Note that there are two work arounds:
 * Remove the -g
 * Build at -Os or -O0

FWIW -- and it took me depressingly long to figure this out --
the easiest way of making sure that the bug triggers is to
recompile dwarf2out.c with -O0. The segfault comes from
the rhs of the size assignment here:

  gcc_assert (GET_CODE (regs) == PARALLEL);

  size = GET_MODE_SIZE (GET_MODE (XVECEXP (regs, 0, 0)));
  loc_result = NULL;

The assignment is dead, so a sufficiently clever compiler
will optimise it (and the segfault) away.

This patch seems to fix it. I'll run a full test and submit upstream.

blocks android binary toolchain build from building android platform to a working state. Should justify a -1 tarball respin. doing a testbuild; wait for confirm.

Thanks Richard! After applying your patch onto gcc-linaro-4.6-2011.07 the ICE is gone and I was able to complete the build of Linaro-Android for my PandaBoard.

Need to confirm that this exists in the -stable branch.

This has been committed upstream.

Related: lp:gcc-linaro/4.6,revno=106782