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 c++/108365] [10 Regression] Wrong code with -O0 Date: Wed, 03 May 2023 15:21:30 +0000 [thread overview] Message-ID: <bug-108365-4-MhBuBnlGlp@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-108365-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108365 --- Comment #13 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:61948b4113a817b0cd61e7e5311d9cfae31bc623 commit r10-11365-g61948b4113a817b0cd61e7e5311d9cfae31bc623 Author: Jakub Jelinek <jakub@redhat.com> Date: Sat Jan 14 10:17:14 2023 +0100 c++: Avoid incorrect shortening of divisions [PR108365] The following testcase is miscompiled, because we shorten the division in a case where it should not be shortened. Divisions (and modulos) can be shortened if it is unsigned division/modulo, or if it is signed division/modulo where we can prove the dividend will not be the minimum signed value or divisor will not be -1, because e.g. on sizeof(long long)==sizeof(int)*2 && __INT_MAX__ == 0x7fffffff targets (-2147483647 - 1) / -1 is UB but (int) (-2147483648LL / -1LL) is not, it is -2147483648. The primary aim of both the C and C++ FE division/modulo shortening I assume was for the implicit integral promotions of {,signed,unsigned} {char,short} and because at this point we have no VRP information etc., the shortening is done if the integral promotion is from unsigned type for the divisor or if the dividend is an integer constant other than -1. This works fine for char/short -> int promotions when char/short have smaller precision than int - unsigned char -> int or unsigned short -> int will always be a positive int, so never the most negative. Now, the C FE checks whether orig_op0 is TYPE_UNSIGNED where op0 is either the same as orig_op0 or that promoted to int, I think that works fine, if it isn't promoted, either the division/modulo common type will have the same precision as op0 but then the division/modulo is unsigned and so without UB, or it will be done in wider precision (e.g. because op1 has wider precision), but then op0 can't be minimum signed value. Or it has been promoted to int, but in that case it was again from narrower type and so never minimum signed int. But the C++ FE was checking if op0 is a NOP_EXPR from TYPE_UNSIGNED. First of all, not sure if the operand of NOP_EXPR couldn't be non-integral type where TYPE_UNSIGNED wouldn't be meaningful, but more importantly, even if it is a cast from unsigned integral type, we only know it can't be minimum signed value if it is a widening cast, if it is same precision or narrowing cast, we know nothing. So, the following patch for the NOP_EXPR cases checks just in case that it is from integral type and more importantly checks it is a widening conversion. 2023-01-14 Jakub Jelinek <jakub@redhat.com> PR c++/108365 * typeck.c (cp_build_binary_op): For integral division or modulo, shorten if type0 is unsigned, or op0 is cast from narrower unsigned integral type or stripped_op1 is INTEGER_CST other than -1. * g++.dg/opt/pr108365.C: New test. * g++.dg/warn/pr108365.C: New test. (cherry picked from commit 5b3a88640f962d4ffca31ae651bed2d8672f1a8c)
next prev parent reply other threads:[~2023-05-03 15:21 UTC|newest] Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-01-10 22:47 [Bug tree-optimization/108365] New: [9/10/11/12/13 " vsevolod.livinskiy at gmail dot com 2023-01-10 22:55 ` [Bug tree-optimization/108365] " pinskia at gcc dot gnu.org 2023-01-10 22:55 ` pinskia at gcc dot gnu.org 2023-01-10 23:07 ` [Bug middle-end/108365] " jakub at gcc dot gnu.org 2023-01-10 23:15 ` pinskia at gcc dot gnu.org 2023-01-10 23:36 ` jakub at gcc dot gnu.org 2023-01-10 23:59 ` jakub at gcc dot gnu.org 2023-01-11 11:47 ` [Bug c++/108365] " jakub at gcc dot gnu.org 2023-01-11 12:10 ` rguenth at gcc dot gnu.org 2023-01-14 9:18 ` cvs-commit at gcc dot gnu.org 2023-01-14 9:23 ` [Bug c++/108365] [9/10/11/12 " jakub at gcc dot gnu.org 2023-02-10 17:47 ` cvs-commit at gcc dot gnu.org 2023-02-10 18:00 ` [Bug c++/108365] [10/11 " jakub at gcc dot gnu.org 2023-05-02 20:14 ` cvs-commit at gcc dot gnu.org 2023-05-03 9:37 ` [Bug c++/108365] [10 " jakub at gcc dot gnu.org 2023-05-03 15:21 ` cvs-commit at gcc dot gnu.org [this message] 2023-05-04 7:23 ` 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-108365-4-MhBuBnlGlp@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).