[Bug target/112740] New: [14 Regression] wrong code with vector compare on riscv64 at -O0

[Bug target/112740] New: [14 Regression] wrong code with vector compare on riscv64 at -O0

[zsojka at seznam dot cz]

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

            Bug ID: 112740
           Summary: [14 Regression] wrong code with vector compare on
                    riscv64 at -O0
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: zsojka at seznam dot cz
  Target Milestone: ---
              Host: x86_64-pc-linux-gnu
            Target: riscv64-unknown-linux-gnu

Created attachment 56704
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56704&action=edit
reduced testcase

Output:
$ riscv64-unknown-linux-gnu-gcc testcase.c -static
$ qemu-riscv64 -- ./a.out 
Aborted

"x" is "ffff...ffff" instead of 0

I am using qemu userspace emulation, so this might be a false positive:

$ qemu-riscv64 -version
qemu-riscv64 version 8.1.3
Copyright (c) 2003-2023 Fabrice Bellard and the QEMU Project developers

$ riscv64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-riscv64/bin/riscv64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-5898-20231127211931-gce52f1f7074-checking-yes-rtl-df-extra-riscv64/bin/../libexec/gcc/riscv64-unknown-linux-gnu/14.0.0/lto-wrapper
Target: riscv64-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --with-isa-spec=2.2
--with-sysroot=/usr/riscv64-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=riscv64-unknown-linux-gnu
--with-ld=/usr/bin/riscv64-unknown-linux-gnu-ld
--with-as=/usr/bin/riscv64-unknown-linux-gnu-as --disable-multilib
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-5898-20231127211931-gce52f1f7074-checking-yes-rtl-df-extra-riscv64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231128 (experimental) (GCC)

[Bug target/112740] [14 Regression] wrong code with vector compare on riscv64 at -O0

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |14.0

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I have a suspision, that it will get fixed with
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/638373.html

[Bug target/112740] [14 Regression] wrong code with vector compare on riscv64 at -O0

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Does this work post:
https://gcc.gnu.org/pipermail/gcc-cvs/2023-November/394162.html

?

If so I will commit a testcase.

[Bug target/112740] [14 Regression] wrong code with vector compare on riscv64 at -O0

[zsojka at seznam dot cz]

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

--- Comment #3 from Zdenek Sojka <zsojka at seznam dot cz> ---
(In reply to Andrew Pinski from comment #2)
> Does this work post:
> https://gcc.gnu.org/pipermail/gcc-cvs/2023-November/394162.html
> 
> ?
> 
> If so I will commit a testcase.

thank you for checking

Assuming this should have been fixed in r14-5938, it is still failing for me
with r14-5940 and r14-5986:
$ riscv64-unknown-linux-gnu-gcc testcase.c -static
$ ./a.out
Aborted

The value of x[0] is "ffff...ffff".

It is FAILing on: aarch64-unknown-linux-gnu, mips64el-unknown-linux-gnuabi64,
riscv64-unknown-linux-gnu
And PASSing on: x86_64-pc-linux-gnu, powerpc64le-unknown-linux-gnu

$ riscv64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-riscv64/bin/riscv64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-5940-20231128183456-g3d104d93a70-checking-yes-rtl-df-extra-riscv64/bin/../libexec/gcc/riscv64-unknown-linux-gnu/14.0.0/lto-wrapper
Target: riscv64-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --with-isa-spec=2.2
--with-sysroot=/usr/riscv64-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=riscv64-unknown-linux-gnu
--with-ld=/usr/bin/riscv64-unknown-linux-gnu-ld
--with-as=/usr/bin/riscv64-unknown-linux-gnu-as --disable-multilib
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-5940-20231128183456-g3d104d93a70-checking-yes-rtl-df-extra-riscv64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231128 (experimental) (GCC)

[Bug target/112740] [14 Regression] wrong code with vector compare on riscv64 at -O0

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2023-11-30
             Target|riscv64-unknown-linux-gnu   |riscv64-unknown-linux-gnu
                   |                            |aarch64
             Status|UNCONFIRMED                 |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |pinskia at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I will check tomorrow if I can see if I can spot what is wrong on aarch64.

[Bug target/112740] [14 Regression] wrong code with vector compare on riscv64 at -O0

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
x86_64 IR:
  c.0_6 = c_5(D);
  _2 = (__int128 unsigned) c.0_6;
  _1 = {_2};
  _10 = VIEW_CONVERT_EXPR<__int128 unsigned>(v_7(D));
  _11 = _10 >= _2;
  _12 = (int128_t) _11;
  _13 = -_12;
  _14 = (<signed-boolean:128>) _13;
  _3 = {_14};
  _15 = _12 + -1;
  _16 = (<signed-boolean:128>) _15;
  _4 = {_16};
  _8 = VIEW_CONVERT_EXPR<V>(_4);



aarch64 (and I think riscv) IR:
  c.0_6 = c_5(D);
  _2 = (__int128 unsigned) c.0_6;
  _1 = {_2};
  _10 = VIEW_CONVERT_EXPR<__int128 unsigned>(v_7(D));
  _11 = _10 >= _2;
  _12 = (int128_t) _11;
  _13 = -_12;
  _14 = (<signed-boolean:128>) _13;
  _3 = {_14};
  _4 = ~_3;
  _15 = VIEW_CONVERT_EXPR<<signed-boolean:128>>(_4);
  _16 = _15 != 0;
  _17 = (__int128 unsigned) _16;
  _18 = -_17;
  _8 = {_18};

[Bug target/112740] [14 Regression] wrong code with vector compare on riscv64 at -O0

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Veclower -O0 produces
  c.0_6 = c_5(D);
  _2 = (__int128 unsigned) c.0_6;
  _1 = {_2};
  _10 = VIEW_CONVERT_EXPR<__int128 unsigned>(v_7(D));
  _11 = _10 >= _2; // 1 true
  _12 = (int128_t) _11; // 1
  _13 = -_12; // -1
  _14 = (<signed-boolean:128>) _13; // -1 aka true
  _3 = {_14}; // {-1} aka true
  _4 = ~_3; // 0 aka false
  _15 = VIEW_CONVERT_EXPR<<signed-boolean:128>>(_4); // 0 aka false
  _16 = _15 != 0; // 0 != 0, 0 false
  _17 = (__int128 unsigned) _16; // 0
  _18 = -_17; // 0
  _8 = {_18};

Which looks correct.
NOTE the ~ there, I am suspecting it is producing the wrong result ...

[Bug middle-end/112740] [14 Regression] wrong code with vector compare on riscv64 at -O0

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|target                      |middle-end

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Oh it is not the ~ but rather `_3 = {_16};` which produces the wrong code:
//  <signed-boolean:128> _16;
//   vector(1) <signed-boolean:128> _3;

;; _3 = {_16};

(insn 36 35 37 (set (reg:TI 114)
        (reg:TI 102 [ _16 ])) "/app/example.cpp":15:6 -1
     (nil))

(insn 37 36 38 (set (subreg:DI (reg:TI 113) 0)
        (and:DI (subreg:DI (reg:TI 114) 0)
            (const_int 1 [0x1]))) "/app/example.cpp":15:6 -1
     (nil))

(insn 38 37 39 (set (reg:DI 115)
        (const_int 0 [0])) "/app/example.cpp":15:6 -1
     (nil))

(insn 39 38 40 (set (subreg:DI (reg:TI 113) 8)
        (and:DI (subreg:DI (reg:TI 114) 8)
            (reg:DI 115))) "/app/example.cpp":15:6 -1
     (nil))

(insn 40 39 0 (set (reg:TI 94 [ _3 ])
        (reg:TI 113)) "/app/example.cpp":15:6 -1
     (nil))


That is wrong. that is producing 1 in _3 when it should have been -1 .
That is it is doing `r94 = r102 & 0x1` which is totally wrong/broken ...

[Bug middle-end/112740] [14 Regression] wrong code with vector compare on riscv64 at -O0

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |NEW
           Assignee|pinskia at gcc dot gnu.org         |unassigned at gcc dot gnu.org

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I am not going to able to figure out how to fix expand for a while so
unassigning. But at least there is some analysis on what is going on.

[Bug middle-end/112740] [14 Regression] wrong code with vector compare on riscv64 at -O0

[pinskia at gcc dot gnu.org]

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

--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Note this was exposed by r14-3350-g47b833a9abe19d which changed the original IR
From:
  _4 = VEC_COND_EXPR <_3, { -1 }, { 0 }>;
  _5 = VIEW_CONVERT_EXPR<vector(1) __int128 unsignedD.14>(_4);
  _6 = _5 == { 0 };
  _7 = VEC_COND_EXPR <_6, { -1 }, { 0 }>;
  _8 = VIEW_CONVERT_EXPR<VD.4391>(_7);

To:
  _4 = ~_3;
  _5 = VEC_COND_EXPR <_4, { 0xffffffffffffffffffffffffffffffff }, { 0 }>;

Which is 100% correct and nothing wrong with that change there either.

[Bug middle-end/112740] [14 Regression] wrong code with vector compare on riscv64 at -O0

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ams at gcc dot gnu.org

--- Comment #10 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Actually it looks like r14-5319-ga5922427c29fad broke this.

This expand patch seems broken for the case in general. I am suspecting
something else is broken for GCN here ...

[Bug middle-end/112740] [14 Regression] wrong code with vector compare on riscv64 at -O0

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
The only thing that's maybe suspicious is that

        machine_mode mode = GET_MODE (target);

but we test

        /* Use sign-extension for uniform boolean vectors with
           integer modes.  Effectively "vec_duplicate" for bitmasks.  */
        if (!TREE_SIDE_EFFECTS (exp)
            && VECTOR_BOOLEAN_TYPE_P (type)
            && SCALAR_INT_MODE_P (mode)

where we might want to test SCALAR_INT_MODE_P (TYPE_MODE (type)) instead.
Not sure if we ever call store_constructor with target not having the same
mode as 'exp' though ...  Or we should check that mode == TYPE_MODE (type)
since we're moving to target anyway.

[Bug middle-end/112740] [14 Regression] wrong code with vector compare on riscv64 at -O0

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2023-11-30 00:00:00         |2024-1-10
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org
           Priority|P3                          |P1
             Status|NEW                         |ASSIGNED
                 CC|                            |rguenth at gcc dot gnu.org

--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> ---
Still the same AFAICS, looking.

[Bug middle-end/112740] [14 Regression] wrong code with vector compare on riscv64 at -O0

[rguenth at gcc dot gnu.org]

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

--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> ---
The issue is the code expects 1-bit masks but doesn't check for it.  Of course
it would also work for multi-bit masks, not sure if that would ever trigger -
maybe for vector lowering code.

[Bug middle-end/112740] [14 Regression] wrong code with vector compare on riscv64 at -O0

[cvs-commit at gcc dot gnu.org]

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

--- Comment #14 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Richard Biener <rguenth@gcc.gnu.org>:

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

commit r14-7129-ge1f2d58a1e2536f13d3f2ea2d7373ae62cec9125
Author: Richard Biener <rguenther@suse.de>
Date:   Wed Jan 10 14:54:10 2024 +0100

    middle-end/112740 - vector boolean CTOR expansion issue

    The optimization to expand uniform boolean vectors by sign-extension
    works only for dense masks but it failed to check that.

            PR middle-end/112740
            * expr.cc (store_constructor): Check the integer vector
            mask has a single bit per element before using sign-extension
            to expand an uniform vector.

            * gcc.dg/pr112740.c: New testcase.

[Bug middle-end/112740] [14 Regression] wrong code with vector compare on riscv64 at -O0

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

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

--- Comment #15 from Richard Biener <rguenth at gcc dot gnu.org> ---
Should be fixed now.