On 3/29/19 9:09 AM, Jason Merrill wrote: > On Fri, Mar 29, 2019 at 4:48 AM Richard Biener <rguent...@suse.de> wrote: >> >> 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. > > Ah, well. Looks good to me, then. Likewise. And with Joseph largely offline right now, that's going to have to be sufficient :-)
jeff
