This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH 2/4] c/c++, asm: Use nicer error for duplicate asm qualifiers
On Wed, Dec 12, 2018 at 06:23:08PM -0500, David Malcolm wrote:
> On Wed, 2018-12-12 at 11:40 -0600, Segher Boessenkool wrote:
> > > Is there test coverage for these errors and notes?
> >
> > Yes, in this same patch. The error, that is; I have no idea how to
> > test
> > the note, and that belongs in a different test anyhow. Dejagnu
> > ignores
> > notes normally.
>
> You can use dg-message to test for a note. The ignoring of notes is
> done by prune.exp, which strips out any notes that are unmatched after
> the dg-message runs.
>
> There are numerous examples in the testsuite, see e.g
> gcc.dg/floatn-errs.c
> which has:
>
> extern float a; /* { dg-message "previous declaration" } */
> extern _Float32 a; /* { dg-error "conflicting" } */
Hrm.
> > > A diagnostic nit (new with gcc 9): please add an:
> > > auto_diagnostic_group d;
> > > to the start of the guarded block, so that the "error" and "note"
> > > are
> > > known to be related.
> >
> > How would that work for
> >
> > asm volatile goto volatile goto ("uh-oh" :::: lab); lab :;
> >
> > There are two groups, overlapping, but not nested. I suppose
> > something
> > could be done with new() but that is too ugly for words. Is there a
> > procedural interface, too? Something that does not depend on C++
> > magic.
>
> If I'm understanding the patch correctly, I'd expect it to output
> something like:
>
> error: duplicate asm qualifier 'volatile'
> asm volatile goto volatile goto ("uh-oh" :::: lab); lab :;
> ^~~~~~~~
> note: first seen here
> asm volatile goto volatile goto ("uh-oh" :::: lab); lab :;
> ^~~~~~~~
> error: duplicate asm qualifier 'goto'
> asm volatile goto volatile goto ("uh-oh" :::: lab); lab :;
> ^~~~
> note: first seen here
> asm volatile goto volatile goto ("uh-oh" :::: lab); lab :;
> ^~~~
Yup.
> where each error/note pair are in their own diagnostic group. I don't
> think it matters that the locations "overlap" here.
So how can I do that, "put them in their own group"? As far as I can
see the interface allows only nested groups.
> There isn't a procedural interface for diagnostic groups - though there
> could be if needed. I think the existing auto_diagnostic_group
> ctor/dtor ought to work here. We definitely don't want/need to be
> using new, I agree that that would be wrong.
If you declare the auto_group somewhere inside the switch (or anywhere
in the loop even), no two qualifiers will be in the same group; and if
you put the auto_group outside the loop, all asm qualifiers will be in
one and the same group. Or, what do I misunderstand here?
> Let me know if you want me to update the patch for you.
Please do a separate patch on top?
> Hope this is constructive
It is :-)
Segher