https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95053
--- Comment #23 from Steve Kargl <sgk at troutmask dot apl.washington.edu> --- On Thu, May 14, 2020 at 02:57:37PM +0000, wschmidt at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95053 > > Bill Schmidt <wschmidt at gcc dot gnu.org> changed: > > What |Removed |Added > ---------------------------------------------------------------------------- > CC| |wschmidt at gcc dot gnu.org > > --- Comment #22 from Bill Schmidt <wschmidt at gcc dot gnu.org> --- > Breaking legitimate code, even if "borderline," does not seem right to me. > Zero division is generally a runtime exception because of such cases. > > You write code for a general case, then later you discover "oh, well, we could > make this variable zero for our specific usage," and now the compiler throws a > fit? Seems like this is warning-level stuff. > If Bill's reduction of the several thousand-line file to 10ish lines is an accurate reduction (and I have no reasons to doubt that it isn't), then no. It is an programming error. This is not the first time that gfortran has found a programming error in WRF. Sure, in this case the 'if (cdleps > 0)' leads to dead code elimination, but DCE happens after gfortran has done some constant folding and common subexpression elimination in the front-end.
