public inbox for gcc-cvs@sourceware.org help / color / mirror / Atom feed
From: Alex Coplan <acoplan@gcc.gnu.org> To: gcc-cvs@gcc.gnu.org Subject: [gcc(refs/vendors/ARM/heads/morello)] c: Ensure intcap save_expr operands are folded Date: Tue, 17 Jan 2023 10:47:10 +0000 (GMT) [thread overview] Message-ID: <20230117104710.D51B43858D28@sourceware.org> (raw) https://gcc.gnu.org/g:aa8dde4799379b90301785bf0beff2c20935eacc commit aa8dde4799379b90301785bf0beff2c20935eacc Author: Alex Coplan <alex.coplan@arm.com> Date: Mon Dec 12 18:17:10 2022 +0000 c: Ensure intcap save_expr operands are folded The commment above c_fully_fold notes the following requirement: Function arguments have already been folded before calling this function, as have the contents of SAVE_EXPR, TARGET_EXPR, BIND_EXPR, VA_ARG_EXPR, OBJ_TYPE_REF and C_MAYBE_CONST_EXPR. When we recently introduced save_exprs to avoid duplicate side-effects when forming .REPLACE_ADDRESS_VALUEs in the C front-end, we didn't take this requirement into account. As the testcase added with the patch shows, this leads to c_maybe_const_expr nodes escaping the C front-end, and subsequent ICEs in the gimplifier. This patch fixes the issue by calling c_fully_fold prior to calling save_expr on intcap operands. Diff: --- gcc/c/c-typeck.c | 6 +++--- gcc/testsuite/c-c++-common/torture/intptr-fold.c | 10 ++++++++++ 2 files changed, 13 insertions(+), 3 deletions(-) diff --git a/gcc/c/c-typeck.c b/gcc/c/c-typeck.c index 1fcaa7dbebb..817b8ac844b 100644 --- a/gcc/c/c-typeck.c +++ b/gcc/c/c-typeck.c @@ -4401,7 +4401,7 @@ build_unary_op (location_t location, enum tree_code code, tree xarg, default: intcap = unary_op_get_intcap_provenance (arg); if (arg == intcap) - intcap = arg = save_expr (arg); + intcap = arg = save_expr (c_fully_fold (arg, false, NULL)); arg = drop_capability (arg); } } @@ -11970,9 +11970,9 @@ build_binary_op_1 (location_t location, enum tree_code code, c + cv --> REPLACE_ADDRESS_VALUE (c, (non-cap type) c + cv) we need to avoid evaluating c twice. */ if (intcap == op0) - intcap = op0 = save_expr (op0); + intcap = op0 = save_expr (c_fully_fold (op0, false, NULL)); else if (intcap == op1) - intcap = op1 = save_expr (op1); + intcap = op1 = save_expr (c_fully_fold (op1, false, NULL)); if (common_ic_type) { diff --git a/gcc/testsuite/c-c++-common/torture/intptr-fold.c b/gcc/testsuite/c-c++-common/torture/intptr-fold.c new file mode 100644 index 00000000000..f62b398ae17 --- /dev/null +++ b/gcc/testsuite/c-c++-common/torture/intptr-fold.c @@ -0,0 +1,10 @@ +/* { dg-do compile } */ +/* This would ICE in the gimplifier on capability targets due to + c_maybe_const_expr escaping the C front-end. */ +typedef __INTPTR_TYPE__ T; +typedef struct { + T a; +} S; +T f(T x) { + return -(x ? ((S *)x)->a : x); +}
reply other threads:[~2023-01-17 10:47 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=20230117104710.D51B43858D28@sourceware.org \ --to=acoplan@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).