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