https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113089
--- Comment #9 from Alex Coplan <acoplan at gcc dot gnu.org> --- (In reply to Manolis Tsamis from comment #8) > (In reply to Alex Coplan from comment #7) > > (In reply to Manolis Tsamis from comment #6) > > > (In reply to Alex Coplan from comment #5) > > > > Also ICEs without -fno-strict-aliasing FWIW, so just -g -O2 > > > > -funroll-loops > > > > seems to be enough. > > > > > > On my local build it doesn't reproduce without -fno-strict-aliasing; I > > > just > > > double-checked (GCC master @ 4e0a467302fea56d63b7a6d17f99c0f388960dc7). > > > > Hmm, that is odd, I definitely don't need that option even when built from > > the same commit. How are you configuring GCC? I suppose it doesn't matter > > since I can reproduce the problem as long as the fix works with/without > > -fno-strict-aliasing. > > Odd indeed, but probably something with my configure flags as you mentioned. > Here's what I use: > > --enable-shared \ > --enable-threads=posix \ > --enable-checking=release \ > --with-system-zlib \ > --enable-__cxa_atexit \ > --disable-libunwind-exceptions \ > --enable-linker-build-id \ > --enable-libstdcxx-backtrace \ > --enable-plugin \ > --enable-initfini-array \ > --enable-gnu-indirect-function \ > --with-isl \ > --enable-lto \ > --with-cpu=neoverse-n1 \ > --disable-multilib \ > --disable-bootstrap > > (I think the most uncommon one here is --with-cpu=neoverse-n1 ?) Ah, that explains it. I have a much more vanilla config, and indeed with -mcpu=neoverse-n1 then it needs -fno-strict-aliasing to reproduce.
