Re: Fortran: Improve file-reading error diagnostic [PR55534] (was: Re: [Patch] Fortran: Improve -Wmissing-include-dirs warnings [PR55534])
On 23.09.21 23:01, Harald Anlauf via Fortran wrote: compiled with -cpp gives: pr55534-play.f90:4:2: 4 | type t | 1~~ Fatal Error: no/such/file.inc: No such file or directory compilation terminated. If you have an easy solution for that one, David has an easy but hackish solution, cf. https://gcc.gnu.org/PR100904 That's a GCC 7 regression, which also affects C/C++ but only when compiling with -traditional-cpp, which gfortran does by default but gcc/g++ don't. 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, Fortran] Add missing diagnostic for F2018 C711 (TS29113 C407c)
On 24.09.21 01:19, Sandra Loosemore wrote:
Here's another missing-diagnostic patch for the Fortran front end,
this time for PR Fortran/101333. OK to commit?
That's "C711 An assumed-type actual argument that corresponds to an
assumed-rank dummy argument shall be assumed-shape or assumed-rank."
LGTM.
Thanks for the patch!
Tobias
commit 53171e748e28901693ca4362ff658883dab97e13
Author: Sandra Loosemore
Date: Thu Sep 23 15:00:43 2021 -0700
Fortran: Add missing diagnostic for F2018 C711 (TS29113 C407c)
2021-09-23 Sandra Loosemore
PR Fortran/101333
gcc/fortran/
* interface.c (compare_parameter): Enforce F2018 C711.
gcc/testsuite/
* gfortran.dg/c-interop/c407c-1.f90: Remove xfails.
diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c
index dae4b95..a2fea0e 100644
--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -2448,6 +2448,21 @@ compare_parameter (gfc_symbol *formal, gfc_expr *actual,
return false;
}
+ /* TS29113 C407c; F2018 C711. */
+ if (actual->ts.type == BT_ASSUMED
+ && symbol_rank (formal) == -1
+ && actual->rank != -1
+ && !(actual->symtree->n.sym->as
+&& actual->symtree->n.sym->as->type == AS_ASSUMED_SHAPE))
+{
+ if (where)
+ gfc_error ("Assumed-type actual argument at %L corresponding to "
+"assumed-rank dummy argument %qs must be "
+"assumed-shape or assumed-rank",
+&actual->where, formal->name);
+ return false;
+}
+
/* F2008, 12.5.2.5; IR F08/0073. */
if (formal->ts.type == BT_CLASS && formal->attr.class_ok
&& actual->expr_type != EXPR_NULL
diff --git a/gcc/testsuite/gfortran.dg/c-interop/c407c-1.f90
b/gcc/testsuite/gfortran.dg/c-interop/c407c-1.f90
index e4da66a..c77e6ac 100644
--- a/gcc/testsuite/gfortran.dg/c-interop/c407c-1.f90
+++ b/gcc/testsuite/gfortran.dg/c-interop/c407c-1.f90
@@ -44,7 +44,7 @@ subroutine s2 (x)
implicit none
type(*) :: x(*)
- call g (x, 1) ! { dg-error "Assumed.type" "pr101333" { xfail *-*-* } }
+ call g (x, 1) ! { dg-error "Assumed.type" }
end subroutine
! Check that a scalar gives an error.
@@ -53,7 +53,7 @@ subroutine s3 (x)
implicit none
type(*) :: x
- call g (x, 1) ! { dg-error "Assumed.type" "pr101333" { xfail *-*-* } }
+ call g (x, 1) ! { dg-error "Assumed.type" }
end subroutine
! Explicit-shape assumed-type actual arguments are forbidden implicitly
-
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] Fortran: Fix assumed-size to assumed-rank passing [PR94070]
Hi Tobias, OK for mainline? As promised on IRC, here's the review. Maybe you can add a test case which shows that the call to the size intrinsic really does not happen. OK with that. Thanks for the patch! Best regards Thomas
Re: [Patch] Fortran: Fix assumed-size to assumed-rank passing [PR94070]
Hi Tobias, Am 21.09.21 um 14:26 schrieb Tobias Burnus: This patch requires the previously mentioned simple-loop-gen patch, which also still needs to be reviewed: https://gcc.gnu.org/pipermail/gcc-patches/2021-September/579576.html For the xfailed part of the new testcase, the updated array descriptor is needed, but I think leaving it as xfailed for now - and reviewing this patch first makes more sense. I played around with your patch and was unable to break it. Are you tracking the xfailed parts? While playing I stumbled over the fact that when allocating an array with a dimension that has extent 0, e.g. 4:-5, the lbound gets reset to 1 and ubound set to 0. I tried to find this in the F2018 standard but could not find this requirement. 9.7.1.2(1) only requires that the extent is 0. Has the standard has changed in this respect? size(a,dim=i) of an array is simply: a.dim[i].ubound - a.dim[i].lbound + 1 except that the result is always >= 0, i.e. a(5:-10) has size 0. Assumed-size arrays like as(5, -3:*) can be passed to assumed-rank arrays – but, obviously, the upper bound is unknown. Without BIND(C), the standard is quiet how those get transported but: ubound(as,dim=2) == size(as,dim=2) == -1 However, for ..., allocatable :: c(:,:) allocate (c(5,-4:-1)) the size(c,dim=2) is surely 4 and not -1. Thus, when passing it to a subroutine foo(x) ..., allocatable :: x(..) it should also come out as size(x, dim=2) == 4. To make the distinction, the allocatable/pointer attribute of the dummy can be used – as an assumed-size array cannot be allocatable. That's what is used in trans-intrinsic.c/trans-array.c – and the main reason I started to generate inline code for the array size. (Given that it permits optimizations and is a trivial code, I also think that it makes sense in general.) Agreed. Loop bounds in loop nests often refer to lbound/ubound/size. But even when doing so, it still did not work properly as when calling call foo(d) the bounds where not always reset such that the caller could still receive ubound(d,dim=last_dim) == -1 - in the case it just happened to be -1, be it for a zero-sized array or because the lbounds just happend to be -1 or smaller. That's taken care of in trans-expr.c. OK for mainline? I am probably not the best person to review the trans-* parts, but I did not spot anything I could point at, and the dump-tree looked reasonable. Therefore OK from my side. Thanks for the work! Harald 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
