------- Comment #18 from ebotcazou at gcc dot gnu dot org 2005-10-11 22:21
-------
> Sorry -- my idea about fixing this in the front end is bogus. It's OK to
> dereference a pointer-to-member to a virtual function member even if the base
> class doesn't have any virtual functions;
Too bad. :-(
> I don't understand your Comment #12 regarding MEM_NO_TRAP_P; MEM_NO_TRAP_P
> calls rtx_addr_can_trap_p.
Not quite, MEM_NOTRAP_P is a RTL flag that may be put on a MEM to assert that
the memory reference doesn't trap; in particular, you're allowed to put it on
any stack slot reference as far as I understand.
> I'd suspect that making rtx_addr_can_trap_p respect STRICT_ALIGNMENT (by
> checking the values of the CONST_INT added to the non-trapping address) would
> work.
Modulo the MEM_NOTRAP_P thing above, I agree. But I'm not sure enhancing the
existing may_trap_p is the way to go, because as far as I can tell you want to
optimize away this faulting memory ref if you can, and may_trap_p MEMs cannot
be optimized away with -fnon-call-exceptions for example. So I'd lean towards
adding a may_fault_p predicate that supercedes may_trap_p and using it in the
reorg pass.
--
ebotcazou at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot
|dot org |org
Status|NEW |ASSIGNED
Last reconfirmed|2005-10-10 22:42:25 |2005-10-11 22:21:07
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23585
