public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "rguenth at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/98069] [8/9/10/11 Regression] Miscompilation with -O3 since r8-2380-g2d7744d4ef93bfff Date: Tue, 01 Dec 2020 09:41:23 +0000 [thread overview] Message-ID: <bug-98069-4-lln3W1ILyB@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-98069-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98069 Richard Biener <rguenth at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |rsandifo at gcc dot gnu.org --- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> --- So before vectorization we have var_3.0_1 = var_3; iftmp.3_10 = var_3.0_1 != 0 ? -2147483648 : 0; _2 = (int) iftmp.3_10; d_11 = -2147483648 - _2; which should compute to 0. Now somewhere (split_constant_offset I'd bet) things go wrong and we produce in dataref analysis base_address: &arr_165 offset from base address: (ssizetype) ((sizetype) -_2 * 2) constant offset from base address: -4294967296 step: 2 base alignment: 32 base misalignment: 0 offset alignment: 2 step alignment: 2 base_object: arr_165 Access function 0: {d_11, +, 1}_2 from { ((sizetype) d_21) * 2, +, 2 }_2 as offset IV which split_constant_offset makes into { (sizetype) -_2 * 2, +, 2 }_2 + -4294967296. The logic is that we can dive into the (sizetype) extension from int since the operation on int cannot overflow (undefined behavior). We then strip the -2147483648 constant, thinking we can associate this as (sizetype)(0 - _2) + -2147483648 but of course 0 - _2 now overflows and we happily fold it to -_2. So here: static bool split_constant_offset_1 (tree type, tree op0, enum tree_code code, tree op1, tree *var, tree *off, hash_map<tree, std::pair<tree, tree> > &cache, unsigned *limit) { ... case PLUS_EXPR: case MINUS_EXPR: if (TREE_CODE (op1) == INTEGER_CST) { split_constant_offset (op0, &var0, &off0, cache, limit); *var = var0; *off = size_binop (ocode, off0, fold_convert (ssizetype, op1)); return true; } split_constant_offset (op0, &var0, &off0, cache, limit); split_constant_offset (op1, &var1, &off1, cache, limit); *var = fold_build2 (code, type, var0, var1); we have to make sure that the expression we fold cannot overflow or use unsigned arithmetic. In fact, using unsigned arithmetic looks like the only reasonable thing since splitting out any constant is not trivially valid. We're doing (var0 + off0) +- (var1 + off1) -> (var0 +- var1) + (off0 + off1) where we know the left side doesn't overflow. This makes associating across the multiplication invalid where we do ((sizetype) (A +- B)) * 2 -> ((sizetype) A) * 2 +- B * 2 and thus from 0 * 2 we go to -2147483648 * 2 + -4294967296. Using unsigned arithmetic to make the inner op no longer undefined doesn't help here. So it looks like we cannot use TYPE_OVERFLOW_UNDEFINED to validate looking across widening conversions. Which points to the same area as PR97960.
next prev parent reply other threads:[~2020-12-01 9:41 UTC|newest] Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-11-30 15:04 [Bug tree-optimization/98069] New: Miscompilation with -O3 vsevolod.livinskij at frtk dot ru 2020-11-30 16:29 ` [Bug tree-optimization/98069] [8/9/10/11 Regression] Miscompilation with -O3 since r8-2380-g2d7744d4ef93bfff marxin at gcc dot gnu.org 2020-11-30 16:29 ` marxin at gcc dot gnu.org 2020-12-01 8:33 ` rguenth at gcc dot gnu.org 2020-12-01 8:33 ` rguenth at gcc dot gnu.org 2020-12-01 9:41 ` rguenth at gcc dot gnu.org [this message] 2020-12-02 8:38 ` rguenth at gcc dot gnu.org 2020-12-04 13:23 ` rguenth at gcc dot gnu.org 2021-01-08 14:39 ` rguenth at gcc dot gnu.org 2021-04-23 9:20 ` [Bug tree-optimization/98069] [8/9/10 " rsandifo at gcc dot gnu.org 2021-04-23 9:21 ` rsandifo at gcc dot gnu.org 2021-04-23 9:21 ` rsandifo at gcc dot gnu.org 2022-06-28 10:42 ` [Bug tree-optimization/98069] [10 " jakub at gcc dot gnu.org 2023-07-07 9:15 ` rguenth 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-98069-4-lln3W1ILyB@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: 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).