[Bug target/27082] segfault with virtual class and visibility ("hidden")

["roger at eyesopen dot com" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #14 from roger at eyesopen dot com  2006-06-19 23:50 -------
Unfortunately, I'm unable to reproduce this failure with a cross-compiler to
alphaev68-unknown-linux-gnu.  However, examination of the tracebacks attached
to this PR and the relevant source code reveals there is a potential problem.
It looks like alpha_expand_mov can call force_const_mem on RTL expressions that
are CONSTANT_P but that potentially don't satify
targetm.cannot_force_const_mem,
such as CONST etc...  This would lead to precisely the failures observed in the
discussion.  operands[1] gets overwritten by NULL_RTX, and we then call
validize_mem on a NULL pointer!  Kaboom!

I think one aspect of the solution is the following patch:

Index: alpha.c
===================================================================
*** alpha.c     (revision 114721)
--- alpha.c     (working copy)
*************** alpha_expand_mov (enum machine_mode mode
*** 2227,2232 ****
--- 2227,2237 ----
        return true;
      }

+   /* Don't call force_const_mem on things that we can't force
+      into the constant pool.  */
+   if (alpha_cannot_force_const_mem (operands[1]))
+     return false;
+
    /* Otherwise we've nothing left but to drop the thing to memory.  */
    operands[1] = force_const_mem (mode, operands[1]);
    if (reload_in_progress)

However, it's not impossible that this will prevent the current failure only
to pass the problematic operand on to somewhere else in the compiler.

Could someone who can reproduce this failure, try the above patch and see
if there's any downstream fallout?  It would also be great to see what the
problematic RTX looks like.  I'm pretty sure its either a SYMBOL_REF, a
LABEL_REF or a CONST.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27082