public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug middle-end/101535] ICE in lookup_decl, at omp-low.c:412
Date: Tue, 10 May 2022 08:20:13 +0000	[thread overview]
Message-ID: <bug-101535-4-C41RD75anS@http.gcc.gnu.org/bugzilla/> (raw)
In-Reply-To: <bug-101535-4@http.gcc.gnu.org/bugzilla/>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101535

--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:

https://gcc.gnu.org/g:69f1936c6700403fb94920f44346a5e2a66e2f86

commit r10-10637-g69f1936c6700403fb94920f44346a5e2a66e2f86
Author: Jakub Jelinek <jakub@redhat.com>
Date:   Wed Jul 21 09:45:02 2021 +0200

    openmp: Fix up omp_check_private [PR101535]

    The target data construct shouldn't affect omp_check_private, unless
    the decl there is privatized (use_device_* clauses).  The routine
    had some code for that, but it just did continue; in a loop that looped
    only if the region type is one of selected 4 kinds, so effectively resulted
    in return false; instead of looping again.  And not diagnosing lastprivate
    (or reduction etc.) on a variable that is private to containing parallel
    results in ICEs later on, as there is no original list item to which store
    the last result.
    The target construct is unclear as it has an implicit parallel region
    and it is not obvious if the data privatization clauses on the construct
    shall be treated as data privatization on the implicit parallel or just
    on the target.  For now treat those as privatization on the implicit
    parallel, but treat map clauses as shared on the implicit parallel.

    2021-07-21  Jakub Jelinek  <jakub@redhat.com>

            PR middle-end/101535
            * gimplify.c (omp_check_private): Properly skip ORT_TARGET_DATA
            contexts in which decl isn't privatized and for ORT_TARGET return
            false if decl is mapped.

            * c-c++-common/gomp/pr101535-1.c: New test.
            * c-c++-common/gomp/pr101535-2.c: New test.

    (cherry picked from commit b136b7a78774107943fe94051c42b5a968a3ad3f)

  parent reply	other threads:[~2022-05-10  8:20 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-20 16:59 [Bug fortran/101535] New: " gscfq@t-online.de
2021-07-20 17:05 ` [Bug fortran/101535] " jakub at gcc dot gnu.org
2021-07-21  7:50 ` [Bug middle-end/101535] " cvs-commit at gcc dot gnu.org
2021-07-21  8:22 ` cvs-commit at gcc dot gnu.org
2021-07-21  8:28 ` jakub at gcc dot gnu.org
2022-05-10  8:20 ` cvs-commit at gcc dot gnu.org [this message]
2022-05-11  6:21 ` cvs-commit at gcc dot gnu.org
2022-05-11  6:36 ` jakub at gcc dot gnu.org

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=bug-101535-4-C41RD75anS@http.gcc.gnu.org/bugzilla/ \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /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).