On Fri, 5 Apr 2019, Christophe Lyon wrote:
> 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.
Works for me.
Richard.
> 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)
>
--
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)
