public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
From: Christophe Lyon <christophe.lyon.oss@gmail.com>
To: Sandra Loosemore <sandra@codesourcery.com>
Cc: "Tobias Burnus" <tobias@codesourcery.com>,
	"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
	"fortran@gcc.gnu.org" <fortran@gcc.gnu.org>,
	"Thomas Koenig" <tkoenig@netcologne.de>,
	"José Rui Faustino de Sousa" <jrfsousa@gmail.com>
Subject: Re: [PATCH v3, Fortran] TS 29113 testsuite
Date: Fri, 3 Sep 2021 09:46:53 +0200	[thread overview]
Message-ID: <CAKhMtSKXCwC6UduzYPFZQFSfvOJWcfsN6GGS4mV4VbFyBiURSw@mail.gmail.com> (raw)
In-Reply-To: <b8180d68-7a04-b963-0c4a-5789bd307b98@codesourcery.com>

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
>

  reply	other threads:[~2021-09-03  7:47 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-01  5:53 [WIP, " 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 [this message]
2021-09-03  9:14           ` Tobias Burnus
2021-09-03 17:18             ` Sandra Loosemore

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAKhMtSKXCwC6UduzYPFZQFSfvOJWcfsN6GGS4mV4VbFyBiURSw@mail.gmail.com \
    --to=christophe.lyon.oss@gmail.com \
    --cc=fortran@gcc.gnu.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jrfsousa@gmail.com \
    --cc=sandra@codesourcery.com \
    --cc=tkoenig@netcologne.de \
    --cc=tobias@codesourcery.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).