https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101053
--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> --- I tried to reproduce it but I could not on the trunk (it has one patch which should not make a difference): Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/home/ubuntu/upstream-gcc/libexec/gcc/aarch64-unknown-linux-gnu/12.0.0/lto-wrapper Target: aarch64-unknown-linux-gnu Configured with: /home/ubuntu/src/upstream-gcc-aarch64/gcc/configure --prefix=/home/ubuntu/upstream-gcc --enable-languages=c,c++,fortran,lto,objc,go Thread model: posix Supported LTO compression algorithms: zlib gcc version 12.0.0 20210604 (experimental) [master revision a3f6bd78914:c52e7e6a230:f1e9719e06611fdbdedccbab54d32fc6611a2fb0] (GCC) make -j 24 libs netlib shared BINARY='64' CC='gcc' FC='gfortran' MAKE_NB_JOBS='-1' USE_OPENMP='1' USE_THREAD='1' COMMON_OPT="-g -O1" ubuntu@ubuntu:~/src/OpenBLAS-0.3.15\# gfortran libopenblas.a -o test1 test.f90 libopenblas.a -lgomp -pthread ubuntu@ubuntu:~/src/OpenBLAS-0.3.15\# ./test1 INFO = 0 1.0000000000000000 -8.0622577482985491 0.58032253547122137 -3.5970073030870449 11.461538461538458 -3.6923076923076938 -0.24806946917841688 4.3076923076923075 2.5384615384615383 --------- CUT ------- I tried the shared library version and that also passed. Maybe the best thing to do is set a breakpoint at dlarfg_ and then watch the stack location where d9 is stored to and see who changes it.
