[WIP, Fortran] TS 29113 testsuite

[WIP, Fortran] TS 29113 testsuite

[Sandra Loosemore]

[-- Attachment #1: Type: text/plain, Size: 1477 bytes --]

For the past several months I've been working on developing a set of 
tests for the Fortran/C interoperability features added to Fortran via 
TS 29113, "Further Interoperability of Fortran with C":

https://wg5-fortran.org/N1901-N1950/N1942.pdf

The goal here is to exercise gfortran's implementation in a more 
systematic and complete way, including conformance with error detection 
requirements and the like as well as making sure correct programs run 
correctly.

I'm posting this as work-in-progress at this time because, well, there 
are a lot of bugs in the implementation causing lots of the tests to 
fail.  :-(  I know maintainers don't like patches that deliberately add 
FAILs to the test results and the normal practice seems to be to XFAIL 
known bugs with references to a PR.  Some of the bugs already have PRs 
open, but others don't.  What I plan to work on next is filing or 
updating the PRs with reference to the testcases that demonstrate the 
bugs, add the XFAILs, and then resubmit the patch for approval.  A few 
of these tests also still have some excessively verbose debugging output 
enabled which I'll also try to clean up before resubmitting.

I have a trivial patch for one set of failures (incorrect initialization 
of version fields) that I'll be posting shortly.  A couple of José's 
recent not-yet-committed patches also fix some of the bugs I've run 
into; I will note those in the corresponding PRs as I work through the list.

-Sandra





[-- Attachment #2: ts29113-testsuite-wip.patch.gz --]
[-- Type: application/gzip, Size: 51644 bytes --]

[PATCH, Fortran] TS 29113 testsuite

[Sandra Loosemore]

[-- Attachment #1: Type: text/plain, Size: 3805 bytes --]

On 6/30/21 11:53 PM, Sandra Loosemore wrote:
> For the past several months I've been working on developing a set of 
> tests for the Fortran/C interoperability features added to Fortran via 
> TS 29113, "Further Interoperability of Fortran with C":
> 
> https://wg5-fortran.org/N1901-N1950/N1942.pdf
> 
> The goal here is to exercise gfortran's implementation in a more 
> systematic and complete way, including conformance with error detection 
> requirements and the like as well as making sure correct programs run 
> correctly.
> 
> I'm posting this as work-in-progress at this time because, well, there 
> are a lot of bugs in the implementation causing lots of the tests to 
> fail.  :-(  I know maintainers don't like patches that deliberately add 
> FAILs to the test results and the normal practice seems to be to XFAIL 
> known bugs with references to a PR.  Some of the bugs already have PRs 
> open, but others don't.  What I plan to work on next is filing or 
> updating the PRs with reference to the testcases that demonstrate the 
> bugs, add the XFAILs, and then resubmit the patch for approval.  A few 
> of these tests also still have some excessively verbose debugging output 
> enabled which I'll also try to clean up before resubmitting.
> 
> I have a trivial patch for one set of failures (incorrect initialization 
> of version fields) that I'll be posting shortly.  A couple of José's 
> recent not-yet-committed patches also fix some of the bugs I've run 
> into; I will note those in the corresponding PRs as I work through the 
> list.

Here's the patch for the cleaned-up testsuite with xfails added. 
Besides disabling the more verbose output, I fixed some issues with 
comments and whitespace.

This is the list of issues I've tagged for the failing tests:

PR 54753
   assumed-rank dummies: Reject assumed-size actuals in in some cases
   (C535c; in F2018: C839)

PR 92482
   BIND(C) with array-descriptor mishandled for type character

PR 92621
   Problems with memory handling with allocatable intent(out) arrays
   with bind(c)

PR 93308
   bind(c) subroutine changes lower bound of array argument in caller

PR 94070
   Assumed-rank arrays – bounds mishandled, SIZE/SHAPE/UBOUND/LBOUND

PR 101304
   Bind(C): CONTIGUOUS attribute not handled correctly in Fortran routines
   called from C with discontiguous argument

PR 101305
   Bind(C): Problems with incorrect kinds/sizes in ISO_Fortran_binding.h
   and CFI_establish

PR 101308
   Bind(C): gfortran does not create C descriptors for scalar
   pointer/allocatable arguments

PR 101309
   Bind(C): gfortran creates invalid C descriptor for result of TRANSPOSE
   intrinsic

PR 101310
   Bind(C): CFI_section seems confused by pointer arrays

PR 101317
   Bind(C): improve error checking in CFI_* functions declared in
   ISO_Fortran_binding.h

PR 101319
   Missing diagnostic for argument with type parameters for assumed-type 
dummy

PR 101320
   Bind(C): Missing diagnostic for constraint C1557 on allocatable/pointer
   arguments

PR 101333
   gfortran fails to enforce C711 on assumed-type actual arguments

PR 101334
   gfortran fails to enforce C838 on disallowed uses of assumed-rank
   variable names + bogus errors

PR 101337
   gfortran doesn't diagnose all operands with constraint violations

There was a question in one of the issues about why this testsuite 
references TS29113 instead of the 2018 standard.  Well, that is what our 
customer is interested in: finding out what parts of the TS29113 
functionality remain unimplemented or broken, and fixing them, so that 
gfortran can say that it implements that specification.

I tested on both x86_64-linux-gnu and i686-pc-linux-gnu (32-bit), and 
verified that there are no FAILing tests left, just ~300 new XFAILs.

OK to check in?

-Sandra

[-- Attachment #2: ts29113-jul6.patch.gz --]
[-- Type: application/gzip, Size: 52642 bytes --]

[PATCH v2, Fortran] TS 29113 testsuite

[Sandra Loosemore]

[-- Attachment #1: Type: text/plain, Size: 1440 bytes --]

Here is an updated version of my TS29113 testsuite.  The last version I 
posted became kind of bit-rotten after Tobias's commit "Fortran: Fix 
bind(C) character length checks" for PR92842, which changed the wording 
of the error message that I'd been catching with dg-bogus in many 
places.  I've also merged some bug fixes to the test cases (most of 
which I'd already posted in conjunction with other patches to fix the 
associated library function bugs), and updated all the 
ISO_Fortran_binding.h #includes on the theory that I will iron out the 
remaining include-path problem with my patch series for PR101305 and get 
that committed before some consensus is reached on what to do about this 
patch.

With this version I'm now getting 263 XFAILs per multilib on x86.  With 
the bug fix patches I have already posted that are still awaiting 
review/committal, 42 of those go away.  And this approved but 
not-yet-committed patch from Jose

https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572725.html

fixes 6 more.

Reducing the exact number of XFAILs probably doesn't matter to the 
meta-discussion about whether it is OK to commit a pile of tests with so 
many things XFAILed, but passing around updated patches like this is 
about the only way to keep a working version of the testsuite handy to 
anyone besides me who might want to help fix some of these bugs and to 
make sure we aren't introducing regressions.  :-(

-Sandra

[-- Attachment #2: ts29113-jul25.patch.gz --]
[-- Type: application/gzip, Size: 53553 bytes --]

Re: [PATCH v2, Fortran] TS 29113 testsuite

[Tobias Burnus]

Hi Sandra, hi Thomas, hi all,

@Thomas K: Comments about the following - and of course to the
testsuite itself - are highly welcome.

In my opinion, the testsuite LGTM and can be committed.

@Sandra:
- Thoughts on the directory name? (cf. below)
- Give others/Thomas a chance to comment on this,
   before committing it. (And remove the now passing xfails.)
   Thanks for the testsuite!

Regarding:

* XFAILS - as discussed before, I think having some XFAILS is
   not ideal but fine, especially if the XFAIL/PASS ratio is low
   and there are plans to fix the known fails, some posted patches
   for those, and open PRs for the issues.

(I think there is one patch pending review and two patches pending
committal with some modifications by Sandra - plus several patches
by José which still need to be reviewed.)


* Naming of the directory + .exp file:
      ts29113/ts29113.exp
   is okay. Given that 'select rank' (in F2018 but not in TS29113)
   is also tested, there was some controversy regarding the name
   and the coverage; additionally, TS29113 is a name which is not
   immediately clear. Thus, we could use some other name like:
      c-interop/c-interop.exp
   or .... (suggestions?).
   In any case, I do not feel strong about either name.

* I had a closer look at earlier versions of the testsuite, I did
   browse through the current one + looked at the diff to previous
   version, but it is big enough and the spec is complex enough that
   I have likely missed something.
   Thus: Additional reviews are highly welcome!


Other than that:

On 25.07.21 21:47, Sandra Loosemore wrote:
> Here is an updated version of my TS29113 testsuite.
...
> And this approved but not-yet-committed patch from Jose
> https://gcc.gnu.org/pipermail/gcc-patches/2021-June/572725.html
> fixes 6 more.

The patch was committed as r12-2511-g0cbf03689e3e7d9d6002b8e5d159ef3716d0404c
[see also PR fortran/101635 for an open issue]:

I can confirm that gfortran.dg/ts29113/interoperability/cf-descriptor-2.f90
now shows XPASS (6 times for -m64, 6 times for -m32).

Overall, I see (x86-64-gnu-linux):

                 === gfortran Summary for unix ===
# of expected passes            1041
# of unexpected successes       6
# of expected failures          269
# of unresolved testcases       30

                 === gfortran Summary for unix/-m32 ===
# of expected passes            1029
# of unexpected successes       6
# of expected failures          257
# of unresolved testcases       30
# of unsupported tests          12

Unexpected success -> see XPASS above
Unsupported = dg-require-effective-target, unsupported for -m32.
Unresolved = dg-do run, but failed to compile

  * * *

Regarding:
gfortran.dg/ts29113/interoperability/contiguous-2.f90
     ! FIXME: is this correct?  "the Fortran processor will handle the
     ! difference in contiguity" may not mean that it's required to make
     ! the array contiguous, just that it can access it correctly?

I think the latter is permitted - and makes sense when the contiguity
is not needed. For instance,
   arg = 5  ! -> implicit loop + array-element access
does not require a contiguous array, even though assuming sm = sizeof(elem)
might generate faster code, e.g. by permitting vector ops. And for
   size(arg)
it does not really matter whether 'arg' is contiguous or not. But for any
call which needs a contiguous argument, contiguity is required -
which then implies that the compiler has to make the argument contiguous
(copy into a contiguous temporary).

The simplest is to always do the copy-in-into-temp (when not contiguous),
but of course there is room for optimization - like always.

In terms of the testsuite, I think the test as written is fine:
if later more optimizations are done in GCC, the GCC developer can still
inspect the FAIL, read your comment, and modify the testcase accordingly.

Thanks,

Tobias

-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955

Re: [PATCH v3, Fortran] TS 29113 testsuite

[Sandra Loosemore]

[-- Attachment #1: Type: text/plain, Size: 3355 bytes --]

On 7/27/21 5:07 AM, Tobias Burnus wrote:
> Hi Sandra, hi Thomas, hi all,
> 
> @Thomas K: Comments about the following - and of course to the
> testsuite itself - are highly welcome.
> 
> In my opinion, the testsuite LGTM and can be committed.
> 
> @Sandra:
> - Thoughts on the directory name? (cf. below)
> - Give others/Thomas a chance to comment on this,
>    before committing it. (And remove the now passing xfails.)
>    Thanks for the testsuite!
> 
> Regarding:
> 
> * XFAILS - as discussed before, I think having some XFAILS is
>    not ideal but fine, especially if the XFAIL/PASS ratio is low
>    and there are plans to fix the known fails, some posted patches
>    for those, and open PRs for the issues.
> 
> (I think there is one patch pending review and two patches pending
> committal with some modifications by Sandra - plus several patches
> by José which still need to be reviewed.)
> 
> 
> * Naming of the directory + .exp file:
>       ts29113/ts29113.exp
>    is okay. Given that 'select rank' (in F2018 but not in TS29113)
>    is also tested, there was some controversy regarding the name
>    and the coverage; additionally, TS29113 is a name which is not
>    immediately clear. Thus, we could use some other name like:
>       c-interop/c-interop.exp
>    or .... (suggestions?).
>    In any case, I do not feel strong about either name.
> 
> * I had a closer look at earlier versions of the testsuite, I did
>    browse through the current one + looked at the diff to previous
>    version, but it is big enough and the spec is complex enough that
>    I have likely missed something.
>    Thus: Additional reviews are highly welcome!

Here is the current version of the testsuite.  Changes since the last 
version include:

* Renaming the directory and .exp file from ts29113 -> c-interop per the 
request above.  There have been no additional review comments.

* I also made it explicit that section and constraint numbers mentioned 
in comments in the test cases refer to TS 29113.  I considered using the 
numbering from 2018 standard, but given that the standard already 
renumbered things twice since the time TS 29113 was published I didn't 
really see the point, as long as it is unambiguous what document is 
being cited.

* I flattened the subdirectory structure after realizing that 
dg-additional-sources can't cope with relative pathnames in remote-host 
testing.

* I split up the typecodes tests (for testing that descriptors 
constructed by the front end match ISO_Fortran_binding.h) to allow for 
finer-grained control over xfails and dg-require-effective-target, and 
added a new effective target for Fortran C_FLOAT128 support.  There are 
also some additional things being tested now in this group.

The current xfails in the tests reflect the two patches I posted last 
night that are still waiting for review:

https://gcc.gnu.org/pipermail/fortran/2021-August/056382.html
https://gcc.gnu.org/pipermail/fortran/2021-August/056383.html

I've been testing on x86 (both 32- and 64-bit) and powerpc64le-linux-gnu.

Given that Tobias already said the last version of the patch was OK, I'd 
like to commit this soon, either at the same time I push the patches 
above, or next week if there is some hold-up on them.  If anybody wants 
more time to review this first, let me know.

-Sandra

[-- Attachment #2: ts29113-aug19.patch.gz --]
[-- Type: application/gzip, Size: 55592 bytes --]

Re: [PATCH v3, Fortran] TS 29113 testsuite

[Christophe Lyon]

Hi,

On Thu, Aug 19, 2021 at 7:29 PM Sandra Loosemore <sandra@codesourcery.com>
wrote:

> On 7/27/21 5:07 AM, Tobias Burnus wrote:
> > Hi Sandra, hi Thomas, hi all,
> >
> > @Thomas K: Comments about the following - and of course to the
> > testsuite itself - are highly welcome.
> >
> > In my opinion, the testsuite LGTM and can be committed.
> >
> > @Sandra:
> > - Thoughts on the directory name? (cf. below)
> > - Give others/Thomas a chance to comment on this,
> >    before committing it. (And remove the now passing xfails.)
> >    Thanks for the testsuite!
> >
> > Regarding:
> >
> > * XFAILS - as discussed before, I think having some XFAILS is
> >    not ideal but fine, especially if the XFAIL/PASS ratio is low
> >    and there are plans to fix the known fails, some posted patches
> >    for those, and open PRs for the issues.
> >
> > (I think there is one patch pending review and two patches pending
> > committal with some modifications by Sandra - plus several patches
> > by José which still need to be reviewed.)
> >
> >
> > * Naming of the directory + .exp file:
> >       ts29113/ts29113.exp
> >    is okay. Given that 'select rank' (in F2018 but not in TS29113)
> >    is also tested, there was some controversy regarding the name
> >    and the coverage; additionally, TS29113 is a name which is not
> >    immediately clear. Thus, we could use some other name like:
> >       c-interop/c-interop.exp
> >    or .... (suggestions?).
> >    In any case, I do not feel strong about either name.
> >
> > * I had a closer look at earlier versions of the testsuite, I did
> >    browse through the current one + looked at the diff to previous
> >    version, but it is big enough and the spec is complex enough that
> >    I have likely missed something.
> >    Thus: Additional reviews are highly welcome!
>
> Here is the current version of the testsuite.  Changes since the last
> version include:
>
> * Renaming the directory and .exp file from ts29113 -> c-interop per the
> request above.  There have been no additional review comments.
>
> * I also made it explicit that section and constraint numbers mentioned
> in comments in the test cases refer to TS 29113.  I considered using the
> numbering from 2018 standard, but given that the standard already
> renumbered things twice since the time TS 29113 was published I didn't
> really see the point, as long as it is unambiguous what document is
> being cited.
>
> * I flattened the subdirectory structure after realizing that
> dg-additional-sources can't cope with relative pathnames in remote-host
> testing.
>
> * I split up the typecodes tests (for testing that descriptors
> constructed by the front end match ISO_Fortran_binding.h) to allow for
> finer-grained control over xfails and dg-require-effective-target, and
> added a new effective target for Fortran C_FLOAT128 support.  There are
> also some additional things being tested now in this group.
>
> The current xfails in the tests reflect the two patches I posted last
> night that are still waiting for review:
>
> https://gcc.gnu.org/pipermail/fortran/2021-August/056382.html
> https://gcc.gnu.org/pipermail/fortran/2021-August/056383.html
>
> I've been testing on x86 (both 32- and 64-bit) and powerpc64le-linux-gnu.
>
>
I'm not quite sure I understand the expected status of this patch: are all
the "expected" failures tagged as XFAIL?

If yes, then there's a problem because I see lots of unresolved on
aarch64/arm
For instance on aarch64:
 /gcc/testsuite/gfortran.dg/c-interop/cf-descriptor-5.f90:10:19: Error:
Sorry, character dummy argument 'a' at (1) with assumed length is not yet
supported for procedure 'ftest' with BIND(C) attribute
compiler exited with status 1
XFAIL: gfortran.dg/c-interop/cf-descriptor-5.f90   -O0  pr92482 (test for
bogus messages, line 10)
PASS: gfortran.dg/c-interop/cf-descriptor-5.f90   -O0  (test for excess
errors)
UNRESOLVED: gfortran.dg/c-interop/cf-descriptor-5.f90   -O0  compilation
failed to produce executable

/gcc/testsuite/gfortran.dg/c-interop/cf-out-descriptor-5.f90:9:19: Error:
Sorry, character dummy argument 'a' at (1) with assumed length is not yet
supported for procedure 'ftest' with BIND(C) attribute
/gcc/testsuite/gfortran.dg/c-interop/cf-out-descriptor-5.f90:23:23: Error:
Sorry, character dummy argument 'a' at (1) with assumed length is not yet
supported for procedure 'ctest' with BIND(C) attribute
/gcc/testsuite/gfortran.dg/c-interop/cf-out-descriptor-5.f90:29:23: Error:
Sorry, character dummy argument 'a' at (1) with assumed length is not yet
supported for procedure 'ftest' with BIND(C) attribute
compiler exited with status 1
XFAIL: gfortran.dg/c-interop/cf-out-descriptor-5.f90   -O0  pr92482 (test
for bogus messages, line 9)
XFAIL: gfortran.dg/c-interop/cf-out-descriptor-5.f90   -O0  pr92482 (test
for bogus messages, line 23)
XFAIL: gfortran.dg/c-interop/cf-out-descriptor-5.f90   -O0  pr92482 (test
for bogus messages, line 29)
PASS: gfortran.dg/c-interop/cf-out-descriptor-5.f90   -O0  (test for excess
errors)
UNRESOLVED: gfortran.dg/c-interop/cf-out-descriptor-5.f90   -O0
 compilation failed to produce executable

and similar for
fc-descriptor-5.f90
fc-out-descriptor-5.f90
ff-descriptor-5.f90

For
typecodes-array-float128.f90
FAIL: gfortran.dg/c-interop/typecodes-array-float128.f90   -O0  (test for
excess errors)
Excess errors:
/gcc/testsuite/gfortran.dg/c-interop/typecodes-array-float128-c.c:35:32:
error: '__float128' undeclared (first use in this function); did you mean
'_Float128'?

typecodes-sanity.f90
FAIL: gfortran.dg/c-interop/typecodes-sanity.f90   -O0  (test for excess
errors)
Excess errors:
/gcc/testsuite/gfortran.dg/c-interop/typecodes-sanity-c.c:41:13: error:
'__float128' undeclared here (not in a function); did you mean '_Float128'?

typecodes-scalar-float128.f90
FAIL: gfortran.dg/c-interop/typecodes-scalar-float128.f90   -O0  (test for
excess errors)
Excess errors:
/gcc/testsuite/gfortran.dg/c-interop/typecodes-scalar-float128-c.c:34:32:
error: '__float128' undeclared (first use in this function); did you mean
'_Float128'?

PR100914.f90
FAIL: gfortran.dg/PR100914.f90   -O0  (test for excess errors)
Excess errors:
/gcc/testsuite/gfortran.dg/PR100914.c:8:10: fatal error: quadmath.h: No
such file or directory


Can you check?

Thanks

Christophe


> Given that Tobias already said the last version of the patch was OK, I'd
> like to commit this soon, either at the same time I push the patches
> above, or next week if there is some hold-up on them.  If anybody wants
> more time to review this first, let me know.
>
> -Sandra
>

Re: [PATCH v3, Fortran] TS 29113 testsuite

[Tobias Burnus]

Hi,

On 03.09.21 09:46, Christophe Lyon wrote:
> I'm not quite sure I understand the expected status of this patch: are
> all the "expected" failures tagged as XFAIL?
I think that's the idea.
> If yes, then there's a problem because I see lots of unresolved on
> aarch64/arm
>
> XFAIL: gfortran.dg/c-interop/cf-descriptor-5.f90   -O0  pr92482 (test
> for bogus messages, line 10)
> PASS: gfortran.dg/c-interop/cf-descriptor-5.f90   -O0  (test for
> excess errors)
> UNRESOLVED: gfortran.dg/c-interop/cf-descriptor-5.f90   -O0
>  compilation failed to produce executable

I think that's the usual result for 'dg-do run' tests if the compilation
failed (be it due to errors or due to effective-target-*).

* * *

If I read https://gcc.gnu.org/onlinedocs/gcc/Floating-Types.html
correctly, we should use _Float128 for the following errors

"The _Float128 type is supported on all systems where __float128 is
supported or where long double has the IEEE binary128 format."

Applies to:

> For
> typecodes-array-float128.f90
> FAIL: gfortran.dg/c-interop/typecodes-array-float128.f90   -O0  (test
> for excess errors)
> Excess errors:
> /gcc/testsuite/gfortran.dg/c-interop/typecodes-array-float128-c.c:35:32:
> error: '__float128' undeclared (first use in this function); did you
> mean '_Float128'?
> typecodes-sanity.f90
> FAIL: gfortran.dg/c-interop/typecodes-sanity.f90   -O0  (test for
> excess errors)
> Excess errors:
> /gcc/testsuite/gfortran.dg/c-interop/typecodes-sanity-c.c:41:13:
> error: '__float128' undeclared here (not in a function); did you mean
> '_Float128'?
> typecodes-scalar-float128.f90
> FAIL: gfortran.dg/c-interop/typecodes-scalar-float128.f90   -O0  (test
> for excess errors)
> Excess errors:
> /gcc/testsuite/gfortran.dg/c-interop/typecodes-scalar-float128-c.c:34:32:
> error: '__float128' undeclared (first use in this function); did you
> mean '_Float128'?
* * *
> PR100914.f90
> FAIL: gfortran.dg/PR100914.f90   -O0  (test for excess errors)
> Excess errors:
> /gcc/testsuite/gfortran.dg/PR100914.c:8:10: fatal error: quadmath.h:
> No such file or directory

  * * *

On a normal x86-64 system, I get XPASS for:

gfortran.dg/PR100914.f90

gfortran.dg/c-interop/typecodes-array-float128.f90

The ! { dg-do run { xfail { { x86_64*-*-* i?86*-*-* } && longdouble128 } } }
does not help as it just checks whether 'sizeof(long double)==16',
which seemingly passes also on x86-64 with 80bit long double.

Tobias

-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955

Re: [PATCH v3, Fortran] TS 29113 testsuite

[Sandra Loosemore]

On 9/3/21 3:14 AM, Tobias Burnus wrote:

> If I read https://gcc.gnu.org/onlinedocs/gcc/Floating-Types.html 
> correctly, we should use _Float128 for the following errors
> 
> "The _Float128 type is supported on all systems where __float128 is 
> supported or where long double has the IEEE binary128 format."
> 
> Applies to:
> 
>> For
>> typecodes-array-float128.f90
>> FAIL: gfortran.dg/c-interop/typecodes-array-float128.f90   -O0  (test 
>> for excess errors)
>> Excess errors:
>> /gcc/testsuite/gfortran.dg/c-interop/typecodes-array-float128-c.c:35:32: 
>> error: '__float128' undeclared (first use in this function); did you 
>> mean '_Float128'?
>> typecodes-sanity.f90
>> FAIL: gfortran.dg/c-interop/typecodes-sanity.f90   -O0  (test for 
>> excess errors)
>> Excess errors:
>> /gcc/testsuite/gfortran.dg/c-interop/typecodes-sanity-c.c:41:13: 
>> error: '__float128' undeclared here (not in a function); did you mean 
>> '_Float128'?
>> typecodes-scalar-float128.f90
>> FAIL: gfortran.dg/c-interop/typecodes-scalar-float128.f90   -O0  (test 
>> for excess errors)
>> Excess errors:
>> /gcc/testsuite/gfortran.dg/c-interop/typecodes-scalar-float128-c.c:34:32: 
>> error: '__float128' undeclared (first use in this function); did you 
>> mean '_Float128'?

Just so I'm clear on this, the situation with ARM/AArch64 is that it 
provides _Float128 but not __float128?

The GNU Fortran manual explicitly defines C_FLOAT128 as corresponding to 
__float128, not _Float128 or some other 128-bit floating-point type.

https://gcc.gnu.org/onlinedocs/gcc-11.2.0/gfortran/ISO_005fC_005fBINDING.html#ISO_005fC_005fBINDING

So the situation with ARM/AArch64 is that it provides _Float128 but not 
__float128?

I guess we could change the documentation and all the references in the 
implementation as well as the test cases to tie this kind to _Float128 
instead.  I think that is backward-compatible with all existing uses?

> * * *
>> PR100914.f90
>> FAIL: gfortran.dg/PR100914.f90   -O0  (test for excess errors)
>> Excess errors:
>> /gcc/testsuite/gfortran.dg/PR100914.c:8:10: fatal error: quadmath.h: 
>> No such file or directory

Does ARM/Aarch64 provide _Float128 support without also providing 
libquadmath.h?  I'm trying to understand why it got that particular 
error.  :-S

> 
>   * * *
> 
> On a normal x86-64 system, I get XPASS for:
> 
> gfortran.dg/PR100914.f90
> 
> gfortran.dg/c-interop/typecodes-array-float128.f90
> 
> The ! { dg-do run { xfail { { x86_64*-*-* i?86*-*-* } && longdouble128 } 
> } }
> does not help as it just checks whether 'sizeof(long double)==16',
> which seemingly passes also on x86-64 with 80bit long double.

I don't understand this, either.  I've been testing on an 
i686-pc-linux-gnu build with both -m32 and -m64.  The tests PASS on -m32 
and XFAIL on -m64.  The XFAIL is there because with -m64, sizeof (long 
double) == 16 and it can't be disambiguated from the true 128-bit 
floating point type __float128 which also has size 16, and the other 
patch I committed makes it choose the standard type over the GNU 
extension type.  With -m32, the 80-bit long double type has size 12 
instead so there is no conflict.

-Sandra