On Fri, 5 Apr 2019 at 09:38, Richard Biener <rguent...@suse.de> wrote:
>
> On Wed, 3 Apr 2019, Christophe Lyon wrote:
>
> > 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).
>
> Hmm, yeah. The question is why do some targets warn and some do not?
Well, that's a target-dependent warning from the linker, because on arm
there is an attribute to describe the type of enums. But indeed it seems it
should apply to all targets, however it could trigger lots of false positives.
> Anyway, can you investigate a dg-prune/message solution instead?
Sure, it seems to work with:
/* { dg-prune-output "use of enum values across objects may fail" } */
which is not target-dependent though.
I'll commit that if there is no objection.
Christophe
> Thanks,
> Richard.
>
> > > Christophe
> > >
> > > > Thanks,
> > > > Richard.
> >
>
> --
> Richard Biener <rguent...@suse.de>
> SUSE Linux GmbH, Maxfeldstrasse 5, 90409 Nuernberg, Germany;
> GF: Felix Imendörffer, Mary Higgins, Sri Rasiah; HRB 21284 (AG Nürnberg)
