On Thu, 28 Mar 2019, Jason Merrill wrote: > On 3/26/19 4:40 AM, Richard Biener wrote: > > On Mon, 18 Mar 2019, Richard Biener wrote: > > > > > On Fri, 15 Mar 2019, Jason Merrill wrote: > > > > > > > On 3/15/19 9:33 AM, Richard Biener wrote: > > > > > > > > > > The following is an attempt to fix PR71598 where C (and C++?) have > > > > > an implementation-defined compatible integer type for each enum > > > > > and the TBAA rules mandate that accesses using a compatible type > > > > > are allowed. > > > > > > > > This does not apply to C++; an enum does not alias its underlying type. > > > > > > Thus the following different patch, introducing c_get_alias_set and > > > only doing the special handling for C family frontends (I assume > > > that at least ObjC is also affected). > > > > > > Bootstrap & regtest running on x86_64-unknown-linux-gnu, OK? > > > > Ping. Also consider the additional testcase below to be added. > > > > Richard. > > > > 2019-03-18 Richard Biener <rguent...@suse.de> > > > > PR c/71598 > > * gimple.c: Include langhooks.h. > > (gimple_get_alias_set): Treat enumeral types as the underlying > > integer type. > > Won't this affect all languages?
It affects all languages during the LTO optimization phase, yes. There's unfortunately no way around that at the moment. Richard.
