On Thu, 26 May 2016, Marek Polacek wrote: > The C++ FE has been changed, as a part of c++/50800, in such a way that it no > longer considers types differentiating only in TYPE_REF_CAN_ALIAS_ALL > incompatible. But the C FE still rejects the following testcase, so this > patch > makes the C FE follow suit. After all, the may_alias attribute is not > considered as "affects_type_identity". This TYPE_REF_CAN_ALIAS_ALL check was > introduced back in 2004 (r90078), but since then we've gotten rid of them, > only > comptypes_internal retained it. I suspect the TYPE_MODE check might go too, > but I don't feel like changing that right now. > > This arised when discussing struct sockaddr vs. may_alias issue in glibc. > > Bootstrapped/regtested on x86_64-linux, ok for trunk?
I'd expect you to need to do something about composite types, to ensure that the composite type has TYPE_REF_CAN_ALIAS_ALL set if either of the two types does - along with tests in such a case, where the two types are in either order, that the composite type produced really is treated as may_alias. (The sort of cases I'm thinking of are typedef int T __attribute__((may_alias)); extern T *p; extern int *p; with the declarations in either order, and then making sure that type-based aliasing handles references through this pointer properly.) -- Joseph S. Myers jos...@codesourcery.com
