This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug tree-optimization/84470] test for address of member being null not eliminated
- From: "rguenth at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: Tue, 27 Feb 2018 11:28:35 +0000
- Subject: [Bug tree-optimization/84470] test for address of member being null not eliminated
- Auto-submitted: auto-generated
- References: <bug-84470-4@http.gcc.gnu.org/bugzilla/>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84470
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2018-02-27
Ever confirmed|0 |1
--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
Hmm, is p->a valid to compute if p is NULL? Is it valid to compute p->b if p
is NULL for
struct A { char a[4]; char b[4]; };
?
Because you say "could" in
if (p->a == 0) // could only be true when p is null
__builtin_abort (); // can be eliminated
which implies it would invoke undefined behavior?
ISTR we still want to not break old offsetof implementations using &(T
*)0->member
style computation?
But yes, wrapping rules say that &p->m is never NULL if m is not a member
at offset zero. See tree_single_nonzero_warnv_p for ADDR_EXPR handling.