public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Julian Brown <julian@codesourcery.com>
To: Thomas Schwinge <thomas@codesourcery.com>
Cc: <gcc-patches@gcc.gnu.org>, Jakub Jelinek <jakub@redhat.com>,
	"Tobias Burnus" <tobias@codesourcery.com>
Subject: Re: [PATCH] [og12] OpenMP: Constructors and destructors for "declare target" static aggregates
Date: Wed, 5 Apr 2023 13:31:14 +0100	[thread overview]
Message-ID: <20230405133114.6810fc7e@squid.athome> (raw)
In-Reply-To: <87ttxyd3od.fsf@euler.schwinge.homeip.net>

On Sun, 2 Apr 2023 11:38:42 +0200
Thomas Schwinge <thomas@codesourcery.com> wrote:

> Hi Julian!
> 
> On 2023-03-27T18:54:30+0000, Julian Brown <julian@codesourcery.com>
> wrote:
> > This patch adds support for running constructors and destructors for
> > static (file-scope) aggregates for C++ objects which are marked with
> > "declare target" directives on OpenMP offload targets.
> >
> > At present, space is allocated on the target for such aggregates,
> > but nothing ever constructs them properly, so they end up
> > zero-initialised.  
> 
> So you've settled that on-device construction is the way to go, and
> not on-host construction before host-to-device copy?

Yes, I think there's less potential for surprises, e.g. if the
constructed object contains pointers to other "declare target" data, or
similar.

(I think it only matters otherwise if the constructor has side-effects
unrelated to the initialisation of the object -- but I don't think the
spec has anything to say about that, at least as of 5.2.)

> I now wonder if we didn't once have a similar issue with Fortran array
> constructors, and how we solved that one.  (I may be misremembering.)

Not sure about that...

> > Tested with offloading to AMD GCN. I will apply to the og12 branch
> > shortly.  
> 
> I've pushed to devel/omp/gcc-12 branch
> commit 472783f3137475b82baadac31cca31021b69aba9
> "Resolve 'error: unused parameter' in
> 'gcc/cp/decl2.cc:one_static_initialization_or_destruction'", see
> attached.

Thank you.

> But glancing at test results, I also see a good number of ICEs.
> That's with '--enable-checking=yes,extra,rtl'.
> 
>      build-gcc/gcc/testsuite/g++/g++.sum                | 924
> ++++++++++++--------- .../libgomp/testsuite/libgomp.sum
>    | 438 ++++++----
> 
> Those are mostly instances of:
> 
>     internal compiler error: tree check: expected omp_clause, have
> tree_list in c_parse_final_cleanups, at cp/decl2.cc:5291
> 
> ..., but also:
> 
>     FAIL: libgomp.c++/static-aggr-constructor-destructor-1.C
> (internal compiler error: tree check: expected omp_clause, have
> tree_list in c_parse_final_cleanups, at cp/decl2.cc:5289) FAIL:
> libgomp.c++/static-aggr-constructor-destructor-1.C (test for excess
> errors) UNRESOLVED:
> libgomp.c++/static-aggr-constructor-destructor-1.C compilation failed
> to produce executable FAIL:
> libgomp.c++/static-aggr-constructor-destructor-2.C (internal compiler
> error: tree check: expected omp_clause, have tree_list in
> c_parse_final_cleanups, at cp/decl2.cc:5289) FAIL:
> libgomp.c++/static-aggr-constructor-destructor-2.C (test for excess
> errors) UNRESOLVED:
> libgomp.c++/static-aggr-constructor-destructor-2.C compilation failed
> to produce executable
> 
> That's in new 'gcc/cp/decl2.cc' code that you've added:
> 
>     5283                while (*fvarsp)
>     5284                  {
>     5285                    tree decl = TREE_VALUE (*fvarsp);
>     5286
>     5287                    if (lookup_attribute ("omp declare
> target", 5288
> DECL_ATTRIBUTES (decl))) 5289                      fvarsp =
> &OMP_CLAUSE_CHAIN (*fvarsp); 5290                    else
>     5291                      *fvarsp = OMP_CLAUSE_CHAIN (*fvarsp);
>     5292                  }
> 
> Please have a look.

I believe these are fixed by:

https://gcc.gnu.org/pipermail/gcc-patches/2023-April/615144.html

Thanks,

Julian

      reply	other threads:[~2023-04-05 12:31 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-27 18:54 Julian Brown
2023-04-02  9:38 ` Thomas Schwinge
2023-04-05 12:31   ` Julian Brown [this message]

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=20230405133114.6810fc7e@squid.athome \
    --to=julian@codesourcery.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=thomas@codesourcery.com \
    --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).