public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug tree-optimization/116098] [14/15 Regression] _Bool value from tagged union is incorrect when built with optimization since r14-1597-g64d90d06d2db43 Date: Sat, 27 Jul 2024 11:01:41 +0000 [thread overview] Message-ID: <bug-116098-4-VsKAolGw5N@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-116098-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116098 --- Comment #9 from rguenther at suse dot de <rguenther at suse dot de> --- > Am 27.07.2024 um 02:38 schrieb pinskia at gcc dot gnu.org <gcc-bugzilla@gcc.gnu.org>: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116098 > > --- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> --- > (In reply to Richard Biener from comment #7) >> Ah, it's the code that makes SRA widen bit-precision values to >> size-precision integers. That said, I don't see why the V_C_E should not be >> moveable. >> >> value$8_11 = MEM <unsigned char> [(struct Value *)&s_value + 8B]; >> _8 = VIEW_CONVERT_EXPR<_Bool>(value$8_11); >> >> is exactly what RTL expansion will create - we're not truncating the >> result to bit-precision on _Bool loads. > > The problem is the bits outside of bool are set and we don't truncate them out > and since we turn it into: > > _6 = VIEW_CONVERT_EXPR<_Bool>(value$8_8); > _12 = value_7 != 0; > _13 = _6 | _12; > > We get the wrong answer. This is very similar to if _6 had been an > uninitialized which we fixed during the development of GCC 14. > That is the range of _6 (or _8) is only conditionally `[0,1]`, otherwise it > should be considered similar to an uninitialized variable. > > The other thing which we might be able to solve this is change: > ``` > /* For integral conversions with the same precision or pointer > conversions use a NOP_EXPR instead. */ > (simplify > (view_convert @0) > (if ((INTEGRAL_TYPE_P (type) || POINTER_TYPE_P (type)) > && (INTEGRAL_TYPE_P (TREE_TYPE (@0)) || POINTER_TYPE_P (TREE_TYPE (@0))) > && TYPE_PRECISION (type) == TYPE_PRECISION (TREE_TYPE (@0))) > (convert @0))) > ``` > > to change bool convert to be convert too. In a similar way how we handle > `zero_one != 0` into a convert instead of a VCE (in VPR and other passes). This > will fix the above too. > > Maybe I will test that to see what code generation will look like. That’s a possibility though it will affect all uses and cause a lot of extra truncation I fear. Richard > -- > You are receiving this mail because: > You are on the CC list for the bug.
next prev parent reply other threads:[~2024-07-27 11:01 UTC|newest] Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top 2024-07-25 21:21 [Bug c/116098] New: _Bool value from tagged union is incorrect when built with -O1 laria at laria dot me 2024-07-25 21:46 ` [Bug tree-optimization/116098] [14/15 Regression] _Bool value from tagged union is incorrect when built with optimization pinskia at gcc dot gnu.org 2024-07-25 21:50 ` sjames at gcc dot gnu.org 2024-07-25 21:56 ` pinskia at gcc dot gnu.org 2024-07-26 3:50 ` pinskia at gcc dot gnu.org 2024-07-26 4:31 ` pinskia at gcc dot gnu.org 2024-07-26 6:04 ` rguenth at gcc dot gnu.org 2024-07-26 6:07 ` pinskia at gcc dot gnu.org 2024-07-26 6:08 ` rguenth at gcc dot gnu.org 2024-07-27 0:38 ` [Bug tree-optimization/116098] [14/15 Regression] _Bool value from tagged union is incorrect when built with optimization since r14-1597-g64d90d06d2db43 pinskia at gcc dot gnu.org 2024-07-27 11:01 ` rguenther at suse dot de [this message] 2024-08-01 9:41 ` jakub at gcc dot gnu.org 2024-08-30 16:28 ` pinskia at gcc dot gnu.org 2024-08-30 21:54 ` pinskia at gcc dot gnu.org 2024-08-31 16:17 ` cvs-commit at gcc dot gnu.org 2024-08-31 16:18 ` [Bug tree-optimization/116098] [14 " pinskia at gcc dot gnu.org 2024-09-06 19:48 ` laria at laria dot me 2024-09-06 19:56 ` [Bug tree-optimization/116098] [14/15 " pinskia 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-116098-4-VsKAolGw5N@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).