From: Sandra Loosemore <sandra@codesourcery.com>
To: "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>,
"fortran@gcc.gnu.org" <fortran@gcc.gnu.org>
Cc: "Tobias Burnus" <tobias@codesourcery.com>,
"José Rui Faustino de Sousa" <jrfsousa@gmail.com>
Subject: [PATCH, Fortran] TS 29113 testsuite
Date: Tue, 6 Jul 2021 21:40:01 -0600 [thread overview]
Message-ID: <a44a53bf-9c71-0b40-bbbb-d197fe74d4f1@codesourcery.com> (raw)
In-Reply-To: <64135fb4-c218-4026-6166-5018f11ebfe0@codesourcery.com>
[-- 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 --]
next prev parent reply other threads:[~2021-07-07 3:40 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 ` Sandra Loosemore [this message]
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
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=a44a53bf-9c71-0b40-bbbb-d197fe74d4f1@codesourcery.com \
--to=sandra@codesourcery.com \
--cc=fortran@gcc.gnu.org \
--cc=gcc-patches@gcc.gnu.org \
--cc=jrfsousa@gmail.com \
--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).