public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
From: Tobias Burnus <tobias@codesourcery.com>
To: Sandra Loosemore <sandra@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>
Cc: "José Rui Faustino de Sousa" <jrfsousa@gmail.com>
Subject: Re: [PATCH v2, Fortran] TS 29113 testsuite
Date: Tue, 27 Jul 2021 13:07:00 +0200	[thread overview]
Message-ID: <47e5cae8-1d71-4017-0978-96670a773ad0@codesourcery.com> (raw)
In-Reply-To: <84cbe3c1-b9db-a4ae-649f-c426448f8bcc@codesourcery.com>

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

  reply	other threads:[~2021-07-27 11:07 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 [this message]
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

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=47e5cae8-1d71-4017-0978-96670a773ad0@codesourcery.com \
    --to=tobias@codesourcery.com \
    --cc=fortran@gcc.gnu.org \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jrfsousa@gmail.com \
    --cc=sandra@codesourcery.com \
    --cc=tkoenig@netcologne.de \
    /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).