[Bug middle-end/110726] New: [14 Regression] wrong code on llvm-16 around 'a |= a == 0'

[Bug middle-end/110726] New: [14 Regression] wrong code on llvm-16 around 'a |= a == 0'

[slyfox at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110726

            Bug ID: 110726
           Summary: [14 Regression] wrong code on llvm-16 around 'a |= a
                    == 0'
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
          Assignee: unassigned at gcc dot gnu.org
          Reporter: slyfox at gcc dot gnu.org
  Target Milestone: ---

This week's gcc r14-2600-g3a407070b610a8 fails llvm-16 test suite as:

      Failed Tests (1):
        LLVM-Unit ::
Support/./SupportTests/BlockFrequencyTest.SaturatingRightShift

It looks like the reproducer is trivial and happens even on -O0:

// $ cat bug.cc
int main(void) {
  unsigned long long freq = 0x10080ULL;

  freq >>= 2;
  freq |= freq == 0;

  if (freq != 0x4020ULL)
      __builtin_trap();
}

$ gcc-14 bug.cc -o a && ./a
Illegal instruction (core dumped)

$ $ gcc bug.cc -o a && ./a
<ok>

$ gcc -v
Using built-in specs.
COLLECT_GCC=/<<NIX>>/gcc-14.0.0/bin/gcc
COLLECT_LTO_WRAPPER=/<<NIX>>/gcc-14.0.0/libexec/gcc/x86_64-unknown-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../source/configure --prefix=/<<NIX>>/gcc-14.0.0
--with-gmp-include=/<<NIX>>/gmp-6.2.1-dev/include
--with-gmp-lib=/<<NIX>>/gmp-6.2.1/lib
--with-mpfr-include=/<<NIX>>/mpfr-4.2.0-dev/include
--with-mpfr-lib=/<<NIX>>/mpfr-4.2.0/lib --with-mpc=/<<NIX>>/libmpc-1.3.1
--with-native-system-header-dir=/<<NIX>>/glibc-2.37-8-dev/include
--with-build-sysroot=/ --program-prefix= --enable-lto --disable-libstdcxx-pch
--without-included-gettext --with-system-zlib --enable-checking=release
--enable-static --enable-languages=c,c++ --disable-multilib --enable-plugin
--disable-libcc1 --with-isl=/<<NIX>>/isl-0.20 --disable-bootstrap
--build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu
--target=x86_64-unknown-linux-gnu
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 99999999 (experimental) (GCC)

[Bug middle-end/110726] [14 Regression] wrong code on llvm-16 around 'a |= a == 0'

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110726

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I think this will be fixed with -momit-leaf-frame-pointer patch at :
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624752.html

[Bug middle-end/110726] [14 Regression] wrong code on llvm-16 around 'a |= a == 0'

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110726

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Whoops wrong bug report.

[Bug middle-end/110726] [14 Regression] wrong code on llvm-16 around 'a |= a == 0'

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110726

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
   Target Milestone|---                         |14.0

[Bug middle-end/110726] [14 Regression] wrong code on llvm-16 around 'a |= a == 0'

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110726

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-07-18
             Status|UNCONFIRMED                 |NEW
           Assignee|unassigned at gcc dot gnu.org      |pinskia at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
It worked at r14-2547-g71a907abdb4c03d4a3419190d .

Mine, looks like r14-2556-g0407ae8a7732d9 caused it ...

[Bug middle-end/110726] [14 Regression] wrong code on llvm-16 around 'a |= a == 0'

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110726

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

[Bug middle-end/110726] [14 Regression] wrong code on llvm-16 around 'a |= a == 0'

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110726

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
/* a | (a == b)  -->  a | (b^1) (boolean version of the above). */
(simplify
 (bit_ior:c @0 (nop_convert? (eq:c @0 @1)))
 (bit_ior @0 (bit_xor @1 { build_one_cst (type); })))


So I guess the issue is eq on generic has an integer type rather than boolean
type ...

[Bug middle-end/110726] [14 Regression] wrong code on llvm-16 around 'a |= a == 0'

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110726

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Created attachment 55575
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55575&action=edit
Patch which should fix this

So I didn't realize I need the check for "INTEGRAL_TYPE_P (TREE_TYPE (@0))
      && TYPE_PRECISION (TREE_TYPE (@0)) == 1" On these.

[Bug middle-end/110726] [14 Regression] wrong code on llvm-16 around 'a |= a == 0'

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110726

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Created attachment 55576
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55576&action=edit
Full testcase

[Bug middle-end/110726] [14 Regression] wrong code on llvm-16 around 'a |= a == 0'

[slyfox at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110726

--- Comment #7 from Sergei Trofimovich <slyfox at gcc dot gnu.org> ---
Silly question: I would expect -O0 not to perform any simplifications like
that.  Does `gcc` have a knob to disable `match.pd` templates? Or some of them
are crucial for correctness?

[Bug middle-end/110726] [14 Regression] wrong code on llvm-16 around 'a |= a == 0'

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110726

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Sergei Trofimovich from comment #7)
> Silly question: I would expect -O0 not to perform any simplifications like
> that.  Does `gcc` have a knob to disable `match.pd` templates? Or some of
> them are crucial for correctness?

Some are crucial for correctness usually dealing with c++. you could always use
dbg_cnt to try to narrow down which one is failing.


See 
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/dbgcnt.def;h=9e2f1d857b49c6c331cc7d1c419eafa0f2403e96;hb=HEAD

For on how to use dbg_cnt

match is the counter here.

Also for generic folding -fdump-tree-original-folding will have the debug info
on what match pattern was applied during "fold" (of generic).

[Bug middle-end/110726] [14 Regression] wrong code on llvm-16 around 'a |= a == 0'

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110726

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |patch
                URL|                            |https://gcc.gnu.org/piperma
                   |                            |il/gcc-patches/2023-July/62
                   |                            |4847.html

--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624847.html

[Bug middle-end/110726] [14 Regression] wrong code on llvm-16 around 'a |= a == 0'

[slyfox at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110726

--- Comment #10 from Sergei Trofimovich <slyfox at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #5)
> Created attachment 55575 [details]
> Patch which should fix this

This fixed llvm-16 test suite for me. Thank you!

[Bug middle-end/110726] [14 Regression] wrong code on llvm-16 around 'a |= a == 0'

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110726

--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The trunk branch has been updated by Andrew Pinski <pinskia@gcc.gnu.org>:

https://gcc.gnu.org/g:bf20b770d9aabb15faf2644b5e3106249cb175f3

commit r14-2648-gbf20b770d9aabb15faf2644b5e3106249cb175f3
Author: Andrew Pinski <apinski@marvell.com>
Date:   Tue Jul 18 21:11:46 2023 +0000

    Fix PR110726: a | (a == b) can sometimes produce wrong code

    So I had missed/forgot that EQ_EXPR could have an non boolean
    type for generic when I implemented r14-2556-g0407ae8a7732d9.
    This patch adds check for one bit precision intergal type
    which fixes the problem.

    OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.

            PR tree-optimization/110726

    gcc/ChangeLog:

            * match.pd ((a|b)&(a==b),a|(a==b),(a&b)|(a==b)):
            Add checks to make sure the type was one bit precision
            intergal type.

    gcc/testsuite/ChangeLog:

            * gcc.c-torture/execute/bitops-1.c: New test.

[Bug middle-end/110726] [14 Regression] wrong code on llvm-16 around 'a |= a == 0'

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110726

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #12 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Fixed.