public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug target/114194] New: ICE when using std::unique_ptr with xtheadvector
@ 2024-03-01 17:02 camel-cdr at protonmail dot com
  2024-03-02  9:22 ` [Bug target/114194] " pinskia at gcc dot gnu.org
                   ` (7 more replies)
  0 siblings, 8 replies; 9+ messages in thread
From: camel-cdr at protonmail dot com @ 2024-03-01 17:02 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 114194
           Summary: ICE when using std::unique_ptr with xtheadvector
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: camel-cdr at protonmail dot com
  Target Milestone: ---

Using std::unique_ptr with xtheadvector enabled causes an ICE:

#include <memory>
extern void use(std::unique_ptr<int> &x);
void test(size_t n) {
        std::unique_ptr<int> x;
        use(x);
}

See also: https://godbolt.org/z/6nbhxKdfd

I've managed to reduce the problem to the following set of templates, but I
have no idea how this could cause the ICE.

struct S1 { int x; };
struct S2 { constexpr S2() { } template<class T> S2(T&); };
struct S3 : S1, S2 { constexpr S3() : S1() { } S3(S3&); };
void f(S3 &) { S3 x; f(x); }


See also: https://godbolt.org/z/5YxM6jd3s

It's extremely brittle, the ICE goes away, if you remove constexpr, the
reference, or any other part I could think of.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug target/114194] ICE when using std::unique_ptr with xtheadvector
  2024-03-01 17:02 [Bug target/114194] New: ICE when using std::unique_ptr with xtheadvector camel-cdr at protonmail dot com
@ 2024-03-02  9:22 ` pinskia at gcc dot gnu.org
  2024-03-04 14:14 ` pinskia at gcc dot gnu.org
                   ` (6 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-03-02  9:22 UTC (permalink / raw)
  To: gcc-bugs

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |riscv
           Keywords|                            |ice-on-valid-code

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

<source>:4:28: error: unrecognizable insn:
    4 | void f(S3 &) { S3 x; f(x); }
      |                            ^
(insn 6 3 7 2 (set (reg:RVVMF8QI 134)
        (unspec:RVVMF8QI [
                (const_vector:RVVMF8QI [
                        (const_int 0 [0])
                    ])
                (reg:DI 0 zero)
                (const_int 1 [0x1])
                (reg:SI 66 vl)
                (reg:SI 67 vtype)
            ] UNSPEC_TH_VWLDST)) "<source>":4:19 -1
     (expr_list:REG_EQUAL (const_vector:RVVMF8QI [
                (const_int 0 [0])
            ])
        (nil)))
during RTL pass: vregs

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug target/114194] ICE when using std::unique_ptr with xtheadvector
  2024-03-01 17:02 [Bug target/114194] New: ICE when using std::unique_ptr with xtheadvector camel-cdr at protonmail dot com
  2024-03-02  9:22 ` [Bug target/114194] " pinskia at gcc dot gnu.org
@ 2024-03-04 14:14 ` pinskia at gcc dot gnu.org
  2024-03-04 19:26 ` bruce at hoult dot org
                   ` (5 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu.org @ 2024-03-04 14:14 UTC (permalink / raw)
  To: gcc-bugs

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bruce at hoult dot org

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
*** Bug 114226 has been marked as a duplicate of this bug. ***

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug target/114194] ICE when using std::unique_ptr with xtheadvector
  2024-03-01 17:02 [Bug target/114194] New: ICE when using std::unique_ptr with xtheadvector camel-cdr at protonmail dot com
  2024-03-02  9:22 ` [Bug target/114194] " pinskia at gcc dot gnu.org
  2024-03-04 14:14 ` pinskia at gcc dot gnu.org
@ 2024-03-04 19:26 ` bruce at hoult dot org
  2024-03-04 23:27 ` bruce at hoult dot org
                   ` (4 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: bruce at hoult dot org @ 2024-03-04 19:26 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #3 from Bruce Hoult <bruce at hoult dot org> ---
Simpler example, found independently.

    void *memset();
    void a(void *b){ memset(b, 0, 1lu); }

There might be a lot of code that triggers this. Fortunately the source file
this happened in didn't actually use RVV (others did) so I was able to simply
use rv64gc for it.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug target/114194] ICE when using std::unique_ptr with xtheadvector
  2024-03-01 17:02 [Bug target/114194] New: ICE when using std::unique_ptr with xtheadvector camel-cdr at protonmail dot com
                   ` (2 preceding siblings ...)
  2024-03-04 19:26 ` bruce at hoult dot org
@ 2024-03-04 23:27 ` bruce at hoult dot org
  2024-03-05  0:04 ` bruce at hoult dot org
                   ` (3 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: bruce at hoult dot org @ 2024-03-04 23:27 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #4 from Bruce Hoult <bruce at hoult dot org> ---
I've bisected this and the problem is introduced in 2d7205eb2c3 "RISC-V: Handle
differences between XTheadvector and Vector"

Fortunately this commit touches only 136 lines of code, unlike the later two
xtheadvector commits which are 1119 and 204 touched lines.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug target/114194] ICE when using std::unique_ptr with xtheadvector
  2024-03-01 17:02 [Bug target/114194] New: ICE when using std::unique_ptr with xtheadvector camel-cdr at protonmail dot com
                   ` (3 preceding siblings ...)
  2024-03-04 23:27 ` bruce at hoult dot org
@ 2024-03-05  0:04 ` bruce at hoult dot org
  2024-03-05  2:21 ` bruce at hoult dot org
                   ` (2 subsequent siblings)
  7 siblings, 0 replies; 9+ messages in thread
From: bruce at hoult dot org @ 2024-03-05  0:04 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #5 from Bruce Hoult <bruce at hoult dot org> ---
oops .. 379 lines .. I grep'd wrong. Anyway...

gcc/config/riscv/riscv-vector-switch.def

-ENTRY (RVVMF2QI, true, LMUL_F2, 16)
-ENTRY (RVVMF4QI, true, LMUL_F4, 32)
-ENTRY (RVVMF8QI, TARGET_MIN_VLEN > 32, LMUL_F8, 64)
+ENTRY (RVVMF2QI, !TARGET_XTHEADVECTOR, LMUL_F2, 16)
+ENTRY (RVVMF4QI, !TARGET_XTHEADVECTOR, LMUL_F4, 32)
+ENTRY (RVVMF8QI, TARGET_MIN_VLEN > 32 && !TARGET_XTHEADVECTOR, LMUL_F8, 64)

Fractional LMUL (including RVVMF8QI) is removed. Correct, 0.7.1 doesn't have
it.

But something still tries to use it.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug target/114194] ICE when using std::unique_ptr with xtheadvector
  2024-03-01 17:02 [Bug target/114194] New: ICE when using std::unique_ptr with xtheadvector camel-cdr at protonmail dot com
                   ` (4 preceding siblings ...)
  2024-03-05  0:04 ` bruce at hoult dot org
@ 2024-03-05  2:21 ` bruce at hoult dot org
  2024-03-21 15:20 ` cmuellner at gcc dot gnu.org
  2024-03-22  7:43 ` cmuellner at gcc dot gnu.org
  7 siblings, 0 replies; 9+ messages in thread
From: bruce at hoult dot org @ 2024-03-05  2:21 UTC (permalink / raw)
  To: gcc-bugs

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

--- Comment #6 from Bruce Hoult <bruce at hoult dot org> ---
The ICE also happens with bzero().

The ICE does NOT happen with a constant length of 16 of greater, in which case
a function call is made instead of expanding inline.

With rv64gv or rv64gcv a series of N `sb` are generated (N < 16)

With rv64gc_xtheadvector, N >= 6, and -Os a tail call to memset is generated,
no ICE. With N < 6 ... ICE.

So the problem is only trying to expand memset() or bzero() inline. Does it try
to use a vectorised memset? That doesn't happen with rv64gcv.

memcpy() does not ICE for any N.

I assume the originally reported C++ code is generating a memset() to
initialise one of the classes/structs.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug target/114194] ICE when using std::unique_ptr with xtheadvector
  2024-03-01 17:02 [Bug target/114194] New: ICE when using std::unique_ptr with xtheadvector camel-cdr at protonmail dot com
                   ` (5 preceding siblings ...)
  2024-03-05  2:21 ` bruce at hoult dot org
@ 2024-03-21 15:20 ` cmuellner at gcc dot gnu.org
  2024-03-22  7:43 ` cmuellner at gcc dot gnu.org
  7 siblings, 0 replies; 9+ messages in thread
From: cmuellner at gcc dot gnu.org @ 2024-03-21 15:20 UTC (permalink / raw)
  To: gcc-bugs

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

Christoph Müllner <cmuellner at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |cmuellner at gcc dot gnu.org
   Last reconfirmed|                            |2024-03-21
                 CC|                            |cmuellner at gcc dot gnu.org
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |ASSIGNED
   Target Milestone|---                         |14.0

--- Comment #7 from Christoph Müllner <cmuellner at gcc dot gnu.org> ---
Thanks for reporting and providing several minimal reproducers.

I can reproduce the issue and have further analyzed it.
During the analysis, I've noticed that not only memset-zero (clear-memory) is
affected,
but all memset expansions (e.g. `memset(p, 3, 15)`).

I also have a potential fix that will be sent to the list once the testing run
is completed.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* [Bug target/114194] ICE when using std::unique_ptr with xtheadvector
  2024-03-01 17:02 [Bug target/114194] New: ICE when using std::unique_ptr with xtheadvector camel-cdr at protonmail dot com
                   ` (6 preceding siblings ...)
  2024-03-21 15:20 ` cmuellner at gcc dot gnu.org
@ 2024-03-22  7:43 ` cmuellner at gcc dot gnu.org
  7 siblings, 0 replies; 9+ messages in thread
From: cmuellner at gcc dot gnu.org @ 2024-03-22  7:43 UTC (permalink / raw)
  To: gcc-bugs

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

Christoph Müllner <cmuellner at gcc dot gnu.org> changed:

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

--- Comment #8 from Christoph Müllner <cmuellner at gcc dot gnu.org> ---
Closing as resolved (the fix has been pushed on master).

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2024-03-22  7:43 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-03-01 17:02 [Bug target/114194] New: ICE when using std::unique_ptr with xtheadvector camel-cdr at protonmail dot com
2024-03-02  9:22 ` [Bug target/114194] " pinskia at gcc dot gnu.org
2024-03-04 14:14 ` pinskia at gcc dot gnu.org
2024-03-04 19:26 ` bruce at hoult dot org
2024-03-04 23:27 ` bruce at hoult dot org
2024-03-05  0:04 ` bruce at hoult dot org
2024-03-05  2:21 ` bruce at hoult dot org
2024-03-21 15:20 ` cmuellner at gcc dot gnu.org
2024-03-22  7:43 ` cmuellner at gcc dot gnu.org

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).