[Bug fortran/103707] New: Stray "Array operands are incommensurate"

[Bug fortran/103707] New: Stray "Array operands are incommensurate"

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103707

            Bug ID: 103707
           Summary: Stray "Array operands are incommensurate"
           Product: gcc
           Version: 11.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

Just stumbled across this...

module prec
  implicit none
  private
  public :: wp
  integer, parameter :: dp = selected_real_kind(15)
  integer, parameter :: sp = selected_real_kind(6)
  integer, parameter :: wp = dp
  real (kind=wp), parameter :: one = 1._wp

end module prec

program main
  use prec
  implicit none
  integer, parameter :: ndim = 6
  real(kind=wp), dimension(ndim), parameter :: &
       fmin = [  0.74_wp, 0.004_wp, 0.002_wp, 0.8_wp,  0._wp,  0.8_wp], &
       fmax = [  1.93_wp, 0.26_wp,  0.127_wp, 4.0_wp,  1.2_wp, 1.0_wp]

contains
  function fld2phys (trial) result (xpt)
    real(kind=wp), dimension(ndim), intent(in) :: trial
    real(kind=wp), dimension(ndim) :: xpt
       xpt = fmin * (fmax/fmin)**trial
  end function fld2phys

end program main
[zfkts@loginb001 ~]$ gfortran tst.f90
tst.f90:24:25:

   24 |        xpt = fmin * (fmax/fmin)**trial
      |                         1
Error: Array operands are incommensurate at (1)

[Bug fortran/103707] Stray "Array operands are incommensurate"

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103707

--- Comment #1 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
This is with gcc 11, no time to further reduce / try with trunk right now.

[Bug fortran/103707] Stray "Array operands are incommensurate"

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103707

--- Comment #2 from anlauf at gcc dot gnu.org ---
Could it be the overflow simplifying fmax/fmin triggering this?

[Bug fortran/103707] Stray "Array operands are incommensurate"

[gscfq@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103707

--- Comment #3 from G. Steinmetz <gscfq@t-online.de> ---
A quick reduction yields z1 and for comparison z2 :


$ cat z1.f90
program p
   real, parameter :: fmin(1) = 0.
   real, parameter :: fmax(1) = 1.
   print *, (fmax/fmin)**2
end

$ cat z2.f90
program p
   real, parameter :: fmin = 0.
   real, parameter :: fmax = 1.
   print *, (fmax/fmin)**2
end



$ gfortran-12-20211212 -c z1.f90
z1.f90:4:17:

    4 |    print *, (fmax/fmin)**2
      |                 1
Error: Array operands are incommensurate at (1)


$ gfortran-12-20211212 -c z2.f90
z2.f90:4:17:

    4 |    print *, (fmax/fmin)**2
      |                 1
Error: Division by zero at (1)

[Bug fortran/103707] Stray "Array operands are incommensurate"

[gscfq@t-online.de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103707

--- Comment #4 from G. Steinmetz <gscfq@t-online.de> ---

Sorry, I forgot z3 :

program p
   print *, [1.]/[0.] 
end

[Bug fortran/103707] Stray "Array operands are incommensurate"

[tkoenig at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103707

--- Comment #5 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
Thanks for the quick reduction, Gerhard.

This originally came from something like

program p
   real, parameter :: fmin(1) = 0.
   real, parameter :: fmax(1) = 1.
   real :: x(1)
   where (fmin <= 0)
      x = fmin + (fmax-fmin)
   elsewhere
      x = (fmax/fmin)**2
   end where
   print *,x
end

so there is no division by zero at runtime.

[Bug fortran/103707] Stray "Array operands are incommensurate"

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103707

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2022-06-26
                 CC|                            |anlauf at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1

--- Comment #6 from anlauf at gcc dot gnu.org ---
(In reply to Thomas Koenig from comment #5)
> Thanks for the quick reduction, Gerhard.
> 
> This originally came from something like
> 
> program p
>    real, parameter :: fmin(1) = 0.
>    real, parameter :: fmax(1) = 1.
>    real :: x(1)
>    where (fmin <= 0)
>       x = fmin + (fmax-fmin)
>    elsewhere
>       x = (fmax/fmin)**2
>    end where
>    print *,x
> end
> 
> so there is no division by zero at runtime.

Some data points from other compiler that reject the code:

NAG prints

NAG Fortran Compiler Release 7.0(Yurakucho) Build 7009
Error: pr103707.f90, line 8: Floating-point divide by zero


Cray versions 10 thru 14 print:

      x = (fmax/fmin)**2
               ^         
ftn-1184 crayftn: WARNING P, File = pr103707.f90, Line = 8, Column = 16 
  Evaluation of this constant expression produced a NaN or other abnormal
value.
                     ^   
ftn-1184 crayftn: WARNING P, File = pr103707.f90, Line = 8, Column = 22 
  Evaluation of this constant expression produced a NaN or other abnormal
value.

Cray Fortran : Version 14.0.0
(20220420160222_c98838affc7b58fed2a72f164d77c35e1bc8772f)


Intel and Nvidia are silent.

While gfortran's error message is misleading, what is our plan?
Avoid simplification in the frontend?

[Bug fortran/103707] Stray "Array operands are incommensurate"

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103707

--- Comment #7 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Harald Anlauf <anlauf@gcc.gnu.org>:

https://gcc.gnu.org/g:93e1d4d24ed014387da97e2ce11556d68fe98e66

commit r14-9340-g93e1d4d24ed014387da97e2ce11556d68fe98e66
Author: Harald Anlauf <anlauf@gmx.de>
Date:   Tue Mar 5 21:54:26 2024 +0100

    Fortran: error recovery while simplifying expressions [PR103707,PR106987]

    When an exception is encountered during simplification of arithmetic
    expressions, the result may depend on whether range-checking is active
    (-frange-check) or not.  However, the code path in the front-end should
    stay the same for "soft" errors for which the exception is triggered by the
    check, while "hard" errors should always terminate the simplification, so
    that error recovery is independent of the flag.  Separation of arithmetic
    error codes into "hard" and "soft" errors shall be done consistently via
    is_hard_arith_error().

            PR fortran/103707
            PR fortran/106987

    gcc/fortran/ChangeLog:

            * arith.cc (is_hard_arith_error): New helper function to determine
            whether an arithmetic error is "hard" or not.
            (check_result): Use it.
            (gfc_arith_divide): Set "Division by zero" only for regular
            numerators of real and complex divisions.
            (reduce_unary): Use is_hard_arith_error to determine whether a hard
            or (recoverable) soft error was encountered.  Terminate immediately
            on hard error, otherwise remember code of first soft error.
            (reduce_binary_ac): Likewise.
            (reduce_binary_ca): Likewise.
            (reduce_binary_aa): Likewise.

    gcc/testsuite/ChangeLog:

            * gfortran.dg/pr99350.f90:
            * gfortran.dg/arithmetic_overflow_3.f90: New test.

[Bug fortran/103707] Stray "Array operands are incommensurate"

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103707

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |anlauf at gcc dot gnu.org

--- Comment #8 from anlauf at gcc dot gnu.org ---
The "Array operands are incommensurate" error is gone.

With -frange-check (the default) we are left with "Division by zero",
which I think is intended.

Use -fno-range-check if you want to compile the code.

[Bug fortran/103707] Stray "Array operands are incommensurate"

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103707

--- Comment #9 from GCC Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-13 branch has been updated by Harald Anlauf
<anlauf@gcc.gnu.org>:

https://gcc.gnu.org/g:2808797fc4da7cc455803e2b69368b52db857b4c

commit r13-8559-g2808797fc4da7cc455803e2b69368b52db857b4c
Author: Harald Anlauf <anlauf@gmx.de>
Date:   Tue Mar 5 21:54:26 2024 +0100

    Fortran: error recovery while simplifying expressions [PR103707,PR106987]

    When an exception is encountered during simplification of arithmetic
    expressions, the result may depend on whether range-checking is active
    (-frange-check) or not.  However, the code path in the front-end should
    stay the same for "soft" errors for which the exception is triggered by the
    check, while "hard" errors should always terminate the simplification, so
    that error recovery is independent of the flag.  Separation of arithmetic
    error codes into "hard" and "soft" errors shall be done consistently via
    is_hard_arith_error().

            PR fortran/103707
            PR fortran/106987

    gcc/fortran/ChangeLog:

            * arith.cc (is_hard_arith_error): New helper function to determine
            whether an arithmetic error is "hard" or not.
            (check_result): Use it.
            (gfc_arith_divide): Set "Division by zero" only for regular
            numerators of real and complex divisions.
            (reduce_unary): Use is_hard_arith_error to determine whether a hard
            or (recoverable) soft error was encountered.  Terminate immediately
            on hard error, otherwise remember code of first soft error.
            (reduce_binary_ac): Likewise.
            (reduce_binary_ca): Likewise.
            (reduce_binary_aa): Likewise.

    gcc/testsuite/ChangeLog:

            * gfortran.dg/arithmetic_overflow_3.f90: New test.

    (cherry picked from commit 93e1d4d24ed014387da97e2ce11556d68fe98e66)

[Bug fortran/103707] Stray "Array operands are incommensurate"

[anlauf at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103707

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |WAITING

--- Comment #10 from anlauf at gcc dot gnu.org ---
I think the main issues are fixed for gcc-14 and on 13-branch.

The "Division by zero" errors can be suppressed with -fno-range-check
and are otherwise intentional IIUC.

How shall we proceed?  Close as fixed?