Re: [PATCH v3, Fortran] TS 29113 testsuite
Hi, On Thu, Aug 19, 2021 at 7:29 PM Sandra Loosemore 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 e
Re: [PATCH v3, Fortran] TS 29113 testsuite
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
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
Re: [r12-3321 Regression] FAIL: gfortran.dg/PR100914.f90 -Os (test for excess errors) on Linux/x86_64
On 9/2/21 11:37 PM, Sandra Loosemore wrote: On 9/2/21 10:18 PM, sunil.k.pandey wrote: On Linux/x86_64, 93b6b2f614eb692d1d8126ec6cb946984a9d01d7 is the first bad commit commit 93b6b2f614eb692d1d8126ec6cb946984a9d01d7 Author: Sandra Loosemore Date: Wed Aug 18 07:22:03 2021 -0700 libgfortran: Further fixes for GFC/CFI descriptor conversions. caused FAIL: gfortran.dg/PR100914.f90 -O0 (test for excess errors) FAIL: gfortran.dg/PR100914.f90 -O1 (test for excess errors) FAIL: gfortran.dg/PR100914.f90 -O2 (test for excess errors) FAIL: gfortran.dg/PR100914.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions (test for excess errors) FAIL: gfortran.dg/PR100914.f90 -O3 -g (test for excess errors) FAIL: gfortran.dg/PR100914.f90 -Os (test for excess errors) I did not see this failure in my own testing, but I also had this patch for another known bug in my stack: https://gcc.gnu.org/pipermail/fortran/2021-August/056382.html I just pinged that earlier this evening as it has not been reviewed yet. I'll rebuild/retest without that patch and confirm that's what the problem is. I'm still not seeing these FAILs in my test results. Can you provide any details about the "excess errors" it is producing? E.g. is it the same missing libquadmath.h error reported here? https://gcc.gnu.org/pipermail/fortran/2021-September/056467.html -Sandra
Re: [r12-3321 Regression] FAIL: gfortran.dg/PR100914.f90 -Os (test for excess errors) on Linux/x86_64
On Fri, Sep 3, 2021 at 10:25 AM Sandra Loosemore wrote: > > On 9/2/21 11:37 PM, Sandra Loosemore wrote: > > On 9/2/21 10:18 PM, sunil.k.pandey wrote: > >> On Linux/x86_64, > >> > >> 93b6b2f614eb692d1d8126ec6cb946984a9d01d7 is the first bad commit > >> commit 93b6b2f614eb692d1d8126ec6cb946984a9d01d7 > >> Author: Sandra Loosemore > >> Date: Wed Aug 18 07:22:03 2021 -0700 > >> > >> libgfortran: Further fixes for GFC/CFI descriptor conversions. > >> > >> caused > >> > >> FAIL: gfortran.dg/PR100914.f90 -O0 (test for excess errors) > >> FAIL: gfortran.dg/PR100914.f90 -O1 (test for excess errors) > >> FAIL: gfortran.dg/PR100914.f90 -O2 (test for excess errors) > >> FAIL: gfortran.dg/PR100914.f90 -O3 -fomit-frame-pointer > >> -funroll-loops -fpeel-loops -ftracer -finline-functions (test for > >> excess errors) > >> FAIL: gfortran.dg/PR100914.f90 -O3 -g (test for excess errors) > >> FAIL: gfortran.dg/PR100914.f90 -Os (test for excess errors) > > > > I did not see this failure in my own testing, but I also had this patch > > for another known bug in my stack: > > > > https://gcc.gnu.org/pipermail/fortran/2021-August/056382.html > > > > I just pinged that earlier this evening as it has not been reviewed yet. > > I'll rebuild/retest without that patch and confirm that's what the > > problem is. > > I'm still not seeing these FAILs in my test results. Can you provide > any details about the "excess errors" it is producing? E.g. is it the > same missing libquadmath.h error reported here? > > https://gcc.gnu.org/pipermail/fortran/2021-September/056467.html > > -Sandra /export/gnu/import/git/gcc-test-master-intel64/bld/gcc/testsuite/gfortran2/../../gfortran -B/export/gnu/import/git/gcc-test-master-intel64/bld/gcc/testsuite/gfortran2/../../ -B/export/gnu/import/git/gcc-test-master-intel64/bld/x86_64-pc-linux-gnu/./libgfortran/ /export/gnu/import/git/gcc-test-master-intel64/src-master/gcc/testsuite/gfortran.dg/PR100914.f90 -fdiagnostics-plain-output -fdiagnostics-plain-output -O0 -pedantic-errors /export/gnu/import/git/gcc-test-master-intel64/src-master/gcc/testsuite/gfortran.dg/PR100914.c -dumpbase -B/export/gnu/import/git/gcc-test-master-intel64/bld/x86_64-pc-linux-gnu/./libgfortran/.libs -L/export/gnu/import/git/gcc-test-master-intel64/bld/x86_64-pc-linux-gnu/./libgfortran/.libs -L/export/gnu/import/git/gcc-test-master-intel64/bld/x86_64-pc-linux-gnu/./libgfortran/.libs -L/export/gnu/import/git/gcc-test-master-intel64/bld/x86_64-pc-linux-gnu/./libatomic/.libs -B/export/gnu/import/git/gcc-test-master-intel64/bld/x86_64-pc-linux-gnu/./libquadmath/.libs -L/export/gnu/import/git/gcc-test-master-intel64/bld/x86_64-pc-linux-gnu/./libquadmath/.libs -L/export/gnu/import/git/gcc-test-master-intel64/bld/x86_64-pc-linux-gnu/./libquadmath/.libs -lm -o ./PR100914.exe /export/gnu/import/git/gcc-test-master-intel64/src-master/gcc/testsuite/gfortran.dg/PR100914.c:8:10: fatal error: quadmath.h: No such file or directory compilation terminated. compiler exited with status 1 FAIL: gfortran.dg/PR100914.f90 -O0 (test for excess errors) Excess errors: /export/gnu/import/git/gcc-test-master-intel64/src-master/gcc/testsuite/gfortran.dg/PR100914.c:8:10: fatal error: quadmath.h: No such file or directory compilation terminated. I think some -B/-I is missing. -- H.J.
Re: [RFC] Native Coarrays (finally!) [Review part 3]
The email below seems to be the most recent email on native coarray
support. Has there been any more recent work or plans for committing a
patch? Could someone tell me whether the planned feature will work on
Windows without requiring the Windows Subsystem for Linux? Asking for a
friend. :)
Damian
On Fri, Oct 16, 2020 at 7:38 AM Paul Richard Thomas via Fortran <
fortran@gcc.gnu.org> wrote:
> Hi Andre,
>
> Yes, as Thomas confirms, you are correct about the function of span.
> Unfortunately the originators of gfortran decided on strides in words for
> array descriptors rather than bytes. As far as I am aware, all the other
> vendors use lbound, stride measure and extent, with stride measure in
> bytes. Once committed to this line, allowing the F95 feature of pointers to
> components of derived type arrays necessitated the introduction of span.
> Tobias and I got a long way to do the change over to {lbound, sm, extent}
> in fortran-dev but we both ran out of availability with a long way to go.
> We did this by calculating stride in words from the new array descriptor
> and substituting it everywhere that the stride was needed. This resulted in
> ugly and inefficient repetitions of sm/element_length in array element
> addressing. When I last looked at it everything worked except coarrays,
> which I broke somewhere in libcaf.
>
> Unfortunately, I am still pressed by daytime activities so something on
> this scale is well beyond my capacity. I will be concentrating on
> regressions in the coming weeks.
>
> Nicolas, I haven't responded to your coarrays patch. Well done for this
> impressive bit of work and thanks to Andre for reviewing it. I sincerely
> hope to see it in master, sometime in the next weeks. As has been said
> elsewhere, this should be an important aid to familiarising fortran users
> with coarrays. Does anybody have access to an AMD Ryzen 32 core machine?
>
> Best regards
>
> Paul
>
>
>
>
> On Fri, 16 Oct 2020 at 10:43, Thomas Koenig wrote:
>
> > Am 16.10.20 um 10:45 schrieb Andre Vehreschild:
> > > Hi Thomas, hi Nicolas,
> > >
> > > I agree with you, that doing copies of array's data should be avoided,
> > but
> > > please keep in mind, that the gfc_descriptor_t is so to say "public".
> > I.e.,
> > > there are also libraries using it, that are not in the gcc repo and
> those
> > > depend on the descriptor being usable as is.
> >
> > I am quite aware of that.
> >
> > However, what can happen?
> >
> > Since the last ABI revision, we set the span. Old code calling a new
> > library will work anyway because it will do the packing / unpacking.
> > New code calling the old library is something we do not, in general,
> > support (we do add new functions to the library), but it would also work
> > because we set the span anyway.
> >
> > The only thing we cannot handle is new user code (without the temporary)
> > calling old user code (which does not handle the span). We cannot
> > change that without an ABI upgrade, but upgrading the library will
> > not be affected.
> >
> > > Furthermore, the span-member is not necessarily the size of the data
> > element in
> > > the array, right @Paul?
> >
> > That's the point of using the span.
> >
> > > Assume a structure whose data components need an odd
> > > number of bytes. Putting this structure into an array, the span-member
> > would
> > > hold the padded data size, right?
> >
> > Not the size, the distance. Fortunately, alignment requirements mean
> > that this will work out OK.
> >
> > > I am not sure about the above, therefore Paul is in copy. This is just
> > like I
> > > have memorized it (may be wrong).
> > >
> > > Anyway, my remark was more the comment not being precise or rather
> > misleading.
> > > I would expect something like "/* store byte-based strides here */".
> > Which
> > > makes it more clear, what will been done.
> >
> > OK :-)
> >
> > Thanks for looking at this!
> >
> > Best regards
> >
> > Thomas
> >
>
>
> --
> "If you can't explain it simply, you don't understand it well enough" -
> Albert Einstein
>
