From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 62699 invoked by alias); 19 Dec 2018 19:01:11 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 62684 invoked by uid 89); 19 Dec 2018 19:01:10 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=researched, *parser X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 19 Dec 2018 19:01:07 +0000 Received: from svr-orw-mbx-06.mgc.mentorg.com ([147.34.90.206]) by relay1.mentorg.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-SHA384:256) id 1gZh5d-0006SN-IG from Thomas_Schwinge@mentor.com ; Wed, 19 Dec 2018 11:01:05 -0800 Received: from SVR-ORW-MBX-06.mgc.mentorg.com (147.34.90.206) by SVR-ORW-MBX-06.mgc.mentorg.com (147.34.90.206) with Microsoft SMTP Server (TLS) id 15.0.1320.4; Wed, 19 Dec 2018 11:01:03 -0800 Received: from tftp-cs (147.34.91.1) by SVR-ORW-MBX-06.mgc.mentorg.com (147.34.90.206) with Microsoft SMTP Server id 15.0.1320.4 via Frontend Transport; Wed, 19 Dec 2018 11:01:03 -0800 Received: by tftp-cs (Postfix, from userid 49978) id 9C8E9C2322; Wed, 19 Dec 2018 11:01:02 -0800 (PST) From: Thomas Schwinge To: David Malcolm CC: , Subject: Re: [PATCH 1/2] C++: more location wrapper nodes (PR c++/43064, PR c++/43486) In-Reply-To: <1541449869-59851-1-git-send-email-dmalcolm@redhat.com> References: <1541449869-59851-1-git-send-email-dmalcolm@redhat.com> User-Agent: Notmuch/0.9-125-g4686d11 (http://notmuchmail.org) Emacs/25.2.2 (x86_64-pc-linux-gnu) Date: Wed, 19 Dec 2018 19:01:00 -0000 Message-ID: <874lb9qr2u.fsf@euler.schwinge.homeip.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-SW-Source: 2018-12/txt/msg01409.txt.bz2 Hi David! I will admit that I don't have researched ;-/ what this is actually all about, and how it's implemented, but... On Mon, 5 Nov 2018 15:31:08 -0500, David Malcolm wro= te: > The C++ frontend gained various location wrapper nodes in r256448 (GCC 8). > That patch: > https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00799.html > added wrapper nodes around all nodes with !CAN_HAVE_LOCATION_P for: >=20 > * arguments at callsites, and for >=20 > * typeid, alignof, sizeof, and offsetof. >=20 > This is a followup to that patch, adding many more location wrappers > to the C++ frontend. It adds location wrappers for nodes with > !CAN_HAVE_LOCATION_P to: >=20 > * all literal nodes (in cp_parser_primary_expression) >=20 > * all id-expression nodes (in finish_id_expression), except within a > decltype. >=20 > * all mem-initializer nodes within a mem-initializer-list > (in cp_parser_mem_initializer) >=20 > However, the patch also adds some suppressions: regions in the parser > for which wrapper nodes will not be created: >=20 > * within a template-parameter-list or template-argument-list (in > cp_parser_template_parameter_list and cp_parser_template_argument_list > respectively), to avoid encoding the spelling location of the nodes > in types. For example, "array<10>" and "array<10>" are the same type, > despite the fact that the two different "10" tokens are spelled in > different locations in the source. >=20 > * within a gnu-style attribute (none of are handlers are set up to cope > with location wrappers yet) >=20 > * within various OpenMP clauses ... I did wonder why things applicable to OpenMP wouldn't likewise apply to OpenACC, too? That is: > (cp_parser_omp_all_clauses): Don't create wrapper nodes within > OpenMP clauses. > (cp_parser_omp_for_loop): Likewise. > (cp_parser_omp_declare_reduction_exprs): Likewise. > @@ -33939,6 +33968,9 @@ cp_parser_omp_all_clauses (cp_parser *parser, omp= _clause_mask mask, > bool first =3D true; > cp_token *token =3D NULL; >=20=20 > + /* Don't create location wrapper nodes within OpenMP clauses. */ > + auto_suppress_location_wrappers sentinel; > + > while (cp_lexer_next_token_is_not (parser->lexer, CPP_PRAGMA_EOL)) > { > pragma_omp_clause c_kind; > @@ -35223,6 +35255,10 @@ cp_parser_omp_for_loop (cp_parser *parser, enum = tree_code code, tree clauses, > } > loc =3D cp_lexer_consume_token (parser->lexer)->location; >=20=20 > + /* Don't create location wrapper nodes within an OpenMP "for" > + statement. */ > + auto_suppress_location_wrappers sentinel; > + > matching_parens parens; > if (!parens.require_open (parser)) > return NULL; > @@ -37592,6 +37628,8 @@ cp_parser_omp_declare_reduction_exprs (tree fndec= l, cp_parser *parser) > else > { > cp_parser_parse_tentatively (parser); > + /* Don't create location wrapper nodes here. */ > + auto_suppress_location_wrappers sentinel; > tree fn_name =3D cp_parser_id_expression (parser, /*template_p=3D*/fa= lse, > /*check_dependency_p=3D*/true, > /*template_p=3D*/NULL, Shouldn't "cp_parser_oacc_all_clauses" (and "some" other functions?) be adjusted in the same way? How would I test that? (I don't see any OpenMP test cases added -- I have not yet tried whether any problems would become apparent when temporarily removing the OpenMP changes cited above.) Gr=C3=BC=C3=9Fe Thomas