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 tree-optimization/109778] [10/11/12/13 Regression] Wrong code at -O1 and above on x86_64-linux-gnu Date: Tue, 09 May 2023 10:49:22 +0000 [thread overview] Message-ID: <bug-109778-4-J8NHfCWPXT@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-109778-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109778 --- Comment #8 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The releases/gcc-13 branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:97f404d53e0f47013afd728e617d03ecc585c6b7 commit r13-7310-g97f404d53e0f47013afd728e617d03ecc585c6b7 Author: Jakub Jelinek <jakub@redhat.com> Date: Tue May 9 12:10:07 2023 +0200 tree-ssa-ccp, wide-int: Fix up handling of [LR]ROTATE_EXPR in bitwise ccp [PR109778] The following testcase is miscompiled, because bitwise ccp2 handles a rotate with a signed type incorrectly. Seems tree-ssa-ccp.cc has the only callers of wi::[lr]rotate with 3 arguments, all other callers just rotate in the right precision and I think work correctly. ccp works with widest_ints and so rotations by the excessive precision certainly don't match what it wants when it sees a rotate in some specific bitsize. Still, if it is unsigned rotate and the widest_int is zero extended from width, the functions perform left shift and logical right shift on the value and then at the end zero extend the result of left shift and uselessly also the result of logical right shift and return | of that. On the testcase we the signed char rrotate by 4 argument is CONSTANT -75 i.e. 0xffffffff....fffffb5 with mask 2. The mask is correctly rotated to 0x20, but because the 8-bit constant is sign extended to 192-bit one, the logical right shift by 4 doesn't yield expected 0xb, but gives 0xfffffffffff....ffffb, and then return wi::zext (left, width) | wi::zext (right, width); where left is 0xfffffff....fb50, so we return 0xfb instead of the expected 0x5b. The following patch fixes that by doing the zero extension in case of the right variable before doing wi::lrshift rather than after it. Also, wi::[lr]rotate widht width < precision always zero extends the result. I'm afraid it can't do better because it doesn't know if it is done for an unsigned or signed type, but the caller in this case knows that very well, so I've done the extension based on sgn in the caller. E.g. 0x5b rotated right (or left) by 4 with width 8 previously gave 0xb5, but sgn == SIGNED in widest_int it should be 0xffffffff....fffb5 instead. 2023-05-09 Jakub Jelinek <jakub@redhat.com> PR tree-optimization/109778 * wide-int.h (wi::lrotate, wi::rrotate): Call wi::lrshift on wi::zext (x, width) rather than x if width != precision, rather than using wi::zext (right, width) after the shift. * tree-ssa-ccp.cc (bit_value_binop): Call wi::ext on the results of wi::lrotate or wi::rrotate. * gcc.c-torture/execute/pr109778.c: New test. (cherry picked from commit a8302d2a4669984c7c287d12ef5b37cde6699c80)
next prev parent reply other threads:[~2023-05-09 10:49 UTC|newest] Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-05-08 19:18 [Bug c/109778] New: Wrong code at -O3 on x86_64-linux-gnu since GCC-12.2 shaohua.li at inf dot ethz.ch 2023-05-08 19:30 ` [Bug tree-optimization/109778] [12/13/14 Regression] Wrong code at -O1 and above " pinskia at gcc dot gnu.org 2023-05-08 19:31 ` [Bug tree-optimization/109778] [13/14 Regression] Wrong code at -O1 and above on x86_64-linux-gnu pinskia at gcc dot gnu.org 2023-05-08 19:36 ` jakub at gcc dot gnu.org 2023-05-08 22:09 ` jakub at gcc dot gnu.org 2023-05-09 7:38 ` rguenth at gcc dot gnu.org 2023-05-09 10:11 ` cvs-commit at gcc dot gnu.org 2023-05-09 10:19 ` cvs-commit at gcc dot gnu.org 2023-05-09 10:23 ` [Bug tree-optimization/109778] [10/11/12/13 " jakub at gcc dot gnu.org 2023-05-09 10:49 ` cvs-commit at gcc dot gnu.org [this message] 2023-05-09 10:49 ` cvs-commit at gcc dot gnu.org 2023-05-09 10:56 ` cvs-commit at gcc dot gnu.org 2023-05-09 10:56 ` cvs-commit at gcc dot gnu.org 2023-05-09 11:04 ` cvs-commit at gcc dot gnu.org 2023-05-09 11:04 ` cvs-commit at gcc dot gnu.org 2023-05-09 11:10 ` cvs-commit at gcc dot gnu.org 2023-05-09 11:10 ` cvs-commit at gcc dot gnu.org 2023-05-21 16:56 ` 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-109778-4-J8NHfCWPXT@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).