https://gcc.gnu.org/bugzilla/show_bug.cgi?id=127067
--- Comment #2 from Filip Kastl <pheeck at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #1)
> PR127058? Fixed I believe.
Yes, most likely since the stacktrace looks the same. I'm checking it now.
Btw I've just realized this stacktrace...
during GIMPLE pass: slp
module_sf_lake.fppized.f90: In function 'lake':
module_sf_lake.fppized.f90:120:5: internal compiler error: Segmentation fault
120 | SUBROUTINE Lake( t_phy ,p8w ,dz8w ,qvcurr
,& !i
| ^
0x1eeae33 internal_error(char const*, ...)
/home/gcc/buildworker/lnt-grace-gcc-trunk-workdays/build/gcc/diagnostic-global-context.cc:787
0xdc9ed3 crash_signal
/home/gcc/buildworker/lnt-grace-gcc-trunk-workdays/build/gcc/toplev.cc:325
0x1f715bb ht_lookup_with_hash(ht*, unsigned char const*, unsigned long,
unsigned int, ht_lookup_option)
/home/gcc/buildworker/lnt-grace-gcc-trunk-workdays/build/libcpp/symtab.cc:164
...is from a release build. That's why it is different. So most likely, there
was the pr127040 ICE, when that got fixed, the pr127058 ICE remained and now
that's fixed too and wrf_r builds again.
