[Bug target/112698] gcc r14-5617-gb8592186611 introduces regressions in bfloat16_vector_typecheck_1.c for cortex-m0 and cortex-m3

2023-12-01 Thread clyon at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112698

Christophe Lyon  changed:

   What|Removed |Added

 CC||ktkachov at gcc dot gnu.org,
   ||rearnsha at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org

--- Comment #6 from Christophe Lyon  ---
adding maintainers who might provide larger context wrt compatibility with
other compilers.

[Bug target/112698] gcc r14-5617-gb8592186611 introduces regressions in bfloat16_vector_typecheck_1.c for cortex-m0 and cortex-m3

2023-11-30 Thread mkretz at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112698

--- Comment #5 from Matthias Kretz (Vir)  ---
OK, I can follow that reasoning. It's still a breaking change for everyone that
was using int up to this point. I guess the argument is that using int was
wrong in the first place and it just happened to work by chance. The right type
to use would have been int32_t instead of int. However, if I use int32_t for
interacting with NEON intrinsics, will this work everywhere (older GCC, Clang,
etc.)? Or is the only portable solution decltype(int32x2t()[0])?

[Bug target/112698] gcc r14-5617-gb8592186611 introduces regressions in bfloat16_vector_typecheck_1.c for cortex-m0 and cortex-m3

2023-11-30 Thread clyon at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112698

--- Comment #4 from Christophe Lyon  ---
@mkretz, this commit may also be of interest for some more context:
https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=d12d2aa4fccc76a9a08c8120c5e37d9cab8683e8

[Bug target/112698] gcc r14-5617-gb8592186611 introduces regressions in bfloat16_vector_typecheck_1.c for cortex-m0 and cortex-m3

2023-11-30 Thread clyon at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112698

Christophe Lyon  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-11-30

--- Comment #3 from Christophe Lyon  ---
gcc.target/arm/bfloat16_vector_typecheck_[12].c testcases fixed.

There's still a problem with experimental/simd/pr109261_constexpr_simd.cc,
which may involve a change to simd_neon.h or simd.h

[Bug target/112698] gcc r14-5617-gb8592186611 introduces regressions in bfloat16_vector_typecheck_1.c for cortex-m0 and cortex-m3

2023-11-30 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112698

--- Comment #2 from GCC Commits  ---
The master branch has been updated by Christophe Lyon :

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

commit r14-6018-gd77d2dd9bdea7b8963db2a0a06ca481458ef2c98
Author: Christophe Lyon 
Date:   Thu Nov 30 10:10:24 2023 +

testsuite/arm: Fix bfloat16_vector_typecheck_[12].c tests [PR 112698]

After commit r14-5617-gb8592186611, int32x[24]_t types now use
elements of 'long int' type instead of 'int' on arm-eabi (it's still
'int' on arm-linux-gnueabihf).  Both are 32-bit types anyway.

This patch adjust the two tests so that they optionnally accept 'long '
before 'int' in the expected error message.

2023-11-30  Christophe Lyon  

PR target/112698
gcc/testsuite/
* gcc.target/arm/bfloat16_vector_typecheck_1.c: Update expected
error message.
* gcc.target/arm/bfloat16_vector_typecheck_2.c: Likewise.