public inbox for gcc-cvs@sourceware.org help / color / mirror / Atom feed
From: Kwok Yeung <kcy@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org Subject: [gcc/devel/omp/gcc-12] Fix bug in processing of array dimensions in data clauses. Date: Wed, 29 Jun 2022 14:37:23 +0000 (GMT) [thread overview] Message-ID: <20220629143723.6B9403853560@sourceware.org> (raw) https://gcc.gnu.org/g:49577050cb3e16a17e57c08c58bbe16f97bf94a5 commit 49577050cb3e16a17e57c08c58bbe16f97bf94a5 Author: Sandra Loosemore <sandra@codesourcery.com> Date: Tue Mar 31 14:29:09 2020 -0700 Fix bug in processing of array dimensions in data clauses. The g++ front end wraps the array length and low_bound values in NON_LVALUE_EXPR, causing the subsequent tests for INTEGER_CST to fail. The test case c-c++-common/goacc/kernels-loop-annotation-1.c was tickling this bug and giving bogus errors in g++ because it was falling through to dynamic array code instead of recognizing the constant bounds. This patch was posted upstream here https://gcc.gnu.org/pipermail/gcc-patches/2020-March/542694.html but not yet committed. It may be that some other fix for this problem is implemented on mainline instead; check before merging this patch. 2020-03-31 Sandra Loosemore <sandra@codesourcery.com> gcc/cp/ * semantics.cc (handle_omp_array_sections_1): Call STRIP_NOPS on length and low_bound; (handle_omp_array_sections): Likewise. Diff: --- gcc/cp/ChangeLog.omp | 6 ++++++ gcc/cp/semantics.cc | 9 +++++++++ 2 files changed, 15 insertions(+) diff --git a/gcc/cp/ChangeLog.omp b/gcc/cp/ChangeLog.omp index 74a672d653f..ead9de41a2c 100644 --- a/gcc/cp/ChangeLog.omp +++ b/gcc/cp/ChangeLog.omp @@ -1,3 +1,9 @@ +2020-03-31 Sandra Loosemore <sandra@codesourcery.com> + + * semantics.cc (handle_omp_array_sections_1): Call STRIP_NOPS + on length and low_bound; + (handle_omp_array_sections): Likewise. + 2020-03-27 Sandra Loosemore <sandra@codesourcery.com> * decl.cc (cp_unwrap_for_init): New. diff --git a/gcc/cp/semantics.cc b/gcc/cp/semantics.cc index 7bcd8094bb1..2c0e1c7eaa0 100644 --- a/gcc/cp/semantics.cc +++ b/gcc/cp/semantics.cc @@ -5185,6 +5185,10 @@ handle_omp_array_sections_1 (tree c, tree t, vec<tree> &types, if (length) length = mark_rvalue_use (length); /* We need to reduce to real constant-values for checks below. */ + if (length) + STRIP_NOPS (length); + if (low_bound) + STRIP_NOPS (low_bound); if (length) length = fold_simple (length); if (low_bound) @@ -5517,6 +5521,11 @@ handle_omp_array_sections (tree c, enum c_omp_region_type ort) tree low_bound = TREE_PURPOSE (t); tree length = TREE_VALUE (t); + if (length) + STRIP_NOPS (length); + if (low_bound) + STRIP_NOPS (low_bound); + i--; if (low_bound && TREE_CODE (low_bound) == INTEGER_CST
reply other threads:[~2022-06-29 14:37 UTC|newest] Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=20220629143723.6B9403853560@sourceware.org \ --to=kcy@gcc.gnu.org \ --cc=gcc-cvs@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: linkBe 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).