On Thu, 4 May 2023, Jason Merrill wrote: > On 5/4/23 09:59, Richard Biener wrote: > > > > I've previously sent > > https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608077.html > > adding ADDR_EXPR_NONZERO and there were comments from Jason > > where I just realized I ignored ARRAY_REF for the following. > > Anyway, here's a more aggressive variant not going for an extra > > flag set by the frontend but instead have the middle-end treat > > all &*.component as non-NULL (all handled_component_p). > > > > This passes bootstrap for all languages, testing there isn't > > complete but it already shows for example > > gcc.c-torture/execute/pr44555.c explicitely testing that > > we keep &p->z NULL when p is NULL and z is at offset zero. > > > > There's also execute FAILs for gfortran.dg/class_optional_2.f90 > > and some optimization dump scan fails I did not yet investigate. > > > > Nevertheless I'd like to hear opinions on whether a middle-end > > implementation without frontend help is the way to go and > > what the reasonable restrictions should be there? Is > > gcc.c-torture/execute/pr44555.c sanctioned by the C standard? > > If so I think we have a lost cause without some help from > > the frontend? > > The relevant C++ rule is https://eel.is/c++draft/expr.ref#8
OK, I can second-guess that the nullptr object doesn't have the type specified by the pointer type but is more or less void which would make subsetting invoke undefined behavior. > The corresponding C clause doesn't have as explicit a rule that I can see, I > don't know what the sense of the C committee is about this. The special > allowance for the common initial sequence suggests such that it is an > exception to such a rule, but I'm not sure where that rule is, exactly. > > I imagine that not all languages are as strict about this, so an unconditional > rule like this may not be what we want. Looks like that then. The original proposal would make that explicit on the ADDR_EXPR though I could imagine we could alternatively put a flag on the COMPONENT_REF as well. > And as I think I commented before, this kind of assumption based on undefined > behavior ought to have a -fsanitize=undefined check. Agreed. I don't feel like poking on the C++ too much so I hope that eventually somebody else will pick this up. Thanks, Richard.
