[Bug target/108495] New: [10/11/12/13 Regression] aarch64 ICE with __builtin_aarch64_rndr

[Bug target/108495] New: [10/11/12/13 Regression] aarch64 ICE with __builtin_aarch64_rndr

[jakub at gcc dot gnu.org]

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

            Bug ID: 108495
           Summary: [10/11/12/13 Regression] aarch64 ICE with
                    __builtin_aarch64_rndr
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

int
main ()
{
  unsigned long v;
  __builtin_aarch64_rndr (&v);
  return 0;
}

ICEs on aarch64 unless compiled with -march that includes rng.
Maybe other builtins do too.
GCC 4.8 didn't support the builtin and didn't ICE (so it is a regression), GCC
8 already ICEs on it.

[Bug target/108495] [10/11/12/13 Regression] aarch64 ICE with __builtin_aarch64_rndr

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P2
   Target Milestone|---                         |10.5
                 CC|                            |ktkachov at gcc dot gnu.org,
                   |                            |rearnsha at gcc dot gnu.org,
                   |                            |rsandifo at gcc dot gnu.org

[Bug target/108495] [10/11/12/13 Regression] aarch64 ICE with __builtin_aarch64_rndr

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
           Keywords|                            |ice-on-invalid-code
   Last reconfirmed|                            |2023-01-23
             Status|UNCONFIRMED                 |NEW

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed. That said, __builtin_aarch64_rndr is not supposed to be used
directly by the user. They should include <arm_acle.h> and use the __rndr
intrinsic instead.
That will give the appropriate error:
inlining failed in call to 'always_inline' '__rndr': target specific option
mismatch

Still, I suppose the compiler shouldn't ICE

[Bug target/108495] [10/11/12/13 Regression] aarch64 ICE with __builtin_aarch64_rndr

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I know, that is basically what I told the reporter in
https://bugzilla.redhat.com/show_bug.cgi?id=2161928

[Bug target/108495] [10/11/12/13 Regression] aarch64 ICE with __builtin_aarch64_rndr

[dantipov at cloudlinux dot com]

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

Dmitry Antipov <dantipov at cloudlinux dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dantipov at cloudlinux dot com

--- Comment #3 from Dmitry Antipov <dantipov at cloudlinux dot com> ---
Thanks. BTW is it possible to make the diagnostics some more
developer-friendly? In particular, plain 'gcc test.c' doesn't specify any
target-specific options explicitly, and it may be required to look through
'arm_acle.h' to realize that the thing like 'gcc -march=armv8.5-a+rng test.c'
is required instead.

[Bug target/108495] [10/11/12/13 Regression] aarch64 ICE with __builtin_aarch64_rndr

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Why?  You shouldn't use the builtins directly, they are implementation detail
for implementing the intrinsics and the intrinsics don't suffer ever from this
problem
because they ensure the correct target options already.

[Bug target/108495] [10/11/12/13 Regression] aarch64 ICE with __builtin_aarch64_rndr

[dantipov at cloudlinux dot com]

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

--- Comment #5 from Dmitry Antipov <dantipov at cloudlinux dot com> ---
# cat t-rand.c 
#include <stdint.h>
#include <arm_acle.h>

int main(int argc, char *argv[]) {
  uint64_t v;
  __rndr(&v);
  return 0;
}

# gcc t-rand.c 
In file included from t-rand.c:2:
/usr/lib/gcc/aarch64-redhat-linux/12/include/arm_acle.h: In function ‘main’:
/usr/lib/gcc/aarch64-redhat-linux/12/include/arm_acle.h:313:1: error: inlining
failed in call to ‘always_inline’ ‘__rndr’: target specific option mismatch
  313 | __rndr (uint64_t *__res)
      | ^~~~~~
t-rand.c:6:3: note: called from here
    6 |   __rndr(&v);
      |   ^~~~~~~~~~

So, what target-specific option is wrong if none of them was specified?

[Bug target/108495] [10/11/12/13 Regression] aarch64 ICE with __builtin_aarch64_rndr

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
That message indeed could at least print the diff between the target options of
the caller and callee as a follow-up note.

[Bug target/108495] [10/11/12/13 Regression] aarch64 ICE with __builtin_aarch64_rndr

[ktkachov at gcc dot gnu.org]

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

--- Comment #7 from ktkachov at gcc dot gnu.org ---
Yes, GCC could be more helpful here. The intrinsics and their use is documented
in the ACLE document:
https://github.com/ARM-software/acle/blob/main/main/acle.md#random-number-generation-intrinsics
There is work ongoing to augument it with more user-friendly information about
compiler flags, but GCC could keep track of the options used to gate these
builtins/intrinsics and report a hint

[Bug target/108495] [11/12/13/14 Regression] aarch64 ICE with __builtin_aarch64_rndr

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|10.5                        |11.5

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> ---
GCC 10 branch is being closed.

[Bug target/108495] [11/12/13/14 Regression] aarch64 ICE with __builtin_aarch64_rndr

[pinskia at gcc dot gnu.org]

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

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

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

--- Comment #9 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I have a (simple) fix.
Just need to tweak the exact error message.

[Bug target/108495] [11/12/13/14 Regression] aarch64 ICE with __builtin_aarch64_rndr

[pinskia at gcc dot gnu.org]

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

--- Comment #10 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Created attachment 57476
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57476&action=edit
Current patch

The error message needs some tweaking but this is basically the patch. Will
also add a few testcases too.

[Bug target/108495] [11/12/13/14 Regression] aarch64 ICE with __builtin_aarch64_rndr

[pinskia at gcc dot gnu.org]

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

--- Comment #11 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The CRC functions need a similar handling, e.g.:
```
int
f ()
{
  unsigned long v;
  return __builtin_aarch64_crc32b (v, v);
}
```

[Bug target/108495] [11/12/13/14 Regression] aarch64 ICE with __builtin_aarch64_rndr

[pinskia at gcc dot gnu.org]

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

--- Comment #12 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Likewise for the __builtin_aarch64_fcmla_laneq* builtins:

```
#define vect64 __attribute__((vector_size(8)))
#define vect128 __attribute__((vector_size(16)))
int
m ()
{
  unsigned long v;
  vect64 float t;
  vect128 float t1;
  __builtin_aarch64_fcmla_laneq0v2sf(t,t,t1,0);
}
```

[Bug target/108495] [11/12/13/14 Regression] aarch64 ICE with __builtin_aarch64_rndr

[pinskia at gcc dot gnu.org]

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

--- Comment #13 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
And __builtin_aarch64_jcvtzs:


```
int
m ()
{
  __builtin_aarch64_jcvtzs(1.0);
}
```

[Bug target/108495] [11/12/13/14 Regression] aarch64 ICE with __builtin_aarch64_rndr

[pinskia at gcc dot gnu.org]

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

--- Comment #14 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I think the rest are handled correctly but I have not audited everyone yet.

[Bug target/108495] [11/12/13/14 Regression] aarch64 ICE with __builtin_aarch64_rndr

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|                            |https://gcc.gnu.org/bugzill
                   |                            |a/show_bug.cgi?id=90798

--- Comment #15 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to ktkachov from comment #7)
> Yes, GCC could be more helpful here. 

And the diagnostic issue with target option mismatch is recorded in PR 90798
though there might be some target specific changes needed really.