public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Thomas Schwinge <thomas@codesourcery.com>
To: David Malcolm <dmalcolm@redhat.com>
Cc: <gcc-patches@gcc.gnu.org>, <jason@redhat.com>
Subject: Re: [PATCH 1/2] C++: more location wrapper nodes (PR c++/43064, PR c++/43486)
Date: Wed, 19 Dec 2018 19:01:00 -0000	[thread overview]
Message-ID: <874lb9qr2u.fsf@euler.schwinge.homeip.net> (raw)
In-Reply-To: <1541449869-59851-1-git-send-email-dmalcolm@redhat.com>

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 <dmalcolm@redhat.com> wrote:
> 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:
> 
> * arguments at callsites, and for
> 
> * typeid, alignof, sizeof, and offsetof.
> 
> 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:
> 
> * all literal nodes (in cp_parser_primary_expression)
> 
> * all id-expression nodes (in finish_id_expression), except within a
>   decltype.
> 
> * all mem-initializer nodes within a mem-initializer-list
>   (in cp_parser_mem_initializer)
> 
> However, the patch also adds some suppressions: regions in the parser
> for which wrapper nodes will not be created:
> 
> * 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.
> 
> * within a gnu-style attribute (none of are handlers are set up to cope
>   with location wrappers yet)
> 
> * 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 = true;
>    cp_token *token = NULL;
>  
> +  /* 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 = cp_lexer_consume_token (parser->lexer)->location;
>  
> +      /* 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 fndecl, cp_parser *parser)
>        else
>  	{
>  	  cp_parser_parse_tentatively (parser);
> +	  /* Don't create location wrapper nodes here.  */
> +	  auto_suppress_location_wrappers sentinel;
>  	  tree fn_name = cp_parser_id_expression (parser, /*template_p=*/false,
>  						  /*check_dependency_p=*/true,
>  						  /*template_p=*/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üße
 Thomas

  parent reply	other threads:[~2018-12-19 19:01 UTC|newest]

Thread overview: 34+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-11-05 19:44 David Malcolm
2018-11-05 19:44 ` [PATCH 2/2] C++: improvements to binary operator diagnostics (PR c++/87504) David Malcolm
2018-11-19 16:51 ` [PING] Re: [PATCH 1/2] C++: more location wrapper nodes (PR c++/43064, PR c++/43486) David Malcolm
2018-12-03 22:10   ` Jeff Law
2018-12-04 15:20     ` David Malcolm
2018-12-04 21:48     ` [PATCH 1/2] v2: " David Malcolm
2018-12-04 21:48       ` [PATCH 2/2] v2: C++: improvements to binary operator diagnostics (PR c++/87504) David Malcolm
2018-12-11 19:52         ` PING " David Malcolm
2018-12-12 20:43         ` Jason Merrill
2018-12-19 23:28           ` Aaron Sawdey
2018-12-20  2:13             ` [PATCH] -Wtautological-compare: fix comparison of macro expansions David Malcolm
2018-12-20 14:29               ` David Malcolm
2018-12-20 23:35                 ` Aaron Sawdey
2018-12-04 23:31     ` [PING] Re: [PATCH 1/2] C++: more location wrapper nodes (PR c++/43064, PR c++/43486) Jason Merrill
2018-12-07 19:25       ` [PATCH 1/2] v3: " David Malcolm
2018-12-12 20:37         ` Jason Merrill
2018-12-13 19:24           ` [PATCH] v4: " David Malcolm
2018-12-13 20:38             ` Jason Merrill
2018-12-14 23:29               ` [PATCH] v5: " David Malcolm
2018-12-17 19:33                 ` Jason Merrill
2018-12-17 23:30                   ` David Malcolm
2018-12-18 20:23                     ` Jason Merrill
2018-12-18 20:34                     ` [PATCH] v6: " David Malcolm
2018-12-18 20:40                       ` Jason Merrill
2018-12-19 15:35                         ` David Malcolm
2018-12-19 19:01 ` Thomas Schwinge [this message]
2018-12-20  2:29   ` [PATCH 1/2] " David Malcolm
2020-03-26  5:02   ` [PATCH, OpenACC] Bug fix for processing OpenACC data clauses in C++ Sandra Loosemore
     [not found]     ` <4a68ec90-456a-cf49-036e-471ba275706c@codesourcery.com>
2020-03-26 14:27       ` C++ 'NON_LVALUE_EXPR' in OMP array section handling (was: [PATCH, OpenACC] Bug fix for processing OpenACC data clauses in C++) Thomas Schwinge
2020-03-26 15:09         ` C++ 'NON_LVALUE_EXPR' in OMP array section handling Sandra Loosemore
2020-03-26 20:53           ` Thomas Schwinge
2020-05-25 10:56             ` [WIP] Fold 'NON_LVALUE_EXPR' some more (was: C++ 'NON_LVALUE_EXPR' in OMP array section handling) Thomas Schwinge
2020-11-26  9:36               ` Don't create location wrapper nodes within OpenACC clauses (was: [WIP] Fold 'NON_LVALUE_EXPR' some more (was: C++ 'NON_LVALUE_EXPR' in OMP array section handling)) Thomas Schwinge
2020-11-26 10:02                 ` Jakub Jelinek

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=874lb9qr2u.fsf@euler.schwinge.homeip.net \
    --to=thomas@codesourcery.com \
    --cc=dmalcolm@redhat.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jason@redhat.com \
    /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).