On Thu, 14 Jan 2021, Jakub Jelinek wrote:
> On Thu, Jan 14, 2021 at 11:05:40AM +0100, Richard Biener wrote:
> > > > Could we print
> > > > t.u.b
> > > > if the TBAA type is compatible with the type of the reference and
> > > > perhaps
> > > > *(int*)&t.u.b
> > > > if it is incompatible?
> > > > >From the aliasing perspective that is still different, but we don't
> > > > >print
> > > > the TBAA type anyway.
> >
> > True. As said we could simply add a GCC extension to write a MEM_REF
> > in source and print that syntax ... then it would be valid (GCC) C/C++.
>
> But even if we do that unless people are familiar with that extension they
> wouldn't know what it means (and they didn't write it in that way in their
> source).
I'd just use it in case we can't express it in the C/C++ way (thus when
the TBAA type differs). We already print {ref-all} in type dumping
for example, which isn't C/C++ either.
> > > There is another option I forgot about, but perhaps it is too verbose.
> > > Print
> > > *(int*)((char*)&t + offsetof (struct T, u.b))
> >
> > or rather offsetof (struct T, u) to not single out a specific union
> > member?
>
> Sure, I can just get rid of the UNION_TYPE handling from the function,
> or use it only if the TBAA access type is compatible.
Sure.
I wonder if we can use some pp flags to tell whether we're being
called from FE or middle-end diagnostics and thus whether we
should try to produce source-like expressions or can expect
weird GIMPLE IL derived expressions.
Richard.
