[RFC] PR95053 and division by zero

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

[RFC] PR95053 and division by zero

Harald Anlauf-3
My fix for PR93499, which tries to catch an ICE on invalid in declarations
involving division by 0 causes a side-effect that it now refuses to compile
code such as that used in SPEC2017.  As an example,

function f (x)
  real, parameter :: cldeps = 0.
  f = 0.
  if (cldeps > 0.) then
     f = floor (x/cldeps) * cldeps
  end if
end function f

now gives an error:

pr95053_2.f90:5:24:

    5 |      f = floor (x/cldeps) * cldeps
      |                        1
Error: Division by zero at (1)

unless one specifies -fno-range-check.

I see two ways to solve the issue:

- either enhance the error message so that it tells users that this error
  may be disabled by -fno-range-check.  This is used in the testsuite,
  see e.g. real_const_3.f90, however, where the division by zero occurs
  during calculation of constant expressions.

  One can argue that the division by zero is protected by an if (), but
  removing the if/endif shows that gcc does not (currently?) throw an
  error; at least I did not find any way to get it to complain.

- or remove the code in question which is part of the patch for PR93499,
  and replace it by other checks in other parts of gfortran, see e.g.
  comment#15 in PR95053.

  This needs some adjustments in the testsuite, since error messages
  will change.

What do people think?

Note: this is not a poll; I'm looking for a pragmatic solution.

Thanks for sharing your insights,

Harald

Reply | Threaded
Open this post in threaded view
|

Re: [RFC] PR95053 and division by zero

Mark Eggleston

On 14/05/2020 19:48, Harald Anlauf wrote:

> My fix for PR93499, which tries to catch an ICE on invalid in declarations
> involving division by 0 causes a side-effect that it now refuses to compile
> code such as that used in SPEC2017.  As an example,
>
> function f (x)
>    real, parameter :: cldeps = 0.
>    f = 0.
>    if (cldeps > 0.) then
>       f = floor (x/cldeps) * cldeps
>    end if
> end function f
>
> now gives an error:
>
> pr95053_2.f90:5:24:
>
>      5 |      f = floor (x/cldeps) * cldeps
>        |                        1
> Error: Division by zero at (1)
>
> unless one specifies -fno-range-check.
>
> I see two ways to solve the issue:
>
> - either enhance the error message so that it tells users that this error
>    may be disabled by -fno-range-check.  This is used in the testsuite,
>    see e.g. real_const_3.f90, however, where the division by zero occurs
>    during calculation of constant expressions.
>
>    One can argue that the division by zero is protected by an if (), but
>    removing the if/endif shows that gcc does not (currently?) throw an
>    error; at least I did not find any way to get it to complain.
>
> - or remove the code in question which is part of the patch for PR93499,
>    and replace it by other checks in other parts of gfortran, see e.g.
>    comment#15 in PR95053.
>
>    This needs some adjustments in the testsuite, since error messages
>    will change.
>
> What do people think?
>
> Note: this is not a poll; I'm looking for a pragmatic solution.
>
> Thanks for sharing your insights,
>
> Harald
>
Where reals are involved I would expect division by zero to result in
infinity as it does using gfortran 10.1.  Looking at PR93499 I would
only expect division by zero errors to occur where a constant is
expected such as in declarations as described in the PR.

I would have expected

  f = floor (x/cldeps) * cldeps

to compile and if executed to assign the value NaN.

--
https://www.codethink.co.uk/privacy.html

Reply | Threaded
Open this post in threaded view
|

Re: [RFC] PR95053 and division by zero

Harald Anlauf-3
Hi Mark,

> Where reals are involved I would expect division by zero to result in
> infinity as it does using gfortran 10.1.  Looking at PR93499 I would
> only expect division by zero errors to occur where a constant is
> expected such as in declarations as described in the PR.
>
> I would have expected
>
>   f = floor (x/cldeps) * cldeps
>
> to compile and if executed to assign the value NaN.

I fully agree.

The code might even use ieee_* stuff to control what the result should be,
even if the given example did not.

I will send another patch to get this fixed.

Thanks,
Harald