[Bug rtl-optimization/23585] [4.0 regression] mem_fun* code fine with -O1, bus error with -O2

["mark at codesourcery dot com" <gcc-bugzilla@gcc.gnu.org>]

------- Comment #11 from mark at codesourcery dot com  2005-10-11 14:22 -------
Subject: Re:  [4.0 regression] mem_fun* code fine
 with -O1, bus error with -O2

ebotcazou at gcc dot gnu dot org wrote:
> ------- Comment #10 from ebotcazou at gcc dot gnu dot org  2005-10-11 13:59 -------
> 
>>may_trap_p is the correct thing as it should detect this instruction as
>>trapping:
>>
>>  /* Memory ref can trap unless it's a static var or a stack slot.  */
>>     case MEM:
>>       if (MEM_NOTRAP_P (x))
>>         return 0;
>>       return rtx_addr_can_trap_p (XEXP (x, 0));
> 
> 
> No, it's the other way around.  The MEM is a stack slot so may_trap_p returns
> 0.

This certainly is a bug in the back-end, not a bug in the default
location of the v-bit.  You shouldn't need to break the C++ ABI on SPARC
to fix this bug.

However, I'm not sure why you're seeing a 4-byte load from an unaligned
address.  One possibility is that in rtx_addr_can_trap_p:

    case PLUS:
      /* An address is assumed not to trap if it is an address that
can't
         trap plus a constant integer or it is the pic register plus a

         constant.  */
      return ! ((! rtx_addr_can_trap_p (XEXP (x, 0))
                 && GET_CODE (XEXP (x, 1)) == CONST_INT)
                || (XEXP (x, 0) == pic_offset_table_rtx
                    && CONSTANT_P (XEXP (x, 1))));

we should consider the address as unsafe if the CONST_INT is not a
multiple of the size of the mode, on a STRICT_ALIGNMENT target.


-- 


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