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

["ebotcazou at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Comment #12 from ebotcazou at gcc dot gnu dot org  2005-10-11 14:41 -------
> 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.

Right, I was confused, I thought __pfn was dereferenced itself.

> However, I'm not sure why you're seeing a 4-byte load from an unaligned
> address.

Because p is a pointer to Class and Class has alignment 1.  I guess the first
branch of the expression works when Class contains a pointer to the vtable,
hence has alignment 4.

> 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.

Yes, but that's not enough, as MEM_NO_TRAP_P might come into play.


-- 


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