On Wed, 3 Apr 2019 at 15:19, Christophe Lyon <christophe.l...@linaro.org> wrote: > > On Wed, 3 Apr 2019 at 10:24, Richard Biener <rguent...@suse.de> wrote: > > > > On Wed, 3 Apr 2019, Christophe Lyon wrote: > > > > > Hi! > > > > > > On Fri, 29 Mar 2019 at 20:02, Jeff Law <l...@redhat.com> wrote: > > > > > > > > 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 :-) > > > > > > > > > > > > > I've noticed minor new errors at link time on arm with the 2 new > > > testcases. > > > pr71598-1.c complains on arm-none-eabi because > > > arm-none-eabi/bin/ld: warning: /ccu5w26t.o uses 32-bit enums yet the > > > output is to use variable-size enums; use of enum values across > > > objects may fail > > > > > > conversely, pr71598-2.c complains on arm-none-linux-gnueabi* because: > > > arm-none-linux-gnueabi/bin/ld: warning: /ccl5OUKi.o uses variable-size > > > enums yet the output is to use 32-bit enums; use of enum values across > > > objects may fail > > > > > > In both cases this is because crt0.o is built with the opposite > > > (default) short-enum option than the testcase, so the linker sees a > > > mismatch between crt0.o and pr71598-X.o. > > > > > > Shall I add target-dependent dg-warning directives in the testcases, > > > or is there a better way? > > > > Maybe dg-skip the test for target_short_enums which seems to exist? > > > > Can you try if that works and if so, commit the fix? > > > > Thanks, here is what I have committed as r270126. > (skip one test on short_enums targets, skip the other one on > non-short_enums targets) > However this has the drawback that pr71598-2.c is now skipped on aarch64 (and probably many other targets).
> Christophe > > > Thanks, > > Richard.
