[Flang] Incorrect execution results of max0 intrinsic function for various arguments

[ohno-fj]

Version of flang : 21.0.0(3e6f618e86f5fbad2c2d5802416ec3d3366a2837)/AArch64

As in the attached program, when max0 intrinsic function is given 1, 2, and 8 byte in addition to default integer (4 byte), the results of the function are all default integer (4 byte).

max0 is written as accept more argument types than specified. by:

https://github.com/llvm/llvm-project/blob/main/flang/docs/Extensions.md
Extensions, deletions, and legacy features supported by default
- Specific intrinsics AMAX0, AMAX1, AMIN0, AMIN1, DMAX1, DMIN1, MAX0, MAX1, MIN0, and MIN1
  accept more argument types than specified.
  They are replaced by the related generics followed by conversions to the specified result types.

Therefore, this program is correct.
And it appears that flang does not support extended argument types.
I have confirmed similar results only for min0.
I haven't checked the other intrinsic functions.

The following are the test program, Flang, Gfortran and ifx compilation/execution result.

max0.f90:

program main
  print *,kind(max0(1_1,2_1))
  print *,kind(max0(1_2,2_2))
  print *,kind(max0(1_4,2_4))
  print *,kind(max0(1_8,2_8))

  print *,kind(min0(1_1,2_1))
  print *,kind(min0(1_2,2_2))
  print *,kind(min0(1_4,2_4))
  print *,kind(min0(1_8,2_8))
end program main

$ flang max0.f90; ./a.out
 4
 4
 4
 4
 4
 4
 4
 4
$

$ gfortran max0.f90; ./a.out
           1
           2
           4
           8
           1
           2
           4
           8
$

$ ifx max0.f90; ./a.out
           1
           2
           4
           8
           1
           2
           4
           8
$

[llvmbot]

@llvm/issue-subscribers-flang-frontend

Author: None (ohno-fj)

``` Version of flang : 21.0.0(3e6f618)/AArch64 ```

As in the attached program, when max0 intrinsic function is given 1, 2, and 8 byte in addition to default integer (4 byte), the results of the function are all default integer (4 byte).

max0 is written as accept more argument types than specified. by:

https://github.com/llvm/llvm-project/blob/main/flang/docs/Extensions.md
Extensions, deletions, and legacy features supported by default
- Specific intrinsics AMAX0, AMAX1, AMIN0, AMIN1, DMAX1, DMIN1, MAX0, MAX1, MIN0, and MIN1
  accept more argument types than specified.
  They are replaced by the related generics followed by conversions to the specified result types.

Therefore, this program is correct.
And it appears that flang does not support extended argument types.
I have confirmed similar results only for min0.
I haven't checked the other intrinsic functions.

The following are the test program, Flang, Gfortran and ifx compilation/execution result.

max0.f90:

program main
  print *,kind(max0(1_1,2_1))
  print *,kind(max0(1_2,2_2))
  print *,kind(max0(1_4,2_4))
  print *,kind(max0(1_8,2_8))

  print *,kind(min0(1_1,2_1))
  print *,kind(min0(1_2,2_2))
  print *,kind(min0(1_4,2_4))
  print *,kind(min0(1_8,2_8))
end program main

$ flang max0.f90; ./a.out
 4
 4
 4
 4
 4
 4
 4
 4
$

$ gfortran max0.f90; ./a.out
           1
           2
           4
           8
           1
           2
           4
           8
$

$ ifx max0.f90; ./a.out
           1
           2
           4
           8
           1
           2
           4
           8
$

[jeanPerier]

Thanks @ceseo for the RFC/patch.

I am not inclined to follow gfortran here because AMAX0/MAX0/... extensions are a type mess: compilers do slightly different things with the different intrinsics, and in the end it is just very hard to explain to the user (example below).

The current flang behavior is simple to explain, and if you use -Wall or the specific -Wuse-generic-intrinsic-when-specific-doesnt-match, you will get a warning that tells what the compiler is doing:

portability: Argument types do not match specific intrinsic 'max0' requirements; using 'max' generic instead and converting the result to INTEGER(4) if needed [-Wuse-generic-intrinsic-when-specific-doesnt-match]

So if the rational for this bug is to pass a regression test/test suite, I do not think we should align MAX0/MIN0 handling because the there is no existing consensus on how specific extremum extensions are implemented.

If this is needed for an application that cannot be fixed to use a portable pattern (that would not have compiled with gfortran < 9.1 as shown below), I am open to extending MAX0/MIN0 usgae.

To show that there is no clear precedent, let's extend the test to test all versions:

  print *, "MAX0(INT(4))  ", kind(max0(1_4,2_4))
  print *, "MAX0(INT(8))  ", kind(max0(1_8,2_8))
  print *, "MAX1(REAL(4)) ", kind(max1(1._4,2._4))
  print *, "MAX1(REAL(8)) ", kind(max1(1._8,2._8))
  print *, "AMAX0(INT(4)) ", kind(amax0(1_4,2_4))
  print *, "AMAX0(INT(8)) ", kind(amax0(1_8,2_8))
  print *, "AMAX1(REAL(4))", kind(amax1(1._4,2._4))
  print *, "AMAX1(REAL(4))", kind(amax1(1._8,2._8))
end

First of all, gfortran results changed in version 9 (2019). If you test version 8.5 or below using godbolt, you will get the same results as flang and classic flang/nvfortran:

 MAX0(INT(4))             4
 MAX0(INT(8))             4
 MAX1(REAL(4))            4
 MAX1(REAL(8))            4
 AMAX0(INT(4))            4
 AMAX0(INT(8))            4
 AMAX1(REAL(4))           4
 AMAX1(REAL(4))           4

gfortran version > 8.5: MAX0 and AMAX1 are handled as generic, not the others.

 MAX0(INT(4))             4
 MAX0(INT(8))             8
 MAX1(REAL(4))            4
 MAX1(REAL(8))            4
 AMAX0(INT(4))            4
 AMAX0(INT(8))            4
 AMAX1(REAL(4))           4
 AMAX1(REAL(4))           8

While IFX handles MAX0 like gfortran, it differs on AMAX1:

 MAX0(INT(4))             4
 MAX0(INT(8))             8
 MAX1(REAL(4))            4
 MAX1(REAL(8))            4
 AMAX0(INT(4))            4
 AMAX0(INT(8))            4
 AMAX1(REAL(4))           4
 AMAX1(REAL(4))           4

Now let's play with -i8/-fdefault-integer-8:

• gfortran -fdefault-integer-8 -fdefault-real-8 (version <=8.5) and flang/classic flang

 MAX0(INT(4))                      8
 MAX0(INT(8))                      8
 MAX1(REAL(4))                     8
 MAX1(REAL(8))                     8
 AMAX0(INT(4))                     8
 AMAX0(INT(8))                     8
 AMAX1(REAL(4))                    8
 AMAX1(REAL(4))                    8

• ifx -i8 -r8, the flags acts consistently, MAX0 is handled as a generic intrinsic, not the others.

 MAX0(INT(4))                       4
 MAX0(INT(8))                       8
 MAX1(REAL(4))                      8
 MAX1(REAL(8))                      8
 AMAX0(INT(4))                      8
 AMAX0(INT(8))                      8
 AMAX1(REAL(4))                     8
 AMAX1(REAL(4))                     8

• gfortran -fdefault-integer-8 -fdefault-real-8 version > 8.5, the flags seem to just have no effects...

 MAX0(INT(4))                      4
 MAX0(INT(8))                      8
 MAX1(REAL(4))                     4
 MAX1(REAL(8))                     4
 AMAX0(INT(4))                     4
 AMAX0(INT(8))                     4
 AMAX1(REAL(4))                    4
 AMAX1(REAL(4))                    8

[ceseo]

So if the rational for this bug is to pass a regression test/test suite, I do not think we should align MAX0/MIN0 handling because the there is no existing consensus on how specific extremum extensions are implemented.

If this is needed for an application that cannot be fixed to use a portable pattern (that would not have compiled with gfortran < 9.1 as shown below), I am open to extending MAX0/MIN0 usgae.

I agree. Let's wait for @ohno-fj to comment. If he's OK with this, we may close this issue and the PR I opened.

[klausler]

The result types of these specific intrinsic functions are clearly specified in the language standard and they have been in the language since its very first release in the 1950's. The extension in this compiler allows additional argument types which would otherwise have been errors, so it does not affect the meaning of any conforming program. Changing the result types, however, seems like a bad idea in the absence of a strong portability argument.

[ohno-fj]

Thank you all for your comments.

I understood that since it is stated that max0 and others accept more argument types than specified, adding argument types would also permit changes to the result type.

As you pointed out, I've come to feel that changing the result type is not good behavior.
And, specifying the -Wuse-generic-intrinsic-when-specific-doesnt-match option is crucial for understanding Flang's behavior, and the message it provides is very helpful for users.

Based on the above, I believe Flang's current behavior is acceptable.

@ceseo, if you agree this is fine, could you please close this issue and the PR?