public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Jakub Jelinek <jakub@redhat.com>
To: Tobias Burnus <Tobias_Burnus@mentor.com>
Cc: Tobias Burnus <tobias@codesourcery.com>, Jan Hubicka <jh@suse.cz>,
	gcc-patches <gcc-patches@gcc.gnu.org>
Subject: Re: [Patch] OpenMP: Handle cpp_implicit_alias in declare-target discovery (PR96390)
Date: Tue, 22 Sep 2020 09:36:59 +0200	[thread overview]
Message-ID: <20200922073659.GV2176@tucnak> (raw)
In-Reply-To: <dcabd7e0-4e2d-4f67-1a9c-c0df7d8d78dc@mentor.com>

On Tue, Sep 22, 2020 at 09:11:48AM +0200, Tobias Burnus wrote:
> > Okay – or do we find more issues?

I'm afraid so.

> +	  if (omp_declare_target_fn_p (decl)
> +	      || lookup_attribute ("omp declare target host",
> +				   DECL_ATTRIBUTES (decl)))
> +	    return NULL_TREE;

I'm worried that omp_declare_target_fn_p could be true and so this would
punt, but the intermediate aliases would be marked.
Or the aliases would be marked and the ultimate alias would not.
Consider:
int v;
#pragma omp declare target to (v)
void foo (void) { v++; }
void bar (void) __attribute__((alias ("foo")));
#pragma omp declare target to (bar)
void baz (void) __attribute__((alias ("foo")));
void qux (void) {
#pragma omp target
{
  bar (); // Here the ultimate alias is not marked, so the code marks it,
	  // and adds another "omp declare target" attribute to bar,
	  // which it shouldn't.
  baz (); // At this point, foo is marked, so the code wouldn't mark
	  // baz alias as "omp declare target".
}
}

So, I think it is fine to find the ultimate alias, but the loop to mark
the intermediate aliases should be invoked regardless of how decl is or is
not marked, and should test in each step whether it should or should not be
marked.

	Jakub


  reply	other threads:[~2020-09-22  7:37 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-03 15:37 Tobias Burnus
2020-08-17  7:17 ` *PING* – " Tobias Burnus
2020-08-25 16:58   ` *PING**2 " Tobias Burnus
2020-08-31 15:53 ` Jakub Jelinek
2020-09-14 13:25   ` Tobias Burnus
2020-09-16 10:36     ` Jakub Jelinek
2020-09-16 23:15       ` Tobias Burnus
2020-09-22  7:11         ` Tobias Burnus
2020-09-22  7:36           ` Jakub Jelinek [this message]
2020-09-22 14:11             ` Tobias Burnus
2020-09-22 14:24               ` Jakub Jelinek
2020-09-22 15:39                 ` Tobias Burnus
2020-09-23 13:52                   ` Tobias Burnus
2020-09-23 14:06                     ` Jakub Jelinek
2020-09-23 15:45                       ` Tobias Burnus
2020-09-25 11:23                         ` 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=20200922073659.GV2176@tucnak \
    --to=jakub@redhat.com \
    --cc=Tobias_Burnus@mentor.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jh@suse.cz \
    --cc=tobias@codesourcery.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).