* [WIP, Fortran] TS 29113 testsuite @ 2021-07-01 5:53 Sandra Loosemore 2021-07-07 3:40 ` [PATCH, " Sandra Loosemore 0 siblings, 1 reply; 8+ messages in thread From: Sandra Loosemore @ 2021-07-01 5:53 UTC (permalink / raw) To: gcc-patches, fortran; +Cc: Tobias Burnus, José Rui Faustino de Sousa [-- 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 --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH, Fortran] TS 29113 testsuite 2021-07-01 5:53 [WIP, Fortran] TS 29113 testsuite Sandra Loosemore @ 2021-07-07 3:40 ` Sandra Loosemore 2021-07-25 19:47 ` [PATCH v2, " Sandra Loosemore 0 siblings, 1 reply; 8+ messages in thread From: Sandra Loosemore @ 2021-07-07 3:40 UTC (permalink / raw) To: gcc-patches, fortran; +Cc: Tobias Burnus, José Rui Faustino de Sousa [-- 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 --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH v2, Fortran] TS 29113 testsuite 2021-07-07 3:40 ` [PATCH, " Sandra Loosemore @ 2021-07-25 19:47 ` Sandra Loosemore 2021-07-27 11:07 ` Tobias Burnus 0 siblings, 1 reply; 8+ messages in thread From: Sandra Loosemore @ 2021-07-25 19:47 UTC (permalink / raw) To: gcc-patches, fortran; +Cc: Tobias Burnus, José Rui Faustino de Sousa [-- 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 --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v2, Fortran] TS 29113 testsuite 2021-07-25 19:47 ` [PATCH v2, " Sandra Loosemore @ 2021-07-27 11:07 ` Tobias Burnus 2021-08-19 17:28 ` [PATCH v3, " Sandra Loosemore 0 siblings, 1 reply; 8+ messages in thread From: Tobias Burnus @ 2021-07-27 11:07 UTC (permalink / raw) To: Sandra Loosemore, gcc-patches, fortran, Thomas Koenig Cc: José Rui Faustino de Sousa 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v3, Fortran] TS 29113 testsuite 2021-07-27 11:07 ` Tobias Burnus @ 2021-08-19 17:28 ` Sandra Loosemore 2021-09-03 7:46 ` Christophe Lyon 0 siblings, 1 reply; 8+ messages in thread From: Sandra Loosemore @ 2021-08-19 17:28 UTC (permalink / raw) To: Tobias Burnus, gcc-patches, fortran, Thomas Koenig Cc: José Rui Faustino de Sousa [-- 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 --] ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v3, Fortran] TS 29113 testsuite 2021-08-19 17:28 ` [PATCH v3, " Sandra Loosemore @ 2021-09-03 7:46 ` Christophe Lyon 2021-09-03 9:14 ` Tobias Burnus 0 siblings, 1 reply; 8+ messages in thread From: Christophe Lyon @ 2021-09-03 7:46 UTC (permalink / raw) To: Sandra Loosemore Cc: Tobias Burnus, gcc-patches, fortran, Thomas Koenig, José Rui Faustino de Sousa 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 > ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v3, Fortran] TS 29113 testsuite 2021-09-03 7:46 ` Christophe Lyon @ 2021-09-03 9:14 ` Tobias Burnus 2021-09-03 17:18 ` Sandra Loosemore 0 siblings, 1 reply; 8+ messages in thread From: Tobias Burnus @ 2021-09-03 9:14 UTC (permalink / raw) To: Christophe Lyon, Sandra Loosemore Cc: gcc-patches, fortran, Thomas Koenig, José Rui Faustino de Sousa 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [PATCH v3, Fortran] TS 29113 testsuite 2021-09-03 9:14 ` Tobias Burnus @ 2021-09-03 17:18 ` Sandra Loosemore 0 siblings, 0 replies; 8+ messages in thread From: Sandra Loosemore @ 2021-09-03 17:18 UTC (permalink / raw) To: Tobias Burnus, Christophe Lyon Cc: gcc-patches, fortran, Thomas Koenig, José Rui Faustino de Sousa 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 ^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2021-09-03 17:18 UTC | newest] Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-07-01 5:53 [WIP, Fortran] TS 29113 testsuite Sandra Loosemore 2021-07-07 3:40 ` [PATCH, " Sandra Loosemore 2021-07-25 19:47 ` [PATCH v2, " Sandra Loosemore 2021-07-27 11:07 ` Tobias Burnus 2021-08-19 17:28 ` [PATCH v3, " Sandra Loosemore 2021-09-03 7:46 ` Christophe Lyon 2021-09-03 9:14 ` Tobias Burnus 2021-09-03 17:18 ` Sandra Loosemore
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).