From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa3.mentor.iphmx.com (esa3.mentor.iphmx.com [68.232.137.180]) by sourceware.org (Postfix) with ESMTPS id D0E603857C6B for ; Mon, 14 Sep 2020 20:30:55 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D0E603857C6B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=joseph_myers@mentor.com IronPort-SDR: MjAXh3tj4R5G3hmOkps9l7kQ4okqlMxDQragraBXUDcEWGjBxCm2//kvsZau6DQVUEXKrD0s4S MB6GDfqOS6pU9vFkKZEWCdapWv5Xe5YTXZ1Cn5kEk6S3iPcYlTmKmlsqcT2CRjLYZVOb9Ay58H SlZXV7+SMY7fofSzgD4bYMBiQdHk+7lwXW4K0PyFermp/ZWuKGhM234U52W2EfpotrNPsn2Lvo cPGxSwOFa9ggwy5q3wnZtksr2d4WbqWnOimsJ98G7B/9hjKE40yt+XsZJ1J8g3o4nAS2baSo9o QBo= X-IronPort-AV: E=Sophos;i="5.76,427,1592899200"; d="scan'208";a="52870538" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa3.mentor.iphmx.com with ESMTP; 14 Sep 2020 12:30:54 -0800 IronPort-SDR: nYYiTDsUH6nkWIglS4BQXCUH2b452i2ufA4VJPeuYvBYSH982ROq0p391Hia50wBT98K4XBOoo rmyPlcq4MV7Bv2MPfOt014q0MqpDars57V/r8aNNKXOvS+kP0SBORLPDH70uOjcH3+A6UIRSoq rzj8by6NA8OjKiGuRC82bTpUMrpd8sv8LRdLuJj1l8V5PH8PafMof4zZj2dDjb3PooMWh/lsDS 8p7ZoL6pSD+d654QC/6lLKd8A7zFIjvy8agPFERlYxC2VXtWsu12+7YHjjLM2Js6So/yqgHUJb tTU= Date: Mon, 14 Sep 2020 20:30:42 +0000 From: Joseph Myers X-X-Sender: jsm28@digraph.polyomino.org.uk To: "Uecker, Martin" CC: "gcc-patches@gcc.gnu.org" Subject: Re: [PATCH] mixing of labels and code in C2X In-Reply-To: <1599996046.28509.3.camel@med.uni-goettingen.de> Message-ID: References: <1599996046.28509.3.camel@med.uni-goettingen.de> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-06.mgc.mentorg.com (139.181.222.6) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-3127.1 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 14 Sep 2020 20:30:57 -0000 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