[PATCH] RISC-V: skip vector tests if target not supporting v extension
The original method tried to overwrite the march option when the target
doesn't support v exctension, which caused unexpected compile and
runtime test failures
This patch change the way to handle targets that don't support v
extension by simply skip the test cases that requires v extension
The test cases under g[cc|++].dg/vect/vect.exp will be skipped on rv64gc after
this patch
gcc/testsuite/ChangeLog:
* lib/target-supports.exp: skip vector tests if target not supporting v
extension
Signed-off-by: Jerry Zhang Jian
---
gcc/testsuite/lib/target-supports.exp | 5 +
1 file changed, 1 insertion(+), 4 deletions(-)
diff --git a/gcc/testsuite/lib/target-supports.exp
b/gcc/testsuite/lib/target-supports.exp
index f001c28072f..71d7e569a7d 100644
--- a/gcc/testsuite/lib/target-supports.exp
+++ b/gcc/testsuite/lib/target-supports.exp
@@ -11807,10 +11807,7 @@ proc check_vect_support_and_set_flags { } {
lappend DEFAULT_VECTCFLAGS "-mno-vector-strict-align"
}
} else {
- foreach item [add_options_for_riscv_v ""] {
- lappend DEFAULT_VECTCFLAGS $item
- }
- set dg-do-what-default compile
+ return 0
}
} elseif [istarget loongarch*-*-*] {
# Set the default vectorization option to "-mlsx" due to the problem
--
2.45.2
Re: [pushed] readings: Drop FORTRAN 77 test suite at itl.nist.gov
On 6/18/24 10:20 AM, Steve Kargl wrote: On Tue, Jun 18, 2024 at 09:13:23AM +0200, Gerald Pfeifer wrote: The original subsite has disappeared and we couldn't find it elsewhere. https://github.com/gklimowicz/FCVS gklimowicz is a flang developer and member of J3. FWIW my copy of the tests still pass: --- snip --- FM921 compiles and runs OK ***FM922*** FM922 compiles and runs OK ***FM923*** FM923 compiles and runs OK The logfile is nist.log 0 compilation errors or warnings 0 load and link errors 0 runtime errors 192 completely successful
Re: [PATCH] Fortran: fix ALLOCATE with SOURCE=, zero-length character [PR83865]
On 6/3/24 1:12 PM, Harald Anlauf wrote: Dear all, the attached simple patch fixes an ICE for ALLOCATE with SOURCE= of a deferred-length character array with source-expression being an array of character with length zero. The reason was that the array descriptor of the source-expression was discarded in the special case of length 0. Solution: restrict special case to rank 0. Regtested on x86_64-pc-linux-gnu. OK for mainline? The offending code was introduced during 7-development, so it is technically a regression. I would therefore like to backport after waiting for a week or two. Thanks, Harald OK and thanks for patch. Jerry
[gcc r13-8640] libfortran: Fix handling of formatted separators.
https://gcc.gnu.org/g:b55a35bcc80a7402576556c2f9d161229fb220ef
commit r13-8640-gb55a35bcc80a7402576556c2f9d161229fb220ef
Author: Jerry DeLisle
Date: Sun Apr 21 20:50:26 2024 -0700
libfortran: Fix handling of formatted separators.
Backport from mainline.
PR libfortran/114304
PR libfortran/105473
libgfortran/ChangeLog:
* io/list_read.c (eat_separator): Add logic to handle spaces
preceding a comma or semicolon such that that a 'null' read
occurs without error at the end of comma or semicolon
terminated input lines. Add check and error message for ';'.
Accept tab as alternative to space.
(list_formatted_read_scalar): Treat comma as a decimal point
when specified by the decimal mode on the first item.
gcc/testsuite/ChangeLog:
* gfortran.dg/pr105473.f90: Modify for revised checks.
* gfortran.dg/pr114304-2.f90: New test.
* gfortran.dg/pr114304.f90: New test.
Diff:
---
gcc/testsuite/gfortran.dg/pr105473.f90 | 4 +-
gcc/testsuite/gfortran.dg/pr114304-2.f90 | 82 ++
gcc/testsuite/gfortran.dg/pr114304.f90 | 114 +++
libgfortran/io/list_read.c | 41 +--
4 files changed, 234 insertions(+), 7 deletions(-)
diff --git a/gcc/testsuite/gfortran.dg/pr105473.f90
b/gcc/testsuite/gfortran.dg/pr105473.f90
index 2679f6bb447..863a312c794 100644
--- a/gcc/testsuite/gfortran.dg/pr105473.f90
+++ b/gcc/testsuite/gfortran.dg/pr105473.f90
@@ -9,11 +9,11 @@
n = 999; m = 777; r=1.2345
z = cmplx(0.0,0.0)
-! Check that semi-colon is allowed as separator with decimal=point.
+! Check that semi-colon is not allowed as separator with decimal=point.
ios=0
testinput = '1;17;3.14159'
read(testinput,*,decimal='point',iostat=ios) n, m, r
- if (ios /= 0) stop 1
+ if (ios /= 5010) stop 1
! Check that semi-colon allowed as a separator with decimal=point.
ios=0
diff --git a/gcc/testsuite/gfortran.dg/pr114304-2.f90
b/gcc/testsuite/gfortran.dg/pr114304-2.f90
new file mode 100644
index 000..5ef5874f528
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr114304-2.f90
@@ -0,0 +1,82 @@
+! { dg-do run }
+!
+! PR fortran/114304
+!
+! Ensure that '\t' (tab) is supported as separator in list-directed input
+! While not really standard conform, this is widely used in user input and
+! widely supported.
+!
+
+use iso_c_binding
+implicit none
+character(len=*,kind=c_char), parameter :: tab = C_HORIZONTAL_TAB
+
+! Accept '' as variant to ' ' as separator
+! Check that and are handled
+
+character(len=*,kind=c_char), parameter :: nml_str &
+ = ''//C_CARRIAGE_RETURN // C_NEW_LINE // &
+ 'first'//tab//'='//tab//' .true.'// C_NEW_LINE // &
+ ' , other'//tab//' ='//tab//'3'//tab//', 2'//tab//'/'
+
+! Check that is handled,
+
+! Note: For new line, Unix uses \n, Windows \r\n but old Apple systems used
'\r'
+!
+! Gfortran does not seem to support all \r, but the following is supported
+! since ages, ! which seems to be a gfortran extension as ifort and flang
don't like it.
+
+character(len=*,kind=c_char), parameter :: nml_str2 &
+ = ''//C_CARRIAGE_RETURN // C_NEW_LINE // &
+ 'first'//C_NEW_LINE//'='//tab//' .true.'// C_CARRIAGE_RETURN // &
+ ' , other'//tab//' ='//tab//'3'//tab//', 2'//tab//'/'
+
+character(len=*,kind=c_char), parameter :: str &
+ = tab//'1'//tab//'2,'//tab//'3'//tab//',4'//tab//','//tab//'5'//tab//'/'
+character(len=*,kind=c_char), parameter :: str2 &
+ = tab//'1'//tab//'2;'//tab//'3'//tab//';4'//tab//';'//tab//'5'//tab//'/'
+logical :: first
+integer :: other(4)
+integer :: ints(6)
+namelist /inparm/ first , other
+
+other = 1
+
+open(99, file="test.inp")
+write(99, '(a)') nml_str
+rewind(99)
+read(99,nml=inparm)
+close(99, status="delete")
+
+if (.not.first .or. any (other /= [3,2,1,1])) stop 1
+
+other = 9
+
+open(99, file="test.inp")
+write(99, '(a)') nml_str2
+rewind(99)
+read(99,nml=inparm)
+close(99, status="delete")
+
+if (.not.first .or. any (other /= [3,2,9,9])) stop 2
+
+ints = 66
+
+open(99, file="test.inp", decimal='point')
+write(99, '(a)') str
+rewind(99)
+read(99,*) ints
+close(99, status="delete")
+
+if (any (ints /= [1,2,3,4,5,66])) stop 3
+
+ints = 77
+
+open(99, file="test.inp", decimal='comma')
+write(99, '(a)') str2
+rewind(99)
+read(99,*) ints
+close(99, status="delete")
+
+if (any (ints /= [1,2,3,4,5,77])) stop 4
+end
diff --git a/gcc/testsuite/gfortran.dg/pr114304.f90
b/gcc/testsuite/gfortran.dg/pr114304.f90
new file mode 100644
index 000..2f913f1ab34
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr114304.f90
@@ -0,0 +1,114 @@
+! { dg-do run }
+!
+! PR fortran/114304
+!
+! See also PR fortran/105473
+!
+! Testing: Does list-directed reading an integer/real allow so
Re: [Patch, fortran] PR114535 - [13/14 regression] ICE with elemental finalizer
On 4/8/24 2:45 AM, Paul Richard Thomas wrote: Hi All, This one is blazingly 'obvious'. I haven't had the heart to investigate why somebody thought that it is a good idea to check if unreferenced symbols are finalizable because, I suspect, that 'somebody' was me. Worse, I tried a couple of other fixes before I hit on the 'obvious' one :-( The ChangeLog says it all. OK for mainline and then backporting in a couple of weeks? Paul Fortran: Fix ICE in trans-stmt.cc(gfc_trans_call) [PR114535] 2024-04-08 Paul Thomas mailto:pa...@gcc.gnu.org>> gcc/fortran PR fortran/114535 * resolve.cc (resolve_symbol): Remove last chunk that checked for finalization of unreferenced symbols. gcc/testsuite/ PR fortran/114535 * gfortran.dg/pr114535d.f90: New test. * gfortran.dg/pr114535iv.f90: Additional source. Yes, OK Paul. Don't feel bad. It wasn't Tabs. LOL Jerry
Re: [Patch] Fortran: List-directed read - accept again tab as alternative to space as separator [PR114304]
On 4/8/24 2:53 AM, Tobias Burnus wrote: Jerry D wrote: See attached updated patch. It turned rather quickly out that this patch – committed as r14-9822-g93adf88cc6744a – caused regressions. Namely, real-world code use tab(s) as separator instead of spaces. [For instance, PR114304 which contains a named-list input file from SPEC CPU 2017; that example uses tabs before the '=' sign, but the issue is more generic.] I think the ISO Fortran standard only permits spaces, but as it feels natural and is widely supported, tabs are used and should remain supported. It is not quite clear how '\r' are or should be handled, but as eat_spaces did use it, I thought I would add one testcase using them as well. That test is not affected by my change; it did work before with GCC and still does – but it does fail with ifort/ifx/flang. I have not thought deeply whether it should be supported or not – and looking at the libgfortran source file, it often but (→ testcase) not consistently requires that an \n follows the \r. OK for mainline? [And: When the previous patch gets backported, this surely needs to be included as well.] Tobias Good catch. I did not even think about tabs. OK to commit and I will take care of it when I do the backport to 13. Thanks! Jerry
[gcc r14-9822] libfortran: Fix handling of formatted separators.
https://gcc.gnu.org/g:93adf88cc6744aa2c732b765e1e3b96e66cb3300
commit r14-9822-g93adf88cc6744aa2c732b765e1e3b96e66cb3300
Author: Jerry DeLisle
Date: Fri Apr 5 19:25:13 2024 -0700
libfortran: Fix handling of formatted separators.
PR libfortran/114304
PR libfortran/105473
libgfortran/ChangeLog:
* io/list_read.c (eat_separator): Add logic to handle spaces
preceding a comma or semicolon such that that a 'null' read
occurs without error at the end of comma or semicolon
terminated input lines. Add check and error message for ';'.
(list_formatted_read_scalar): Treat comma as a decimal point
when specified by the decimal mode on the first item.
gcc/testsuite/ChangeLog:
* gfortran.dg/pr105473.f90: Modify to verify new error message.
* gfortran.dg/pr114304.f90: New test.
Diff:
---
gcc/testsuite/gfortran.dg/pr105473.f90 | 4 +-
gcc/testsuite/gfortran.dg/pr114304.f90 | 114 +
libgfortran/io/list_read.c | 41 ++--
3 files changed, 152 insertions(+), 7 deletions(-)
diff --git a/gcc/testsuite/gfortran.dg/pr105473.f90
b/gcc/testsuite/gfortran.dg/pr105473.f90
index 2679f6bb447..863a312c794 100644
--- a/gcc/testsuite/gfortran.dg/pr105473.f90
+++ b/gcc/testsuite/gfortran.dg/pr105473.f90
@@ -9,11 +9,11 @@
n = 999; m = 777; r=1.2345
z = cmplx(0.0,0.0)
-! Check that semi-colon is allowed as separator with decimal=point.
+! Check that semi-colon is not allowed as separator with decimal=point.
ios=0
testinput = '1;17;3.14159'
read(testinput,*,decimal='point',iostat=ios) n, m, r
- if (ios /= 0) stop 1
+ if (ios /= 5010) stop 1
! Check that semi-colon allowed as a separator with decimal=point.
ios=0
diff --git a/gcc/testsuite/gfortran.dg/pr114304.f90
b/gcc/testsuite/gfortran.dg/pr114304.f90
new file mode 100644
index 000..2f913f1ab34
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr114304.f90
@@ -0,0 +1,114 @@
+! { dg-do run }
+!
+! PR fortran/114304
+!
+! See also PR fortran/105473
+!
+! Testing: Does list-directed reading an integer/real allow some non-integer
input?
+!
+! Note: GCC result comments before fix of this PR.
+
+ implicit none
+ call t(.true., 'comma', ';') ! No error shown
+ call t(.false., 'point', ';') ! /!\ gfortran: no error, others: error
+ call t(.false., 'comma', ',') ! Error shown
+ call t(.true., 'point', ',') ! No error shown
+ call t(.false., 'comma', '.') ! Error shown
+ call t(.false., 'point', '.') ! Error shown
+ call t(.false., 'comma', '5.') ! Error shown
+ call t(.false., 'point', '5.') ! gfortran/flang: Error shown, ifort: no error
+ call t(.false., 'comma', '5,') ! gfortran: error; others: no error
+ call t(.true., 'point', '5,') ! No error shown
+ call t(.true., 'comma', '5;') ! No error shown
+ call t(.false., 'point', '5;') ! /!\ gfortran: no error shown, others: error
+ call t(.true., 'comma', '7 .') ! No error shown
+ call t(.true., 'point', '7 .') ! No error shown
+ call t(.true., 'comma', '7 ,') ! /!\ gfortran: error; others: no error
+ call t(.true., 'point', '7 ,') ! No error shown
+ call t(.true., 'comma', '7 ;') ! No error shown
+ call t(.true., 'point', '7 ;') ! No error shown
+
+! print *, '---'
+
+ call t(.false., 'comma', '8.', .true.) ! Error shown
+ call t(.true., 'point', '8.', .true.) ! gfortran/flang: Error shown, ifort:
no error
+ call t(.true., 'comma', '8,', .true.) ! gfortran: error; others: no error
+ call t(.true., 'point', '8,', .true.) ! No error shown
+ call t(.true., 'comma', '8;', .true.) ! No error shown
+ call t(.false., 'point', '8;', .true.) ! /!\ gfortran: no error shown,
others: error
+ call t(.true., 'comma', '9 .', .true.) ! No error shown
+ call t(.true., 'point', '9 .', .true.) ! No error shown
+ call t(.true., 'comma', '9 ,', .true.) ! /!\ gfortran: error; others: no
error
+ call t(.true., 'point', '9 ,', .true.) ! No error shown
+ call t(.true., 'comma', '9 ;', .true.) ! No error shown
+ call t(.true., 'point', '9 ;', .true.) ! No error shown
+ call t(.false., 'comma', '3,3.', .true.) ! Error shown
+ call t(.false., 'point', '3.3.', .true.) ! Error shown
+ call t(.false., 'comma', '3,3,', .true.) ! gfortran/flang: no error; ifort:
error
+ call t(.true., 'comma', '3,3;', .true.) ! No error shown
+ call t(.false., 'point', '3.3;', .true.) ! gfortran/flang: no error; ifort:
error
+ call t(.true., 'comma', '4,4 .', .true.) ! N error shown
+ call t(.true., 'point', '4.4 .', .true.) ! No error shown
+ call t(.true., 'comma', '4,4 ,', .true.) ! /!\ gfortran: error; others: no
error
+ call t(.true., 'point', '4.4 ,', .true.) ! No error shown
+ call t(.true., 'comma', '4,4 ;', .true.) ! No error shown
+ call t(.true., 'point', '4.4 ;', .true.) ! No error shown
+
+! print *, '---'
+
+ call t(.true., 'comma', '8
Re: [patch, libgfortran] PR114304 - [13/14 Regression] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"
On 4/5/24 10:47 AM, Jerry D wrote:
On 4/4/24 2:41 PM, Tobias Burnus wrote:
Hi Jerry,
I think for the current testcases, I like the patch – the question is
only what's about:
',3' as input for 'comma' (or '.3' as input for 'point')
For 'point' – 0.3 is read and ios = 0 (as expected)
But for 'comma':
* GCC 12 reads nothing and has ios = 0.
* GCC 13/mainline has an error (ios != 0 – and reads nothing)
* GCC with your patch: Same result: ios != 0 and nothing read.
Expected: Same as with ','/'comma' – namely: read-in value is 0.3.
→ https://godbolt.org/z/4rc8fz4sT for the full example, which works
with ifort, ifx and flang
* * *
Can you check and fix this? It looks perfectly valid to me to have
remove the '0' in the floating point numbers '0.3' or '0,3' seems to
be permitted – and it works for '.' (with 'point') but not for ','
(with 'comma').
Yes, I found the spot to fix this.
F2023's "13.10.3.1 List-directed input forms" refers to "13.7.2.3.2 F
editing", which states:
"The standard form of the input field [...] The form of the mantissa
is an optional sign, followed by a string of one or more digits
optionally containing a decimal symbol."
The latter does not require that the digit has to be before the
decimal sign and as for output, it is optional, it is surely intended
that ",3" is a valid floating-point number for decimal='comma'.
Agree
* * *
I extended the testcase to check for this – see attached diff. All
'point' work, all 'comma' fail.
Thanks for working on this!
Tobias
Thanks much. After I fix it, I will use your extended test case in the
test suite.
Jerry -
See attached updated patch.
Regressions tested on x86-64. OK for trunk and 13 after a bit.
Jerry -
commit 690b9fa57d95796ba0e92a172e1490601f25e03a
Author: Jerry DeLisle
Date: Fri Apr 5 19:25:13 2024 -0700
libfortran: Fix handling of formatted separators.
PR libfortran/114304
PR libfortran/105473
libgfortran/ChangeLog:
* io/list_read.c (eat_separator): Add logic to handle spaces
preceding a comma or semicolon such that that a 'null' read
occurs without error at the end of comma or semicolon
terminated input lines. Add check and error message for ';'.
(list_formatted_read_scalar): Treat comma as a decimal point
when specified by the decimal mode on the first item.
gcc/testsuite/ChangeLog:
* gfortran.dg/pr105473.f90: Modify to verify new error message.
* gfortran.dg/pr114304.f90: New test.
diff --git a/gcc/testsuite/gfortran.dg/pr105473.f90 b/gcc/testsuite/gfortran.dg/pr105473.f90
index 2679f6bb447..863a312c794 100644
--- a/gcc/testsuite/gfortran.dg/pr105473.f90
+++ b/gcc/testsuite/gfortran.dg/pr105473.f90
@@ -9,11 +9,11 @@
n = 999; m = 777; r=1.2345
z = cmplx(0.0,0.0)
-! Check that semi-colon is allowed as separator with decimal=point.
+! Check that semi-colon is not allowed as separator with decimal=point.
ios=0
testinput = '1;17;3.14159'
read(testinput,*,decimal='point',iostat=ios) n, m, r
- if (ios /= 0) stop 1
+ if (ios /= 5010) stop 1
! Check that semi-colon allowed as a separator with decimal=point.
ios=0
diff --git a/gcc/testsuite/gfortran.dg/pr114304.f90 b/gcc/testsuite/gfortran.dg/pr114304.f90
new file mode 100644
index 000..2f913f1ab34
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr114304.f90
@@ -0,0 +1,114 @@
+! { dg-do run }
+!
+! PR fortran/114304
+!
+! See also PR fortran/105473
+!
+! Testing: Does list-directed reading an integer/real allow some non-integer input?
+!
+! Note: GCC result comments before fix of this PR.
+
+ implicit none
+ call t(.true., 'comma', ';') ! No error shown
+ call t(.false., 'point', ';') ! /!\ gfortran: no error, others: error
+ call t(.false., 'comma', ',') ! Error shown
+ call t(.true., 'point', ',') ! No error shown
+ call t(.false., 'comma', '.') ! Error shown
+ call t(.false., 'point', '.') ! Error shown
+ call t(.false., 'comma', '5.') ! Error shown
+ call t(.false., 'point', '5.') ! gfortran/flang: Error shown, ifort: no error
+ call t(.false., 'comma', '5,') ! gfortran: error; others: no error
+ call t(.true., 'point', '5,') ! No error shown
+ call t(.true., 'comma', '5;') ! No error shown
+ call t(.false., 'point', '5;') ! /!\ gfortran: no error shown, others: error
+ call t(.true., 'comma', '7 .') ! No error shown
+ call t(.true., 'point', '7 .') ! No error shown
+ call t(.true., 'comma', '7 ,') ! /!\ gfortran: error; others: no error
+ call t(.true., 'point', '7 ,') ! No error shown
+ call t(.true., 'comma', '7 ;') ! No error shown
+ call t(.true., 'point', '7 ;') ! No error shown
+
+! print *, '---'
+
+ call t(.false., 'comma', '8.', .true.) ! Error shown
+ call t(.true., 'point', '8.', .true.) ! gfortran/flang: Error shown, ifort: no error
+ call t(.true.,
Re: [patch, libgfortran] PR114304 - [13/14 Regression] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"
On 4/4/24 2:41 PM, Tobias Burnus wrote: Hi Jerry, I think for the current testcases, I like the patch – the question is only what's about: ',3' as input for 'comma' (or '.3' as input for 'point') For 'point' – 0.3 is read and ios = 0 (as expected) But for 'comma': * GCC 12 reads nothing and has ios = 0. * GCC 13/mainline has an error (ios != 0 – and reads nothing) * GCC with your patch: Same result: ios != 0 and nothing read. Expected: Same as with ','/'comma' – namely: read-in value is 0.3. → https://godbolt.org/z/4rc8fz4sT for the full example, which works with ifort, ifx and flang * * * Can you check and fix this? It looks perfectly valid to me to have remove the '0' in the floating point numbers '0.3' or '0,3' seems to be permitted – and it works for '.' (with 'point') but not for ',' (with 'comma'). Yes, I found the spot to fix this. F2023's "13.10.3.1 List-directed input forms" refers to "13.7.2.3.2 F editing", which states: "The standard form of the input field [...] The form of the mantissa is an optional sign, followed by a string of one or more digits optionally containing a decimal symbol." The latter does not require that the digit has to be before the decimal sign and as for output, it is optional, it is surely intended that ",3" is a valid floating-point number for decimal='comma'. Agree * * * I extended the testcase to check for this – see attached diff. All 'point' work, all 'comma' fail. Thanks for working on this! Tobias Thanks much. After I fix it, I will use your extended test case in the test suite. Jerry -
Re: [patch, libgfortran] PR114304 - [13/14 Regression] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"
On 4/4/24 2:31 AM, Tobias Burnus wrote:
Hi Jerry,
--- snip ---
The patch looks mostly like I would expect, except for decimal='point'
and a ';' which is *not* preceded by a space.
Thanks for working on it.
Regarding the 'except' case:
--- snip ---
i.e. for the following string, I had *expected an error*:
point, isreal = F , testinput = ";"n= 42 ios= 0
point, isreal = F , testinput = "5;"n= 5 ios= 0
point, isreal = T , testinput = "8;"r= 8. ios= 0
point, isreal = T , testinput = "3.3;"r= 3.2995 ios= 0
point, isreal = T , testinput = "3,3;"r= 3. ios= 0
--- snip ---
I have attached the modified testcase linked above; consider adding it
as well. - Changes to the one of the attachment:
- I added a few additional (albeit boring) tests
- I added an expected output + error diagnostic.
The testcase assumes an error for ';' as separator (with 'point'),
unless there is a space before it.
--- snip ---
Here attached is the revised patch. I replaced the new test case I had
with the one you provided modified and it now passes.
I modified the test case pr105473.f90 to expect the error on semicolon.
Regression tested on X86_64. OK for trunk and a bit later back port to 13?
Cheers,
Jerry
commit 9c8318cd8703d49ad7563e89765f8849ebc14385
Author: Jerry DeLisle
Date: Thu Apr 4 13:48:20 2024 -0700
libfortran: Fix handling of formatted separators.
PR libfortran/114304
PR libfortran/105473
libgfortran/ChangeLog:
* io/list_read.c (eat_separator): Add logic to handle spaces
preceding a comma or semicolon such that that a 'null' read
occurs without error at the end of comma or semicolon
terminated input lines. Add check and error message for ';'.
gcc/testsuite/ChangeLog:
* gfortran.dg/pr105473.f90: Modify to verify new error message.
* gfortran.dg/pr114304.f90: New test.
diff --git a/gcc/testsuite/gfortran.dg/pr105473.f90 b/gcc/testsuite/gfortran.dg/pr105473.f90
index 2679f6bb447..863a312c794 100644
--- a/gcc/testsuite/gfortran.dg/pr105473.f90
+++ b/gcc/testsuite/gfortran.dg/pr105473.f90
@@ -9,11 +9,11 @@
n = 999; m = 777; r=1.2345
z = cmplx(0.0,0.0)
-! Check that semi-colon is allowed as separator with decimal=point.
+! Check that semi-colon is not allowed as separator with decimal=point.
ios=0
testinput = '1;17;3.14159'
read(testinput,*,decimal='point',iostat=ios) n, m, r
- if (ios /= 0) stop 1
+ if (ios /= 5010) stop 1
! Check that semi-colon allowed as a separator with decimal=point.
ios=0
diff --git a/gcc/testsuite/gfortran.dg/pr114304.f90 b/gcc/testsuite/gfortran.dg/pr114304.f90
new file mode 100644
index 000..8344a9ea857
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr114304.f90
@@ -0,0 +1,101 @@
+! { dg-do run }
+!
+! PR fortran/114304
+!
+! See also PR fortran/105473
+!
+! Testing: Does list-directed reading an integer/real allow some non-integer input?
+!
+! Note: GCC result comments before fix of this PR.
+
+ implicit none
+ call t(.true., 'comma', ';') ! No error shown
+ call t(.false., 'point', ';') ! /!\ gfortran: no error, others: error
+ call t(.false., 'comma', ',') ! Error shown
+ call t(.true., 'point', ',') ! No error shown
+ call t(.false., 'comma', '.') ! Error shown
+ call t(.false., 'point', '.') ! Error shown
+ call t(.false., 'comma', '5.') ! Error shown
+ call t(.false., 'point', '5.') ! gfortran/flang: Error shown, ifort: no error
+ call t(.false., 'comma', '5,') ! gfortran: error; others: no error
+ call t(.true., 'point', '5,') ! No error shown
+ call t(.true., 'comma', '5;') ! No error shown
+ call t(.false., 'point', '5;') ! /!\ gfortran: no error shown, others: error
+ call t(.true., 'comma', '7 .') ! No error shown
+ call t(.true., 'point', '7 .') ! No error shown
+ call t(.true., 'comma', '7 ,') ! /!\ gfortran: error; others: no error
+ call t(.true., 'point', '7 ,') ! No error shown
+ call t(.true., 'comma', '7 ;') ! No error shown
+ call t(.true., 'point', '7 ;') ! No error shown
+
+! print *, '---'
+
+ call t(.false., 'comma', '8.', .true.) ! Error shown
+ call t(.true., 'point', '8.', .true.) ! gfortran/flang: Error shown, ifort: no error
+ call t(.true., 'comma', '8,', .true.) ! gfortran: error; others: no error
+ call t(.true., 'point', '8,', .true.) ! No error shown
+ call t(.true., 'comma', '8;', .true.) ! No error shown
+ call t(.false., 'point', '8;', .true.) ! /!\ gfortran: no error shown, others: error
+ call t(.true., 'comma', '9 .', .true.) ! No error shown
+ call t(.true., 'point', '9 .', .true.) ! No error shown
+ call t(.true., 'comma', '9 ,', .true.) ! /!\ gfortran: error; others: no error
+ call t(.true., 'point', '9 ,', .true.) ! No error shown
+ call t(.true., 'comma', '9 ;',
Re: [patch, libgfortran] PR114304 - [13/14 Regression] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"
On 4/4/24 2:31 AM, Tobias Burnus wrote: Hi Jerry, Jerry D wrote: The attached log entry and patch (git show) fixes this issue by adding logic to handle spaces in eat_separators. One or more spaces by themselves are a valid separator. So in this case we look at the character following the spaces to see if it is a comma or semicolon. If so, I change it to the valid separator for the given decimal mode, point or comma. This allows the comma or semicolon to be interpreted as a null read on the next effective item in the formatted read. I chose a permissive approach here that allows reads to proceed when the input line is mal-formed with an incorrect separator as long as there is at least one space in front of it. First: Consider also adding 'PR fortran/105473' to the commit log as the PRs are closely related, albeit this PR is different- The patch looks mostly like I would expect, except for decimal='point' and a ';' which is *not* preceded by a space. Thanks for working on it. Regarding the 'except' case: * * * If I try your patch with the testcase of at comment 19, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304#c19 → https://gcc.gnu.org/bugzilla/attachment.cgi?id=57695 , I do note that with 'decimal=point', a tailing semicolon is silently accepted – even if not proceeded by a space. I did that on purpose out of leniency and fear of breaking something. I will add that in and do some testing. I think such code is invalid – and you could consider to reject it. Otherwise, the handling all seems to be in line with the Fortran spec. i.e. for the following string, I had *expected an error*: I will see what it does. I agree in principle. point, isreal = F , testinput = ";"n= 42 ios= 0 point, isreal = F , testinput = "5;"n= 5 ios= 0 point, isreal = T , testinput = "8;"r= 8. ios= 0 point, isreal = T , testinput = "3.3;"r= 3.2995 ios= 0 point, isreal = T , testinput = "3,3;"r= 3. ios= 0 while I think the following is OK (i.e. no error is what I expect) due to the the space before the ';'. Agree and this is what I was attempting. point, isreal = F , testinput = "7 ;"n= 7 ios= 0 point, isreal = T , testinput = "9 ;"r= 9. ios= 0 point, isreal = T , testinput = "4.4 ;"r= 4.4010 ios=0 point, isreal = T , testinput = "9 ;"r= 9. ios= 0 point, isreal = T , testinput = "4,4 ;"r= 4. ios= 0 * * * Looking at the other compilers, ifort, ifx and Flang do issue an error here. Likewise, g95 seems to yield an error in this case (see below). I do note that the Lapack testcase that triggered this PR did have such a code - but it was then changed because g95 did not like it: https://github.com/Reference-LAPACK/lapack/commit/64e8a7500d817869e5fcde35afd39af8bc7a8086 I am glad they fixed that, it triggered a whole lot of cycles here. In terms of gfortran: until recently did accept it (all versions, including 13+14); it then rejected it due to the change in PR105473 (GCC 14/mainline, backported to 13)– but I now think it rightly did so. With the current patch, it is accepted again. * * * I have attached the modified testcase linked above; consider adding it as well. - Changes to the one of the attachment: - I added a few additional (albeit boring) tests - I added an expected output + error diagnostic. The testcase assumes an error for ';' as separator (with 'point'), unless there is a space before it. [If we want to not diagnose this as vendor extension, we really need to add a comment to that testcase besides changing valid = .false. to .true.] I have gone back and forth on this issue many times trying to find the middle ground. The standard is fairly clear. To me it is on the user to not use malformed input so allowing with the intervening space we are simply ignoring the trailing ',' or ';' and calling the spaces sufficient as a valid separator. Regardless I now have your modified test case passing. Much appreciated. Thanks for the reviews. I will resubmit when I can, hopefully today. Cheers, Jerry
[patch, libgfortran] PR114304 - [13/14 Regression] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"
Hi all,
The attached log entry and patch (git show) fixes this issue by adding
logic to handle spaces in eat_separators. One or more spaces by
themselves are a valid separator. So in this case we look at the
character following the spaces to see if it is a comma or semicolon.
If so, I change it to the valid separator for the given decimal mode,
point or comma. This allows the comma or semicolon to be interpreted as
a null read on the next effective item in the formatted read.
I chose a permissive approach here that allows reads to proceed when the
input line is mal-formed with an incorrect separator as long as there is
at least one space in front of it.
New test case included. Regression tested on X86-64.
OK for trunk? Backport to 13 after some time.
Regards,
Jerrycommit 7d1a958d6b099ea88b6c51649baf5dbd5e598909
Author: Jerry DeLisle
Date: Wed Apr 3 18:07:30 2024 -0700
libfortran: Fix handling of formatted separators.
PR libfortran/114304
libgfortran/ChangeLog:
* io/list_read.c (eat_separator): Add logic to handle spaces
preceding a comma or semicolon such that that a 'null' read
occurs without error at the end of comma or semicolon
terminated input lines.
gcc/testsuite/ChangeLog:
* gfortran.dg/pr114304.f90: New test.
diff --git a/gcc/testsuite/gfortran.dg/pr114304.f90 b/gcc/testsuite/gfortran.dg/pr114304.f90
new file mode 100644
index 000..57af619246b
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr114304.f90
@@ -0,0 +1,49 @@
+! { dg-do run }
+! pr114304
+real :: x(3)
+character(len=1) :: s
+integer :: ios
+
+s = 'x'
+
+open(99, decimal="comma", status='scratch')
+write(99, '(a)') '1,23435 1243,24 13,24 a'
+rewind(99)
+read(99, *, iostat=ios) x, s
+if (ios /= 0 .or. s /= 'a') stop 1
+
+rewind(99)
+write(99, '(a)') '1,23435;1243,24;13,24;a'
+rewind(99)
+read(99, *, iostat=ios) x, s
+if (ios /= 0 .or. s /= 'a') stop 2
+
+! Note: not reading 's'
+rewind(99)
+write(99, '(a)') '1,23435 1243,24 13,24 ,'
+rewind(99)
+read(99, *) x
+if (ios /= 0) stop 3
+
+rewind(99)
+write(99, '(a)') '1,23435;1243,24;13,24 ,'
+rewind(99)
+read(99, *, iostat=ios) x
+if (ios /= 0) stop 4
+
+! Now reading 's'
+s = 'w'
+rewind(99)
+write(99, '(a)') '1,23435 1243,24 13,24 ,'
+rewind(99)
+read(99, *, iostat=ios) x, s
+if (ios /= 0 .or. s /= 'w') stop 5
+
+s = 'w'
+rewind(99)
+write(99, '(a)') '1,23435;1243,24;13,24 ,'
+rewind(99)
+read(99, *, iostat=ios) x, s
+if (ios /= 0 .or. s /= 'w') stop 6
+close(99)
+end
diff --git a/libgfortran/io/list_read.c b/libgfortran/io/list_read.c
index fb3f7dbc34d..f6f169043bf 100644
--- a/libgfortran/io/list_read.c
+++ b/libgfortran/io/list_read.c
@@ -461,11 +461,30 @@ eat_separator (st_parameter_dt *dtp)
int c, n;
int err = 0;
- eat_spaces (dtp);
dtp->u.p.comma_flag = 0;
+ c = next_char (dtp);
+ if (c == ' ')
+{
+ eat_spaces (dtp);
+ c = next_char (dtp);
+ if (c == ',')
+ {
+ if (dtp->u.p.current_unit->decimal_status == DECIMAL_COMMA)
+ unget_char (dtp, ';');
+ dtp->u.p.comma_flag = 1;
+ eat_spaces (dtp);
+ return err;
+ }
+ if (c == ';')
+ {
+ if (dtp->u.p.current_unit->decimal_status == DECIMAL_POINT)
+ unget_char (dtp, ',');
+ dtp->u.p.comma_flag = 1;
+ eat_spaces (dtp);
+ return err;
+ }
+}
- if ((c = next_char (dtp)) == EOF)
-return LIBERROR_END;
switch (c)
{
case ',':
@@ -476,7 +495,10 @@ eat_separator (st_parameter_dt *dtp)
unget_char (dtp, c);
break;
}
-/* Fall through. */
+ dtp->u.p.comma_flag = 1;
+ eat_spaces (dtp);
+ break;
+
case ';':
dtp->u.p.comma_flag = 1;
eat_spaces (dtp);
Re: [PATCH] Fortran: fix DATA and derived types with pointer components [PR114474]
On 3/27/24 1:42 PM, Harald Anlauf wrote: Dear all, the attached patch fixes a 10+ regression for cases where a derived type with a pointer component is used in a DATA statement. The failure looked obscure, see testcase comments, and pointed to a possible issue in the resolution (order). For the failing test, the target variable was seen with ts.type == BT_PROCEDURE instead of its actual type. For this reason, I restricted the fixup as much as possible. For details, please see the commit message. Testcase cross-checked with NAG. Regtested on x86_64-pc-linux-gnu. OK for mainline? If this fix survives broader testing, I would like to backport. Thanks, Harald P.S.: while trying to extend coverage of conforming code, I had much fun also with other compilers (e.g. NAG panicking...) OK, for trunk and we will see how it survives for a bit before back port. Jerry -
[gcc r14-9681] libgfortran: Fix file position after ENDFILE statement.
https://gcc.gnu.org/g:41e767c482fc903ca5d54014b034c7526dbf8f1c
commit r14-9681-g41e767c482fc903ca5d54014b034c7526dbf8f1c
Author: Jerry DeLisle
Date: Tue Mar 26 16:44:17 2024 -0700
libgfortran: Fix file position after ENDFILE statement.
PR libfortran/107031
libgfortran/ChangeLog:
* io/file_pos.c (st_endfile): Remove call to next_record().
gcc/testsuite/ChangeLog:
* gfortran.dg/endfile_5.f90: New test.
Diff:
---
gcc/testsuite/gfortran.dg/endfile_5.f90 | 30 ++
libgfortran/io/file_pos.c | 1 -
2 files changed, 30 insertions(+), 1 deletion(-)
diff --git a/gcc/testsuite/gfortran.dg/endfile_5.f90
b/gcc/testsuite/gfortran.dg/endfile_5.f90
new file mode 100644
index 000..90eaa6b2e5b
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/endfile_5.f90
@@ -0,0 +1,30 @@
+! { dg-do run }
+! PR107031 Check that endfile truncates at end of record 5.
+program test_truncate
+integer :: num_rec, tmp, i, nr, j
+open(10, file="in.dat", action='readwrite')
+
+do i=1,10
+ write(10, *) i
+end do
+
+rewind (10)
+
+num_rec = 5
+i = 1
+ioerr = 0
+do while (i <= num_rec .and. ioerr == 0)
+read(10, *, iostat=ioerr) tmp
+i = i + 1
+enddo
+endfile(10)
+rewind (10)
+i = 0
+ioerr = 0
+do while (i <= num_rec + 1 .and. ioerr == 0)
+ read(10, *, iostat=ioerr) j
+ i = i + 1
+end do
+close(10, status='delete')
+if (i - 1 /= 5) stop 1
+end program test_truncate
diff --git a/libgfortran/io/file_pos.c b/libgfortran/io/file_pos.c
index 2bc05b293f8..d169961f997 100644
--- a/libgfortran/io/file_pos.c
+++ b/libgfortran/io/file_pos.c
@@ -352,7 +352,6 @@ st_endfile (st_parameter_filepos *fpp)
dtp.common = fpp->common;
memset (, 0, sizeof (dtp.u.p));
dtp.u.p.current_unit = u;
- next_record (, 1);
}
unit_truncate (u, stell (u->s), >common);
[patch, libgfortran] PR107031 - endfile truncates file at wrong position
Hi all,
There has been a bit of discussio on which way to go on this.
I took a look today and this trivial patch gives the behavior concluded
on Fortran Discourse. See the bugzilla for all the relevant information.
Regresion tested on x86-64.
I will do the appropriate changelog.
OK for trunk?
Attached is a new test case and the patch here:
diff --git a/libgfortran/io/file_pos.c b/libgfortran/io/file_pos.c
index 2bc05b293f8..d169961f997 100644
--- a/libgfortran/io/file_pos.c
+++ b/libgfortran/io/file_pos.c
@@ -352,7 +352,6 @@ st_endfile (st_parameter_filepos *fpp)
dtp.common = fpp->common;
memset (, 0, sizeof (dtp.u.p));
dtp.u.p.current_unit = u;
- next_record (, 1);
}
unit_truncate (u, stell (u->s), >common);
! { dg-do run }
! PR107031 Check that endfile truncates at end of record 5.
program test_truncate
integer :: num_rec, tmp, i, nr, j
open(10, file="in.dat", action='readwrite')
do i=1,10
write(10, *) i
end do
rewind (10)
num_rec = 5
i = 1
ioerr = 0
do while (i <= num_rec .and. ioerr == 0)
read(10, *, iostat=ioerr) tmp
i = i + 1
enddo
endfile(10)
rewind (10)
i = 0
ioerr = 0
do while (i <= num_rec + 1 .and. ioerr == 0)
read(10, *, iostat=ioerr) j
i = i + 1
end do
close(10, status='delete')
if (i - 1 /= 5) stop 1
end program test_truncate
[gcc r13-8417] libgfortran: [PR114304] Revert portion of PR105347 change.
https://gcc.gnu.org/g:824a71f609b37a8121793075b175e2bbe14fdb82
commit r13-8417-g824a71f609b37a8121793075b175e2bbe14fdb82
Author: Jerry DeLisle
Date: Mon Mar 11 15:15:34 2024 -0700
libgfortran: [PR114304] Revert portion of PR105347 change.
PR libfortran/105437
PR libfortran/114304
libgfortran/ChangeLog:
* io/list_read.c (eat_separator): Remove check for decimal
point mode and semicolon used as a seprator. Removes
the regression.
gcc/testsuite/ChangeLog:
* gfortran.dg/pr105473.f90: Add additional checks to address
the case of semicolon at the end of a line.
(cherry picked from commit 0c179654c3170749f3fb3232f2442fcbc99bffbb)
Diff:
---
gcc/testsuite/gfortran.dg/pr105473.f90 | 21 ++---
libgfortran/io/list_read.c | 12 +---
2 files changed, 15 insertions(+), 18 deletions(-)
diff --git a/gcc/testsuite/gfortran.dg/pr105473.f90
b/gcc/testsuite/gfortran.dg/pr105473.f90
index b309217540d..2679f6bb447 100644
--- a/gcc/testsuite/gfortran.dg/pr105473.f90
+++ b/gcc/testsuite/gfortran.dg/pr105473.f90
@@ -3,44 +3,51 @@
implicit none
integer n,m,ios
real r
+ real :: x(3)
complex z
character(40):: testinput
n = 999; m = 777; r=1.2345
z = cmplx(0.0,0.0)
-! Check that semi-colon is not allowed as separator with decimal=point.
+! Check that semi-colon is allowed as separator with decimal=point.
ios=0
testinput = '1;17;3.14159'
read(testinput,*,decimal='point',iostat=ios) n, m, r
- if (ios /= 5010) print *, "stop 1"
+ if (ios /= 0) stop 1
+! Check that semi-colon allowed as a separator with decimal=point.
+ ios=0
+ testinput = '1.23435 1243.24 13.24 ;'
+ read(testinput, *, iostat=ios) x
+ if (ios /= 0) stop 2
+
! Check that comma is not allowed as a separator with decimal=comma.
ios=0
testinput = '1,17,3,14159'
read(testinput,*,decimal='comma',iostat=ios) n, m, r
- if (ios /= 5010) print *, "stop 2"
+ if (ios /= 5010) stop 3
! Check a good read.
ios=99
testinput = '1;17;3,14159'
read(testinput,*,decimal='comma',iostat=ios) n, m, r
- if (ios /= 0) print *, "stop 3"
+ if (ios /= 0) stop 4
! Check that comma is not allowed as a separator with decimal=comma.
ios=99; z = cmplx(0.0,0.0)
testinput = '1,17, (3,14159, 1,7182)'
read(testinput,*,decimal='comma', iostat=ios) n, m, z
- if (ios /= 5010) stop 4
+ if (ios /= 5010) stop 5
! Check that semi-colon is not allowed as separator with decimal=point.
ios=99; z = cmplx(0.0,0.0)
testinput = '1,17; (3.14159; 1.7182)'
read(testinput,*,decimal='point', iostat=ios) n, m, z
- if (ios /= 5010) stop 5
+ if (ios /= 5010) stop 6
! Check a good read.
ios=99;z = cmplx(0.0,0.0)
testinput = '1;17; (3,14159; 1,7182)'
read(testinput,*,decimal='comma', iostat=ios) n, m, z
- if (ios /= 0) stop 6
+ if (ios /= 0) stop 7
end program
diff --git a/libgfortran/io/list_read.c b/libgfortran/io/list_read.c
index 6ae8de548bb..eabc67c16af 100644
--- a/libgfortran/io/list_read.c
+++ b/libgfortran/io/list_read.c
@@ -480,18 +480,8 @@ eat_separator (st_parameter_dt *dtp)
unget_char (dtp, c);
break;
}
- dtp->u.p.comma_flag = 1;
- eat_spaces (dtp);
- break;
-
+/* Fall through. */
case ';':
- if (dtp->u.p.current_unit->decimal_status == DECIMAL_POINT)
- {
- generate_error (>common, LIBERROR_READ_VALUE,
- "Semicolon not allowed as separator with DECIMAL='point'");
- unget_char (dtp, c);
- break;
- }
dtp->u.p.comma_flag = 1;
eat_spaces (dtp);
break;
[gcc r14-9432] libgfortran: [PR114304] Revert portion of PR105347 change.
https://gcc.gnu.org/g:0c179654c3170749f3fb3232f2442fcbc99bffbb
commit r14-9432-g0c179654c3170749f3fb3232f2442fcbc99bffbb
Author: Jerry DeLisle
Date: Mon Mar 11 15:15:34 2024 -0700
libgfortran: [PR114304] Revert portion of PR105347 change.
PR libfortran/105437
PR libfortran/114304
libgfortran/ChangeLog:
* io/list_read.c (eat_separator): Remove check for decimal
point mode and semicolon used as a seprator. Removes
the regression.
gcc/testsuite/ChangeLog:
* gfortran.dg/pr105473.f90: Add additional checks to address
the case of semicolon at the end of a line.
Diff:
---
gcc/testsuite/gfortran.dg/pr105473.f90 | 21 ++---
libgfortran/io/list_read.c | 12 +---
2 files changed, 15 insertions(+), 18 deletions(-)
diff --git a/gcc/testsuite/gfortran.dg/pr105473.f90
b/gcc/testsuite/gfortran.dg/pr105473.f90
index b309217540d..2679f6bb447 100644
--- a/gcc/testsuite/gfortran.dg/pr105473.f90
+++ b/gcc/testsuite/gfortran.dg/pr105473.f90
@@ -3,44 +3,51 @@
implicit none
integer n,m,ios
real r
+ real :: x(3)
complex z
character(40):: testinput
n = 999; m = 777; r=1.2345
z = cmplx(0.0,0.0)
-! Check that semi-colon is not allowed as separator with decimal=point.
+! Check that semi-colon is allowed as separator with decimal=point.
ios=0
testinput = '1;17;3.14159'
read(testinput,*,decimal='point',iostat=ios) n, m, r
- if (ios /= 5010) print *, "stop 1"
+ if (ios /= 0) stop 1
+! Check that semi-colon allowed as a separator with decimal=point.
+ ios=0
+ testinput = '1.23435 1243.24 13.24 ;'
+ read(testinput, *, iostat=ios) x
+ if (ios /= 0) stop 2
+
! Check that comma is not allowed as a separator with decimal=comma.
ios=0
testinput = '1,17,3,14159'
read(testinput,*,decimal='comma',iostat=ios) n, m, r
- if (ios /= 5010) print *, "stop 2"
+ if (ios /= 5010) stop 3
! Check a good read.
ios=99
testinput = '1;17;3,14159'
read(testinput,*,decimal='comma',iostat=ios) n, m, r
- if (ios /= 0) print *, "stop 3"
+ if (ios /= 0) stop 4
! Check that comma is not allowed as a separator with decimal=comma.
ios=99; z = cmplx(0.0,0.0)
testinput = '1,17, (3,14159, 1,7182)'
read(testinput,*,decimal='comma', iostat=ios) n, m, z
- if (ios /= 5010) stop 4
+ if (ios /= 5010) stop 5
! Check that semi-colon is not allowed as separator with decimal=point.
ios=99; z = cmplx(0.0,0.0)
testinput = '1,17; (3.14159; 1.7182)'
read(testinput,*,decimal='point', iostat=ios) n, m, z
- if (ios /= 5010) stop 5
+ if (ios /= 5010) stop 6
! Check a good read.
ios=99;z = cmplx(0.0,0.0)
testinput = '1;17; (3,14159; 1,7182)'
read(testinput,*,decimal='comma', iostat=ios) n, m, z
- if (ios /= 0) stop 6
+ if (ios /= 0) stop 7
end program
diff --git a/libgfortran/io/list_read.c b/libgfortran/io/list_read.c
index e38e9a84976..fb3f7dbc34d 100644
--- a/libgfortran/io/list_read.c
+++ b/libgfortran/io/list_read.c
@@ -476,18 +476,8 @@ eat_separator (st_parameter_dt *dtp)
unget_char (dtp, c);
break;
}
- dtp->u.p.comma_flag = 1;
- eat_spaces (dtp);
- break;
-
+/* Fall through. */
case ';':
- if (dtp->u.p.current_unit->decimal_status == DECIMAL_POINT)
- {
- generate_error (>common, LIBERROR_READ_VALUE,
- "Semicolon not allowed as separator with DECIMAL='point'");
- unget_char (dtp, c);
- break;
- }
dtp->u.p.comma_flag = 1;
eat_spaces (dtp);
break;
[gcc r13-8411] libgfortran: [PR105473] Fix checks for decimal='comma'.
https://gcc.gnu.org/g:7ecea49245bc6aeb6c889a4914961f94417f16e5
commit r13-8411-g7ecea49245bc6aeb6c889a4914961f94417f16e5
Author: Jerry DeLisle
Date: Sat Feb 17 09:24:58 2024 -0800
libgfortran: [PR105473] Fix checks for decimal='comma'.
PR libfortran/105473
libgfortran/ChangeLog:
* io/list_read.c (eat_separator): Reject comma as a
separator when it is being used as a decimal point.
(parse_real): Reject a '.' when it should be a comma.
(read_real): Likewise.
* io/read.c (read_f): Add more checks for ',' and '.'
conditions.
gcc/testsuite/ChangeLog:
* gfortran.dg/pr105473.f90: New test.
(cherry picked from commit a71d87431d0c4e04a402ef6566be090c470b2b53)
Diff:
---
gcc/testsuite/gfortran.dg/pr105473.f90 | 46
libgfortran/io/list_read.c | 48 --
libgfortran/io/read.c | 11 +++-
3 files changed, 96 insertions(+), 9 deletions(-)
diff --git a/gcc/testsuite/gfortran.dg/pr105473.f90
b/gcc/testsuite/gfortran.dg/pr105473.f90
new file mode 100644
index 000..b309217540d
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr105473.f90
@@ -0,0 +1,46 @@
+! { dg-do run }
+! PR libgfortran/105473
+ implicit none
+ integer n,m,ios
+ real r
+ complex z
+ character(40):: testinput
+ n = 999; m = 777; r=1.2345
+ z = cmplx(0.0,0.0)
+
+! Check that semi-colon is not allowed as separator with decimal=point.
+ ios=0
+ testinput = '1;17;3.14159'
+ read(testinput,*,decimal='point',iostat=ios) n, m, r
+ if (ios /= 5010) print *, "stop 1"
+
+! Check that comma is not allowed as a separator with decimal=comma.
+ ios=0
+ testinput = '1,17,3,14159'
+ read(testinput,*,decimal='comma',iostat=ios) n, m, r
+ if (ios /= 5010) print *, "stop 2"
+
+! Check a good read.
+ ios=99
+ testinput = '1;17;3,14159'
+ read(testinput,*,decimal='comma',iostat=ios) n, m, r
+ if (ios /= 0) print *, "stop 3"
+
+! Check that comma is not allowed as a separator with decimal=comma.
+ ios=99; z = cmplx(0.0,0.0)
+ testinput = '1,17, (3,14159, 1,7182)'
+ read(testinput,*,decimal='comma', iostat=ios) n, m, z
+ if (ios /= 5010) stop 4
+
+! Check that semi-colon is not allowed as separator with decimal=point.
+ ios=99; z = cmplx(0.0,0.0)
+ testinput = '1,17; (3.14159; 1.7182)'
+ read(testinput,*,decimal='point', iostat=ios) n, m, z
+ if (ios /= 5010) stop 5
+
+! Check a good read.
+ ios=99;z = cmplx(0.0,0.0)
+ testinput = '1;17; (3,14159; 1,7182)'
+ read(testinput,*,decimal='comma', iostat=ios) n, m, z
+ if (ios /= 0) stop 6
+end program
diff --git a/libgfortran/io/list_read.c b/libgfortran/io/list_read.c
index 109313c15b1..6ae8de548bb 100644
--- a/libgfortran/io/list_read.c
+++ b/libgfortran/io/list_read.c
@@ -475,11 +475,23 @@ eat_separator (st_parameter_dt *dtp)
case ',':
if (dtp->u.p.current_unit->decimal_status == DECIMAL_COMMA)
{
+ generate_error (>common, LIBERROR_READ_VALUE,
+ "Comma not allowed as separator with DECIMAL='comma'");
unget_char (dtp, c);
break;
}
- /* Fall through. */
+ dtp->u.p.comma_flag = 1;
+ eat_spaces (dtp);
+ break;
+
case ';':
+ if (dtp->u.p.current_unit->decimal_status == DECIMAL_POINT)
+ {
+ generate_error (>common, LIBERROR_READ_VALUE,
+ "Semicolon not allowed as separator with DECIMAL='point'");
+ unget_char (dtp, c);
+ break;
+ }
dtp->u.p.comma_flag = 1;
eat_spaces (dtp);
break;
@@ -1318,8 +1330,13 @@ parse_real (st_parameter_dt *dtp, void *buffer, int
length)
{
if ((c = next_char (dtp)) == EOF)
goto bad;
- if (c == ',' && dtp->u.p.current_unit->decimal_status == DECIMAL_COMMA)
- c = '.';
+ if (dtp->u.p.current_unit->decimal_status == DECIMAL_COMMA)
+ {
+ if (c == '.')
+ goto bad;
+ if (c == ',')
+ c = '.';
+ }
switch (c)
{
CASE_DIGITS:
@@ -1628,8 +1645,18 @@ read_real (st_parameter_dt *dtp, void *dest, int length)
seen_dp = 0;
c = next_char (dtp);
- if (c == ',' && dtp->u.p.current_unit->decimal_status == DECIMAL_COMMA)
-c = '.';
+ if (dtp->u.p.current_unit->decimal_status == DECIMAL_COMMA)
+{
+ if (c == '.')
+ goto bad_real;
+ if (c == ',')
+ c = '.';
+}
+ if (dtp->u.p.current_unit->decimal_status == DECIMAL_POINT)
+{
+ if (c == ';')
+ goto bad_real;
+}
switch (c)
{
CASE_DIGITS:
@@ -1669,8 +1696,13 @@ read_real (st_parameter_dt *dtp, void *dest, int length)
for (;;)
{
c = next_char (dtp);
- if (c == ',' && dtp->u.p.current_unit->decimal_status == DECIMAL_COMMA)
Re: [patch, libgfortran] Part 2: PR105456 Child I/O does not propage iostat
On 3/6/24 9:13 AM, Harald Anlauf wrote: Hi Jerry, can you please replace the user message in e.g. your new testcase pr105456-wf.f90 by say: piomsg="The users message containing % and %% and %s and other stuff" This behaves as expected with Intel, but dies horribly with gfortran after your patch! Cheers, Harald Fixed with: commit 03932d3203bce244edd812b81921c2f16ea18d86 (HEAD -> master, origin/master, origin/HEAD) Author: Jerry DeLisle Date: Wed Mar 6 19:46:04 2024 -0800 Fortran: Fix issue with using snprintf function. The previous patch used snprintf to set the message string. The message string is not a formatted string and the snprintf will interpret '%' related characters as format specifiers when there are no associated output variables. A segfault ensues. This change replaces snprintf with a fortran string copy function and null terminates the message string. PR libfortran/105456 libgfortran/ChangeLog: * io/list_read.c (list_formatted_read_scalar): Use fstrcpy from libgfortran/runtime/string.c to replace snprintf. (nml_read_obj): Likewise. * io/transfer.c (unformatted_read): Likewise. (unformatted_write): Likewise. (formatted_transfer_scalar_read): Likewise. (formatted_transfer_scalar_write): Likewise. * io/write.c (list_formatted_write_scalar): Likewise. (nml_write_obj): Likewise. gcc/testsuite/ChangeLog: * gfortran.dg/pr105456.f90: Revise using '%' characters in users error message. Jerry -
[gcc r14-9348] Fortran: Fix issue with using snprintf function.
https://gcc.gnu.org/g:03932d3203bce244edd812b81921c2f16ea18d86
commit r14-9348-g03932d3203bce244edd812b81921c2f16ea18d86
Author: Jerry DeLisle
Date: Wed Mar 6 19:46:04 2024 -0800
Fortran: Fix issue with using snprintf function.
The previous patch used snprintf to set the message
string. The message string is not a formatted string
and the snprintf will interpret '%' related characters
as format specifiers when there are no associated
output variables. A segfault ensues.
This change replaces snprintf with a fortran string copy
function and null terminates the message string.
PR libfortran/105456
libgfortran/ChangeLog:
* io/list_read.c (list_formatted_read_scalar): Use fstrcpy
from libgfortran/runtime/string.c to replace snprintf.
(nml_read_obj): Likewise.
* io/transfer.c (unformatted_read): Likewise.
(unformatted_write): Likewise.
(formatted_transfer_scalar_read): Likewise.
(formatted_transfer_scalar_write): Likewise.
* io/write.c (list_formatted_write_scalar): Likewise.
(nml_write_obj): Likewise.
gcc/testsuite/ChangeLog:
* gfortran.dg/pr105456.f90: Revise using '%' characters
in users error message.
Diff:
---
gcc/testsuite/gfortran.dg/pr105456.f90 | 4 ++--
libgfortran/io/list_read.c | 10 ++
libgfortran/io/transfer.c | 20
libgfortran/io/write.c | 10 ++
4 files changed, 26 insertions(+), 18 deletions(-)
diff --git a/gcc/testsuite/gfortran.dg/pr105456.f90
b/gcc/testsuite/gfortran.dg/pr105456.f90
index 188323847a7..60cd3b6f3e8 100644
--- a/gcc/testsuite/gfortran.dg/pr105456.f90
+++ b/gcc/testsuite/gfortran.dg/pr105456.f90
@@ -19,7 +19,7 @@ contains
character :: ch
read (unit,fmt='(A1)', advance="no", iostat=piostat, iomsg=piomsg) ch
piostat = 42
-piomsg="The users message"
+piomsg="The users message containing % and %% and %s and other stuff"
dtv%ch = ch
end subroutine read_formatted
end module sk1
@@ -35,4 +35,4 @@ program skip1
write (*,'(10(A))') "Read: '",x%ch,"'"
end program skip1
! { dg-output ".*(unit = 10, file = .*)" }
-! { dg-output "Fortran runtime error: The users message" }
+! { dg-output "Fortran runtime error: The users message containing % and %%
and %s and other stuff" }
diff --git a/libgfortran/io/list_read.c b/libgfortran/io/list_read.c
index 707afaeb8dc..e38e9a84976 100644
--- a/libgfortran/io/list_read.c
+++ b/libgfortran/io/list_read.c
@@ -2268,9 +2268,10 @@ list_formatted_read_scalar (st_parameter_dt *dtp, bt
type, void *p,
!(dtp->common.flags & IOPARM_HAS_IOSTAT))
{
char message[IOMSG_LEN + 1];
- child_iomsg_len = string_len_trim (IOMSG_LEN, child_iomsg) + 1;
+ child_iomsg_len = string_len_trim (IOMSG_LEN, child_iomsg);
free_line (dtp);
- snprintf (message, child_iomsg_len, child_iomsg);
+ fstrcpy (message, child_iomsg_len, child_iomsg, child_iomsg_len);
+ message[child_iomsg_len] = '\0';
generate_error (>common, dtp->u.p.child_saved_iostat,
message);
}
@@ -3082,8 +3083,9 @@ nml_read_obj (st_parameter_dt *dtp, namelist_info *nl,
index_type offset,
!(dtp->common.flags & IOPARM_HAS_IOSTAT))
{
char message[IOMSG_LEN + 1];
- child_iomsg_len = string_len_trim (IOMSG_LEN, child_iomsg)
+ 1;
- snprintf (message, child_iomsg_len, child_iomsg);
+ child_iomsg_len = string_len_trim (IOMSG_LEN, child_iomsg);
+ fstrcpy (message, child_iomsg_len, child_iomsg,
child_iomsg_len);
+ message[child_iomsg_len] = '\0';
generate_error (>common, dtp->u.p.child_saved_iostat,
message);
goto nml_err_ret;
diff --git a/libgfortran/io/transfer.c b/libgfortran/io/transfer.c
index 9523a14c4bf..a86099d46f5 100644
--- a/libgfortran/io/transfer.c
+++ b/libgfortran/io/transfer.c
@@ -1128,8 +1128,9 @@ unformatted_read (st_parameter_dt *dtp, bt type,
!(dtp->common.flags & IOPARM_HAS_IOSTAT))
{
char message[IOMSG_LEN + 1];
- child_iomsg_len = string_len_trim (IOMSG_LEN, child_iomsg) + 1;
- snprintf (message, child_iomsg_len, child_iomsg);
+ child_iomsg_len = string_len_trim (IOMSG_LEN, child_iomsg);
+ fstrcpy (message, child_iomsg_len, child_iomsg, child_iomsg_len);
+ message[child_iomsg_len] = '\0';
generate_error (>common, dtp->u.p.child_saved_iostat,
[gcc r14-9328] Fortran: Add user defined error messages for UDTIO.
https://gcc.gnu.org/g:21edfb0051ed8d0ff46d5638c2bce2dd71f26d1f
commit r14-9328-g21edfb0051ed8d0ff46d5638c2bce2dd71f26d1f
Author: Jerry DeLisle
Date: Tue Mar 5 20:49:23 2024 -0800
Fortran: Add user defined error messages for UDTIO.
The defines IOMSG_LEN and MSGLEN were redundant so these are combined
into IOMSG_LEN as defined in io.h.
The remainder of the patch adds checks for when a user defined
derived type IO procedure sets the IOSTAT or IOMSG variables
independent of the librrary defined I/O messages.
PR libfortran/105456
libgfortran/ChangeLog:
* io/io.h (IOMSG_LEN): Moved to here.
* io/list_read.c (MSGLEN): Removed MSGLEN.
(convert_integer): Changed MSGLEN to IOMSG_LEN.
(parse_repeat): Likewise.
(read_logical): Likewise.
(read_integer): Likewise.
(read_character): Likewise.
(parse_real): Likewise.
(read_complex): Likewise.
(read_real): Likewise.
(check_type): Likewise.
(list_formatted_read_scalar): Adjust to IOMSG_LEN.
(nml_read_obj): Add user defined error message.
* io/transfer.c (unformatted_read): Add user defined error
message.
(unformatted_write): Add user defined error message.
(formatted_transfer_scalar_read): Add user defined error message.
(formatted_transfer_scalar_write): Add user defined error message.
* io/write.c (list_formatted_write_scalar): Add user defined error
message.
(nml_write_obj): Add user defined error message.
gcc/testsuite/ChangeLog:
* gfortran.dg/pr105456-nmlr.f90: New test.
* gfortran.dg/pr105456-nmlw.f90: New test.
* gfortran.dg/pr105456-ruf.f90: New test.
* gfortran.dg/pr105456-wf.f90: New test.
* gfortran.dg/pr105456-wuf.f90: New test.
Diff:
---
gcc/testsuite/gfortran.dg/pr105456-nmlr.f90 | 60 +
gcc/testsuite/gfortran.dg/pr105456-nmlw.f90 | 60 +
gcc/testsuite/gfortran.dg/pr105456-ruf.f90 | 36 +
gcc/testsuite/gfortran.dg/pr105456-wf.f90 | 34
gcc/testsuite/gfortran.dg/pr105456-wuf.f90 | 34
libgfortran/io/io.h | 7 ++-
libgfortran/io/list_read.c | 81 +++--
libgfortran/io/transfer.c | 49 +
libgfortran/io/write.c | 26 +
9 files changed, 343 insertions(+), 44 deletions(-)
diff --git a/gcc/testsuite/gfortran.dg/pr105456-nmlr.f90
b/gcc/testsuite/gfortran.dg/pr105456-nmlr.f90
new file mode 100644
index 000..5ce5d082133
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr105456-nmlr.f90
@@ -0,0 +1,60 @@
+! { dg-do run }
+! { dg-shouldfail "The users message" }
+module m
+ implicit none
+ type :: t
+character :: c
+integer :: k
+ contains
+procedure :: write_formatted
+generic :: write(formatted) => write_formatted
+procedure :: read_formatted
+generic :: read(formatted) => read_formatted
+ end type
+contains
+ subroutine write_formatted(dtv, unit, iotype, v_list, iostat, iomsg)
+class(t), intent(in) :: dtv
+integer, intent(in) :: unit
+character(*), intent(in) :: iotype
+integer, intent(in) :: v_list(:)
+integer, intent(out) :: iostat
+character(*), intent(inout) :: iomsg
+if (iotype.eq."NAMELIST") then
+ write (unit, '(a1,a1,i3)') dtv%c,',', dtv%k
+else
+ write (unit,*) dtv%c, dtv%k
+end if
+ end subroutine
+ subroutine read_formatted(dtv, unit, iotype, v_list, iostat, iomsg)
+class(t), intent(inout) :: dtv
+integer, intent(in) :: unit
+character(*), intent(in) :: iotype
+integer, intent(in) :: v_list(:)
+integer, intent(out) :: iostat
+character(*), intent(inout) :: iomsg
+character :: comma
+if (iotype.eq."NAMELIST") then
+ read (unit, '(a1,a1,i3)') dtv%c, comma, dtv%k
+else
+ read (unit,*) dtv%c, comma, dtv%k
+endif
+iostat = 42
+iomsg = "The users message"
+if (comma /= ',') STOP 1
+ end subroutine
+end module
+
+program p
+ use m
+ implicit none
+ character(len=50) :: buffer
+ type(t) :: x
+ namelist /nml/ x
+ x = t('a', 5)
+ write (buffer, nml)
+ if (buffer.ne.' X=a, 5 /') STOP 1
+ x = t('x', 0)
+ read (buffer, nml)
+ if (x%c.ne.'a'.or. x%k.ne.5) STOP 2
+end
+! { dg-output "Fortran runtime error: The users message" }
diff --git a/gcc/testsuite/gfortran.dg/pr105456-nmlw.f90
b/gcc/testsuite/gfortran.dg/pr105456-nmlw.f90
new file mode 100644
index 000..2c496e611f4
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr105456-nmlw.f90
@@ -0,0 +1,60 @@
+! { dg-do run }
+! { dg-shouldfail "The users message" }
+module m
+ implicit none
+ type ::
Re: [patch, libgfortran] Part 2: PR105456 Child I/O does not propage iostat
On 3/5/24 1:51 PM, Harald Anlauf wrote: Hi Jerry, on further thought, do we sanitize 'child_iomsg'? We pass it to snprintf as format. Wouldn't a strncpy be sufficient? Harald Just to be safe I will bump char message[IOMSG_LEN] to char message[IOMSG_LEN + 1] This is like a C string vs a Fortran string length situation. snprintf guarantees we don't exceed the child_iomsg_len and null terminates it. I added 1 to: child_iomsg_len = string_len_trim (IOMSG_LEN, child_iomsg) + 1 Because snprintf was chopping off the last character of the fortran string to put the null in. (zero based vs one based char array). I test this with a very long string which exceeded the length and then reduced it until I could see the desired end. I have not tried running a test case with sanitize. I did check with valgrind. I will try the sanitize flags to see if we get a problem. If not will push. Thanks for comments, Jerry - On 3/5/24 22:37, Harald Anlauf wrote: Hi Jerry, I think there is the risk of buffer overrun in the following places: + char message[IOMSG_LEN]; + child_iomsg_len = string_len_trim (IOMSG_LEN, child_iomsg) + 1; free_line (dtp); snprintf (message, child_iomsg_len, child_iomsg); generate_error (>common, dtp->u.p.child_saved_iostat, plus several more. Wouldn't it be better to increase the size of message by one? Thanks, Harald On 3/5/24 04:15, Jerry D wrote: On 3/1/24 11:24 AM, rep.dot@gmail.com wrote: Hi Jerry and Steve, On 29 February 2024 19:28:19 CET, Jerry D wrote: On 2/29/24 10:13 AM, Steve Kargl wrote: On Thu, Feb 29, 2024 at 09:36:43AM -0800, Jerry D wrote: On 2/29/24 1:47 AM, Bernhard Reutner-Fischer wrote: And, just for my own education, the length limitation of iomsg to 255 chars is not backed by the standard AFAICS, right? It's just our STRERR_MAXSZ? Yes, its what we have had for a long lone time. Once you throw an error things get very processor dependent. I found MSGLEN set to 100 and IOMSG_len to 256. Nothing magic about it. There is no restriction on the length for the iomsg-variable that receives the generated error message. In fact, if the iomsg-variable has a deferred-length type parameter, then (re)-allocation to the exact length is expected. F2023 12.11.6 IOMSG= specifier If an error, end-of-file, or end-of-record condition occurs during execution of an input/output statement, iomsg-variable is assigned an explanatory message, as if by intrinsic assignment. If no such condition occurs, the definition status and value of iomsg-variable are unchanged. character(len=23) emsg read(fd,*,iomsg=emsg) Here, the generated iomsg is either truncated to a length of 23 or padded with blanks to a length of 23. character(len=:), allocatable :: emsg read(fd,*,iomsg=emsg) Here, emsg should have the length of whatever error message was generated. HTH Well, currently, if someone uses a larger string than 256 we are going to chop it off. Do we want to process this differently now? Yes. There is some odd hunk about discrepancy of passed len and actual len afterwards in 22-007-r1, IIRC. Didn't look closely though. --- snip --- Attached is the revised patch using the already available string_len_trim function. This hunk is only executed if a user has not passed an iostat or iomsg variable in the parent I/O statement and an error is triggered which terminates execution of the program. In this case, the iomsg string is provided in the usual error message in a "processor defined" way. (F2023): 12.6.4.8.3 Executing defined input/output data transfers --- 11 If the iostat argument of the defined input/output procedure has a nonzero value when that procedure returns, and the processor therefore terminates execution of the program as described in 12.11, the processor shall make the value of the iomsg argument available in a processor-dependent manner. --- OK for trunk? Regards, Jerry
Re: [patch, libgfortran] Part 2: PR105456 Child I/O does not propage iostat
On 3/1/24 11:24 AM, rep.dot@gmail.com wrote:
Hi Jerry and Steve,
On 29 February 2024 19:28:19 CET, Jerry D wrote:
On 2/29/24 10:13 AM, Steve Kargl wrote:
On Thu, Feb 29, 2024 at 09:36:43AM -0800, Jerry D wrote:
On 2/29/24 1:47 AM, Bernhard Reutner-Fischer wrote:
And, just for my own education, the length limitation of iomsg to 255
chars is not backed by the standard AFAICS, right? It's just our
STRERR_MAXSZ?
Yes, its what we have had for a long lone time. Once you throw an error
things get very processor dependent. I found MSGLEN set to 100 and IOMSG_len
to 256. Nothing magic about it.
There is no restriction on the length for the iomsg-variable
that receives the generated error message. In fact, if the
iomsg-variable has a deferred-length type parameter, then
(re)-allocation to the exact length is expected.
F2023
12.11.6 IOMSG= specifier
If an error, end-of-file, or end-of-record condition occurs during
execution of an input/output statement, iomsg-variable is assigned
an explanatory message, as if by intrinsic assignment. If no such
condition occurs, the definition status and value of iomsg-variable
are unchanged.
character(len=23) emsg
read(fd,*,iomsg=emsg)
Here, the generated iomsg is either truncated to a length of 23
or padded with blanks to a length of 23.
character(len=:), allocatable :: emsg
read(fd,*,iomsg=emsg)
Here, emsg should have the length of whatever error message was
generated.
HTH
Well, currently, if someone uses a larger string than 256 we are going to chop
it off.
Do we want to process this differently now?
Yes. There is some odd hunk about discrepancy of passed len and actual len
afterwards in 22-007-r1, IIRC. Didn't look closely though.
--- snip ---
Attached is the revised patch using the already available
string_len_trim function.
This hunk is only executed if a user has not passed an iostat or iomsg
variable in the parent I/O statement and an error is triggered which
terminates execution of the program. In this case, the iomsg string is
provided in the usual error message in a "processor defined" way.
(F2023):
12.6.4.8.3 Executing defined input/output data transfers
---
11 If the iostat argument of the defined input/output procedure has a
nonzero value when that procedure returns, and the processor therefore
terminates execution of the program as described in 12.11, the processor
shall make the value of the iomsg argument available in a
processor-dependent manner.
---
OK for trunk?
Regards,
Jerry
commit 51a24ace512e96b425bcde46c056e816c4606784
Author: Jerry DeLisle
Date: Mon Mar 4 18:45:49 2024 -0800
Fortran: Add user defined error messages for UDTIO.
The defines IOMSG_LEN and MSGLEN were redundant so these are combined
into IOMSG_LEN as defined in io.h.
The remainder of the patch adds checks for when a user defined
derived type IO procedure sets the IOSTAT or IOMSG variables
independent of the librrary defined I/O messages.
PR libfortran/105456
libgfortran/ChangeLog:
* io/io.h (IOMSG_LEN): Moved to here.
* io/list_read.c (MSGLEN): Removed MSGLEN.
(convert_integer): Changed MSGLEN to IOMSG_LEN.
(parse_repeat): Likewise.
(read_logical): Likewise.
(read_integer): Likewise.
(read_character): Likewise.
(parse_real): Likewise.
(read_complex): Likewise.
(read_real): Likewise.
(check_type): Likewise.
(list_formatted_read_scalar): Adjust to IOMSG_LEN.
(nml_read_obj): Add user defined error message.
* io/transfer.c (unformatted_read): Add user defined error
message.
(unformatted_write): Add user defined error message.
(formatted_transfer_scalar_read): Add user defined error message.
(formatted_transfer_scalar_write): Add user defined error message.
* io/write.c (list_formatted_write_scalar): Add user defined error message.
(nml_write_obj): Add user defined error message.
gcc/testsuite/ChangeLog:
* gfortran.dg/pr105456-nmlr.f90: New test.
* gfortran.dg/pr105456-nmlw.f90: New test.
* gfortran.dg/pr105456-ruf.f90: New test.
* gfortran.dg/pr105456-wf.f90: New test.
* gfortran.dg/pr105456-wuf.f90: New test.
diff --git a/gcc/testsuite/gfortran.dg/pr105456-nmlr.f90 b/gcc/testsuite/gfortran.dg/pr105456-nmlr.f90
new file mode 100644
index 000..5ce5d082133
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr105456-nmlr.f90
@@ -0,0 +1,60 @@
+! { dg-do run }
+! { dg-shouldfail "The users message" }
+module m
+ implicit none
+ type :: t
+character :: c
+integer :: k
+ contains
+procedure :: write_formatted
+generic :: write(formatted) => write_formatted
+procedure :: read_formatted
+ge
Re: [PATCH] Fortran: improve checks of NULL without MOLD as actual argument [PR104819]
On 2/29/24 12:56 PM, Harald Anlauf wrote: Dear all, here's a first patch addressing issues with NULL as actual argument: if the dummy is assumed-rank or assumed length, MOLD shall be present. There is also an interp on interoperability of c_sizeof and NULL pointers, for which we have a partially incorrect testcase (gfortran.dg/pr101329.f90) which gets fixed. See https://j3-fortran.org/doc/year/22/22-101r1.txt for more. Furthermore, nested NULL()s are now handled. Regtested on x86_64-pc-linux-gnu. OK for mainline? I consider this part as safe and would like to backport to 13-branch. Objections? Thanks, Harald Looks good to me. I think backport is OK as well. Jerry -
Re: [patch, libgfortran] Part 2: PR105456 Child I/O does not propage iostat
On 2/29/24 1:47 AM, Bernhard Reutner-Fischer wrote: On Wed, 28 Feb 2024 21:29:06 -0800 Jerry D wrote: The attached patch adds the error checks similar to the first patch previously committed. I noticed a redundancy in some defines MSGLEN and IOMSG_LEN so I consolidated this to one define in io.h. This is just cleanup stuff. I have added test cases for each of the places where UDTIO is done in the library. Regressions tested on x86_64. OK for trunk? I think the commit hooks will complain about several missing spaces before open brace; See contrib/check_GNU_style.py /tmp/pr105456-3.diff I was given the OK from git gcc-verify. Regardless if hooks fail I just fix and try again. Would it make sense to introduce and use an internal helper like trim()? Or would it be possible to trim the message in generate_error_common()? I was debating this and what would be the best approach. I was not sure where to put it. I like the idea of doing in the generate_error_common. I will try that and see how it plays. And, just for my own education, the length limitation of iomsg to 255 chars is not backed by the standard AFAICS, right? It's just our STRERR_MAXSZ? Yes, its what we have had for a long lone time. Once you throw an error things get very processor dependent. I found MSGLEN set to 100 and IOMSG_len to 256. Nothing magic about it. I appreciate the comments. --- snip --- Jerry -
[patch, libgfortran] Part 2: PR105456 Child I/O does not propage iostat
The attached patch adds the error checks similar to the first patch
previously committed.
I noticed a redundancy in some defines MSGLEN and IOMSG_LEN so I
consolidated this to one define in io.h. This is just cleanup stuff.
I have added test cases for each of the places where UDTIO is done in
the library.
Regressions tested on x86_64.
OK for trunk?
Regards,
Jerry
commit 640991bd6b83df4197b2eaec63d1e0e695e48b75
Author: Jerry DeLisle
Date: Wed Feb 28 20:51:06 2024 -0800
Fortran: Add user defined error messages for UDTIO.
The defines IOMSG_LEN and MSGLEN were redundant so these are combined
into IOMSG_LEN as defined in io.h.
The remainder of the patch adds checks for when a user defined
derived type IO procedure sets the IOSTAT or IOMSG variables
independent of the librrary defined I/O messages.
PR libfortran/105456
libgfortran/ChangeLog:
* io/io.h (IOMSG_LEN): Moved to here.
* io/list_read.c (MSGLEN): Removed MSGLEN.
(convert_integer): Changed MSGLEN to IOMSG_LEN.
(parse_repeat): Likewise.
(read_logical): Likewise.
(read_integer): Likewise.
(read_character): Likewise.
(parse_real): Likewise.
(read_complex): Likewise.
(read_real): Likewise.
(check_type): Likewise.
(list_formatted_read_scalar): Adjust to IOMSG_LEN.
(nml_read_obj): Add user defined error message.
* io/transfer.c (unformatted_read): Add user defined error
message.
(unformatted_write): Add user defined error message.
(formatted_transfer_scalar_read): Add user defined error
message.
(formatted_transfer_scalar_write): Add user defined error
message.
* io/write.c (list_formatted_write_scalar): Add user
defined error message.
(nml_write_obj): Add user defined error message.
gcc/testsuite/ChangeLog:
* gfortran.dg/pr105456-nmlr.f90: New test.
* gfortran.dg/pr105456-nmlw.f90: New test.
* gfortran.dg/pr105456-ruf.f90: New test.
* gfortran.dg/pr105456-wf.f90: New test.
* gfortran.dg/pr105456-wuf.f90: New test.diff --git a/gcc/testsuite/gfortran.dg/pr105456-nmlr.f90 b/gcc/testsuite/gfortran.dg/pr105456-nmlr.f90
new file mode 100644
index 000..5ce5d082133
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr105456-nmlr.f90
@@ -0,0 +1,60 @@
+! { dg-do run }
+! { dg-shouldfail "The users message" }
+module m
+ implicit none
+ type :: t
+character :: c
+integer :: k
+ contains
+procedure :: write_formatted
+generic :: write(formatted) => write_formatted
+procedure :: read_formatted
+generic :: read(formatted) => read_formatted
+ end type
+contains
+ subroutine write_formatted(dtv, unit, iotype, v_list, iostat, iomsg)
+class(t), intent(in) :: dtv
+integer, intent(in) :: unit
+character(*), intent(in) :: iotype
+integer, intent(in) :: v_list(:)
+integer, intent(out) :: iostat
+character(*), intent(inout) :: iomsg
+if (iotype.eq."NAMELIST") then
+ write (unit, '(a1,a1,i3)') dtv%c,',', dtv%k
+else
+ write (unit,*) dtv%c, dtv%k
+end if
+ end subroutine
+ subroutine read_formatted(dtv, unit, iotype, v_list, iostat, iomsg)
+class(t), intent(inout) :: dtv
+integer, intent(in) :: unit
+character(*), intent(in) :: iotype
+integer, intent(in) :: v_list(:)
+integer, intent(out) :: iostat
+character(*), intent(inout) :: iomsg
+character :: comma
+if (iotype.eq."NAMELIST") then
+ read (unit, '(a1,a1,i3)') dtv%c, comma, dtv%k
+else
+ read (unit,*) dtv%c, comma, dtv%k
+endif
+iostat = 42
+iomsg = "The users message"
+if (comma /= ',') STOP 1
+ end subroutine
+end module
+
+program p
+ use m
+ implicit none
+ character(len=50) :: buffer
+ type(t) :: x
+ namelist /nml/ x
+ x = t('a', 5)
+ write (buffer, nml)
+ if (buffer.ne.' X=a, 5 /') STOP 1
+ x = t('x', 0)
+ read (buffer, nml)
+ if (x%c.ne.'a'.or. x%k.ne.5) STOP 2
+end
+! { dg-output "Fortran runtime error: The users message" }
diff --git a/gcc/testsuite/gfortran.dg/pr105456-nmlw.f90 b/gcc/testsuite/gfortran.dg/pr105456-nmlw.f90
new file mode 100644
index 000..2c496e611f4
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr105456-nmlw.f90
@@ -0,0 +1,60 @@
+! { dg-do run }
+! { dg-shouldfail "The users message" }
+module m
+ implicit none
+ type :: t
+character :: c
+integer :: k
+ contains
+procedure :: write_formatted
+generic :: write(formatted) => write_formatted
+procedure :: read_formatted
+generic :: read(formatted) => read_formatted
+ end type
+contains
+ subroutine write_formatted(dtv, unit, iotype, v_list, iostat, iomsg)
+class(t), intent(in) :: dtv
+integer, intent(in) :: unit
+
Re: [PATCH] Fortran testsuite: fix invalid Fortran in testcase
On 2/27/24 1:00 PM, Harald Anlauf wrote: Dear all, the attached patch fixes invalid Fortran in testcase gfortran.dg/pr101026.f, which might prohibit progress in fixing pr111781. (Note that the testcase was for a tree-optimizer issue, not the Fortran frontend.) OK for mainline? Will commit within 24h unless there are comments. Thanks, Harald OK, simple.
Re: [PATCH] Fortran: do not evaluate polymorphic functions twice in assignment [PR114012]
On 2/25/24 12:26 PM, Harald Anlauf wrote: Dear all, the attached simple patch fixes an issue where we evaluated polymorphic functions twice in assignments: once for the _data component, and once for the _vptr. Using save_expr prevents the double evaluation. Regtested on x86_64-pc-linux-gnu. OK for mainline? And a backport to 13-branch after some delay? Thanks, Harald Yes, simple enough. OK. Thanks, Jerry
Re: [patch, libgfortran] PR105456 Child I/O does not propage iostat
On 2/25/24 12:34 PM, Harald Anlauf wrote: Hi Jerry, On 2/22/24 20:11, Jerry D wrote: Hi all, The attached fix adds a check for an error condition from a UDDTIO procedure in the case where there is no actual underlying error, but the user defines an error by setting the iostat variable manually before returning to the parent READ. the libgfortran fix LGTM. Regarding the testcase code, the following looks like you left some debugging code in it: + rewind (10) + read (10,*) x + print *, myerror, mymessage + write (*,'(10(A))') "Read: '",x%ch,"'" --- snip --- I cleaned up the test case. Thanks for review. The master branch has been updated by Jerry DeLisle : https://gcc.gnu.org/g:3f58f96a4e8255e222953f9856bcd6c25f7b33cd Regards, Jerry
[patch, libgfortran] PR105456 Child I/O does not propage iostat
Hi all,
The attached fix adds a check for an error condition from a UDDTIO
procedure in the case where there is no actual underlying error, but the
user defines an error by setting the iostat variable manually before
returning to the parent READ.
I did not address the case of a formatted WRITE or unformatted
READ/WRITE until I get some feedback on the approach. If this approach
is OK I would like to commit and then do a separate patch for the cases
I just mentioned.
Feedback appreciated. Regression tested on x86_64. OK for trunk?
Jerry
Author: Jerry DeLisle
Date: Thu Feb 22 10:48:39 2024 -0800
libgfortran: Propagate user defined iostat and iomsg.
PR libfortran/105456
libgfortran/ChangeLog:
* io/list_read.c (list_formatted_read_scalar): Add checks
for the case where a user defines their own error codes
and error messages and generate the runtime error.
gcc/testsuite/ChangeLog:
* gfortran.dg/pr105456.f90: New test.diff --git a/gcc/testsuite/gfortran.dg/pr105456.f90 b/gcc/testsuite/gfortran.dg/pr105456.f90
new file mode 100644
index 000..411873f4aed
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr105456.f90
@@ -0,0 +1,41 @@
+! { dg-do run }
+! { dg-shouldfail "The users message" }
+module sk1
+ implicit none
+ type char
+ character :: ch
+ end type char
+ interface read (formatted)
+ module procedure read_formatted
+ end interface read (formatted)
+contains
+ subroutine read_formatted (dtv, unit, iotype, vlist, piostat, piomsg)
+class (char), intent(inout) :: dtv
+integer, intent(in) :: unit
+character (len=*), intent(in) :: iotype
+integer, intent(in) :: vlist(:)
+integer, intent(out) :: piostat
+character (len=*), intent(inout) :: piomsg
+character :: ch
+read (unit,fmt='(A1)', advance="no", iostat=piostat, iomsg=piomsg) ch
+piostat = 42
+piomsg="The users message"
+dtv%ch = ch
+ end subroutine read_formatted
+end module sk1
+
+program skip1
+ use sk1
+ implicit none
+ integer :: myerror = 0
+ character(64) :: mymessage = ""
+ type (char) :: x
+ open (10,status="scratch")
+ write (10,'(A)') '', 'a'
+ rewind (10)
+ read (10,*) x
+ print *, myerror, mymessage
+ write (*,'(10(A))') "Read: '",x%ch,"'"
+end program skip1
+! { dg-output ".*(unit = 10, file = .*)" }
+! { dg-output "Fortran runtime error: The users message" }
diff --git a/libgfortran/io/list_read.c b/libgfortran/io/list_read.c
index 3d29cb64813..ee3ab713519 100644
--- a/libgfortran/io/list_read.c
+++ b/libgfortran/io/list_read.c
@@ -2138,6 +2138,7 @@ static int
list_formatted_read_scalar (st_parameter_dt *dtp, bt type, void *p,
int kind, size_t size)
{
+ char message[MSGLEN];
gfc_char4_t *q, *r;
size_t m;
int c;
@@ -2247,7 +2248,7 @@ list_formatted_read_scalar (st_parameter_dt *dtp, bt type, void *p,
child_iostat = ((dtp->common.flags & IOPARM_HAS_IOSTAT)
? dtp->common.iostat : );
- /* Set iomsge, intent(inout). */
+ /* Set iomsg, intent(inout). */
if (dtp->common.flags & IOPARM_HAS_IOMSG)
{
child_iomsg = dtp->common.iomsg;
@@ -2266,6 +2267,25 @@ list_formatted_read_scalar (st_parameter_dt *dtp, bt type, void *p,
iotype_len, child_iomsg_len);
dtp->u.p.child_saved_iostat = *child_iostat;
dtp->u.p.current_unit->child_dtio--;
+
+
+ if ((dtp->u.p.child_saved_iostat != 0) &&
+ !(dtp->common.flags & IOPARM_HAS_IOMSG) &&
+ !(dtp->common.flags & IOPARM_HAS_IOSTAT))
+ {
+ /* Trim trailing spaces from the message. */
+ for(int i = IOMSG_LEN - 1; i > 0; i--)
+ if (!isspace(child_iomsg[i]))
+ {
+ /* Add two to get back to the end of child_iomsg. */
+ child_iomsg_len = i+2;
+ break;
+ }
+ free_line (dtp);
+ snprintf (message, child_iomsg_len, child_iomsg);
+ generate_error (>common, dtp->u.p.child_saved_iostat,
+ message);
+ }
}
break;
default:
Re: [PATCH] Fix fortran/PR114024
On 2/21/24 12:28 PM, Harald Anlauf wrote: On 2/21/24 20:41, Jerry D wrote: On 2/21/24 10:30 AM, Steve Kargl wrote: I have attached a patch to PR114024, see https://gcc.gnu.org/pipermail/gcc-bugs/2024-February/854651.html The patch contains a new testcase and passes regression testing on x86_64-*-freebsd. Could someone castr an eye over the patch and commit it? Hi Steve, I looked it over and looks reasonable. I will try to apply it next few days and test here. If OK, I will commit. Jerry Actually the patch has two issues: - a minor one: a new front-end memleak which can be avoided by using either gfc_replace_expr (see its other uses) Hint: try valgrind on f951 Yes, I am learning to do that. - it still fails on the following code, because the traversal of the refs is incomplete / wrong: program foo implicit none complex :: cmp(3) real, pointer :: pp(:) class(*), allocatable :: uu(:) type t real :: re real :: im end type t type u type(t) :: tt(3) end type u type(u) :: cc cmp = (3.45,6.78) cc% tt% re = cmp% re cc% tt% im = cmp% im allocate (pp, source = cc% tt% im) ! ICE print *, pp allocate (uu, source = cc% tt% im) ! ICE end This still crashes for me for the indicated cases. Harald Good catch. I will hold off until that is figured out. Jerry
Re: [PATCH] Fix fortran/PR114024
On 2/21/24 10:30 AM, Steve Kargl wrote: I have attached a patch to PR114024, see https://gcc.gnu.org/pipermail/gcc-bugs/2024-February/854651.html The patch contains a new testcase and passes regression testing on x86_64-*-freebsd. Could someone castr an eye over the patch and commit it? Hi Steve, I looked it over and looks reasonable. I will try to apply it next few days and test here. If OK, I will commit. Jerry
[patch, libgfortran] Bug 105473 - semicolon allowed when list-directed read integer with decimal='point'
Hello,
I posted the attached patch in bugzilla some time ago. This includes a
new test case. The patch adds additional checks in key places to catch
eroneous use of semicolons
Regression tested on x86_64,
OK for trunk and later backport to 13?
Jerrydiff --git a/gcc/testsuite/gfortran.dg/pr105473.f90 b/gcc/testsuite/gfortran.dg/pr105473.f90
new file mode 100644
index 000..b309217540d
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr105473.f90
@@ -0,0 +1,46 @@
+! { dg-do run }
+! PR libgfortran/105473
+ implicit none
+ integer n,m,ios
+ real r
+ complex z
+ character(40):: testinput
+ n = 999; m = 777; r=1.2345
+ z = cmplx(0.0,0.0)
+
+! Check that semi-colon is not allowed as separator with decimal=point.
+ ios=0
+ testinput = '1;17;3.14159'
+ read(testinput,*,decimal='point',iostat=ios) n, m, r
+ if (ios /= 5010) print *, "stop 1"
+
+! Check that comma is not allowed as a separator with decimal=comma.
+ ios=0
+ testinput = '1,17,3,14159'
+ read(testinput,*,decimal='comma',iostat=ios) n, m, r
+ if (ios /= 5010) print *, "stop 2"
+
+! Check a good read.
+ ios=99
+ testinput = '1;17;3,14159'
+ read(testinput,*,decimal='comma',iostat=ios) n, m, r
+ if (ios /= 0) print *, "stop 3"
+
+! Check that comma is not allowed as a separator with decimal=comma.
+ ios=99; z = cmplx(0.0,0.0)
+ testinput = '1,17, (3,14159, 1,7182)'
+ read(testinput,*,decimal='comma', iostat=ios) n, m, z
+ if (ios /= 5010) stop 4
+
+! Check that semi-colon is not allowed as separator with decimal=point.
+ ios=99; z = cmplx(0.0,0.0)
+ testinput = '1,17; (3.14159; 1.7182)'
+ read(testinput,*,decimal='point', iostat=ios) n, m, z
+ if (ios /= 5010) stop 5
+
+! Check a good read.
+ ios=99;z = cmplx(0.0,0.0)
+ testinput = '1;17; (3,14159; 1,7182)'
+ read(testinput,*,decimal='comma', iostat=ios) n, m, z
+ if (ios /= 0) stop 6
+end program
diff --git a/libgfortran/io/list_read.c b/libgfortran/io/list_read.c
index 0b7884fdda7..d2316ad6fe2 100644
--- a/libgfortran/io/list_read.c
+++ b/libgfortran/io/list_read.c
@@ -53,7 +53,6 @@ typedef unsigned char uchar;
#define CASE_SEPARATORS /* Fall through. */ \
case ' ': case ',': case '/': case '\n': \
case '\t': case '\r': case ';'
-
/* This macro assumes that we're operating on a variable. */
#define is_separator(c) (c == '/' || c == ',' || c == '\n' || c == ' ' \
@@ -475,11 +474,23 @@ eat_separator (st_parameter_dt *dtp)
case ',':
if (dtp->u.p.current_unit->decimal_status == DECIMAL_COMMA)
{
+ generate_error (>common, LIBERROR_READ_VALUE,
+ "Comma not allowed as separator with DECIMAL='comma'");
unget_char (dtp, c);
break;
}
- /* Fall through. */
+ dtp->u.p.comma_flag = 1;
+ eat_spaces (dtp);
+ break;
+
case ';':
+ if (dtp->u.p.current_unit->decimal_status == DECIMAL_POINT)
+ {
+ generate_error (>common, LIBERROR_READ_VALUE,
+ "Semicolon not allowed as separator with DECIMAL='point'");
+ unget_char (dtp, c);
+ break;
+ }
dtp->u.p.comma_flag = 1;
eat_spaces (dtp);
break;
@@ -1326,8 +1337,13 @@ parse_real (st_parameter_dt *dtp, void *buffer, int length)
{
if ((c = next_char (dtp)) == EOF)
goto bad;
- if (c == ',' && dtp->u.p.current_unit->decimal_status == DECIMAL_COMMA)
- c = '.';
+ if (dtp->u.p.current_unit->decimal_status == DECIMAL_COMMA)
+ {
+ if (c == '.')
+ goto bad;
+ if (c == ',')
+ c = '.';
+ }
switch (c)
{
CASE_DIGITS:
@@ -1636,8 +1652,18 @@ read_real (st_parameter_dt *dtp, void *dest, int length)
seen_dp = 0;
c = next_char (dtp);
- if (c == ',' && dtp->u.p.current_unit->decimal_status == DECIMAL_COMMA)
-c = '.';
+ if (dtp->u.p.current_unit->decimal_status == DECIMAL_COMMA)
+{
+ if (c == '.')
+ goto bad_real;
+ if (c == ',')
+ c = '.';
+}
+ if (dtp->u.p.current_unit->decimal_status == DECIMAL_POINT)
+{
+ if (c == ';')
+ goto bad_real;
+}
switch (c)
{
CASE_DIGITS:
@@ -1677,8 +1703,13 @@ read_real (st_parameter_dt *dtp, void *dest, int length)
for (;;)
{
c = next_char (dtp);
- if (c == ',' && dtp->u.p.current_unit->decimal_status == DECIMAL_COMMA)
- c = '.';
+ if (dtp->u.p.current_unit->decimal_status == DECIMAL_COMMA)
+ {
+ if (c == '.')
+ goto bad_real;
+ if (c == ',')
+ c = '.';
+ }
switch (c)
{
CASE_DIGITS:
@@ -1718,7 +1749,7 @@ read_real (st_parameter_dt *dtp, void *dest, int length)
CASE_SEPARATORS:
case EOF:
- if (c != '\n' && c != ',' && c != '\r' && c != ';')
+ if (c != '\n' && c != ',' && c != ';' && c != '\r')
unget_char (dtp, c);
goto done;
diff --git a/libgfortran/io/read.c b/libgfortran/io/read.c
index e2d2f8be806..7a9e341d7d8 100644
--- a/libgfortran/io/read.c
+++ b/libgfortran/io/read.c
@@ -1062,8 +1062,17 @@ read_f (st_parameter_dt *dtp, const fnode *f, char *dest, int length)
case ',':
if (dtp->u.p.current_unit->decimal_status != DECIMAL_COMMA)
[patch, libgfortran] PR107068 Run-time error when reading logical arrays with a namelist
The attached patch fixes this one. Se the ChangeLog below for explanation.
OK for trunk?
I think simple enough to backport to 13 as well.
Regards,
Jerry
Author: Jerry DeLisle
Date: Fri Feb 16 17:06:37 2024 -0800
libgfortran: Fix namelist read.
PR libgfortran/107068
libgfortran/ChangeLog:
* io/list_read.c (read_logical): When looking for a possible
variable name, check for left paren, indicating a possible
array reference.
gcc/testsuite/ChangeLog:
* gfortran.dg/pr107068.f90: New test.
diff --git a/gcc/testsuite/gfortran.dg/pr107068.f90 b/gcc/testsuite/gfortran.dg/pr107068.f90
new file mode 100644
index 000..c5ea0c1d244
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr107068.f90
@@ -0,0 +1,22 @@
+! { dg-do run }
+program test
+ implicit none
+ integer :: error
+ logical, dimension(3,3) :: flc,flp
+ namelist/inputdata/flc, flp
+
+ flc = .false.
+ flp = .false.
+
+ open(10, file="inputfile")
+ write(10,*) ""
+ write(10,*) " FLC = T, "
+ write(10,*) " FLP(1,2) = T,"
+ write(10,*) "/"
+ rewind(10)
+ !write(*, nml=inputdata)
+ !open(10,file="inputfile")
+ read(10,inputdata,iostat=error)
+ close(10, status='delete')
+ if (error /= 0) stop 20
+end program test
diff --git a/libgfortran/io/list_read.c b/libgfortran/io/list_read.c
index f8ca64422de..0b7884fdda7 100644
--- a/libgfortran/io/list_read.c
+++ b/libgfortran/io/list_read.c
@@ -888,6 +888,14 @@ read_logical (st_parameter_dt *dtp, int length)
for(i = 0; i < 63; i++)
{
c = next_char (dtp);
+ if (c == '(')
+ {
+ l_push_char (dtp, c);
+ dtp->u.p.nml_read_error = 1;
+ dtp->u.p.line_buffer_enabled = 1;
+ dtp->u.p.line_buffer_pos = 0;
+ return;
+ }
if (is_separator(c))
{
/* All done if this is not a namelist read. */
Re: [PATCH] Fortran: deferred length of character variables shall not get lost [PR113911]
On 2/16/24 1:40 PM, Harald Anlauf wrote: Dear all, this patch fixes a regression which was a side-effect of r14-8947, losing the length of a deferred-length character variable when passed as a dummy. The new testcase provides a workout for deferred length to improve coverage in the testsuite. Another temporarily disabled test was re-enabled. Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald Yes OK for mainline. Thanks, Jerry
[patch, fortran] Bug 105847 - namelist-object-name can be a renamed host associated entity
Pushed as simple and obvious. Regards, Jerry commit 8221201cc59870579b9dc451b173f94b8d8b0993 (HEAD -> master, origin/master, origin/HEAD) Author: Steve Kargl Date: Wed Feb 14 14:40:16 2024 -0800 Fortran: namelist-object-name renaming. PR fortran/105847 gcc/fortran/ChangeLog: * trans-io.cc (transfer_namelist_element): When building the namelist object name, if the use rename attribute is set, use the local name specified in the use statement. gcc/testsuite/ChangeLog: * gfortran.dg/pr105847.f90: New test.
[patch, libgfortran] PR99210 X editing for reading file with encoding='utf-8'
The attached patch fixes the X editing.
Fairly self explanatory. I created the patch a few years back.
Regression tested on x86_64 and new test case.
OK for trunk?
Regards,
Jerrydiff --git a/gcc/testsuite/gfortran.dg/pr99210.f90 b/gcc/testsuite/gfortran.dg/pr99210.f90
new file mode 100644
index 000..9fd2fb468df
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr99210.f90
@@ -0,0 +1,29 @@
+! { dg-do run }
+! PR99210 X editing for reading file with encoding='utf-8'
+program test_bug_format_x
+ use iso_fortran_env
+ integer, parameter :: u = selected_char_kind('ISO_10646')
+
+ character(kind=u, len=1) a, b, a1, b1, b2
+
+ open(unit=10, file='test_bug_format_x.tmp', encoding='UTF-8')
+
+ a = char(int(z'03B1'), u)
+ b = char(int(z'03B2'), u)
+ write(10, '(a1, a1)') a, b
+
+ rewind(10)
+ read(10, '(a1, a1)') a1, b1
+
+ rewind(10)
+ read(10, '(1x, a1)') b2
+
+ close (10, status="delete")
+ if(a /= a1 .or. b /= b1) then
+error stop 1
+ end if
+
+ if(b /= b2) then
+error stop 2
+ end if
+end program test_bug_format_x
diff --git a/libgfortran/io/read.c b/libgfortran/io/read.c
index 0ffcf76fd38..e2d2f8be806 100644
--- a/libgfortran/io/read.c
+++ b/libgfortran/io/read.c
@@ -1307,6 +1307,23 @@ read_x (st_parameter_dt *dtp, size_t n)
if (n == 0)
return;
+
+ if (dtp->u.p.current_unit->flags.encoding == ENCODING_UTF8)
+{
+ gfc_char4_t c;
+ size_t nbytes, j;
+
+ /* Proceed with decoding one character at a time. */
+ for (j = 0; j < n; j++)
+ {
+ c = read_utf8 (dtp, );
+
+ /* Check for a short read and if so, break out. */
+ if (nbytes == 0 || c == (gfc_char4_t)0)
+ break;
+ }
+ return;
+}
length = n;
[patch, libgfortran] PR109358
The attached patch fixes this PR by properly adjusting some variables
When using stream io. See log below. New test case included.
Regression tested on x86_64.
OK for trunk and backport?
Regards,
Jerry
ChangeLog:
libgfortran: Adjust bytes_left and pos for access="STREAM".
During tab edits, the pos (position) and bytes_used
Variables were not being set correctly for stream I/O.
Since stream I/O does not have 'real' records, the
format buffer active length must be used instead of
the record length variable.
libgfortran/ChangeLog:
PR libgfortran/109358
* io/transfer.c (formatted_transfer_scalar_write): Adjust
bytes_used and pos variable for stream access.
gcc/testsuite/ChangeLog:
PR libgfortran/109358
* gfortran.dg/pr109358.f90: New test.
diff --git a/gcc/testsuite/gfortran.dg/pr109358.f90 b/gcc/testsuite/gfortran.dg/pr109358.f90
new file mode 100644
index 000..5013984095b
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr109358.f90
@@ -0,0 +1,14 @@
+! { dg-do run }
+! PR109358, test that tabs during stream io are correct.
+program tabs
+ implicit none
+ integer :: fd
+ character(64) :: line
+ open(newunit=fd, file="otabs.txt", form="formatted", access="stream")
+ write(fd, "(i4, t40, i4, t20, i5.5)") 1234, , 67890
+ close(fd)
+ open(newunit=fd, file="otabs.txt", form="formatted")
+ read(fd,"(a)") line
+ close(fd, status='delete')
+ if (line .ne. "1234 67890 ") stop 10
+end program tabs
diff --git a/libgfortran/io/transfer.c b/libgfortran/io/transfer.c
index 80b60dfeb9f..99ef96a9e7c 100644
--- a/libgfortran/io/transfer.c
+++ b/libgfortran/io/transfer.c
@@ -2072,11 +2072,11 @@ formatted_transfer_scalar_write (st_parameter_dt *dtp, bt type, void *p, int kin
dtp->u.p.skips = dtp->u.p.pending_spaces = 0;
}
- bytes_used = dtp->u.p.current_unit->recl
- - dtp->u.p.current_unit->bytes_left;
-
if (is_stream_io(dtp))
- bytes_used = 0;
+ bytes_used = dtp->u.p.current_unit->fbuf->act;
+ else
+ bytes_used = dtp->u.p.current_unit->recl
+ - dtp->u.p.current_unit->bytes_left;
switch (t)
{
@@ -2452,7 +2452,11 @@ formatted_transfer_scalar_write (st_parameter_dt *dtp, bt type, void *p, int kin
p = ((char *) p) + size;
}
- pos = dtp->u.p.current_unit->recl - dtp->u.p.current_unit->bytes_left;
+ if (is_stream_io(dtp))
+ pos = dtp->u.p.current_unit->fbuf->act;
+ else
+ pos = dtp->u.p.current_unit->recl - dtp->u.p.current_unit->bytes_left;
+
dtp->u.p.max_pos = (dtp->u.p.max_pos > pos) ? dtp->u.p.max_pos : pos;
}
Re: [PATCH] Fortran: error recovery on arithmetic overflow on unary operations [PR113799]
On 2/8/24 1:03 PM, Harald Anlauf wrote: Dear all, the attached patch improves error recovery when we encounter an array constructor where a unary operator (e.g. minus) is applied and -frange-check is active. The solution is not to terminate early in that case to avoid inconsistencies between check_result and reduce_unary when such a situation occurs. (There might be similar issues for binary operators, not treated here.) Regtested on x86_64-pc-linux-gnu. OK for mainline? The ICE/memory corruption is actually a 10+ regression. Do we need a backport? Thanks, Harald Hi Harald, This patch looks OK. Thanks, Jerry
Re: [patch, libgfortran] PR111022 ES0.0E0 format gave ES0.dE0 output with d too high.
On 1/30/24 12:36 PM, Harald Anlauf wrote:
Hi Jerry,
Am 30.01.24 um 19:15 schrieb Jerry D:
The attached patch attempts to fix the handling of the EN0.0E0 and
ES0.0E0 formatting by correctly calculating the number of digits needed
for the exponents and building those exponents into the float string.
while your patch addresses ENw.dE0 and ESw.dE0 formatting,
it does not fix Ew.dE0, which can be seen with the following test:
write(buffer,"(E0.3E0)") .6660_4
print *, buffer
write(buffer,"(E0.3)") .6660_4
print *, buffer
I get even with your patch:
0.666
0.666
but would have expected:
0.666E+0 ! F2018 & F2023, table 13.1
0.666E+0 ! F2023, table 13.1
Tha attached file shows the complete revised patch and git log generated
by using the 'git show' command. I only just discovered that one. (eye
roll).
Regressions tested on x86-64. OK for trunk?
Regards,
Jerry
commit 95c878a97944f952aef226ff0224b2198abfbe0f
Author: Jerry DeLisle
Date: Fri Feb 2 18:12:33 2024 -0800
libgfortran: EN0.0E0 and ES0.0E0 format editing.
PR libgfortran/111022
F2018 and F2023 standards added zero width exponents. This required
additional special handing in the process of building formatted
floating point strings.
G formatting uses either F or E formatting as documented in
write_float.def comments. This logic changes the format token from FMT_G
to FMT_F or FMT_E. The new formatting requirements interfere with this
process when a FMT_G float string is being built. To avoid this, a new
component called 'pushed' is added to the fnode structure to save this
condition. The 'pushed' condition is then used to bypass portions of
the new ES,E,EN, and D formatting, falling through to the existing
default formatting which is retained.
libgfortran/ChangeLog:
* io/format.c (get_fnode): Update initialization of fnode.
(parse_format_list): Initialization.
* io/format.h (struct fnode): Added the new 'pushed' component.
* io/write.c (select_buffer): Whitespace.
(write_real): Whitespace.
(write_real_w0): Adjust logic for the d == 0 condition.
* io/write_float.def (determine_precision): Whitespace.
(build_float_string): Calculate width of ..E0 exponents and
adjust logic accordingly.
(build_infnan_string): Whitespace.
(CALCULATE_EXP): Whitespace.
(quadmath_snprintf): Whitespace.
(determine_en_precision): Whitespace.
gcc/testsuite/ChangeLog:
* gfortran.dg/fmt_error_10.f: Show D+0 exponent.
* gfortran.dg/pr96436_4.f90: Show E+0 exponent.
* gfortran.dg/pr96436_5.f90: Show E+0 exponent.
* gfortran.dg/pr111022.f90: New test.
diff --git a/gcc/testsuite/gfortran.dg/fmt_error_10.f b/gcc/testsuite/gfortran.dg/fmt_error_10.f
index 6e1a5f60bea..fc6620a60a6 100644
--- a/gcc/testsuite/gfortran.dg/fmt_error_10.f
+++ b/gcc/testsuite/gfortran.dg/fmt_error_10.f
@@ -18,7 +18,7 @@
str = '(1pd0.15)'
write (line,str,iostat=istat, iomsg=msg) 1.0d0
- if (line.ne."1.000") STOP 5
+ if (line.ne."1.000D+0") STOP 5
read (*,str,iostat=istat, iomsg=msg) x
if (istat.ne.5006 .or. msg(1:10).ne."Zero width") STOP 6
if (x.ne.555.25) STOP 7
diff --git a/gcc/testsuite/gfortran.dg/pr111022.f90 b/gcc/testsuite/gfortran.dg/pr111022.f90
new file mode 100644
index 000..eef55ff5ce0
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr111022.f90
@@ -0,0 +1,72 @@
+! { dg-do run }
+program pr111022
+ character(20) :: buffer
+ write(buffer,"(EN0.3E0)") .6660_4
+ if (buffer.ne."666.000E-3") stop 1
+ write(buffer,"(EN0.3E0)") 6.660_4
+ if (buffer.ne."6.660E+0") stop 2
+ write(buffer,"(EN0.3E0)") 66.60_4
+ if (buffer.ne."66.600E+0") stop 3
+ write(buffer,"(EN0.3E0)") 666.0_4
+ if (buffer.ne."666.000E+0") stop 4
+ write(buffer,"(EN0.3E0)") 6660.0_4
+ if (buffer.ne."6.660E+3") stop 5
+ write(buffer,"(EN0.3E0)") 66600.0_4
+ if (buffer.ne."66.600E+3") stop 6
+
+ write(buffer,"(EN0.0E0)") 666.0_4
+ if (buffer.ne."666.E+0") stop 7
+ write(buffer,"(EN0.0E1)") 666.0_4
+ if (buffer.ne."666.E+0") stop 8
+ write(buffer,"(EN0.0E2)") 666.0_4
+ if (buffer.ne."666.E+00") stop 9
+ write(buffer,"(EN0.0E3)") 666.0_4
+ if (buffer.ne."666.E+000") stop 10
+ write(buffer,"(EN0.0E4)") 666.0_4
+ if (buffer.ne."666.E+") stop 11
+ write(buffer,"(EN0.0E5)") 666.0_4
+ if (buffer.ne."666.E+0") stop 12
+ write(buffer,"(EN0.0E6)") 666.0_4
+ if (buffer.ne."666.E+00") st
[patch, libgfortran] PR111022 ES0.0E0 format gave ES0.dE0 output with d too high.
The attached patch attempts to fix the handling of the EN0.0E0 and
ES0.0E0 formatting by correctly calculating the number of digits needed
for the exponents and building those exponents into the float string.
My editor judiciously deleted trailing blank spaces in a number of
places. I apologize for the clutter, but we might as well get rid of it
now.
Two existing test cases needed to be adjusted and I am adding one new
test case to capture the changes in our testsuite.
Regression tested on X86_64.
OK for trunk? Do we need to backport this?
Regards,
Jerry
Author: Jerry DeLisle
Date: Tue Jan 30 09:45:49 2024 -0800
libgfortran: EN0.0E0 and ES0.0E0 format editing.
PR libgfortran/111022
F2018 and F2023 standards added zero width exponents. This required
additional special handing in the process of building formatted
floating point strings.
libgfortran/ChangeLog:
* io/write.c (select_buffer): Whitespace.
(write_real): Whitespace.
(write_real_w0): Adjust logic for d==0.
* io/write_float.def (determine_precision): Whitespace.
(build_float_string): Calculate the width of the E0 exponents.
(build_infnan_string): Whitespace.
(CALCULATE_EXP): Whitespace
(quadmath_snprintf): Whitespace.
(determine_en_precision): Whitespace.
gcc/testsuite/ChangeLog:
* gfortran.dg/pr96436_4.f90: Changed for ES0 and EN0.
* gfortran.dg/pr96436_5.f90: Changed for ES0 and EN0.
* gfortran.dg/pr111022.f90: New test.
diff --git a/gcc/testsuite/gfortran.dg/pr111022.f90 b/gcc/testsuite/gfortran.dg/pr111022.f90
new file mode 100644
index 000..d7e8edf2d19
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr111022.f90
@@ -0,0 +1,60 @@
+! { dg-do run }
+program case2
+ character(20) :: buffer
+ write(buffer,"(EN0.3E0)") .6660_4
+ if (buffer.ne."666.000E-3") stop 1
+ write(buffer,"(EN0.3E0)") 6.660_4
+ if (buffer.ne."6.660E+0") stop 2
+ write(buffer,"(EN0.3E0)") 66.60_4
+ if (buffer.ne."66.600E+0") stop 3
+ write(buffer,"(EN0.3E0)") 666.0_4
+ if (buffer.ne."666.000E+0") stop 4
+ write(buffer,"(EN0.3E0)") 6660.0_4
+ if (buffer.ne."6.660E+3") stop 5
+ write(buffer,"(EN0.3E0)") 66600.0_4
+ if (buffer.ne."66.600E+3") stop 6
+
+ write(buffer,"(EN0.0E0)") 666.0_4
+ if (buffer.ne."666.E+0") stop 7
+ write(buffer,"(EN0.0E1)") 666.0_4
+ if (buffer.ne."666.E+0") stop 8
+ write(buffer,"(EN0.0E2)") 666.0_4
+ if (buffer.ne."666.E+00") stop 9
+ write(buffer,"(EN0.0E3)") 666.0_4
+ if (buffer.ne."666.E+000") stop 10
+ write(buffer,"(EN0.0E4)") 666.0_4
+ if (buffer.ne."666.E+") stop 11
+ write(buffer,"(EN0.0E5)") 666.0_4
+ if (buffer.ne."666.E+0") stop 12
+ write(buffer,"(EN0.0E6)") 666.0_4
+ if (buffer.ne."666.E+00") stop 13
+
+ write(buffer,"(ES0.3E0)") .6660_4
+ if (buffer.ne."6.660E-1") stop 14
+ write(buffer,"(ES0.3E0)") 6.660_4
+ if (buffer.ne."6.660E+0") stop 15
+ write(buffer,"(ES0.3E0)") 66.60_4
+ if (buffer.ne."6.660E+1") stop 16
+ write(buffer,"(ES0.3E0)") 666.0_4
+ if (buffer.ne."6.660E+2") stop 17
+ write(buffer,"(ES0.3E0)") 6660.0_4
+ if (buffer.ne."6.660E+3") stop 18
+ write(buffer,"(ES0.3E0)") 66600.0_4
+ if (buffer.ne."6.660E+4") stop 19
+
+ write(buffer,"(ES0.0E0)") 666.0_4
+ if (buffer.ne."7.E+2") stop 20
+ write(buffer,"(ES0.0E1)") 666.0_4
+ if (buffer.ne."7.E+2") stop 21
+ write(buffer,"(ES0.0E2)") 666.0_4
+ if (buffer.ne."7.E+02") stop 22
+ write(buffer,"(ES0.0E3)") 666.0_4
+ if (buffer.ne."7.E+002") stop 23
+ write(buffer,"(ES0.0E4)") 666.0_4
+ if (buffer.ne."7.E+0002") stop 24
+ write(buffer,"(ES0.0E5)") 666.0_4
+ if (buffer.ne."7.E+2") stop 25
+ write(buffer,"(ES0.0E6)") 666.0_4
+ if (buffer.ne."7.E+02") stop 26
+
+end program case2
diff --git a/gcc/testsuite/gfortran.dg/pr96436_4.f90 b/gcc/testsuite/gfortran.dg/pr96436_4.f90
index 335ce5fb009..7d2cfef0ef8 100644
--- a/gcc/testsuite/gfortran.dg/pr96436_4.f90
+++ b/gcc/testsuite/gfortran.dg/pr96436_4.f90
@@ -17,9 +17,9 @@ write(buffer,fmt) ">", 3.0, "<"
if (buffer.ne.">0.30E+1<") stop 4
fmt = "(1a1,en0.2,1a1)"
write(buffer,fmt) ">", 3.0, "<"
-if (buffer.ne.">3.00<") stop 5
+if (buffer.ne.">3.00E+0<") stop 5
fmt = "(1a1,es0.2,1a1)"
write(buffer,fmt) ">", 3.0, &q
Re: PR82943 - Suggested patch to fix
On 1/20/24 12:08 PM, Harald Anlauf wrote: Am 20.01.24 um 20:08 schrieb Jerry D: On 1/20/24 10:46 AM, Alexander Westbrooks wrote: Hello and Happy New Year! I wanted to follow up on this patch I made to address PR82943 for GFortran. Has anyone had a chance to review it? Thanks, Alexander Westbrooks Inserting myself in here just a little bit. I will apply and test today if I can. Paul is unavailable for a few weeks. Harald can chime in. Do you have commit rights for gcc? I am not aware of Alex having a copyright assignment on file, or a DCO certificate, and the patch is not signed off. But I might be wrong. --- snip --- I do not mind committing this but need clarifications regarding the copyright (copyleft?) rules in this case. In the past we have allowed small contributions like this. This may be a little more than minor. Regardless it appears to do the job! Jerry
Re: PR82943 - Suggested patch to fix
On 1/20/24 11:08 AM, Jerry D wrote: On 1/20/24 10:46 AM, Alexander Westbrooks wrote: Hello and Happy New Year! I wanted to follow up on this patch I made to address PR82943 for GFortran. Has anyone had a chance to review it? Thanks, Alexander Westbrooks Inserting myself in here just a little bit. I will apply and test today if I can. Paul is unavailable for a few weeks. Harald can chime in. Do you have commit rights for gcc? Your efforts are appreciated. Regards, Jerry I did send you an invite to our Mattermost workspace. I did apply your patch. Some comments. The ChangeLog files are auto generated so do not get manually changed with a patch. The push process to the gcc git repository will generate those from the git commit log. If the git commit log is not formatted correctly the push will be rejected. The patch attempts to create a PDT_33.f03 test case. There is one already there so probably rename that one. In resolve.cc There was a compile error that looked like an extra '&&' in the conditional. I deleted that and all compiled ok and all regression tested OK, including your new test cases and the existing PDT_33.f03 case. I did not try your new test case yet for PDT_33. So next steps are walk you through using the git scripts to make commits with the logs formatted correctly. (assuming no one else chimes in with any other comment about code changes themselves.. Regards, Jerry
Re: PR82943 - Suggested patch to fix
On 1/20/24 10:46 AM, Alexander Westbrooks wrote: Hello and Happy New Year! I wanted to follow up on this patch I made to address PR82943 for GFortran. Has anyone had a chance to review it? Thanks, Alexander Westbrooks Inserting myself in here just a little bit. I will apply and test today if I can. Paul is unavailable for a few weeks. Harald can chime in. Do you have commit rights for gcc? Your efforts are appreciated. Regards, Jerry
[libgfortran, patch] PR113223 NAMELIST internal write missing leading blank character
Committed as simple and obvious. Initial patch thanks to Steve. When using git gcc-commit-mklog how does one add in the coauthor? The master branch has been updated by Jerry DeLisle : https://gcc.gnu.org/g:add995ec117d756e61d207041cd32f937c1a1cd9 commit r14-6986-gadd995ec117d756e61d207041cd32f937c1a1cd9 Author: Jerry DeLisle Date: Sun Jan 7 10:22:19 2024 -0800 libgfortran: Emit a space at beginning of internal unit NML. PR libgfortran/113223 libgfortran/ChangeLog: * io/write.c (namelist_write): If internal_unit precede with space. gcc/testsuite/ChangeLog: * gfortran.dg/dtio_25.f90: Update. * gfortran.dg/namelist_57.f90: Update. * gfortran.dg/namelist_65.f90: Update.
[patch, fortran, committed] PR112873 F2023 degree trig functions
The following has been committed per discussion in the subject PR. commit 95b70545331764c85079a1d0e1e19b605bda1456 (HEAD -> master, origin/master, origin/HEAD) Author: Jerry DeLisle Date: Wed Dec 13 19:04:50 2023 -0800 fortran: Add degree based trig functions for F2023 PR fortran/112873 gcc/fortran/ChangeLog: * gfortran.texi: Update to reflect the changes. * intrinsic.cc (add_functions): Update the standard that the various degree trigonometric functions have been described in. (gfc_check_intrinsic_standard): Add an error string for F2023. * intrinsic.texi: Update accordingly. Thanks to Steve for the changes checked by Harald and myself. I know there is a way to do a co-Author on a git commit. Will try to do that next time when it applies. Jerry
Build breakage
I am getting this failure to build from clean trunk.
In file included from ../../../../trunk/libgomp/config/linux/allocator.c:31:
../../../../trunk/libgomp/config/linux/allocator.c: In function
‘linux_memspace_alloc’:
../../../../trunk/libgomp/config/linux/allocator.c:70:26: error: format
‘%ld’ expects argument of type ‘long int’, but argument 3 has type
‘size_t’ {aka ‘unsigned int’} [-Werror=format=]
70 | gomp_debug (0, "libgomp: failed to pin %ld bytes of"
| ^
71 | " memory (ulimit too low?)\n", size);
|
| |
| size_t
{aka unsigned int}
../../../../trunk/libgomp/libgomp.h:186:29: note: in definition of macro
‘gomp_debug’
186 | (gomp_debug) ((KIND), __VA_ARGS__); \
| ^~~
../../../../trunk/libgomp/config/linux/allocator.c:70:52: note: format
string is defined here
70 | gomp_debug (0, "libgomp: failed to pin %ld bytes of"
| ~~^
||
|long int
| %d
Re: {Patch, fortran] PR112834 - Class array function selector causes chain of syntax and other spurious errors
On 12/6/23 8:09 AM, Paul Richard Thomas wrote: Dear All, This patch was rescued from my ill-fated and long winded attempt to provide a fix-up for function selector references, where the function is parsed after the procedure containing the associate/select type construct (PRs 89645 and 99065). The fix-ups broke down completely once these constructs were enclosed by another associate construct, where the selector is a derived type or class function. My inclination now is to introduce two pass parsing for contained procedures. Returning to PR112834, the patch is simple enough and is well described by the change logs. PR111853 was fixed as a side effect of the bigger patch. Steve Kargl had also posted the same fix on the PR. Regression tests - OK for trunk and 13-branch? Paul Hi Paul, I am taking a crack at this. It looks reasonable to me. Certainly OK for trunk, and then, if no fallout, 13 at your discretion. Regards, Jerry
Re: [PATCH] Fortran: out of bounds access with nested implied-do IO [PR111837]
On 10/16/23 12:11 PM, Harald Anlauf wrote: Dear All, the attached patch fixes a dependency check in frontend optimzation for nested implied-do IO. The problem appeared for >= 3 loops only as the check considered dependencies to be only of band form instead of triangular form. Regtested on x86_64-pc-linux-gnu. OK for mainline? As this fixes a regression since 8-release, I plan to backport to all active branches. Thanks, Harald OK for Mainline and backport Thanks Harald Jerry
Re: [PATCH] Fortran: name conflict between internal procedure and derived type [PR104351]
On 10/11/23 12:44 PM, Harald Anlauf wrote: Dear All, sorry for attaching the wrong patch - this time it is the correct one! Harald On 10/11/23 21:39, Harald Anlauf wrote: Dear All, the attached trivial patch fixes (= catches) a forgotten corner-case in the detection of a name conflict between an internal procedure and a local declaration for the case that the latter is a derived type. Another torture test by Gerhard... ;-) Used to ICE previously. Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald This one is OK as well. Once I found the right patch on the right email. Regardless, both good to go. Thanks, Jerry
Re: [PATCH] Fortran: name conflict between internal procedure and derived type [PR104351]
On 10/11/23 12:39 PM, Harald Anlauf wrote: Dear All, the attached trivial patch fixes (= catches) a forgotten corner-case in the detection of a name conflict between an internal procedure and a local declaration for the case that the latter is a derived type. Another torture test by Gerhard... ;-) Used to ICE previously. Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald This one is OK Harald. Thanks, Jerry
Re: [PATCH] fortran: fix checking of CHARACTER lengths in array constructors [PR70231]
On 9/18/23 1:27 PM, Harald Anlauf via Fortran wrote: Dear all, as correctly analyzed by Jerry, the code for checking the consistency of character lengths in array constructors did not properly initialize the auxiliary variable used in "bounds checking". The attached patch resolves this by initializing this auxiliary variable with a length obtained by scanning the constructor. Interestingly, the failure depended on optimization level and was apparent only at -O0, and could exhibit both false-positives and false-negatives. Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald Wow 2016 when I looked at that one. The patch looks reasonable to me. OK for mainline. Jerry
Re: [PATCH] Fortran: improve bounds checking for DATA with implied-do [PR35095]
On 8/24/23 2:28 PM, Harald Anlauf via Fortran wrote: Dear all, the attached patch adds stricter bounds-checking for DATA statements with implied-do. I chose to allow overindexing (for arrays of rank greater than 1) for -std=legacy, as there might be codes in the wild that need this (and this is accepted by some other compilers, while NAG is strict here). We now get a warning with -std=gnu, and an error with -std=f. Regtested on x86_64-pc-linux-gnu. OK for mainline? (The PR is over 15 years old, so no backport intended... ;-) Thanks, Harald Looks good Harold, OK for mainline.
Re: [Patch, fortran] PR109684 - compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)
On 8/9/23 7:58 AM, Paul Richard Thomas via Fortran wrote: I took a look at my calendar and decided to backport right away. r13-7703-ged049e5d5f36cc0f4318cd93bb6b33ed6f6f2ba7 BTW It is a regression :-) Paul On Wed, 9 Aug 2023 at 12:10, Paul Richard Thomas wrote: Committed to trunk as 'obvious' in r14-3098-gb8ec3c952324f866f191883473922e250be81341 13-branch to follow in a few days. Paul Thanks Paul, I was about ready to do it myself. Jerry
Re: [PATCH] Fortran: set shape of initializers of zero-sized arrays [PR95374,PR104352]
On 5/17/23 11:52 AM, Harald Anlauf via Fortran wrote: Dear all, the attached patch is neat, because it fixes a bug by removing code ;-) When generating the initializer for a parameter array, we excepted the case of size 0, which however prevented the detection of array bounds violations and lead to ICEs in various places. The solution which removes the comparison for size > 0 also has the bonus that it fixes a minor memory leak for the size==0 case... Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald Looks Good To Me. OK, Jerry
Re: [patch, fortran] PR109662 Namelist input with comma after name accepted
I plan to commit the following as simple.
The issue was a value was being modified on a short namelist read. After
tthe first read gives the correct EOF, a second read would give the
error but modify the variable.
diff --git a/libgfortran/io/unit.c b/libgfortran/io/unit.c
index 82664dc5f98..36d025949c2 100644
--- a/libgfortran/io/unit.c
+++ b/libgfortran/io/unit.c
@@ -504,6 +504,7 @@ set_internal_unit (st_parameter_dt *dtp, gfc_unit
*iunit, int kind)
iunit->current_record=0;
iunit->read_bad = 0;
iunit->endfile = NO_ENDFILE;
+ iunit->last_char = 0;
/* Set flags for the internal unit. */
The revised test case attached. It has been regression tested OK.
Regards,
Jerry! { dg-do run }
! { dg-options "-std=f2003" }
! PR109662-a semi-colon after namelist name accepted on input.
program testnmlread
implicit none
character(16) :: line = ' n = 759/'
character(100)::message
integer :: n, i, ioresult
namelist/stuff/n
message = ""
ioresult = 0
n = 99
read(line,nml=stuff,iostat=ioresult)
if (ioresult == 0) STOP 13 ! Should error with the semi-colon in there.
! Intentional short input (-> EOF)
line = ""
! Problem manifests on two bad reads on same string.
do i = 1, 6
n = -1
ioresult = 0
read (line,nml=stuff,iostat=ioresult)
if (n /= -1) STOP 24
if (ioresult == 0) STOP 25
end do
end program testnmlread
Re: [patch, fortran] PR109662 Namelist input with comma after name accepted
On 5/6/23 11:15 AM, Harald Anlauf via Fortran wrote: Hi Jerry, Steve, I think I have to pour a little water into the wine. The patch fixes the reported issue only for a comma after the namelist name, but we still accept a few other illegal characters, e.g. ';', because: #define is_separator(c) (c == '/' || c == ',' || c == '\n' || c == ' ' \ || c == '\t' || c == '\r' || c == ';' || \ (dtp->u.p.namelist_mode && c == '!')) We don't want that in standard conformance mode, or do we? Cheers, Harald On 5/6/23 06:02, Steve Kargl via Gcc-patches wrote: 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. As I think back, I don't recall ever seeing a semi-colon used after a NAMELIST name, so I think we should reject it always. The other "soft" blanks we should allow. I will make a another patch on trunk to reject the semi-colon and if no one objects here I will test and push it. Regards, Jerry
[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);
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
Hosting our gfortran MatterMost workspace
Hello all and gcc overseers, I received a notice that the MasterMost server providers decided to drop their free service. Unfortunate and understandable. I plan to contact the Open Software Lab folks at Oregon State University to see if they can host for us. If anyone else has any suggestions of possible places we can host an instance, please let me know. The software for the platform is open source many folks self host, so we can do this. I am not sure where gcc.gnu.org is hosted, but that might be a logical place. Best regards, Jerry
Re: [PATCH] testsuite: fix scan-tree-dump patterns [PR83904, PR100297]
On 4/18/23 12:39 PM, Harald Anlauf via Fortran wrote: Dear all, the attached patch adjusts the scan-tree-dump patterns of the reported testcases which likely were run in a location such that a path in an error message showing in the tree-dump might have accidentally matched "free" or "data", respectively. For the testcase gfortran.dg/reshape_8.f90 I checked with a failing gfortran-11 that the pattern is appropriate. OK for mainline? Thanks, Harald Yes, OK Thanks
Re: [PATCH] Fortran: resolve correct generic with TYPE(C_PTR) arguments [PR61615]
On 4/10/23 1:49 PM, Harald Anlauf via Fortran wrote: Dear all, when comparing formal and actual arguments of a procedure, there was no check of rank for derived types from intrinsic module ISO_C_BINDING. This could lead to a wrong resolution of generic procedures with dummy argument of related types, see PR. This was likely an oversight. The attached fix is simple and regtests cleanly on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald Looks good to go. Jerry
Re: [PATCH] Fortran: fix ICE with bind(c) in block data [PR104332]
On 3/9/23 10:08 AM, Harald Anlauf via Fortran wrote: Dear all, the attached almost obvious patch fixes a NULL pointer dereference in a check of a symbol with the bind(c) attribute. Regtested on x86_64-pc-linux-gnu. OK for mainline? This PR is marked as 10/11/12/13 regression, thus it should qualify for a backport. It's simple enough anyway. Thanks, Harald OK, please proceed. Thanks for the patch. Jerry
Re: [PATCH][stage1] Remove conditionals around free()
On 3/3/23 3:32 PM, Iain Sandoe wrote: On 3 Mar 2023, at 23:11, Bernhard Reutner-Fischer via Fortran wrote: On 2 March 2023 02:23:10 CET, Jerry D wrote: On 3/1/23 4:07 PM, Steve Kargl via Fortran wrote: On Wed, Mar 01, 2023 at 10:28:56PM +0100, Bernhard Reutner-Fischer via Fortran wrote: libgfortran/caf/single.c |6 ++ libgfortran/io/async.c |6 ++ libgfortran/io/format.c |3 +-- libgfortran/io/transfer.c|6 ++ libgfortran/io/unix.c|3 +-- The Fortran ones are OK. The only question I have: Is free posix compliant on all platforms? For example ming64 or mac? OSX / macOS are [certified] Posix compliant - but to unix03 (and might be missing features declared as optional at that revision, or features from later Posix versions). In the case of free() man says: "The free() function deallocates the memory allocation pointed to by ptr. If ptr is a NULL pointer, no operation is performed.” Iain It seems sometimes we run into things like this once in a while. I think we have the -liberty to cater even for non compliant systems either way, if you please excuse the pun. That's not an excuse on POSIX systems, imho. I am certainly not a C++ expert but it seems to me this all begs for automatic finalization where one would not have to invoke free at all. I suspect the gfortran frontend is not designed for such things. Otherwise I have no issue at all. It is a lot cleaner. Jerry
Re: [PATCH][stage1] Remove conditionals around free()
On 3/1/23 4:07 PM, Steve Kargl via Fortran wrote: On Wed, Mar 01, 2023 at 10:28:56PM +0100, Bernhard Reutner-Fischer via Fortran wrote: libgfortran/caf/single.c |6 ++ libgfortran/io/async.c |6 ++ libgfortran/io/format.c |3 +-- libgfortran/io/transfer.c|6 ++ libgfortran/io/unix.c|3 +-- The Fortran ones are OK. The only question I have: Is free posix compliant on all platforms? For example ming64 or mac? It seems sometimes we run into things like this once in a while. Otherwise I have no issue at all. It is a lot cleaner. Jerry
Re: [patch, libgfortran] Initailize some variable to get rid of nuisance warnings.
Pushed, thanks for feedback On 2/26/23 11:54 PM, Tobias Burnus wrote: Just side remarks, the 0 init in the patch is fine. On 27.02.23 03:53, Jerry D via Gcc-patches wrote: regarding PACK: since this is a bogus warning as the compiler does not realize that dim >= 1, wouldn't a gcc_assert (dim >= 1); Note: gcc_assert only exists in the compiler itself; in libgfortran, we use GFC_ASSERT or directly 'assert'. You could also use 'if (dim < 1) __builtin_unreachable();' – or since GCC 13: __attribute__((assume (dim >= 1))); Tobias PS: In Fortran, '-fopenmp-simd' plus '!$omp assume holds(dim>=0) ... !$omp end assume' (or !$omp ... + block/end block) can be used to denote such assumptions. '-fopenmp-simd' enables only those bits of OpenMP that do not require any library support (no libgomp, no pthreads), contrary to '-fopenmp'. - 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, libgfortran] Initailize some variable to get rid of nuisance warnings.
On 2/26/23 12:59 PM, Harald Anlauf wrote: Hi Jerry, regarding PACK: since this is a bogus warning as the compiler does not realize that dim >= 1, wouldn't a gcc_assert (dim >= 1); in the right place achieve the same effect, since the first argument must be an array? (It's different for SPREAD, though, where SOURCE may be scalar). I should have clarified in my posts that the warnings are on the use of sstride[0], mstride[0] or both. For example. ../../../trunk/libgfortran/generated/pack_i2.c: In function ‘pack_i2’: ../../../trunk/libgfortran/generated/pack_i2.c:129:14: warning: ‘sstride’ may be used uninitialized [-Wmaybe-uninitialized] 129 | if (sstride[0] == 0) | ~~~^~~ ../../../trunk/libgfortran/generated/pack_i2.c:80:14: note: ‘sstride’ declared here 80 | index_type sstride[GFC_MAX_DIMENSIONS]; | ^~~ ../../../trunk/libgfortran/generated/pack_i2.c:131:14: warning: ‘mstride’ may be used uninitialized [-Wmaybe-uninitialized] 131 | if (mstride[0] == 0) | ~~~^~~ ../../../trunk/libgfortran/generated/pack_i2.c:84:14: note: ‘mstride’ declared here 84 | index_type mstride[GFC_MAX_DIMENSIONS]; | ^~~ ../../../trunk/libgfortran/generated/pack_i2.c:131:14: warning: ‘mstride’ may be used uninitialized [-Wmaybe-uninitialized] 131 | if (mstride[0] == 0) | ~~~^~~ ../../../trunk/libgfortran/generated/pack_i2.c:84:14: note: ‘mstride’ declared here 84 | index_type mstride[GFC_MAX_DIMENSIONS]; | ^~~ In a sense it is a regression. It showed up when builds started to use -Wmaybe-unitialized. Cheers, Harald Am 26.02.23 um 20:52 schrieb Jerry D via Gcc-patches: The attached patch is minor and self explanatory. I assume this should wait for gfortran 14 since no regression involved. Please advise otherwise. Regression tested on x86-64. OK for trunk when the time is right? Regards, Jerry Author: Jerry DeLisle Date: Sat Feb 25 20:30:35 2023 -0800 Fortran: Eliminate nuisance warnings by initializing. Set sstride[0] and mstide[0] to zero, eliminating some warnings. libgfortran/ChangeLog: * generated/pack_c10.c (pack_c10): Regenerated. * generated/pack_c16.c (pack_c16): Regenerated. * generated/pack_c17.c (pack_c17): Regenerated. * generated/pack_c4.c (pack_c4): Regenerated. * generated/pack_c8.c (pack_c8): Regenerated. * generated/pack_i1.c (pack_i1): Regenerated. * generated/pack_i16.c (pack_i16): Regenerated. * generated/pack_i2.c (pack_i2): Regenerated. * generated/pack_i4.c (pack_i4): Regenerated. * generated/pack_i8.c (pack_i8): Regenerated. * generated/pack_r10.c (pack_r10): Regenerated. * generated/pack_r16.c (pack_r16): Regenerated. * generated/pack_r17.c (pack_r17): Regenerated. * generated/pack_r4.c (pack_r4): Regenerated. * generated/pack_r8.c (pack_r8): Regenerated. * generated/spread_c10.c (spread_c10): Regenerated. * generated/spread_c16.c (spread_c16): Regenerated. * generated/spread_c17.c (spread_c17): Regenerated. * generated/spread_c4.c (spread_c4): Regenerated. * generated/spread_c8.c (spread_c8): Regenerated. * generated/spread_i1.c (spread_i1): Regenerated. * generated/spread_i16.c (spread_i16): Regenerated. * generated/spread_i2.c (spread_i2): Regenerated. * generated/spread_i4.c (spread_i4): Regenerated. * generated/spread_i8.c (spread_i8): Regenerated. * generated/spread_r10.c (spread_r10): Regenerated. * generated/spread_r16.c (spread_r16): Regenerated. * generated/spread_r17.c (spread_r17): Regenerated. * generated/spread_r4.c (spread_r4): Regenerated. * generated/spread_r8.c (spread_r8): Regenerated. * intrinsics/execute_command_line.c (execute_command_line_i4), (execute_command_line_i8): Set estat_initial to zero. * intrinsics/pack_generic.c (pack_internal): Set sstride[0] and mstride[0] to zero. * intrinsics/spread_generic.c (spread_internal): Set sstride[0]. * m4/pack.m4: Set sstride[0] and mstride[0]. * m4/spread.m4: Set sstride[0].
[patch, libgfortran] Initailize some variable to get rid of nuisance warnings.
The attached patch is minor and self explanatory. I assume this should wait for gfortran 14 since no regression involved. Please advise otherwise. Regression tested on x86-64. OK for trunk when the time is right? Regards, Jerry Author: Jerry DeLisle Date: Sat Feb 25 20:30:35 2023 -0800 Fortran: Eliminate nuisance warnings by initializing. Set sstride[0] and mstide[0] to zero, eliminating some warnings. libgfortran/ChangeLog: * generated/pack_c10.c (pack_c10): Regenerated. * generated/pack_c16.c (pack_c16): Regenerated. * generated/pack_c17.c (pack_c17): Regenerated. * generated/pack_c4.c (pack_c4): Regenerated. * generated/pack_c8.c (pack_c8): Regenerated. * generated/pack_i1.c (pack_i1): Regenerated. * generated/pack_i16.c (pack_i16): Regenerated. * generated/pack_i2.c (pack_i2): Regenerated. * generated/pack_i4.c (pack_i4): Regenerated. * generated/pack_i8.c (pack_i8): Regenerated. * generated/pack_r10.c (pack_r10): Regenerated. * generated/pack_r16.c (pack_r16): Regenerated. * generated/pack_r17.c (pack_r17): Regenerated. * generated/pack_r4.c (pack_r4): Regenerated. * generated/pack_r8.c (pack_r8): Regenerated. * generated/spread_c10.c (spread_c10): Regenerated. * generated/spread_c16.c (spread_c16): Regenerated. * generated/spread_c17.c (spread_c17): Regenerated. * generated/spread_c4.c (spread_c4): Regenerated. * generated/spread_c8.c (spread_c8): Regenerated. * generated/spread_i1.c (spread_i1): Regenerated. * generated/spread_i16.c (spread_i16): Regenerated. * generated/spread_i2.c (spread_i2): Regenerated. * generated/spread_i4.c (spread_i4): Regenerated. * generated/spread_i8.c (spread_i8): Regenerated. * generated/spread_r10.c (spread_r10): Regenerated. * generated/spread_r16.c (spread_r16): Regenerated. * generated/spread_r17.c (spread_r17): Regenerated. * generated/spread_r4.c (spread_r4): Regenerated. * generated/spread_r8.c (spread_r8): Regenerated. * intrinsics/execute_command_line.c (execute_command_line_i4), (execute_command_line_i8): Set estat_initial to zero. * intrinsics/pack_generic.c (pack_internal): Set sstride[0] and mstride[0] to zero. * intrinsics/spread_generic.c (spread_internal): Set sstride[0]. * m4/pack.m4: Set sstride[0] and mstride[0]. * m4/spread.m4: Set sstride[0]. diff --git a/libgfortran/generated/pack_c10.c b/libgfortran/generated/pack_c10.c index a961057a8a6..c01efd11cf8 100644 --- a/libgfortran/generated/pack_c10.c +++ b/libgfortran/generated/pack_c10.c @@ -96,6 +96,9 @@ pack_c10 (gfc_array_c10 *ret, const gfc_array_c10 *array, dim = GFC_DESCRIPTOR_RANK (array); + sstride[0] = 0; /* Avoid warnings if not initialized. */ + mstride[0] = 0; + mptr = mask->base_addr; /* Use the same loop for all logical types, by using GFC_LOGICAL_1 diff --git a/libgfortran/generated/pack_c16.c b/libgfortran/generated/pack_c16.c index 37c062798bb..8ee6b25cbe6 100644 --- a/libgfortran/generated/pack_c16.c +++ b/libgfortran/generated/pack_c16.c @@ -96,6 +96,9 @@ pack_c16 (gfc_array_c16 *ret, const gfc_array_c16 *array, dim = GFC_DESCRIPTOR_RANK (array); + sstride[0] = 0; /* Avoid warnings if not initialized. */ + mstride[0] = 0; + mptr = mask->base_addr; /* Use the same loop for all logical types, by using GFC_LOGICAL_1 diff --git a/libgfortran/generated/pack_c17.c b/libgfortran/generated/pack_c17.c index f9638d640ad..7a1cf5e17e8 100644 --- a/libgfortran/generated/pack_c17.c +++ b/libgfortran/generated/pack_c17.c @@ -96,6 +96,9 @@ pack_c17 (gfc_array_c17 *ret, const gfc_array_c17 *array, dim = GFC_DESCRIPTOR_RANK (array); + sstride[0] = 0; /* Avoid warnings if not initialized. */ + mstride[0] = 0; + mptr = mask->base_addr; /* Use the same loop for all logical types, by using GFC_LOGICAL_1 diff --git a/libgfortran/generated/pack_c4.c b/libgfortran/generated/pack_c4.c index d72717041a1..76c8a853fac 100644 --- a/libgfortran/generated/pack_c4.c +++ b/libgfortran/generated/pack_c4.c @@ -96,6 +96,9 @@ pack_c4 (gfc_array_c4 *ret, const gfc_array_c4 *array, dim = GFC_DESCRIPTOR_RANK (array); + sstride[0] = 0; /* Avoid warnings if not initialized. */ + mstride[0] = 0; + mptr = mask->base_addr; /* Use the same loop for all logical types, by using GFC_LOGICAL_1 diff --git a/libgfortran/generated/pack_c8.c b/libgfortran/generated/pack_c8.c index 9f8e97e4bc8..365c26ed0e8 100644 --- a/libgfortran/generated/pack_c8.c +++ b/libgfortran/generated/pack_c8.c @@ -96,6 +96,9 @@ pack_c8 (gfc_array_c8 *ret, const gfc_array_c8 *array, dim = GFC_DESCRIPTOR
[PATCHES, Committed] As obvious
Committed as obvious: commit 061b13ed014ba0b6891800a5c7f852bf58e4d856 Author: Jerry DeLisle Date: Thu Feb 16 18:13:56 2023 -0800 Fortran Tests: Allow passing on mingw. gcc/testsuite/ChangeLog: * gfortran.dg/bind_c_array_params_2.f90: Add *-*-ming* to dg-final. and commit f978585c2939691176ad8d3fa9c2e4e91ed18bf4 (HEAD -> master, origin/master, origin/HEAD) Author: Jerry DeLisle Date: Thu Feb 16 19:29:44 2023 -0800 Fortran test: Modify test cases to pass on mingw. gcc/testsuite/ChangeLog: * gfortran.dg/ISO_Fortran_binding_14.f90: Change example function to CLOCK which is available on mingw as well as other platforms. * gfortran.dg/pr96486.f90: Change variable to PATH likewise.
Re: [PATCH] Fortran: ASSOCIATE variables should not be TREE_STATIC [PR95107]
On 2/6/23 12:10 PM, Harald Anlauf via Fortran wrote: Dear all, as the PR shows, it is likely not a good idea to try to make an ASSOCIATE variable static when -fno-automatic is specified, so rather keep it on the stack. Attached patch regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald Yes, OK Thanks, Jerry
Re: *PING* [PATCH] Fortran: prevent redundant integer division truncation warnings [PR108592]
On 2/5/23 11:33 AM, Harald Anlauf via Fortran wrote: Early gentle ping. Am 30.01.23 um 22:55 schrieb Harald Anlauf via Gcc-patches: Dear Fortranners, the subject says it all: in some cases we emit redundant integer division truncation warnings (2 or 4), where just one would have been sufficient. This is solved by using gfc_warning instead of gfc_warning_now. The testcase uses a suggestion by Andrew to verify that we get the desired warning exactly once. Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald The patch is gentle enough to be OK to commit. Thanks, Jerry
Re: ☠ Buildbot (Sourceware): gcc - failed configure (failure) (master)
On 1/30/23 5:46 AM, Sam James wrote: On 30 Jan 2023, at 06:27, Steve Kargl via Gcc wrote: Hi Steve, Please remove the skull and cross bones in the subject line. This is a sourceware project so I've CC'd the buildbot mailing list where we discuss these matters. Does the emoji bother you, or is it the skull and crossbones specifically (which is a recognised symbol for a hazard)? Note that this is the default upstream from the Buildbot project (we use their software) too. We haven't chosen it ourselves. Thanks, sam As long as your asking it just looks stupid, childish to think anyone needs an emoji in what we try think is a professional product. ( Too informal? ) If that's not enough, how about corny, or something for 12 year olds. Yep, it's just stupid. I don't have an issue with bots, I just don't need emojis outside of my personal chats on my phone. If it is suppose to be a notification, how about just the word "Alert" or "Notice" Regards, Jerry Jerry
Fwd: ☠ Buildbot (Sourceware): gcc - failed configure (failure) (master)
I had this show up today. I have no idea what this is about. Please advise. Jerry Forwarded Message Subject: ☠ Buildbot (Sourceware): gcc - failed configure (failure) (master) Date: Sun, 29 Jan 2023 19:31:23 + From: buil...@sourceware.org To: Jerry DeLisle A new failure has been detected on builder gcc-gentoo-sparc while building gcc. Full details are available at: https://builder.sourceware.org/buildbot/#builders/231/builds/210 Build state: failed configure (failure) Revision: 8011fbba7baa46947341ca8069b5a327163a68d5 Worker: gentoo-sparc-big Build Reason: (unknown) Blamelist: Jerry DeLisle Steps: - 0: worker_preparation ( success ) - 1: git checkout ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/231/builds/210/steps/1/logs/stdio - 2: rm -rf gcc-build ( success ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/231/builds/210/steps/2/logs/stdio - 3: configure ( failure ) Logs: - stdio: https://builder.sourceware.org/buildbot/#builders/231/builds/210/steps/3/logs/stdio
[patch, fortran] PR103506 [10/11/12/13 Regression] ICE in gfc_free_namespace, at fortran/symbol.c
Attached patch fixes this problem by allowing the namespace pointer to
be set correctly regardless of error condition.
Regression tested on x86_64_linux_gnu.
OK for trunk and backports?
Regards,
Jerry
Author: Jerry DeLisle
Date: Sat Jan 28 20:00:34 2023 -0800
ICE in gfc_free_namespace. ice-on-invalid.
PR fortran/103506
gcc/fortran/ChangeLog:
* parse.cc (parse_module): Remove use of a bool error value
that prevented proper setting of the namespace pointer.
gcc/testsuite/ChangeLog:
* gfortran.dg/pr103506_1.f90: New test.diff --git a/gcc/fortran/parse.cc b/gcc/fortran/parse.cc
index 0fb19cc9f0f..039e7e7da53 100644
--- a/gcc/fortran/parse.cc
+++ b/gcc/fortran/parse.cc
@@ -6502,7 +6502,6 @@ parse_module (void)
{
gfc_statement st;
gfc_gsymbol *s;
- bool error;
s = gfc_get_gsymbol (gfc_new_block->name, false);
if (s->defined || (s->type != GSYM_UNKNOWN && s->type != GSYM_MODULE))
@@ -6525,7 +6524,6 @@ parse_module (void)
st = parse_spec (ST_NONE);
- error = false;
loop:
switch (st)
{
@@ -6544,16 +6542,11 @@ loop:
default:
gfc_error ("Unexpected %s statement in MODULE at %C",
gfc_ascii_statement (st));
-
- error = true;
reject_statement ();
st = next_statement ();
goto loop;
}
-
- /* Make sure not to free the namespace twice on error. */
- if (!error)
-s->ns = gfc_current_ns;
+ s->ns = gfc_current_ns;
}
diff --git a/gcc/testsuite/gfortran.dg/pr103506_1.f90 b/gcc/testsuite/gfortran.dg/pr103506_1.f90
new file mode 100644
index 000..3f57809e099
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr103506_1.f90
@@ -0,0 +1,9 @@
+! { dg-do compile }
+! PR103506 ICE in gfc_free_namespace. ice-on-invalid
+! Test case from the PR.
+module m ! { dg-error "is already being used as a MODULE" }
+stop ! { dg-error "Unexpected STOP statement in MODULE" }
+end
+program p
+call m ! { dg-error "is already being used as a MODULE" }
+end
Re: [PATCH] Fortran: diagnose USE associated symbols in COMMON blocks [PR108453]
On 1/28/23 9:07 AM, Harald Anlauf via Fortran wrote: Dear all, a USE associated symbol shall not appear in a COMMON block (F2018:C8121) and needs to be diagnosed. The patch is fairly obvious. Regtested on x86_64-pc-linux-gnu. OK for mainline? As the PR is marked as a 10/11/12/13 regression, I plan to backport as appropriate. Thanks, Harald Yes, this is OK for all. Thanks Jerry
Re: [PATCH] Fortran: fix ICE in compare_bound_int [PR108527]
On 1/24/23 1:48 PM, Harald Anlauf via Fortran wrote: Dear all, when checking expressions for array sections, we need to ensure that these use only type INTEGER. However, it does not make sense to generate an internal error when encountering wrong types, but rather take the ordinary route of error recovery. The initial fix was provided by Steve. While working on the same PR, I found that the comments related to the logic needed a minor adjustment, and the logic could be cleaned up to actually match the intended comment. Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald Harald, this looks OK to me. Good for Mainline.
Re: [patch, gfortran.dg] Adjust numerous tests so that they pass on line endings
Committed: It is not apparent to me that the testsuite/ChangeLog was updated. Maybe there is a time delay on that? Please be patient with me as I figure out how all this works. ommit f963705752e9d0b79a340788166269af417e344e (HEAD -> master, origin/master, origin/HEAD) Author: Jerry DeLisle Date: Sat Jan 21 15:47:19 2023 -0800 Fortran tests: Revise line end tests allowing windows testing. gcc/testsuite/ChangeLog: * gfortran.dg/ISO_Fortran_binding_17.f90: Replace (\n|\r\n|\r) with (\r*\n+). * gfortran.dg/array_temporaries_2.f90: Likewise. * gfortran.dg/bind-c-contiguous-1.f90: Likewise. * gfortran.dg/bind-c-contiguous-4.f90: Likewise. * gfortran.dg/bind-c-contiguous-5.f90: Likewise. * gfortran.dg/fmt_error_4.f90: Likewise. * gfortran.dg/fmt_error_5.f90: Likewise. * gfortran.dg/fmt_float.f90: Likewise. * gfortran.dg/fmt_l.f90: Likewise. * gfortran.dg/fmt_nonchar_2.f90: Likewise. * gfortran.dg/fmt_zero_precision.f90: Likewise. * gfortran.dg/g77/f77-edit-apostrophe-out.f: Likewise. * gfortran.dg/g77/f77-edit-colon-out.f: Likewise. * gfortran.dg/g77/f77-edit-h-out.f: Likewise. * gfortran.dg/g77/f77-edit-i-out.f: Likewise. * gfortran.dg/g77/f77-edit-s-out.f: Likewise. * gfortran.dg/g77/f77-edit-slash-out.f: Likewise. * gfortran.dg/g77/f77-edit-t-out.f: Likewise. * gfortran.dg/g77/f77-edit-x-out.f: Likewise. * gfortran.dg/namelist_40.f90: Likewise. * gfortran.dg/namelist_47.f90: Likewise. * gfortran.dg/namelist_print_1.f: Likewise. * gfortran.dg/parameter_array_dummy.f90: Likewise.
Re: [patch, gfortran.dg] Adjust numerous tests so that they pass on line endings
On 1/22/23 5:38 AM, Mikael Morin wrote: Hello, Le 22/01/2023 à 00:59, Jerry D via Fortran a écrit : (...) Proposed ChangeLog entry using git gcc-commit-mklog: Author: Jerry DeLisle Date: Sat Jan 21 15:47:19 2023 -0800 Revise the line end tests to pass on certain windows test environments which inject spurious /r characters. Adjust (\n|\r\n|\r) to (\r*\n+). gcc/testsuite/ChangeLog: * gfortran.dg/ISO_Fortran_binding_17.f90: As noted above. (...)This part will be integrated in the ChangeLog file, without the preceding text. Don't start with "As noted above", as there will be no "above" to refer to. Thank you, relearning how these things work with the automation scripts. Jerry
Re: [patch, gfortran.dg] Adjust numerous tests so that they pass on line endings
On 1/20/23 6:13 PM, Jerry DeLisle via Fortran wrote: Hi all, The attached patch modifies the following tests to check for line endings. Some test environments inject superfluous /r characters at ends of lines. The expression matching in dg-output tests are changed from: (\n|\r\n|\r) to (\r*\n+) This allows these tests to pass. The failing tests tend to mask the real bugs in these systems. The changes were provided by Nightstrike who has tested on the troublesome environment. I ran the tests successfully on Linux. I do not know if anyone has tested on Mac or some of the other system that use odd line endings. OK for trunk? What about for 12? Regards, Jerry modified: gcc/testsuite/gfortran.dg/ISO_Fortran_binding_17.f90 modified: gcc/testsuite/gfortran.dg/array_temporaries_2.f90 modified: gcc/testsuite/gfortran.dg/bind-c-contiguous-1.f90 modified: gcc/testsuite/gfortran.dg/bind-c-contiguous-4.f90 modified: gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 modified: gcc/testsuite/gfortran.dg/fmt_error_4.f90 modified: gcc/testsuite/gfortran.dg/fmt_error_5.f90 modified: gcc/testsuite/gfortran.dg/fmt_float.f90 modified: gcc/testsuite/gfortran.dg/fmt_l.f90 modified: gcc/testsuite/gfortran.dg/fmt_nonchar_2.f90 modified: gcc/testsuite/gfortran.dg/fmt_zero_precision.f90 modified: gcc/testsuite/gfortran.dg/g77/f77-edit-apostrophe-out.f modified: gcc/testsuite/gfortran.dg/g77/f77-edit-colon-out.f modified: gcc/testsuite/gfortran.dg/g77/f77-edit-h-out.f modified: gcc/testsuite/gfortran.dg/g77/f77-edit-i-out.f modified: gcc/testsuite/gfortran.dg/g77/f77-edit-s-out.f modified: gcc/testsuite/gfortran.dg/g77/f77-edit-slash-out.f modified: gcc/testsuite/gfortran.dg/g77/f77-edit-t-out.f modified: gcc/testsuite/gfortran.dg/g77/f77-edit-x-out.f modified: gcc/testsuite/gfortran.dg/namelist_40.f90 modified: gcc/testsuite/gfortran.dg/namelist_47.f90 modified: gcc/testsuite/gfortran.dg/namelist_print_1.f modified: gcc/testsuite/gfortran.dg/parameter_array_dummy.f90 Proposed ChangeLog entry using git gcc-commit-mklog: Author: Jerry DeLisle Date: Sat Jan 21 15:47:19 2023 -0800 Revise the line end tests to pass on certain windows test environments which inject spurious /r characters. Adjust (\n|\r\n|\r) to (\r*\n+). gcc/testsuite/ChangeLog: * gfortran.dg/ISO_Fortran_binding_17.f90: As noted above. * gfortran.dg/array_temporaries_2.f90: As noted above. * gfortran.dg/bind-c-contiguous-1.f90: As noted above. * gfortran.dg/bind-c-contiguous-4.f90: As noted above. * gfortran.dg/bind-c-contiguous-5.f90: As noted above. * gfortran.dg/fmt_error_4.f90: As noted above. * gfortran.dg/fmt_error_5.f90: As noted above. * gfortran.dg/fmt_float.f90: As noted above. * gfortran.dg/fmt_l.f90: As noted above. * gfortran.dg/fmt_nonchar_2.f90: As noted above. * gfortran.dg/fmt_zero_precision.f90: As noted above. * gfortran.dg/g77/f77-edit-apostrophe-out.f: As noted above. * gfortran.dg/g77/f77-edit-colon-out.f: As noted above. * gfortran.dg/g77/f77-edit-h-out.f: As noted above. * gfortran.dg/g77/f77-edit-i-out.f: As noted above. * gfortran.dg/g77/f77-edit-s-out.f: As noted above. * gfortran.dg/g77/f77-edit-slash-out.f: As noted above. * gfortran.dg/g77/f77-edit-t-out.f: As noted above. * gfortran.dg/g77/f77-edit-x-out.f: As noted above. * gfortran.dg/namelist_40.f90: As noted above. * gfortran.dg/namelist_47.f90: As noted above. * gfortran.dg/namelist_print_1.f: As noted above. * gfortran.dg/parameter_array_dummy.f90: As noted above.
Re: [patch. fortran] PR102595 ICE in var_element, at fortran/decl.c
On 1/20/23 9:16 PM, Jerry D wrote:
On 1/20/23 5:46 PM, Jerry D wrote:
A PARAMETER value is not allowed in a DATA statement, similar to an
EQUIVALENCE.
The check for this was in gfc_assign_data_value() in data.cc which
turns out to be too late when trying to assign a zero sized array.
Correction, the chunk in data.cc must remain for one test case. I
spotted this after rerunning check-fortran for several variations.
Attached patch is revised to include a new test case and adjustment of
an existing test case. It also adds in a return MATCH_ERROR I
accidentally left of the first submit when I was cleaning some things up.
Ok for Mainline?
Jeyy
diff --git a/gcc/fortran/data.cc b/gcc/fortran/data.cc
index 443d35da9cf..d29eb12c1b1 100644
--- a/gcc/fortran/data.cc
+++ b/gcc/fortran/data.cc
@@ -244,13 +244,6 @@ gfc_assign_data_value (gfc_expr *lvalue, gfc_expr *rvalue, mpz_t index,
"array-element nor a scalar-structure-component";
symbol = lvalue->symtree->n.sym;
- if (symbol->attr.flavor == FL_PARAMETER)
-{
- gfc_error ("PARAMETER %qs shall not appear in a DATA statement at %L",
- symbol->name, >where);
- return false;
-}
-
init = symbol->value;
last_ts = >ts;
last_con = NULL;
diff --git a/gcc/fortran/primary.cc b/gcc/fortran/primary.cc
index 543d9cc0de4..28ce5fea865 100644
--- a/gcc/fortran/primary.cc
+++ b/gcc/fortran/primary.cc
@@ -4076,8 +4076,14 @@ match_variable (gfc_expr **result, int equiv_flag, int host_flag)
gfc_error ("Named constant at %C in an EQUIVALENCE");
return MATCH_ERROR;
}
- /* Otherwise this is checked for and an error given in the
- variable definition context checks. */
+ if (gfc_in_match_data())
+ {
+ gfc_error ("PARAMETER %qs shall not appear in a DATA statement at %C",
+ sym->name);
+ return MATCH_ERROR;
+ }
+ /* Otherwise this is checked for an error given in the
+ variable definition context checks. */
break;
case FL_PROCEDURE:
diff --git a/gcc/testsuite/gfortran.dg/parameter_data0.f90 b/gcc/testsuite/gfortran.dg/parameter_data0.f90
new file mode 100644
index 000..4f1da9ea42e
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/parameter_data0.f90
@@ -0,0 +1,6 @@
+! { dg-do compile }
+! PR fortran/102595 Similar to 88048 with a zero sized array
+program p
+ complex, parameter:: x(0) = 2
+ data x%im /3.0/ ! { dg-error "shall not appear in a DATA statement" }
+end
diff --git a/gcc/testsuite/gfortran.dg/pr88048.f90 b/gcc/testsuite/gfortran.dg/pr88048.f90
index 11293934330..ad82d45881c 100644
--- a/gcc/testsuite/gfortran.dg/pr88048.f90
+++ b/gcc/testsuite/gfortran.dg/pr88048.f90
@@ -2,6 +2,6 @@
! PR fortran/88048
program p
integer, parameter :: a(2) = 1
- data a(2) /a(1)/ ! { dg-error "definable entity" }
+ data a(2) /a(1)/ ! { dg-error "shall not appear in a DATA statement" }
print *, a
end
Re: [patch. fortran] PR102595 ICE in var_element, at fortran/decl.c
On 1/20/23 5:46 PM, Jerry D wrote: A PARAMETER value is not allowed in a DATA statement, similar to an EQUIVALENCE. The check for this was in gfc_assign_data_value() in data.cc which turns out to be too late when trying to assign a zero sized array. Correction, the chunk in data.cc must remain for one test case. I spotted this after rerunning check-fortran for several variations. Regards, Jerry
[patch, gfortran.dg] Allow test to pass on mingw
Hi all,
Similar to a patch I committed a while ago for Cygwin, the attached
patch allows it to pass on the mingw version of gfortran.
It is trivial.
Ok for trunk?
Regards,
Jerrydiff --git a/gcc/testsuite/gfortran.dg/bind_c_array_params_2.f90 b/gcc/testsuite/gfortran.dg/bind_c_array_params_2.f90
index 8dd7e8fb088..04faa433435 100644
--- a/gcc/testsuite/gfortran.dg/bind_c_array_params_2.f90
+++ b/gcc/testsuite/gfortran.dg/bind_c_array_params_2.f90
@@ -16,9 +16,9 @@ integer :: aa(4,4)
call test(aa)
end
-! { dg-final { scan-assembler-times "\[ \t\]\[$,_0-9\]*myBindC" 1 { target { ! { hppa*-*-* s390*-*-* *-*-cygwin* amdgcn*-*-* powerpc-ibm-aix*} } } } }
+! { dg-final { scan-assembler-times "\[ \t\]\[$,_0-9\]*myBindC" 1 { target { ! { hppa*-*-* s390*-*-* *-*-cygwin* amdgcn*-*-* powerpc-ibm-aix* *-*-ming* } } } } }
! { dg-final { scan-assembler-times "myBindC,%r2" 1 { target { hppa*-*-* } } } }
-! { dg-final { scan-assembler-times "call\tmyBindC" 1 { target { *-*-cygwin* } } } }
+! { dg-final { scan-assembler-times "call\tmyBindC" 1 { target { *-*-cygwin* *-*-ming* } } } }
! { dg-final { scan-assembler-times "brasl\t%r\[0-9\]*,myBindC" 1 { target { s390*-*-* } } } }
! { dg-final { scan-assembler-times "bl \.myBindC" 1 { target { powerpc-ibm-aix* } } } }
! { dg-final { scan-assembler-times "add_u32\t\[sv\]\[0-9\]*, \[sv\]\[0-9\]*, myBindC@rel32@lo" 1 { target { amdgcn*-*-* } } } }
[patch. fortran] PR102595 ICE in var_element, at fortran/decl.c
A PARAMETER value is not allowed in a DATA statement, similar to an
EQUIVALENCE.
The check for this was in gfc_assign_data_value() in data.cc which turns
out to be too late when trying to assign a zero sized array.
To correct this, the check is moved to match_variable() in primary.cc
where a similar check for EQUIVALENCE is already being performed.
Regression tested on x86_64-linux-gnu. I will create a test case from
the case presented in the PR which is trivial. There are already two
other tests in the test suite that exercise this check.
OK for trunk?
Regards,
Jerrydiff --git a/gcc/fortran/data.cc b/gcc/fortran/data.cc
index 443d35da9cf..d29eb12c1b1 100644
--- a/gcc/fortran/data.cc
+++ b/gcc/fortran/data.cc
@@ -244,13 +244,6 @@ gfc_assign_data_value (gfc_expr *lvalue, gfc_expr *rvalue, mpz_t index,
"array-element nor a scalar-structure-component";
symbol = lvalue->symtree->n.sym;
- if (symbol->attr.flavor == FL_PARAMETER)
-{
- gfc_error ("PARAMETER %qs shall not appear in a DATA statement at %L",
- symbol->name, >where);
- return false;
-}
-
init = symbol->value;
last_ts = >ts;
last_con = NULL;
diff --git a/gcc/fortran/primary.cc b/gcc/fortran/primary.cc
index 543d9cc0de4..158f039f225 100644
--- a/gcc/fortran/primary.cc
+++ b/gcc/fortran/primary.cc
@@ -4076,6 +4076,11 @@ match_variable (gfc_expr **result, int equiv_flag, int host_flag)
gfc_error ("Named constant at %C in an EQUIVALENCE");
return MATCH_ERROR;
}
+ if (gfc_in_match_data())
+ {
+ gfc_error ("PARAMETER %qs shall not appear in a DATA statement at %C",
+ sym->name);
+ }
/* Otherwise this is checked for and an error given in the
variable definition context checks. */
break;
Re: [Patch] libfortran: Fix execute_command_line for Windows
On 1/18/23 7:42 AM, Tobias Burnus wrote: Reported by nightstrike, who also tested this patch. On Windows, we call system() which works as described at https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/system-wsystem?view=msvc-170 Namely, it only fails with "-1" if the command interpreter could not be started. Otherwise, it has the return value. (Same on Linux.) On POSIX systems, 'sh' calls exit(127) or _exit(127) if it cannot execute the program of the passed string, as documented. Cf. https://www.unix.com/man-page/posix/3p/system/ Thus, the question is what happens on Windows. Our experiments, several webpages (like stackoverflow) and the source code of WINE for cmd.exe indicate that Windows returns 9009 in that case. See for instance https://github.com/wine-mirror/wine/blob/master/programs/cmd/wcmdmain.c#L1262-L1269 Thus, we now do likewise. The code is for MINGW; Cygwin does not set that that var and is likely to use return values closer to POSIX. OK for mainline? Tobias OK, thanks fir fix. Jerry
Re: [PING] nvptx: '-mframe-malloc-threshold', '-Wframe-malloc-threshold' (was: Handling of large stack objects in GPU code generation -- maybe transform into heap allocation?)
On 1/11/23 4:06 AM, Thomas Schwinge wrote: Hi! Ping -- the '-mframe-malloc-threshold' idea, at least. Note that while this issue originally did pop up for Fortran I/O, it's likewise relevant for other functions that maintain big frames, for example in newlib: libc/string/libc_a-memmem.o:.local .align 16 .b8 %frame_ar[2064]; libc/string/libc_a-strcasestr.o:.local .align 16 .b8 %frame_ar[2064]; libc/string/libc_a-strstr.o:.local .align 16 .b8 %frame_ar[2064]; libm/math/libm_a-k_rem_pio2.o:.local .align 16 .b8 %frame_ar[560]; Therefore a generic solution (or, workaround if you'd like) does seem appropriate. ---snip --- AS a gfortranner I have to at least say anyone doing fortran I/O on a GPU is nuts. With that said, a configurable option to address the broader issue makes sense. Perhaps the default threshold should be whatever it is now and if someone has a real situation where it is needed, they can adjust. Regards, Jerry
Re: testsuite under wine
On 1/5/23 7:33 PM, Jacob Bachmeyer via Fortran wrote:
NightStrike wrote:
On Fri, Dec 23, 2022 at 11:00 PM Jacob Bachmeyer
wrote:
NightStrike wrote:
On Wed, Dec 21, 2022 at 11:37 PM Jacob Bachmeyer
wrote:
[...]
So at least we know for sure that this particular instance of extra
characters is coming from Wine. Maybe Wine can be smart enough to
only translate \n into \r\n instead of translating \r\n into \r\r\n.
Jacek / Eric, comments here? I'm happy to try another patch, the
first one was great.
I doubt that Wine is doing that translation. MinGW libc produces output
conformant to Windows conventions, so printf("\n") on a text handle
emits "\r\n", which Wine passes along. POSIX convention is that "\n" is
translated to "\r\n" in the kernel terminal driver upon output, so the
kernel translates the "\n" in the "\r\n" into /another/ "\r\n", yielding
"\r\r\n" at the pty master end. This is why DejaGnu testsuites must be
prepared to discard excess carriage returns. The first CR came from
MinGW libc; the second CR came from the kernel terminal driver; the LF
was ultimately passed through.
Jacek and I have been digging into this on IRC, and he's been very
helpful in trying to get further, but we're still stuck. We tried to
be more introspective, inserting strace both as "strace script wine"
and as "script strace wine". We tried running just "wine a.exe"
without any extra glue, and logging the raw SSH packets from putty.
After many iterations on these and other tests, Jacek finally had the
idea to try removing Windows entirely from the equation, and we ran
with a purely unix program / compiler combination:
#include
int main()
{
write(1, "test\r\n", 6);
return 0;
}
(and also as "test\n", 5)
In both versions, the following was observed:
case 1) ./a.out | xxd
case 2) script -c ./a.out out; xxd out
case 3) enable putting logging, ./a.out
In case 1, xxd showed no extra \r's. In cases 2 and 3, there was an
extra \r (either 0d 0d 0a for test\r\n, or 0d 0a for test\n).
So, is it possible after all of this back and forth regarding mingw,
wine, and others, that it's down to the write() system call that's
inserting extra \r's? Is this expected?
"This is why DejaGnu testsuites must be prepared to discard excess
carriage returns."
The write(2) system call inserts nothing and simply hands off the buffer
to the relevant part of the kernel I/O subsystem. (The kernel in POSIX
is *not* a monolithic black box.) When stdout for your test program is
a pty slave, that relevant part is the kernel terminal driver. The
kernel terminal driver is converting "\n" to "\r\n" upon output to the
associated port, since hardware terminals typically *do* require CRLF.
The associated port in this case is virtual and part of the kernel pty
subsystem, which presents octets written to that port to its associated
pty master device. The user-visible pty slave device acts just like a
serial terminal, including all translations normally done for handling
serial terminals.
A pty is conceptually a null-modem cable connected between two
infinitely-fast serial ports on the same machine, although the slave
will still report an actual baud rate if queried. (Run "stty" with no
arguments under script(1), an ssh session, or an X11 terminal emulator
to see what a pty slave looks like on your machine.)
In your case 1, the pty subsystem is not used and output is collected
over a pipe. Using "./a.out > out; xxd out" would produce the same
results. In cases 2 and 3, there is a pty involved, either set up by
script(1) or by sshd (assuming you meant "enable putty logging" in case
3) that performs the standard terminal translations. In all cases,
strace(1) will show the exact string written to the pty slave device,
which will not include any extra CRs because *those* *are* *inserted*
*by* *the* *kernel* *terminal* *driver* as the data is transferred to
the pty master device's read queue.
This insertion of carriage returns is expected and standardized behavior
in POSIX and is the reason Unix could use bare LF as end-of-line even
though hardware terminals always needed CRLF. CP/M (and therefore
MS-DOS which began its existence as a cheap CP/M knockoff) did not have
this translation layer and instead dumped the complexity of a two-octet
end-of-line sequence on user programs, leading to much confusion even
today. This is not a Wine issue, although the terminal escape sequences
in your original issue *were* from Wine. Note that the number of excess
carriage returns that a DejaGnu testsuite must be prepared to discard is
unspecified because running tests on remote targets may result in *any*
*number* of CRs preceding each LF by the time the results reach the test
driver machine in more complex testing lab environments.
-- Jacob
Agree
Re: testsuite under wine
On 1/4/23 6:50 PM, NightStrike via Fortran wrote:
On Fri, Dec 23, 2022 at 11:00 PM Jacob Bachmeyer wrote:
NightStrike wrote:
On Wed, Dec 21, 2022 at 11:37 PM Jacob Bachmeyer wrote:
NightStrike wrote:
[...]
Second, the problems with extra \r's still remain, but I think we've
generally come to think that that part isn't Wine and is instead
either the testsuite or deja. So I'll keep those replies to Jacob's
previous message.
Most likely, it is a combination of the MinGW libc (which emits "\r\n"
for end-of-line in accordance with Windows convention) and the kernel
terminal driver (which passes "\r" and translates "\n" to "\r\n" in
accordance with POSIX convention). Wine, short of trying to translate
"\r\n" back to "\n" in accordance with POSIX conventions (and likely
making an even bigger mess---does Wine know if a handle is supposed to
be text or binary?) cannot really fix this, so the testsuite needs to
handle non-POSIX-standard line endings. (The Rust tests probably have
an outright bug if the newlines are being duplicated.)
You may be onto something here. I ran wine under script as `script -c
"wine64 ./a.exe" out` (thanks, Arsen!), and it had the same extra \r
prepended to the \r\n. I was making the mistake previously of running
wine manually and capturing it to a file as `wine64 ./a.exe > out`,
which as several have pointed out in this thread, that would disable
the quirk, so of course it didn't reveal any problems. I'm behind,
but I'll catch up to you guys eventually :)
So close, and yet so far... script(1) /also/ uses a pty, so it is
getting the same translations as Expect and therefore DejaGnu.
So at least we know for sure that this particular instance of extra
characters is coming from Wine. Maybe Wine can be smart enough to
only translate \n into \r\n instead of translating \r\n into \r\r\n.
Jacek / Eric, comments here? I'm happy to try another patch, the
first one was great.
I doubt that Wine is doing that translation. MinGW libc produces output
conformant to Windows conventions, so printf("\n") on a text handle
emits "\r\n", which Wine passes along. POSIX convention is that "\n" is
translated to "\r\n" in the kernel terminal driver upon output, so the
kernel translates the "\n" in the "\r\n" into /another/ "\r\n", yielding
"\r\r\n" at the pty master end. This is why DejaGnu testsuites must be
prepared to discard excess carriage returns. The first CR came from
MinGW libc; the second CR came from the kernel terminal driver; the LF
was ultimately passed through.
Jacek and I have been digging into this on IRC, and he's been very
helpful in trying to get further, but we're still stuck. We tried to
be more introspective, inserting strace both as "strace script wine"
and as "script strace wine". We tried running just "wine a.exe"
without any extra glue, and logging the raw SSH packets from putty.
After many iterations on these and other tests, Jacek finally had the
idea to try removing Windows entirely from the equation, and we ran
with a purely unix program / compiler combination:
#include
int main()
{
write(1, "test\r\n", 6);
return 0;
}
(and also as "test\n", 5)
In both versions, the following was observed:
case 1) ./a.out | xxd
case 2) script -c ./a.out out; xxd out
case 3) enable putting logging, ./a.out
In case 1, xxd showed no extra \r's. In cases 2 and 3, there was an
extra \r (either 0d 0d 0a for test\r\n, or 0d 0a for test\n).
So, is it possible after all of this back and forth regarding mingw,
wine, and others, that it's down to the write() system call that's
inserting extra \r's? Is this expected?
I have reproduced this test with C. I suspect that the 'write' function
was written to accommodate non standard behavior of windows which
expects a CR-LF. This means that POSIX compliant code is adjusted by
the C or gfortran libraries to emit a extra CR so that on Windows it
will just work ok. So the test is doing exactly what you are telling it
to do. An LF causes the run times to add a CR in front.
With libgfortran I remember implementing some of this code myself and
this is the reason, to keep applications happy on Windows.
So the gfortran tests we wrote to accept either a CR or a CR-LF, and in
the test code to only issue a normal line ending which on UNIX will be
an LF and Windows an CR-LF.
I lose track of details in between looking ta the test cases. let me
know one of them to study that is gfortran side and will see what it is
doing.
Jerry
[patch, fortran] ICE in attr_decl1, at fortran/decl.c:8691
The attached patch was provided by Steve Kargl. After exploring for
possible other checks I settled on leaving the patch intact.
Two existing test cases updated as different but sensible error messages
resulted.
Regression tested on main line.
OK to commit?
Regards,
Jerry
Author: Steve Kargl
Date: Mon Dec 26 14:07:04 2022 -0800
Modify checks to avoid referencing NULL pointer.
Update test cases with error messages that changed as a result.
gcc/fortran/ChangeLog:
* decl.cc (attr_decl1): Guard against NULL pointer.
* parse.cc (match_deferred_characteristics): Include
BT_CLASS in check for
derived being undefined.
gcc/testsuite/ChangeLog:
* gfortran.dg/class_result_4.f90: Update error message check.
* gfortran.dg/pr85779_3.f90: Update error message check.diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index e593518a77e..bac7b6568b0 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -8743,7 +8743,9 @@ attr_decl1 (void)
/* Update symbol table. DIMENSION attribute is set in
gfc_set_array_spec(). For CLASS variables, this must be applied
to the first component, or '_data' field. */
- if (sym->ts.type == BT_CLASS && sym->ts.u.derived->attr.is_class)
+ if (sym->ts.type == BT_CLASS
+ && sym->ts.u.derived
+ && sym->ts.u.derived->attr.is_class)
{
/* gfc_set_array_spec sets sym->attr not CLASS_DATA(sym)->attr. Check
for duplicate attribute here. */
diff --git a/gcc/fortran/parse.cc b/gcc/fortran/parse.cc
index bc2b2188eea..6186c48aee2 100644
--- a/gcc/fortran/parse.cc
+++ b/gcc/fortran/parse.cc
@@ -3934,7 +3934,7 @@ match_deferred_characteristics (gfc_typespec * ts)
m = gfc_match_prefix (ts);
gfc_buffer_error (false);
- if (ts->type == BT_DERIVED)
+ if (ts->type == BT_DERIVED || ts->type == BT_CLASS)
{
ts->kind = 0;
@@ -4215,7 +4215,7 @@ declSt:
if (bad_characteristic)
{
ts = _current_block ()->result->ts;
- if (ts->type != BT_DERIVED)
+ if (ts->type != BT_DERIVED && ts->type != BT_CLASS)
gfc_error ("Bad kind expression for function %qs at %L",
gfc_current_block ()->name,
_current_block ()->declared_at);
diff --git a/gcc/testsuite/gfortran.dg/class_result_4.f90 b/gcc/testsuite/gfortran.dg/class_result_4.f90
index 4b22a3c30ee..5497ac652ec 100644
--- a/gcc/testsuite/gfortran.dg/class_result_4.f90
+++ b/gcc/testsuite/gfortran.dg/class_result_4.f90
@@ -1,6 +1,6 @@
! { dg-do compile }
! PR fortran/78500
-class(t) function f() ! { dg-error "must be dummy, allocatable or pointer" }
+class(t) function f() ! { dg-error "is not accessible" }
f = 1 ! { dg-error "variable must not be polymorphic" }
end
diff --git a/gcc/testsuite/gfortran.dg/pr85779_3.f90 b/gcc/testsuite/gfortran.dg/pr85779_3.f90
index fba1133b3ea..a81a9faf88e 100644
--- a/gcc/testsuite/gfortran.dg/pr85779_3.f90
+++ b/gcc/testsuite/gfortran.dg/pr85779_3.f90
@@ -1,6 +1,6 @@
! { dg-do compile }
! PR fortran/85779
-class(t) function f() ! { dg-error "must be dummy, allocatable or pointer" }
+class(t) function f() ! { dg-error "is not accessible" }
type f ! { dg-error "already has a basic type" }
end type ! { dg-error "END FUNCTION statement" }
end
Re: nvptx: '-mframe-malloc-threshold', '-Wframe-malloc-threshold' (was: Handling of large stack objects in GPU code generation -- maybe transform into heap allocation?)
On 12/23/22 6:08 AM, Thomas Schwinge wrote:
Hi!
On 2022-11-11T15:35:44+0100, Richard Biener via Fortran
wrote:
On Fri, Nov 11, 2022 at 3:13 PM Thomas Schwinge wrote:
For example, for Fortran code like:
write (*,*) "Hello world"
..., 'gfortran' creates:
struct __st_parameter_dt dt_parm.0;
try
{
dt_parm.0.common.filename =
&"source-gcc/libgomp/testsuite/libgomp.oacc-fortran/print-1_.f90"[1]{lb: 1 sz:
1};
dt_parm.0.common.line = 29;
dt_parm.0.common.flags = 128;
dt_parm.0.common.unit = 6;
_gfortran_st_write (_parm.0);
_gfortran_transfer_character_write (_parm.0, &"Hello world"[1]{lb:
1 sz: 1}, 11);
_gfortran_st_write_done (_parm.0);
}
finally
{
dt_parm.0 = {CLOBBER(eol)};
}
The issue: the stack object 'dt_parm.0' is a half-KiB in size (yes,
really! -- there's a lot of state in Fortran I/O apparently). That's a
problem for GPU execution -- here: OpenACC/nvptx -- where typically you
have small stacks. (For example, GCC/OpenACC/nvptx: 1 KiB per thread;
GCC/OpenMP/nvptx is an exception, because of its use of '-msoft-stack'
"Use custom stacks instead of local memory for automatic storage".)
Now, the Nvidia Driver tries to accomodate for such largish stack usage,
and dynamically increases the per-thread stack as necessary (thereby
potentially reducing parallelism) -- if it manages to understand the call
graph. In case of libgfortran I/O, it evidently doesn't. Not being able
to disprove existance of recursion is the common problem, as I've read.
At run time, via 'CU_JIT_INFO_LOG_BUFFER' you then get, for example:
warning : Stack size for entry function 'MAIN__$_omp_fn$0' cannot be
statically determined
That's still not an actual problem: if the GPU kernel's stack usage still
fits into 1 KiB. Very often it does, but if, as happens in libgfortran
I/O handling, there is another such 'dt_parm' put onto the stack, the
stack then overflows; device-side SIGSEGV.
(There is, by the way, some similar analysis by Tom de Vries in
<https://gcc.gnu.org/PR85519> "[nvptx, openacc, openmp, testsuite]
Recursive tests may fail due to thread stack limit".)
Of course, you shouldn't really be doing I/O in GPU kernels, but people
do like their occasional "'printf' debugging", so we ought to make that
work (... without pessimizing any "normal" code).
I assume that generally reducing the size of 'dt_parm' etc. is out of
scope.
There are so many wiggles and turns and corner cases and the like of
nightmares in I/O I would advise not trying to reduce the dt_parm. It
could probably be done.
For debugging GPU, would it not be better to have a way you signal back
to a main thread to do a print from there, like some sort of call back
in the users code under test.
Putting this another way, recommend users debugging to use a different
method than embedding print statements for debugging rather than do a
tone of work to enable something that is not really a legitimate use case.
FWIW,
Jerry
Re: [PATCH] Fortran: incorrect array bounds when bound intrinsic used in decl [PR108131]
On 12/17/22 1:21 PM, Harald Anlauf via Fortran wrote: Dear all, the previous fix for pr103505 introduced a regression that could lead to wrong array bounds when LBOUND/UBOUND were used in the array spec of a declaration. The reason was that we tried to simplify too early the array element spec, which appears to have interfered with the subtle semantics of the bound intrinsics. The solution is to undo the fix for pr103505. It turns out that there are other code changes in place that were put in place to fix related ICEs, and which handle that one, too, and only lead to a change of the emitted error diagnostics. Regtested on x86_64-pc-linux-gnu. OK for mainline? Yes, OK for mainline. My thought is that this is the kind of bug that can go unseen with incorrect array bounds so is a good candidate to backport. At least 12, 10 and 11 if you have time and it is applicable. As this is a 10/11/12/13 regression, I would like to backport as seems fit. Thanks, Harald
[patch, fortran] ICE on automatic array of derived type with DTIO
I have committed the obvious as simple. The master branch has been updated by Jerry DeLisle : https://gcc.gnu.org/g:7e76cd96950f49ce21246d44780e972d86b2bcdd commit r13-4862-g7e76cd96950f49ce21246d44780e972d86b2bcdd Author: Steve Kargl Date: Thu Dec 22 20:38:57 2022 -0800 Remove not needed assert macro which fails. PR fortran/106731 gcc/fortran/ChangeLog: * trans-array.cc (gfc_trans_auto_array_allocation): Remove gcc_assert (!TREE_STATIC()). gcc/testsuite/ChangeLog: * gfortran.dg/pr106731.f90: New test.
Re: [committed] testsuite: Fix up pr107397.f90 test [PR107397]
On 12/19/22 2:29 AM, Jakub Jelinek wrote: On Sat, Dec 17, 2022 at 09:12:43AM -0800, Jerry D via Gcc-patches wrote: The attached patch fixes a regression and is a patch from Steve. I have regression tested it and provided a test case. It is fairly simple and I will commit under the "simple" rule in a little while. Thanks Steve for Patch. Thanks Harald for helping me get back up to speed on the git magic. The pr107397.f90 test FAILs for me, one problem was that the added diagnostics has an indefinite article before BOZ, but the test dg-error didn't. The other problem was that on the other dg-error there was no space between the string and closing }, so it was completely ignored and the error was an excess error. 2022-12-19 Jakub Jelinek PR fortran/107397 * gfortran.dg/pr107397.f90: Adjust expected diagnostic wording and add space between dg-error string and closing }. === snip === Thanks Jakub.
[patch, fortran] PR107397 ICE in gfc_arith_plus, at fortran/arith.cc:654
Hi all,
The attached patch fixes a regression and is a patch from Steve. I have
regression tested it and provided a test case. It is fairly simple and
I will commit under the "simple" rule in a little while.
Thanks Steve for Patch. Thanks Harald for helping me get back up to
speed on the git magic.
Regards,
Jerry
diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index 0f9b2ced4c2..1562dc22bc6 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -2221,6 +2221,14 @@ add_init_expr_to_sym (const char *name, gfc_expr **initp, locus *var_locus)
sym->ts.f90_type = init->ts.f90_type;
}
+ /* Catch the case: type(t), parameter :: x = z'1'. */
+ if (sym->ts.type == BT_DERIVED && init->ts.type == BT_BOZ)
+ {
+ gfc_error ("Entity %qs at %L is incompatible with a BOZ "
+ "literal constant", name, >declared_at);
+ return false;
+ }
+
/* Add initializer. Make sure we keep the ranks sane. */
if (sym->attr.dimension && init->rank == 0)
{
diff --git a/gcc/testsuite/gfortran.dg/pr107397.f90 b/gcc/testsuite/gfortran.dg/pr107397.f90
new file mode 100644
index 000..4592a275e70
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr107397.f90
@@ -0,0 +1,9 @@
+!{ dg-do compile }
+!
+program p
+ type t
+real :: a = 1.0
+ end type
+ type(t), parameter :: x = z'1' ! { dg-error "incompatible with BOZ" }
+ x%a = x%a + 2 ! { dg-error "has no IMPLICIT type"}
+end
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: [PATCH, committed] Fortran: error recovery for bad initializers of implied-shape arrays [PR106209]
Hi Herald, Looks good to me. I have always preferred informative messages. Thanks, Jerry On 7/14/22 1:34 PM, Harald Anlauf via Fortran wrote: Dear all, the attached patch introduces error recovery for two cases of using an invalid array in a declaration of an implied-shape array instead of hitting internal errors. Initial patch by Steve. The final version was approved in the PR by Steve. Committed as: https://gcc.gnu.org/g:748f8a8b145dde59c7b63aa68b5a59515b7efc49 Thanks, Harald
Re: *PING* [PATCH 0/4] Use pointer arithmetic for array references [PR102043]
Yes, Thank you Mikael! On 4/22/22 6:59 AM, Thomas Koenig via Fortran wrote: Hi Mikael, Ping for the four patches starting at https://gcc.gnu.org/pipermail/fortran/2022-April/057759.html : https://gcc.gnu.org/pipermail/fortran/2022-April/057757.html https://gcc.gnu.org/pipermail/fortran/2022-April/057760.html https://gcc.gnu.org/pipermail/fortran/2022-April/057758.html https://gcc.gnu.org/pipermail/fortran/2022-April/057761.html Richi accepted the general direction and the middle-end interaction. I need a fortran frontend ack as well. Looks good to me. Thanks a lot for taking this on! This would have been a serious regression if released with gcc 12. Best regards Thomas
Re: *Ping* [PATCH] PR fortran/104210 - [11/12 Regression] ICE in gfc_zero_size_array, at fortran/arith.cc:1685
On 4/4/22 12:09 PM, Harald Anlauf via Fortran wrote: Am 29.03.22 um 23:41 schrieb Harald Anlauf via Fortran: Dear all, during error recovery on invalid declarations of functions as coarrays we may hit multiple places with NULL pointer dereferences. The attached patch provides a minimal and conservative solution. Regtested on x86_64-pc-linux-gnu. OK for mainline/11-branch? Thanks, Harald Patch looks OK Harald, OK. Thanks, Jerry
Re: [PATCH] PR fortran/105138 - Bogus error when function name does not shadow an intrinsic when RESULT clause is used
On 4/4/22 12:04 PM, Harald Anlauf via Fortran wrote: Dear all, Steve's analysis (see PR) showed that we confused the case when a symbol refererred to a recursive procedure which was named the same as an intrinsic. The standard allows such recursive references (see e.g. F2018:19.3.1). The attached patch is based on Steve's, but handles both functions and subroutines. Testcase verified with NAG and Crayftn. Regtested on x86_64-pc-linux-gnu. OK for mainline? This bug is a rejects-valid, but could also lead to wrong code, see e.g. the PR, comment#4. Would this qualify for a backport to e.g. the 11-branch? Thanks, Harald Yes, looks good, OK to commit Regards, Jerry
Re: GCC GSoC 2022: Call for project ideas and mentors
Perhaps someone could work on completing and merging the shared memory (native) fortran coarrays branch. Regards, Jerry On 3/9/22 6:39 AM, Martin Jambor wrote: Hello, I am pleased that I can announce that GCC has been accepted as a mentoring organization of Google Summer of Code 2022. Contributors(*) will be applying from April 4th to April 19th but have already seen some announcing their intention to apply and asking for guidance when selecting a project and preparing their applications. Please continue helping them figure stuff out about GCC like you always do. If anyone still wants to add a project to our idea list (and sign up to be a potential mentor), now is the time to do it. I'm looking forward to another year of interesting projects, Martin (*) Contributors no longer have to be students - they should however be "new or beginner" contributors to our project with the exception that participants of GSoC 2020 or GSoC 2021 can apply. More on changes this year is in my original call for projects: https://gcc.gnu.org/pipermail/gcc/2022-January/238006.html
Re: [PATCH] PR fortran/84519 - [F2018] STOP and ERROR STOP statements with QUIET specifier
On 2/23/22 2:21 PM, Harald Anlauf via Fortran wrote: Dear Fortranners, Fortran 2018 added a QUIET= specifier to STOP and ERROR STOP statements. Janne already implemented the library side code four (4!) years ago, but so far the frontend implementation was missing. Furthermore, F2018 allows for non-default-integer stopcode expressions (finally!). The attached patch provides this implementation. That was not too much fun for the following reasons: - fixed format vs. free format - F95 and F2003 apparently did not require a blank between STOP and stopcode, while F2008+ do require it. This should explain for the three testcases. Regtested on x86_64-pc-linux-gnu. OK for mainline? One step closer to F2018! Thanks, Harald A minor comment. Is there a way to also have a run-time test case? OK to commit now and additional test case can be added if necessary later. Regards, Jerry
