[committed] fortran/openmp.cc: Remove 's' that slipped in during %<..%> replacement (was: [Patch] Fortran: Replace simple '.' quotes by %<.%>)
On 09.12.22 22:12, Tobias Burnus wrote:
Found when working on the just submitted/committed patch.
Committed as r13-4590 – but it required a follow-up that I somehow
missed :-/ but that is now committed as well (as r13-4597).
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
commit 045592f665bcb67b75dc6b86badbe2fd44aed3e6
Author: Tobias Burnus
Date: Sun Dec 11 11:47:55 2022 +0100
fortran/openmp.cc: Remove 's' that slipped in during %<..%> replacement
Seemingly, 's' (in VI that's the 's'ubstitute command) appeared verbatim in
a gfc_error message when to doing the '...' to %<...%> replacements in commit
r13-4590-g84f6f8a2a97f88be01e223c9c9dbab801a4f501f
gcc/fortran/
* openmp.cc (gfc_match_omp_context_selector_specification):
Remove spurious 's' in an error message.
---
gcc/fortran/openmp.cc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gcc/fortran/openmp.cc b/gcc/fortran/openmp.cc
index 7edc78ad0cb..686f924b47a 100644
--- a/gcc/fortran/openmp.cc
+++ b/gcc/fortran/openmp.cc
@@ -5568,7 +5568,7 @@ gfc_match_omp_context_selector_specification (gfc_omp_declare_variant *odv)
if (m != MATCH_YES || i == selector_set_count)
{
- gfc_error ("expected %, %, % "
+ gfc_error ("expected %, %, % "
"or % at %C");
return MATCH_ERROR;
}
Re: [PATCH] Fortran: fix ICE on bad use of statement function [PR107995]
On 12/10/22 1:23 PM, Harald Anlauf via Fortran wrote: Dear all, I'm submitting the attached patch on behalf of Steve. It fixes an ICE that occurs on an obscure use of a statement function as argument to that function. Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald OK, looks good. See my unrelated question on mattermost. Jerry
RE: Team Collaboration Considerations
My main contribution to the early (*really* early, I started with g95) intrinsics implementation was a lot of cutting-and-pasting and typing. I just replicated functions fairly mindlessly and made appropriate substitutions. But I hope at least that my copyright assignment paperwork is still in force. Katherine Holcomb UVA Research Computing https://www.rc.virginia.edu ka...@virginia.edu434-982-5948 -Original Message- From: Fortran On Behalf Of Steve Kargl via Fortran Sent: Saturday, December 10, 2022 4:09 PM To: Jerry D Cc: Holcomb, Katherine A (kah3f) ; Jerry D via Fortran ; Benson Muite ; Harald Anlauf Subject: Re: Team Collaboration Considerations On Sat, Dec 10, 2022 at 12:10:20PM -0800, Jerry D wrote: > On 12/8/22 11:14 AM, Holcomb, Katherine A (kah3f) via Fortran wrote: > > I was thinking I might try to contribute when I retire, though that may be > > in a year or two. But it's been a very long time since I dove into a large > > software project and it's intimidating. I do know C (really C++, I haven't > > used plain C for a long time). I am one of those "aging" types but I am > > familiar at least superficially with newer tools because I must use them > > for work, specifically git and Slack (Mattermost seems to be an open-source > > Slack alternative) -- we make heavy use of Slack in particular. > > > > Is there some kind of "getting started" guide? > > > > Katherine Holcomb > > UVA Research Computing https://www.rc.virginia.edu > > ka...@virginia.edu434-982-5948 > > > > In your case I would recommend just pick a bug and start exploring it > with gdb and valgrind. There is no need to learn the whole project. > If you want, we could pick one for you as a starter. I will send you > an invite to the Mattermost so you can watch as we organize it. One > thought we had is to use "boards" for categories of bugs and use it as > a way to triage the list of bugs (ideas evolving) > Katherine's name appears in the copyright notice in intrinsic.h and intrinsic.c. The overall design has not changed from when g95 was imported to become gfortran. There are a few new intrinsics coming with F2023. Perhaps, this might be a point of entry (pun intended) for returning to gfortran hacking. Katherine, your return will be most welcomed. -- Steve
[PATCH] Fortran: improve checking of assumed size array spec [PR102180]
Dear all,
the attached patch improves checking of array specs in two ways:
- bad assumed size array spec
- a bad first array element spec may already trigger an error,
leading to a more consistent behavior
Regtested on x86_64-pc-linux-gnu. OK for mainline?
Thanks,
Harald
From 06c1d0a96544640c7b1485fe977337ef1572ac91 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Sun, 11 Dec 2022 23:24:03 +0100
Subject: [PATCH] Fortran: improve checking of assumed size array spec
[PR102180]
gcc/fortran/ChangeLog:
PR fortran/102180
* array.cc (match_array_element_spec): Add check for bad
assumed-implied-spec.
(gfc_match_array_spec): Reorder logic so that a first bad array
element spec may trigger an error.
gcc/testsuite/ChangeLog:
PR fortran/102180
* gfortran.dg/pr102180.f90: New test.
---
gcc/fortran/array.cc | 12 ++--
gcc/testsuite/gfortran.dg/pr102180.f90 | 19 +++
2 files changed, 29 insertions(+), 2 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/pr102180.f90
diff --git a/gcc/fortran/array.cc b/gcc/fortran/array.cc
index bbdb5b392fc..9c1d55fa8cc 100644
--- a/gcc/fortran/array.cc
+++ b/gcc/fortran/array.cc
@@ -488,6 +488,14 @@ match_array_element_spec (gfc_array_spec *as)
return AS_ASSUMED_SIZE;
}
+ /* F2018:R821: "assumed-implied-spec is [ lower-bound : ] *". */
+ if (gfc_match (" : * ") == MATCH_YES)
+{
+ gfc_error ("A lower bound must precede colon in "
+ "assumed size array specification at %C");
+ return AS_UNKNOWN;
+}
+
if (gfc_match_char (':') == MATCH_YES)
return AS_DEFERRED;
@@ -591,6 +599,8 @@ gfc_match_array_spec (gfc_array_spec **asp, bool match_dim, bool match_codim)
{
as->rank++;
current_type = match_array_element_spec (as);
+ if (current_type == AS_UNKNOWN)
+ goto cleanup;
/* Note that current_type == AS_ASSUMED_SIZE for both assumed-size
and implied-shape specifications. If the rank is at least 2, we can
@@ -600,8 +610,6 @@ gfc_match_array_spec (gfc_array_spec **asp, bool match_dim, bool match_codim)
if (as->rank == 1)
{
- if (current_type == AS_UNKNOWN)
- goto cleanup;
as->type = current_type;
}
else
diff --git a/gcc/testsuite/gfortran.dg/pr102180.f90 b/gcc/testsuite/gfortran.dg/pr102180.f90
new file mode 100644
index 000..cbf3e7299e7
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr102180.f90
@@ -0,0 +1,19 @@
+! { dg-do compile }
+! { dg-options "-fcoarray=lib" }
+! PR fortran/102180 - Improve checking of assumed size array spec
+
+subroutine s(x,y)
+ real :: x(0:*) ! legal
+ real :: y[0:*] ! legal
+end
+
+subroutine t(x,y)
+ real :: x(:*) ! { dg-error "A lower bound must precede colon" }
+ real :: y[:*] ! { dg-error "A lower bound must precede colon" }
+end
+
+subroutine u(x,y,z)
+ real :: x(2,*)
+ real :: y(2,2:*)
+ real :: z(2,:*) ! { dg-error "A lower bound must precede colon" }
+end
--
2.35.3
Re: [PATCH] Fortran: improve checking of assumed size array spec [PR102180]
On Sun, Dec 11, 2022 at 11:33:43PM +0100, Harald Anlauf via Fortran wrote:
> Dear all,
>
> the attached patch improves checking of array specs in two ways:
> - bad assumed size array spec
> - a bad first array element spec may already trigger an error,
> leading to a more consistent behavior
>
> Regtested on x86_64-pc-linux-gnu. OK for mainline?
>
OK with minor nit.
> + /* F2018:R821: "assumed-implied-spec is [ lower-bound : ] *". */
> + if (gfc_match (" : * ") == MATCH_YES)
> +{
> + gfc_error ("A lower bound must precede colon in "
> + "assumed size array specification at %C");
"assumed size" should likely be "assumed-size"
> + return AS_UNKNOWN;
> +}
> +
--
Steve
