[Bug libfortran/108056] [12/13 Regression] backward compatibility issue between 11 and 12

[gilles.gouaillardet at gmail dot com via Gcc-bugs]

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

--- Comment #11 from Gilles Gouaillardet  
---
gfortran-11 compiles and run correctly when it uses libgfortran-11.

To be perfectly clear, compilation always work: the issue occurs at runtime
when gfortran-11 compiled code uses libgfortran-12).

[Bug libfortran/108056] backward compatibility issue between 11 and 12

[gilles.gouaillardet at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Gilles Gouaillardet  
---
For the sake of completeness, debian/ubuntu ships libgfortran.a (read, the
static library) from gfortran-11, so I can get this reproducer work if
compiling with -static-libgfortran.

I also manually rebuilt gfortran-11 on debian (I did my best to reuse debian
patches) and it worked. It took me some time to figure out it worked because I
then implicitly used libgfortran-11.

[Bug libfortran/108056] backward compatibility issue between 11 and 12

[gilles.gouaillardet at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Gilles Gouaillardet  
---
ubuntu does not ship libgfortran.so from gfortran-11.

I tried on a RedHat box, and the issue only occurs when
 - I compile with gfortran-11
 - *and* I force libgfortran-12

(so if i use the same gfortran and libgfortran versions, there is no issue).

Here is a stack trace in these conditions:

#0  0x2ba2dd70 in _exit () from /lib64/libc.so.6
#1  0x2b9a1cab in __run_exit_handlers () from /lib64/libc.so.6
#2  0x2b9a1d37 in exit () from /lib64/libc.so.6
#3  0x2acf0976 in _gfortrani_exit_error (status=3) at
../../../../src/gcc-12.1.0/libgfortran/runtime/error.c:218
#4  0x2acf12af in _gfortrani_internal_error (cmp=0x0,
message=0x2afdf2a5 "Invalid type in descriptor") at
../../../../src/gcc-12.1.0/libgfortran/runtime/error.c:534
#5  0x2af787e2 in _gfortran_gfc_desc_to_cfi_desc (d_ptr=0x7fffcfa8,
s=0x7fffcfd0) at
../../../../src/gcc-12.1.0/libgfortran/runtime/ISO_Fortran_binding.c:219
#6  0x00400808 in pub_f08ts (a=, 
b=) at /home/usersup/gilles/y.f90:29
#7  0x004007ad in bugsub (a=1, b=-3.67578065e-13) at
/home/usersup/gilles/y.f90:35
#8  0x004008d0 in bug () at /home/usersup/gilles/y.f90:43
#9  0x00400907 in main (argc=1, argv=0x7fffd4cd) at
/home/usersup/gilles/y.f90:44
#10 0x2b98a555 in __libc_start_main () from /lib64/libc.so.6
#11 0x00400699 in _start ()


FWIW, here is the value of s when _gfortran_gfc_desc_to_cfi_desc is invoked
(gdb) p *s
$6 = {base_addr = 0x7fffd04c, offset = 38, dtype = {elem_len = 4, version =
0, rank = 0 '\000', type = 11 '\v', attribute = 2}, span = 4, dim =
0x7fffcff8}

I also noted that if the reproducer is built with gcc-12,
_gfortran_gfc_desc_to_cfi_desc() is not invoked at all.

[Bug libfortran/108056] New: backward compatibility issue between 11 and 12

[gilles.gouaillardet at gmail dot com via Gcc-bugs]

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

Bug ID: 108056
   Summary: backward compatibility issue between 11 and 12
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gilles.gouaillardet at gmail dot com
  Target Milestone: ---

Created attachment 54062
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54062=edit
a simple reproducer

The attached program crashes when compiled on ubuntu 22.04 (jammy) based on
debian bookworm with gfortran-11:

$ gfortran bug.f90 
$ ./a.out 
Internal Error: Invalid type in descriptor

Error termination. Backtrace:
#0  0x7f04aefe9ad0 in ???
#1  0x7f04aefea649 in ???
#2  0x7f04aefeae38 in ???
#3  0x7f04af22c8a4 in ???
#4  0x56490815c24e in ???
#5  0x56490815c1f3 in ???
#6  0x56490815c316 in ???
#7  0x56490815c352 in ???
#8  0x7f04aedc7d8f in __libc_start_call_main
at ../sysdeps/nptl/libc_start_call_main.h:58
#9  0x7f04aedc7e3f in __libc_start_main_impl
at ../csu/libc-start.c:392
#10  0x56490815c0c4 in ???
#11  0x in ???


After some investigations, I found gfortran-11 uses libgfortran built for
gfortran-12. I guess the fine folks at debian chose to do so since the version
library for libgfortran in 5.0.0 (from gfortran-8 up to gfortran-12, I did not
test gfortran-13) and they assume or expect ABI and semantic compatibility.

The issue can be reproduced by compiling the attached reproducer with
gfortran-11, and running it after tweaking LD_LIBRARY_PATH so it uses
libgfortran from gfortran-12.


I think there are basically two ways to see this issue:
 - it should work, this is a bug in libfrotran-12
 - libgfortran does not ensure such backward compatibility, and because of the
semantic change, the library version should be/have been bumped ( e.g. 5.1.0 or
6.0.0) from gfortran-12.

Once it is decided on how to move forward, I will be more than happy to report
this to the debian folks.

For the records, this issue came to my attention at
https://stackoverflow.com/questions/74738981/the-use-mpi-f08-statement-causes-fortran-mpi-programs-to-crash-on-ubuntu-22-04/74742760#74742760

[Bug c/105449] suspicious optimization since GCC 10.1.0 from -O2

[gilles.gouaillardet at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Gilles Gouaillardet  
---
Thanks for the clarification!

[Bug c/105449] suspicious optimization since GCC 10.1.0 from -O2

[gilles.gouaillardet at gmail dot com via Gcc-bugs]

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

Gilles Gouaillardet  changed:

   What|Removed |Added

 CC||gilles.gouaillardet at gmail 
dot c
   ||om
Summary|suspicious optimization |suspicious optimization
   |since GCC 10.1.0 from - |since GCC 10.1.0 from -O2

--- Comment #2 from Gilles Gouaillardet  
---
The attached reproducer works fine when using -O1 or less aggressive
optimization and on all GCC versions I tested.

However, starting from GCC 10.1.0 and when using -O2 or more aggressive
optimization, the local_pos() subroutine behaves differently compared to the
global_pos() and volatile_pos() subroutines. All these subroutines do virtually
the same things, but only the declaration of the bogus variable changes.

I suspect recent GCC versions perform some register inlining when the bogus
variable is declared as local and non volatile.


Can you please have a look at the reproducer and establish whether:
 - this reproducer has an undefined behavior, and the recent optimizations are
legit
 - this is a bug in GCC >= 10.1.0


For the record, here are my logs (on a x86_64 system, same behavior on aarch64.
Though I did not test, a different behavior is expected on a 64 bits big endian
processor).

$ gcc --version
gcc (GCC) 11.2.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gcc bug.c && ./a.out
global: 0
local: 0
volatile: 0

$ gcc -O2 bug.c && ./a.out
global: 0
local: 2   <--- UNEXPECTED VALUE
volatile: 0


FWIW, a consequence of this optimization is an issue that has been reported at
https://github.com/open-mpi/ompi/issues/10339

[Bug c/105449] suspicious optimization since GCC 10.1.0 from -

[gilles.gouaillardet at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Gilles Gouaillardet  
---
Created attachment 52916
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52916=edit
a simple reproducer

[Bug c/105449] New: suspicious optimization since GCC 10.1.0 from -

[gilles.gouaillardet at gmail dot com via Gcc-bugs]

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

Bug ID: 105449
   Summary: suspicious optimization since GCC 10.1.0 from -
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gilles.gouaillardet at gmail dot com
  Target Milestone: ---

[Bug target/104152] New: ICE with -Ofast -march=armv8.2-a+sve -msve-vector-bits=scalable

[gilles.gouaillardet at gmail dot com via Gcc-bugs]

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

Bug ID: 104152
   Summary: ICE with -Ofast -march=armv8.2-a+sve
-msve-vector-bits=scalable
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gilles.gouaillardet at gmail dot com
  Target Milestone: ---

Created attachment 52248
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52248=edit
a simple reproducer

The attached reproducer crashes with the trunk branch when -Ofast
-march=armv8.2-a+sve -msve-vector-bits=scalable is used:


FWIW, git bisect points to this commit:

commit ce670e4faafb296d1f1a7828d20f8c8ba4686797
Author: Richard Biener 
Date:   Wed Nov 18 14:17:34 2020 +0100

tree-optimization/97832 - handle associatable chains in SLP discovery

This makes SLP discovery handle associatable (including mixed
plus/minus) chains better by swapping operands across the whole
chain.  To work this adds caching of the 'matches' lanes for
failed SLP discovery attempts, thereby fixing a failed SLP
discovery for the slp-pr98855.cc testcase which results in
building an operand from scalars as expected.  Unfortunately
this makes us trip over the cost threshold so I'm XFAILing the
testcase for now.

For BB vectorization all this doesn't work because we have no way
to distinguish good from bad associations as we eventually build
operands from scalars and thus not fail in the classical sense.

2021-05-31  Richard Biener  

PR tree-optimization/97832
* tree-vectorizer.h (_slp_tree::failed): New.
* tree-vect-slp.c (_slp_tree::_slp_tree): Initialize
failed member.
(_slp_tree::~_slp_tree): Free failed.
(vect_build_slp_tree): Retain failed nodes and record
matches in them, copying that back out when running
into a cached fail.  Dump start and end of discovery.
(dt_sort_cmp): New.
(vect_build_slp_tree_2): Handle associatable chains
together doing more aggressive operand swapping.

* gcc.dg/vect/pr97832-1.c: New testcase.
* gcc.dg/vect/pr97832-2.c: Likewise.
* gcc.dg/vect/pr97832-3.c: Likewise.
* g++.dg/vect/slp-pr98855.cc: XFAIL.



Here is the stack trace in my environment:

$ g++ -c -Ofast -march=armv8.2-a+sve -msve-vector-bits=scalable -c badaboum.cpp
2>&1 | tee badaboum.log
during GIMPLE pass: vect
badaboum.cpp: In function ?int badaboum(float*, float**)?:
badaboum.cpp:20:5: internal compiler error: in duplicate_and_interleave, at
tree-vect-slp.cc:6188
   20 | int badaboum(rvec_ cm_mol, float **tc)
  | ^~~~
0x136d3e7 duplicate_and_interleave(vec_info*, gimple**, tree_node*,
vec const&, unsigned int, vec&)
../../../src/gcc-trunk/gcc/tree-vect-slp.cc:6188
0x136d89b vect_create_constant_vectors
../../../src/gcc-trunk/gcc/tree-vect-slp.cc:6409
0x136d89b vect_schedule_slp_node
../../../src/gcc-trunk/gcc/tree-vect-slp.cc:7114
0x137d363 vect_schedule_scc
../../../src/gcc-trunk/gcc/tree-vect-slp.cc:7426
0x137ddbf vect_schedule_scc
../../../src/gcc-trunk/gcc/tree-vect-slp.cc:7443
0x137ddbf vect_schedule_scc
../../../src/gcc-trunk/gcc/tree-vect-slp.cc:7443
0x137ddbf vect_schedule_scc
../../../src/gcc-trunk/gcc/tree-vect-slp.cc:7443
0x137ddbf vect_schedule_scc
../../../src/gcc-trunk/gcc/tree-vect-slp.cc:7443
0x137e60f vect_schedule_slp(vec_info*, vec<_slp_instance*, va_heap, vl_ptr>
const&)
../../../src/gcc-trunk/gcc/tree-vect-slp.cc:7579
0x1355bc3 vect_transform_loop(_loop_vec_info*, gimple*)
../../../src/gcc-trunk/gcc/tree-vect-loop.cc:9753
0x138aa2b vect_transform_loops
../../../src/gcc-trunk/gcc/tree-vectorizer.cc:1003
0x138aa2b try_vectorize_loop_1
../../../src/gcc-trunk/gcc/tree-vectorizer.cc:1133
0x138aa2b try_vectorize_loop
../../../src/gcc-trunk/gcc/tree-vectorizer.cc:1162
0x138b097 execute
../../../src/gcc-trunk/gcc/tree-vectorizer.cc:1278
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/104005] [12 Regression] Regression on aarch64+sve with -O2 -fPIC since r12-5204

[gilles.gouaillardet at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Gilles Gouaillardet  
---
Thanks Richard for the quick fix!

Unfortunately, I just found an other (and much older) issue (ICE, only at
-Ofast) I reported at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104112

[Bug target/104112] ICE with -Ofast -march=armv8.2-a+sve -msve-vector-bits=512

[gilles.gouaillardet at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Gilles Gouaillardet  
---
Created attachment 52227
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52227=edit
a slightly rewritten reproducer that passes compilation

[Bug target/104112] New: ICE with -Ofast -march=armv8.2-a+sve -msve-vector-bits=512

[gilles.gouaillardet at gmail dot com via Gcc-bugs]

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

Bug ID: 104112
   Summary: ICE with -Ofast -march=armv8.2-a+sve
-msve-vector-bits=512
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gilles.gouaillardet at gmail dot com
  Target Milestone: ---

Created attachment 52226
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52226=edit
a simple reproducer

The attached reproducer (trimmed from BLAS) can be used to evidence a crash of
the compiler:

$ g++ -march=armv8.2-a+sve -msve-vector-bits=512 -Ofast -c boom.cpp 
during GIMPLE pass: vect
boom.cpp: In function ?void boom(int, double*, double*)?:
boom.cpp:4:1: internal compiler error: Segmentation fault
4 | boom(int n,
  | ^~~~
0x10436f3 crash_signal
../.././gcc/toplev.c:328
0x12f86ec tree_class_check(tree_node*, tree_code_class, char const*, int, char
const*)
../.././gcc/tree.h:3495
0x12f86ec vect_create_partial_epilog
../.././gcc/tree-vect-loop.c:4953
0x13050ff vect_transform_cycle_phi(_loop_vec_info*, _stmt_vec_info*, gimple**,
_slp_tree*, _slp_instance*)
../.././gcc/tree-vect-loop.c:7728
0x12f562b vect_transform_stmt(vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, _slp_tree*, _slp_instance*)
../.././gcc/tree-vect-stmts.c:10999
0x1311e9b vect_transform_loop(_loop_vec_info*, gimple*)
../.././gcc/tree-vect-loop.c:9686
0x13416db try_vectorize_loop_1
../.././gcc/tree-vectorizer.c:1103
0x13418b7 try_vectorize_loop_1
../.././gcc/tree-vectorizer.c:1141
0x1342317 vectorize_loops()
../.././gcc/tree-vectorizer.c:1242
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


FWIW, g++ works just fine with the slightly rewritten (e.g. do not use a local
variable) noboom.cpp

Based on my snapshots, the issue occurred first between 20210711 and 20210718
(I am now running a git bisect to point to a suspect commit)

[Bug target/104005] [12 Regression] Regression on aarch64+sve with -O2 -fPIC since r12-5204

[gilles.gouaillardet at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Gilles Gouaillardet  
---
Created attachment 52210
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52210=edit
before/after (preprocessed sources + assembly)

[Bug target/104005] New: Regression on arm+sve with -O2 -fPIC

[gilles.gouaillardet at gmail dot com via Gcc-bugs]

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

Bug ID: 104005
   Summary: Regression on arm+sve with -O2 -fPIC
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gilles.gouaillardet at gmail dot com
  Target Milestone: ---

The GROMACS (2021.3) non regression test suite now hangs with the latest trunk
when shared libraries are used from -O2 when two or more thread-MPI are used. I
only tried 512 bit SVE vectors.

I ran a git bisect and it pointed to the following commit:

commit 526e1639aa76b0a8496b0dc3a3ff2c450229544e (refs/bisect/bad)
Author: Richard Sandiford 
Date:   Fri Nov 12 17:33:00 2021 +

aarch64: Detect more consecutive MEMs


When investigating this issue, I found out that rebuilding the
src/gromacs/domdec/redistribute.cpp file **without** -fPIC is enough to avoid
the issue (a crash or a hang depending on the test cases).

FWIW, thread-MPI is a "fake" MPI implementation that used threads instead
processes. In this case, that means two threads. Then each thread enter its own
#pragma omp parallel section (and each thread-MPI thread has a unique OpenMP
thread)


The attached tarball includes preprocessed source (redistribute.cpp.i) and
assembly with -fPIC (redistribute.cpp.PIC.s) and without -fPIC
(redistribute.cpp.noPIC.s) for the commit mentioned above and the commit right
before.


Please let me know if this is enough for you to make sense of this bug,
otherwise I will provide instructions on how to build GROMACS from sources and
manually workaround the issue by "removing" the -fPIC flags for the
redistribute.cpp file.

[Bug target/102252] svbool_t with SVE can generate invalid assembly

[gilles.gouaillardet at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Gilles Gouaillardet  
---
I am happy to confirm this issue is fixed in the latest 12-20210919 snapshot
:-)

FWIW, I was not yet able to build GROMACS because of an other issue that was
introduced last week. I reported it at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102421

[Bug target/102421] ICE with -march=armv8.2-a+sve -O3

[gilles.gouaillardet at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Gilles Gouaillardet  
---
Created attachment 51487
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51487=edit
a trimmed reproducer (FWIW - include files are missing)

[Bug target/102421] ICE with -march=armv8.2-a+sve -O3

[gilles.gouaillardet at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Gilles Gouaillardet  
---
Created attachment 51486
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51486=edit
a (compressed) pre-processed reproducer

[Bug target/102421] New: ICE with -march=armv8.2-a+sve -O3

[gilles.gouaillardet at gmail dot com via Gcc-bugs]

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

Bug ID: 102421
   Summary: ICE with -march=armv8.2-a+sve -O3
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gilles.gouaillardet at gmail dot com
  Target Milestone: ---

This is a new issue that happens with -march=armv8.2-a+sve -O3 with the latest
snapshot (12-20210919). FWIW, no crash with
 - 12-20210912 (last week snapshot)
 - -march=armv8.2-a+sve -O2
 - -march=armv8.2-a -O3


I tried to trim the file that caused an issue (it is from GROMACS 2021.3) but
was not quite able to do so. The attached reproducer is my best effort at
trimming it.


g++ (GCC) 12.0.0 20210919 (experimental)
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Singularity> g++ -march=armv8.2-a+sve -O3 -c test.i
during GIMPLE pass: vect
test.cpp: In function 'void foo(gmx::PaddedVector >,
gmx::PaddedVector >, int, short unsigned int*, const
int (*)[3])':
test.cpp:12:6: internal compiler error: in dr_misalignment, at
tree-vect-data-refs.c:900
   12 | void foo (
  |  ^~~
0x1d279c7 dr_misalignment(dr_vec_info*)
../.././gcc/tree-vect-data-refs.c:900
0x1d27a07 vect_duplicate_ssa_name_ptr_info
../.././gcc/tree-vect-data-refs.c:4639
0x1d2aa0f vect_create_addr_base_for_vector_ref(vec_info*, _stmt_vec_info*,
gimple**, tree_node*, tree_node*)
../.././gcc/tree-vect-data-refs.c:4750
0x1d2ac9f vect_create_data_ref_ptr(vec_info*, _stmt_vec_info*, tree_node*,
loop*, tree_node*, tree_node**, gimple_stmt_iterator*, gimple**, bool,
tree_node*, tree_node*)
../.././gcc/tree-vect-data-refs.c:4951
0x130b5b7 vectorizable_load
../.././gcc/tree-vect-stmts.c:9370
0x131854b vect_transform_stmt(vec_info*, _stmt_vec_info*,
gimple_stmt_iterator*, _slp_tree*, _slp_instance*)
../.././gcc/tree-vect-stmts.c:11044
0x131a7a3 vect_transform_loop_stmt
../.././gcc/tree-vect-loop.c:9343
0x1335717 vect_transform_loop(_loop_vec_info*, gimple*)
../.././gcc/tree-vect-loop.c:9779
0x1365f2b try_vectorize_loop_1
../.././gcc/tree-vectorizer.c:1108
0x13669af vectorize_loops()
../.././gcc/tree-vectorizer.c:1247
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/102252] svbool_t with SVE can generate invalid assembly

[gilles.gouaillardet at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Gilles Gouaillardet  
---
Created attachment 51430
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51430=edit
a test that works

FWIW, the attached test_svfloat.cpp passes.
It is very similar to test_svbool.cpp but it "abstracts" a svfloat32_t instead
of a svbool_t.

[Bug target/102252] New: svbool_t with SVE can generate invalid assembly

[gilles.gouaillardet at gmail dot com via Gcc-bugs]

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

Bug ID: 102252
   Summary: svbool_t with SVE can generate invalid assembly
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gilles.gouaillardet at gmail dot com
  Target Milestone: ---

Created attachment 51429
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51429=edit
a simple reproducer

Let's consider the attached test_svbool.cpp and compile it with SVE fixed 512
bits:

$ g++ -march=armv8.2-a+sve -msve-vector-bits=512 -c test_svbool.cpp 
/tmp/cc38qRcE.s: Assembler messages:
/tmp/cc38qRcE.s:44: Error: invalid addressing mode at operand 2 -- `ldr
p0,[x0,x1,lsl 3]'

The generated assembly is invalid and cannot be assembled.

All branches that support SVE (10, 11 and 12) are affected.

FWIW, the code compiles just fine with LLVM 12, 13 and main branches.
This code is a trimmed version of an improvement for GROMACS.

[Bug target/102226] ICE with -O3 -msve-vector-bits=128

[gilles.gouaillardet at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Gilles Gouaillardet  
---
Created attachment 51421
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51421=edit
preprocessed reproducer

Here is the preprocessed reproducer

[Bug target/102226] New: ICE with -O3 -msve-vector-bits=128

[gilles.gouaillardet at gmail dot com via Gcc-bugs]

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

Bug ID: 102226
   Summary: ICE with -O3 -msve-vector-bits=128
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gilles.gouaillardet at gmail dot com
  Target Milestone: ---

Created attachment 51419
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51419=edit
A quite simple reproducer

The attached reproducer crashes the latest LATEST-12 compilers when invoked
with

$ g++ -march=armv8.2-a+sve -c -msve-vector-bits=128 -O3 test.cpp 
test.cpp: In function 'int
findPropertyIndex(std::vector >, const
std::string&)':
test.cpp:36:5: error: incompatible types in 'PHI' argument 1
   36 | int findPropertyIndex(std::vector ap,
  | ^
vector(2) long unsigned int

vector(2) long unsigned int

_142 = PHI 
during GIMPLE pass: vect
test.cpp:36:5: internal compiler error: verify_gimple failed
0x10b48a3 verify_gimple_in_cfg(function*, bool)
../.././gcc/tree-cfg.c:5531
0xf71baf execute_function_todo
../.././gcc/passes.c:2042
0xf72643 execute_todo
../.././gcc/passes.c:2096
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.



The compiler does not crash when  invoked with the following options (on top of
-march=armv8.2-a+sve :
 -O2 -msve-vector-bits=128
 -O3 -msve-vector-bits=256
 -O3 -msve-vector-bits=512
 -O3

FWIW, snapshot gcc-12-20210711 did not crash, and crash started from
gcc-12-20210718, and the 10 and 11 branches are unaffected by this issue.

[Bug target/101053] Incorrect code at -O1 on arm64

[gilles.gouaillardet at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Gilles Gouaillardet  
---
And here is the one-liner to fix this mess

--- orig/OpenBLAS-0.3.15/kernel/arm64/dznrm2_thunderx2t99.c 2021-05-03
06:50:22.0 +0900
+++ OpenBLAS-0.3.15/kernel/arm64/dznrm2_thunderx2t99.c  2021-06-14
15:54:26.087232321 +0900
@@ -321,7 +321,7 @@
: "cc",
  "memory",
  "x0", "x1", "x2", "x3", "x4", "x5", "x6",
- "d0", "d1", "d2", "d3", "d4", "d5", "d6", "d7", "d8"
+ "d0", "d1", "d2", "d3", "d4", "d5", "d6", "d7", "d8", REGINF
);

 }

[Bug target/101053] Incorrect code at -O1 on arm64

[gilles.gouaillardet at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Gilles Gouaillardet  
---
It seems OpenBLAS is to be blamed after all ...


>From kernel/arm64/dznrm2_thunderx2t99.c:


#define REGINF  "d9"

static void nrm2_compute(BLASLONG n, FLOAT *x, BLASLONG inc_x,
 double *ssq, double *scale)
{

__asm__ __volatile__ (
"   fmov"REGINF", x6


There is no mechanism to push/pop $d9 in the inline assembly :-(


If you concur, please close this issue and my apologies for the noise.

[Bug target/101053] Incorrect code at -O1 on arm64

[gilles.gouaillardet at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Gilles Gouaillardet  
---
Note you have to 'make clean' before re-running 'make ...' with different
options.
Otherwise, pretty much nothing gets rebuilt.

[Bug target/101053] Incorrect code at -O1 on arm64

[gilles.gouaillardet at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Gilles Gouaillardet  
---
I will set the watchpoint and follow the flow ...

That being said, I still see the issue with the latest snapshot

gcc (GCC) 12.0.0 20210613 (experimental)

./dgehd2 
 INFO =0
   1.   -8.0622577482985491   0.58032253547122137  
   -Infinity   NaN   NaN   
 -Infinity   NaN   NaN

[Bug target/101053] Incorrect code at -O1 on arm64

[gilles.gouaillardet at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Gilles Gouaillardet  
---
Thanks for the clarification about which registers have to be preserved.

I will dig this a bit more from now

[Bug fortran/101053] New: Incorrect code at -O1 on arm64

[gilles.gouaillardet at gmail dot com via Gcc-bugs]

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

Bug ID: 101053
   Summary: Incorrect code at -O1 on arm64
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gilles.gouaillardet at gmail dot com
  Target Milestone: ---

Created attachment 51003
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51003=edit
A simple reproducer

This issue was initially reported at
https://github.com/numpy/numpy/issues/18422

Bottom line, since the gcc-9 series(!), gfortran generates incorrect code for
OpenBLAS from -O1 on arm64.

Here is how to reproduce the issue:

# set the local prefix (to be customized)
prefix=...

# Download OpenBLAS
wget
https://github.com/xianyi/OpenBLAS/releases/download/v0.3.15/OpenBLAS-0.3.15.tar.gz

# Build and install OpenBLAS
tar xfz OpenBLAS-0.3.15.tar.gz
cd OpenBLAS-0.3.15/
make -j 56 libs netlib shared  BINARY='64'  CC='gcc'  FC='gfortran' 
MAKE_NB_JOBS='-1'  USE_OPENMP='1'  USE_THREAD='1' COMMON_OPT="-g -O1"
make install PREFIX=$prefix
cd ..

# Build and execute the attached reproducer
gfortran dgehd2.f90 -o dgehd2 -L$prefix/lib -Wl,-rpath,$prefix/lib -lopenblas
./dgehd2

Expected result (obtained with gfortran 8.3.1 (from rhel8) and 8.5.0, or if
OpenBLAS is built with COMMON_OPT="-g -O0":
 INFO =0
   1.   -8.0622577482985491   0.58032253547122137  
-3.597007303087044911.461538461538458   -3.6923076923076938 
-0.248069469178416884.30769230769230752.5384615384615383 

Current result (from gfortran 9.1.0 up to the gcc-12-20210606 snapshot):
 INFO =0
   1.   -8.0622577482985491   0.58032253547122137  
   -Infinity   NaN   NaN   
 -Infinity   NaN   NaN


The faulty code is in the dgehd2 subroutine:
  PARAMETER  ( ONE = 1.0D+0 )

  DO 10 I = ILO, IHI - 1
 CALL DLARFG( IHI-I, A( I+1, I ), A( MIN( I+2, N ), I ), 1,
 $TAU( I ) )
 AII = A( I+1, I )
 A( I+1, I ) = ONE
 CALL DLARF( 'Right', IHI, IHI-I, A( I+1, I ), 1, TAU( I ),
 $   A( 1, I+1 ), LDA, WORK )
 CALL DLARF( 'Left', IHI-I, N-I, A( I+1, I ), 1, TAU( I ),
 $   A( I+1, I+1 ), LDA, WORK )
 A( I+1, I ) = AII
   10 CONTINUE

At the following line
 A( I+1, I ) = ONE


Here is a snippet of the assembly (generated with gfortran 10.3.0)
.LBE9:  
.loc 1 206 72 view .LVU34
fmovd9, 1.0e+0
.LBB10: 
.loc 1 211 72 view .LVU35
adrpx0, .LC1
add x0, x0, :lo12:.LC1
str x0, [sp, 192]
.LBE10:
.LBB11: 
.loc 1 216 72 view .LVU36
adrpx0, .LC2
add x0, x0, :lo12:.LC2
str x0, [sp, 200]
.LVL20:
.L7:
.loc 1 216 72 is_stmt 0 view .LVU37
.LBE11:
.LBB12: 
.loc 1 204 72 is_stmt 1 view .LVU38
ldr w0, [x22]
sub w0, w0, w20
str w0, [sp, 224]
add w0, w20, 2
ldr w2, [x26]
cmp w2, w0
cselw2, w2, w0, le
mov w24, w20
add w20, w20, 1
.LVL21: 
.loc 1 204 72 is_stmt 0 view .LVU39
add x2, x23, x2, sxtw
mov x4, x21
mov x3, x25
ldr x0, [sp, 136]
add x2, x0, x2, lsl 3
mov x1, x19
ldr x0, [sp, 184]
bl  dlarfg_
.LVL22:
.LBE12: 
.loc 1 205 72 is_stmt 1 view .LVU40
ldr d8, [x19]
.LVL23: 
.loc 1 206 72 view .LVU41
str d9, [x19]


The constant 1.0D+0 is stored in $d9, but this register is used **after** the
invocation of the dlarfg_ subroutine, and it turns out this subroutine does
modify the $d9 register.
When $d9 is used to be stored into [x19], its value is
(gdb) p $d9
$1 = ( f = inf, u = 9218868437227405312, s = 9218868437227405312 )

If I set a breakpoint at that instruction, and manually
(gdb) set $d9=1.0
then the program behaves as expected.


Bottom line, there is an issue from gfortran 9 on arm64 from -O1 with this:
 - Did gfortran incorrectly assume $d9 will not be modified (or at least, will
be restored) by other subroutines?
 - Did dlarfg_ forget to restore $d9?
 - Something else?

[Bug c++/100381] New: new static_assert((std::__is_complete_or_unbounded(...)) failure from g++ 11.1.0

[gilles.gouaillardet at gmail dot com via Gcc-bugs]

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

Bug ID: 100381
   Summary: new
static_assert((std::__is_complete_or_unbounded(...))
failure from g++ 11.1.0
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gilles.gouaillardet at gmail dot com
  Target Milestone: ---

Created attachment 50732
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50732=edit
a reproducer that fails from g++ 11.1.0

g++ 11.1.0 is no more able to compile GROMACS, as reported at
https://gitlab.com/gromacs/gromacs/-/issues/4039

I trimmed the offending code into the attached and self-contained reproducer,
that fails to build with the following error:

$ g++ -c reproducer.cpp
In file included from
/home/users/gilles/local/gcc-11.1.0/include/c++/11.1.0/bits/move.h:57,
 from
/home/users/gilles/local/gcc-11.1.0/include/c++/11.1.0/bits/stl_function.h:60,
 from
/home/users/gilles/local/gcc-11.1.0/include/c++/11.1.0/functional:49,
 from reproducer.cpp:1:
/home/users/gilles/local/gcc-11.1.0/include/c++/11.1.0/type_traits: In
instantiation of 'struct std::is_invocable_r&, IndexGroupsAndNames>':
/home/users/gilles/local/gcc-11.1.0/include/c++/11.1.0/type_traits:3011:46:  
required from 'constexpr const bool std::is_invocable_r_v&, IndexGroupsAndNames>'
/home/users/gilles/local/gcc-11.1.0/include/c++/11.1.0/bits/invoke.h:103:27:  
required by substitution of 'template constexpr std::enable_if_t,
_Res> std::__invoke_r(_Callable&&, _Args&& ...) [with _Res = void; _Callable =
{anonymous}::DensityFitting::subscribeToPreProcessingNotifications(MdModulesNotifier*)::&; _Args = {IndexGroupsAndNames}]'
/home/users/gilles/local/gcc-11.1.0/include/c++/11.1.0/bits/std_function.h:291:30:
  required from 'static _Res std::_Function_handler<_Res(_ArgTypes ...),
_Functor>::_M_invoke(const std::_Any_data&, _ArgTypes&& ...) [with _Res = void;
_Functor =
{anonymous}::DensityFitting::subscribeToPreProcessingNotifications(MdModulesNotifier*)::; _ArgTypes = {IndexGroupsAndNames}]'
/home/users/gilles/local/gcc-11.1.0/include/c++/11.1.0/bits/std_function.h:422:21:
  required from 'std::function<_Res(_ArgTypes ...)>::function(_Functor) [with
_Functor =
{anonymous}::DensityFitting::subscribeToPreProcessingNotifications(MdModulesNotifier*)::;  = void;
 = void; _Res = void; _ArgTypes =
{IndexGroupsAndNames}]'
reproducer.cpp:55:56:   required from here
/home/users/gilles/local/gcc-11.1.0/include/c++/11.1.0/type_traits:2954:7:
error: static assertion failed: each argument type must be a complete class or
an unbounded array
 2954 |   static_assert((std::__is_complete_or_unbounded(
  |   ^
/home/users/gilles/local/gcc-11.1.0/include/c++/11.1.0/type_traits:2954:7:
note:
'std::__is_complete_or_unbounded
>((std::__type_identity{},
std::__type_identity()))' evaluates to false
/home/users/gilles/local/gcc-11.1.0/include/c++/11.1.0/type_traits: In
instantiation of 'struct std::is_nothrow_invocable_r&, IndexGroupsAndNames>':
/home/users/gilles/local/gcc-11.1.0/include/c++/11.1.0/type_traits:3016:54:  
required from 'constexpr const bool std::is_nothrow_invocable_r_v&, IndexGroupsAndNames>'
/home/users/gilles/local/gcc-11.1.0/include/c++/11.1.0/bits/invoke.h:105:14:  
required from 'constexpr std::enable_if_t, _Res> std::__invoke_r(_Callable&&, _Args&& ...) [with _Res = void;
_Callable =
{anonymous}::DensityFitting::subscribeToPreProcessingNotifications(MdModulesNotifier*)::&; _Args = {IndexGroupsAndNames};
std::enable_if_t, _Res> = void]'
/home/users/gilles/local/gcc-11.1.0/include/c++/11.1.0/bits/std_function.h:291:30:
  required from 'static _Res std::_Function_handler<_Res(_ArgTypes ...),
_Functor>::_M_invoke(const std::_Any_data&, _ArgTypes&& ...) [with _Res = void;
_Functor =
{anonymous}::DensityFitting::subscribeToPreProcessingNotifications(MdModulesNotifier*)::; _ArgTypes = {IndexGroupsAndNames}]'
/home/users/gilles/local/gcc-11.1.0/include/c++/11.1.0/bits/std_function.h:422:21:
  required from 'std::function<_Res(_ArgTypes ...)>::function(_Functor) [with
_Functor =
{anonymous}::DensityFitting::subscribeToPreProcessingNotifications(MdModulesNotifier*)::;  = void;
 = void; _Res = void; _ArgTypes =
{IndexGroupsAndNames}]'
reproducer.cpp:55:56:   required from here
/home/users/gilles/local/gcc-11.1.0/include/c++/11.1.0/type_traits:2992:7:
error: static assertion failed: each argument type must be a complete class or
an unbounded array
 2992 |   static_assert((std::__is_complete_or_unbounded(
  |   ^
/home/users/gilles/local/gcc-11.1.0/include/c++/11.1.0/type_traits:2992:7:
note:
'std::__is_complete_or_unbounded
>((std::__type_identity{},
std::__type_identity()))' evaluates to false


The same code can be compiled with previous g++ versions 

[Bug target/100305] [10 Regression] aarch64: ICE in output_operand_lossage with -O3

[gilles.gouaillardet at gmail dot com via Gcc-bugs]

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

--- Comment #13 from Gilles Gouaillardet  
---
Thanks Richard for the quick fix.

I am happy to confirm that the latest trunk passes the three reproducers
included in this ticket.

However, the latest gcc-11 branch only passes the mini reproducer you posted
(and crashes with a similar stack trace with Andrew's reproducer and the one I
trimmed from GROMACS)

FWIW, I am still unable to build GROMACS 2021.1 with the latest trunk (both
neon and SVE, now checking x86_64), but this is a different issue (looks like a
C++ frontend issue, unless this is a legit error in the application).

[Bug target/100305] [11/12 Regression] aarch64: ICE in output_operand_lossage with -O3

[gilles.gouaillardet at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Gilles Gouaillardet  
---
Thanks Alex for the more minimal reproducer.

Sadly, the just released GCC 11.1.0 crashed with this code.

[Bug tree-optimization/100284] ICE in operation_could_trap_p with -march=armv8.2-a+sve -O3

[gilles.gouaillardet at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Gilles Gouaillardet  
---
I made a mistake when building GCC 11.1.0, and I am happy to make the following
correction: GCC 11.1.0 is *not* affected by this issue. The stack trace came
from the master branch.

[Bug c++/100305] New: ICE in output_operand_lossage with -march=armv8.2-a -O3

[gilles.gouaillardet at gmail dot com via Gcc-bugs]

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

Bug ID: 100305
   Summary: ICE in output_operand_lossage with -march=armv8.2-a
-O3
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gilles.gouaillardet at gmail dot com
  Target Milestone: ---

Created attachment 50696
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50696=edit
a (compressed) preprocessed reproducer

This is a new bug with the g++ compiler I found when building GROMACS on
aarch64 with -O3.

-O2 works fine, and so does x86_64. I was only able to reproduce the issue on
aarch64 (initially with SVE, but same outcome without it)

The compiler crashed with the following stack trace:

$ ~/local/gcc-latest/bin/g++ -c -O3 -march=armv8.2-a readpull.i 
during RTL pass: final
readpull.cpp: In function 'std::vector >
read_pullparams(std::vector*, pull_params_t*, warninp_t)':
readpull.cpp:96:1: internal compiler error: output_operand: invalid expression
as operand
   96 | }
  | ^
0xc66ab7 output_operand_lossage(char const*, ...)
../../../src/gcc-latest/gcc/final.c:3627
0xc67283 output_addr_const(_IO_FILE*, rtx_def*)
../../../src/gcc-latest/gcc/final.c:4184
0xc66d0f output_address(machine_mode, rtx_def*)
../../../src/gcc-latest/gcc/final.c:4085
0xc66c4b output_operand(rtx_def*, int)
../../../src/gcc-latest/gcc/final.c:4069
0xc6769f output_asm_insn(char const*, rtx_def**)
../../../src/gcc-latest/gcc/final.c:3981
0xc6b84f output_asm_insn(char const*, rtx_def**)
../../../src/gcc-latest/gcc/final.c:3858
0xc6b84f final_scan_insn_1
../../../src/gcc-latest/gcc/final.c:3125
0xc6be43 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
../../../src/gcc-latest/gcc/final.c:3171
0xc6bf63 final_1
../../../src/gcc-latest/gcc/final.c:2022
0xc6cc0b rest_of_handle_final
../../../src/gcc-latest/gcc/final.c:4676
0xc6cc0b execute
../../../src/gcc-latest/gcc/final.c:4754
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug tree-optimization/100284] ICE in operation_could_trap_p with -march=armv8.2-a+sve -O3

[gilles.gouaillardet at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Gilles Gouaillardet  
---
Created attachment 50695
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50695=edit
preprocessed reproducer

$ ~/local/gcc-11.1.0/bin/gcc -march=armv8.2-a+sve -O3 -c bug.i

The bug has been fixed in master, thanks for the quick action!

I have attached the preprocessed bug.i, and here is the stack trace on the just
released gcc 11.1.0

during GIMPLE pass: vrp
bug.c: In function 'Ptngc_pack_array_xtc3':
bug.c:107:16: internal compiler error: in operation_could_trap_p, at
tree-eh.c:2546
  107 | unsigned char *Ptngc_pack_array_xtc3(int *input, int *length, const int
natoms, int speed)
  |^
0xda9a07 operation_could_trap_p(tree_code, bool, bool, tree_node*)
../../../src/gcc/gcc/tree-eh.c:2546
0x11c0497 maybe_resimplify_conditional_op
../../../src/gcc/gcc/gimple-match-head.c:156
0x11c0153 gimple_resimplify3
../../../src/gcc/gcc/gimple-match-head.c:404
0x11c1317 gimple_match_op::resimplify(gimple**, tree_node* (*)(tree_node*))
../../../src/gcc/gcc/gimple-match-head.c:493
0x11c1317 gimple_simplify_383
/home/users/u0001043/build/gcc-11.1.0/gcc/gimple-match.c:21030
0x11c399b gimple_simplify_PLUS_EXPR
/home/users/u0001043/build/gcc-11.1.0/gcc/gimple-match.c:58341
0x11d2a27 gimple_resimplify2
../../../src/gcc/gcc/gimple-match-head.c:318
0x121847b try_conditional_simplification
../../../src/gcc/gcc/gimple-match-head.c:872
0x121847b gimple_simplify(gimple*, gimple_match_op*, gimple**, tree_node*
(*)(tree_node*), tree_node* (*)(tree_node*))
../../../src/gcc/gcc/gimple-match-head.c:1046
0xa320ab fold_stmt_1
../../../src/gcc/gcc/gimple-fold.c:6001
0xf0e80b substitute_and_fold_dom_walker::before_dom_children(basic_block_def*)
../../../src/gcc/gcc/tree-ssa-propagate.c:1155
0x17fd477 dom_walker::walk(basic_block_def*)
../../../src/gcc/gcc/domwalk.c:309
0xf0d7a3 substitute_and_fold_engine::substitute_and_fold(basic_block_def*)
../../../src/gcc/gcc/tree-ssa-propagate.c:1283
0x103edb7 execute_vrp
../../../src/gcc/gcc/tree-vrp.c:4531
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c/100284] New: gcc crash with -march=armv8.2-a+sve -O3

[gilles.gouaillardet at gmail dot com via Gcc-bugs]

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

Bug ID: 100284
   Summary: gcc crash with -march=armv8.2-a+sve -O3
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gilles.gouaillardet at gmail dot com
  Target Milestone: ---

Created attachment 50686
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50686=edit
a reproducer

The attached (and self-contained) bug.c (trimmed from GROMACS 2021.1) can be
used to evidence this issue with the latest GCC from the master and
releases/gcc-11 branches:

gcc -march=armv8.2-a+sve -O3 -c bug.c

The crash occurs at -O3 (and no crash at -O2) and only with an aarch64+sve
target
(this is a compiler crash that can be evidenced on a *non* SVE capable hardware
too)

I ran a git bisect and it points to

# first bad commit: [cdb2e365fc0dba2ee052827e5ca65234ca82d605] SLP: support
entire BB.

GCC 10.3.0 is not affected.