https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95053
--- Comment #24 from wschmidt at linux dot ibm.com --- On 5/14/20 12:08 PM, sgk at troutmask dot apl.washington.edu wrote: > 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. > I'm afraid I disagree. A divide-by-zero that cannot ever be executed is not an error.
