Re: [patch, fortran] PR109662 Namelist input with comma after name accepted
On Fri, May 05, 2023 at 08:41:48PM -0700, Jerry D via Fortran wrote: > The attached patch adds a check for the invalid comma and emits a runtime > error if -std=f95,f2003,f2018 are specified at compile time. > > Attached patch includes a new test case. > > Regression tested on x86_64-linux-gnu. > > OK for mainline? > Yes. Thanks for the fix. It's been a long time since I looked at libgfortran code and couldn't quite determine where to start to fix this. -- Steve
[patch, fortran] PR109662 Namelist input with comma after name accepted
The attached patch adds a check for the invalid comma and emits a
runtime error if -std=f95,f2003,f2018 are specified at compile time.
Attached patch includes a new test case.
Regression tested on x86_64-linux-gnu.
OK for mainline?
Regards,
Jerry
Author: Jerry DeLisle
Date: Fri May 5 20:12:25 2023 -0700
Fortran: Namelist read with invalid input accepted.
PR fortran/109662
libgfortran/ChangeLog:
* io/list_read.c: Add a check for a comma after a namelist
name in read input. Issue a runtime error message.
gcc/testsuite/ChangeLog:
* gfortran.dg/pr109662.f90: New test.
diff --git a/gcc/testsuite/gfortran.dg/pr109662.f90 b/gcc/testsuite/gfortran.dg/pr109662.f90
new file mode 100644
index 000..988cfab73cc
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr109662.f90
@@ -0,0 +1,15 @@
+! { dg-do run }
+! { dg-options "-std=f2003" }
+! PR109662 a comma after namelist name accepted on input.
+program testnmlread
+ implicit none
+ character(16) :: list = ', n = 759/'
+ character(100)::message
+ integer :: n, ioresult
+ namelist/stuff/n
+ message = ""
+ ioresult = 0
+ n = 99
+ read(list,nml=stuff,iostat=ioresult)
+ if (ioresult == 0) STOP 13
+end program testnmlread
diff --git a/libgfortran/io/list_read.c b/libgfortran/io/list_read.c
index 109313c15b1..78bfd9e8787 100644
--- a/libgfortran/io/list_read.c
+++ b/libgfortran/io/list_read.c
@@ -3596,8 +3596,12 @@ find_nml_name:
if (dtp->u.p.nml_read_error)
goto find_nml_name;
- /* A trailing space is required, we give a little latitude here, 10.9.1. */
+ /* A trailing space is required, we allow a comma with std=gnu. */
c = next_char (dtp);
+ if (c == ',' && !(compile_options.allow_std & GFC_STD_GNU))
+generate_error (>common, LIBERROR_READ_VALUE,
+ "Comma after namelist name not allowed");
+
if (!is_separator(c) && c != '!')
{
unget_char (dtp, c);
Re: [PATCH] Fortran: overloading of intrinsic binary operators [PR109641]
Hi Mikael,
On 5/5/23 13:43, Mikael Morin wrote:
Hello,
Le 01/05/2023 à 18:29, Harald Anlauf via Fortran a écrit :
+/* Given two expressions, check that their rank is conformable, i.e.
either
+ both have the same rank or at least one is a scalar. */
+
+bool
+gfc_op_rank_conformable (gfc_expr *op1, gfc_expr *op2)
+{
+// if (op1->expr_type == EXPR_VARIABLE && op1->ref)
Please remove this, and the other one below.
oops, that was a leftover from debugging sessions, which
I missed during my final pass. Fixed and pushed as
r14-529-g185da7c2014ba41f38dd62cc719873ebf020b076.
Thanks for the review!
Harald
+ if (op1->expr_type == EXPR_VARIABLE)
+ gfc_expression_rank (op1);
+// if (op2->expr_type == EXPR_VARIABLE && op2->ref)
+ if (op2->expr_type == EXPR_VARIABLE)
+ gfc_expression_rank (op2);
+
+ return (op1->rank == 0 || op2->rank == 0 || op1->rank == op2->rank);
+}
+
+
static void
add_caf_get_intrinsic (gfc_expr *e)
{
The rest looks good.
OK for master, and backport as well.
Thanks
Mikael
Fwd: Hosting our gfortran MatterMost workspace
Forgot to copy the list on this. Forwarded Message Subject: Re: Hosting our gfortran MatterMost workspace Date: Fri, 5 May 2023 10:24:11 -0700 From: Jerry D To: Mark Wielaard On 4/29/23 5:36 AM, Mark Wielaard wrote: Hi, On Fri, Apr 28, 2023 at 08:55:44PM +0200, Bernhard Reutner-Fischer wrote: On 28 April 2023 18:46:07 CEST, Mark Wielaard wrote: OSUOSL already provides some machines for sourceware/gcc. If you could put a bit more technical details into that bugzilla issue, with expected usage (how many people, groups, moderation?) then we can coordinate and put it on the overseers agenda. Or you just ask Lance folks over there, but they'll need a ticket anyway. As long as there is a sensible IRC adapter I'm sure nobody would mind it. I'm not sure if anything ever happened to hosting these here, i only remember a quick poll some time ago locally. Just let us know what works best for you. If you feel it could be useful to the rest of the gcc/sourceware community we can coordinate through the overseers infrastructure ticket: https://sourceware.org/bugzilla/show_bug.cgi?id=29853 And we'll arrange a machine through Conservancy & OSUOSL. But if you are more comfortable setting something up just for the gfortran hackers and wanting to maintain it fully yourself then going directly to OSUOSL might be easier for you. Cheers, Mark I have sent an email to Lance at osuosl.org and Mark to see if we can get started on this. I am wondering how to migrate what we have now over to a new host. I will have to query the MatterMost web pages. Regards, Jerry
Re: [PATCH] Fortran: overloading of intrinsic binary operators [PR109641]
Hello,
Le 01/05/2023 à 18:29, Harald Anlauf via Fortran a écrit :
Dear all,
the attached patch is mostly self-explaining: we mishandled the
overloading of intrinsic binary operators in the case the actual
operands were of intrinsic numeric type and the ranks of the
operands were not conformable, i.e. both were of non-zero and
different ranks. In that case the operators could be converted
to the same type before the correct user-defined operator was
resolved, leading to either rejects-valid or accepts-invalid
or wrong resolution (= wrong code).
Regtested on x86_64-pc-linux-gnu. OK for mainline?
The patch is actually very limited in impact, but the bug is
sort of annoying. Would it be OK to backport to 13.2 after
some waiting?
Thanks,
Harald
(...)
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index c3d508fb45d..341909d7de7 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -5644,6 +5666,23 @@ done:
}
+/* Given two expressions, check that their rank is conformable, i.e. either
+ both have the same rank or at least one is a scalar. */
+
+bool
+gfc_op_rank_conformable (gfc_expr *op1, gfc_expr *op2)
+{
+// if (op1->expr_type == EXPR_VARIABLE && op1->ref)
Please remove this, and the other one below.
+ if (op1->expr_type == EXPR_VARIABLE)
+gfc_expression_rank (op1);
+// if (op2->expr_type == EXPR_VARIABLE && op2->ref)
+ if (op2->expr_type == EXPR_VARIABLE)
+gfc_expression_rank (op2);
+
+ return (op1->rank == 0 || op2->rank == 0 || op1->rank == op2->rank);
+}
+
+
static void
add_caf_get_intrinsic (gfc_expr *e)
{
The rest looks good.
OK for master, and backport as well.
Thanks
Mikael
