[PATCH] D104150: [test-suite] NIST Fortran Compiler Validation Suite.

Nichols A. Romero via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Jun 18 08:54:41 PDT 2021


naromero77 added a comment.

In D104150#2826484 <https://reviews.llvm.org/D104150#2826484>, @rovka wrote:

> In D104150#2824793 <https://reviews.llvm.org/D104150#2824793>, @naromero77 wrote:
>
>> In D104150#2818673 <https://reviews.llvm.org/D104150#2818673>, @rovka wrote:
>>
>>> Is this expected to pass with current upstream flang?
>>> I gave this a quick spin on an AArch64 machine similar to our buildbots (same hardware, not necessarily same ubuntu version, system compiler etc) and I'm seeing one failure in FM509:
>>>
>>>   /path/to/build/bin/flang -DNDEBUG  -w -Werror=date-time -c /path/to/llvm-test-suite/Fortran/UnitTests/fcvs21_f95/FM509.f -o CMakeFiles/FM509.dir/FM509.f.o
>>>   f18-c234.f90:237:12:
>>>   
>>>     237 |  CALL sn512(c1n001(5)(2:9), cvcomp)
>>>         |            1
>>>   Error: Actual argument contains too few elements for dummy argument ‘c1d001’ (19/48) at (1)
>>>   execvp(gfortran) failed: 
>>>   flang: in /path/to/test-suite-sandbox/build/Fortran/UnitTests/fcvs21_f95, f18 failed with exit status 0: /path/to/build/bin/f18 -module-suffix .f18.mod -DNDEBUG -w -Werror=date-time -c /path/to/llvm-test-suite/Fortran/UnitTests/fcvs21_f95/FM509.f -o CMakeFiles/FM509.dir/FM509.f.o
>>>
>>> I'm attaching the produced f18-c234.f90 in case anyone wants to have a look. F17403672: f18-c234.f90 <https://reviews.llvm.org/F17403672>
>>
>> Sorry for the slow reply. I am on vacation this week and will return to a regular schedule next week. I had no failures with an GCC 7.5, but did have one failure with GCC 10.2 with this same test. Are you using the Flang throw away driver? If so, which GCC are you using.
>
> No worries :) I'm using GCC 9.3.0.

Can you try running it again with the latest version of the patch? It should compile and pass now. This test needs the `-std=legacy` flag.

>> It would be pretty easy to remove this test if we decided that is the best thing to do.
>
> For now it would be best to investigate :)
>
> If the test looks fishy (e.g. isn't conformant to the standard or uses obsolete features that we're not interested in), then of course we can remove it.

It kind of looks like this type of thing:
https://gcc.gnu.org/gcc-10/porting_to.html

Except that the

  -fallow-argument-mismatch

does not actually help, you have to use

  -std=legacy

It looks like it might be non-conformant, but I am not 100% sure.

> If it looks sensible and the issue is in gfortran, then we should commit the test and mark it as XFAIL for certain versions of GCC (looks like probably >= 9.3.0). I don't know exactly how that's done but we can probably look for other examples in the test-suite. If the issue is in flang itself, then it's best to open a bug report and commit the test as XFAIL until the bug is fixed.
>
> TL;DR: We shouldn't block this patch just because that test is failing, but we don't necessarily have to remove it either.




Repository:
  rT test-suite

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D104150/new/

https://reviews.llvm.org/D104150



More information about the llvm-commits mailing list