From: Joseph Myers <joseph@codesourcery.com>
To: "Uecker, Martin" <Martin.Uecker@med.uni-goettingen.de>
Cc: "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] mixing of labels and code in C2X
Date: Mon, 14 Sep 2020 20:30:42 +0000 [thread overview]
Message-ID: <alpine.DEB.2.21.2009142012590.13061@digraph.polyomino.org.uk> (raw)
In-Reply-To: <1599996046.28509.3.camel@med.uni-goettingen.de>
On Sun, 13 Sep 2020, Uecker, Martin wrote:
> Hi Joseph,
>
> here is the (unfinished) patch to support
> mixing of labels in C2X.
I think there should be explicit tests for old standard versions
(c11-labels-1.c etc.) that these usages are errors with -pedantic-errors
with the old -std option, are warnings with -pedantic, and are quietly
accepted with neither. In addition to using -pedantic-errors with the new
standard version test to confirm it's not diagnosed, and a test with the
new version and -Wc11-c2x-compat.
By way of example of further places that I think need changing in the
patch: at present, c_parser_label gives an error (that you correctly
change to a pedwarn_c11) if the label is followed by a declaration - and
then parses the declaration itself rather than leaving it to be parsed in
the caller. So c_parser_compound_statement_nostart would parse a label
followed by a declaration, and at that point last_label would be set to
true, meaning that a second declaration would be rejected, when in C2x it
should be accepted. You can see this even without the patch with a test
such as:
void
f (void)
{
label : int a; int b;
}
I think that instead c_parser_label should never try to parse a
declaration following the label; that should be left for the caller to
handle. To avoid c_parser_label needing to return information about
standard attributes on a following declaration, maybe it shouldn't parse
standard attributes either (note that means that c_parser_all_labels would
need to handle parsing and warning about and discarding standard
attributes after each label instead - such attributes might be ones on a
statement, or ones on the next label in a sequence of labels).
Then of course the checks of last_label in
c_parser_compound_statement_nostart would need to become checks for
whether to pedwarn_c11 about the use of a label in a given context, once
the code knows whether there is a declaration, rather than preventing
parsing a declaration there at all. So probably c_parser_label would no
longer have the pedwarn_c11 either; that would all be left to its callers.
--
Joseph S. Myers
joseph@codesourcery.com
next prev parent reply other threads:[~2020-09-14 20:30 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-13 11:20 Uecker, Martin
2020-09-14 20:30 ` Joseph Myers [this message]
2020-11-01 22:34 ` Uecker, Martin
2020-11-02 21:16 ` Joseph Myers
2020-11-06 6:56 ` Uecker, Martin
2020-11-06 22:07 ` Joseph Myers
2020-11-06 22:25 ` Uecker, Martin
2020-11-06 22:44 ` Joseph Myers
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=alpine.DEB.2.21.2009142012590.13061@digraph.polyomino.org.uk \
--to=joseph@codesourcery.com \
--cc=Martin.Uecker@med.uni-goettingen.de \
--cc=gcc-patches@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).