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.

Reply via email to