Re: TO DOWNLOAD FREE FORTRAN

[Jerry D]

On 6/23/24 11:33 PM, ΚΩΣΤΑΣ ΚΥΡΙΑΚΟΠΟΥΛΟΣ wrote:

TO THE GNU ORGANIZATION    24-6-2024


Goodmorning!I am a mechanical engineer who loves mathematics and work 
after my graduate thesis in mechanical engineering with higher 
mathematics and excellent knowledge of FORTRAN on  a PhD research on the 
exact medical image analysis for every type of medical images per pixel 
for the therapy of every kind of traumas and diseases of the human 
neural system and I want to work with the compiler of Fortran.I have the 
prosthesis and I will do it to inform you for every important result 
having to do with the potential of the language. Can I download it for free?


SIGNATURE OF MY MESSAGE,
KOSTAS APOSTOLOS KYRIAKOPOULOS,MECHANICAL ENGINEER,GRADUATE DIPLOMA 
OWNER,FIRST WITH GRADE OF DIPLOMA 8.13,UNIVERSITY OF THESSALY,MEMBER OF 
THE GREEK CHAMBER OF ENGINEERS,PHD RESEARCH IN BIOMEDICAL ENGINEERING 
FOR THE THERAPY OF ALL KIND OF DISEASES AND TRAUMAS OF THE HUMAN NEURAL 
SYSTEM,IEEE,UNIVERSITY OF PELOPONNESUS  WITH CONTRIBUTION IN THE 
IMPROVEMENT OF THE QUALITY OF LIFE OF ATHLETES OF BASKETBALL ON 
WHEELCHAIR IN THE INTERNATIONAL CONFERENCE OF THE SCHOOL OF SPORTS 
MANAGEMENT OF THE UNIVERSITY OF PELOPONNESUS .I HAVE ATTENDED THE 
UNIVERSITY OF THE SOCIETY,THE SERIES OF LECTURE OF JEAN MONNET IN THE 
SCHOOL OF POLITICAL SCIENCE AND INTERNATIONAL RELATIONS OF THE 
UNIVERSITY OF PELOPONNESUS.
MY ENGINEERING OFFICE ADDRESS;OMIRON 12 AND VARVOGLI 
STREET-ENTRANCE,TRIPOLIS,GREECE,my mob.phone number:6989561101,MY EMAIL 
ADDRESS:kostaskakour...@gmail.com 



Yes yo can get it free. Let us know what computer system you are using 
and I can guide you or pointt you to someone who can help.


Regards,

Jerry

Re: [pushed] readings: Drop FORTRAN 77 test suite at itl.nist.gov

[Jerry D]

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]

[Jerry D]

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

Re: Mattermost discussion on PR98426

[Jerry D]

On 4/26/24 2:47 AM, Tobias Burnus wrote:

Hi Bernhard, hello all,

Bernhard Reutner-Fischer wrote:

PS: unfortunately the git branch (
https://gcc.gnu.org/git/?p=gcc.git;a=log;h=refs/heads/aldot/fortran-fe-stringpool
  ) mentioned in mail (I) lived in the old git, before we switched to
git, and i fear that branch maybe got lost.


Try gcc-old.git instead:

https://gcc.gnu.org/git/?p=gcc-old.git;a=log;h=refs/heads/aldot/fortran-fe-stringpool

Tobias


I found these (and several more) patches dated around 2018.

https://gcc.gnu.org/git/?p=gcc-old.git;a=commitdiff;h=d38e734485cc84ed0eda7f30b16fb62bdb0cb174

https://gcc.gnu.org/git/?p=gcc-old.git;a=commitdiff;h=2b3f2cd325234a8eb9e9e197ebbbc18de623d7bb

https://gcc.gnu.org/git/?p=gcc-old.git;a=commitdiff;h=f77b9ecc5fac886164fee75254aca14c42e95f1b

https://gcc.gnu.org/git/?p=gcc-old.git;a=commitdiff;h=48d6fc163c26752ca53f23d8b846102338c32ad9

The question is how do we merge these with current master?

Jerry --

Mattermost discussion on PR98426

[Jerry D]

Hi posted some thoughts on the subject at our mattermost workspace.

This particular PR caught my attention because I have done things like 
this before. I am looking forward to gcc15. I think changing things at 
this point might be a bit intrusive.


I am thinking about:

"The FNV-1a algorithm is:

hash = FNV_offset_basis
for each octetOfData to be hashed
hash = hash xor octetOfData
hash = hash * FNV_prime
return hash"

Found here:

https://softwareengineering.stackexchange.com/questions/49550/which-hashing-algorithm-is-best-for-uniqueness-and-speed

If you are interested, comment on MatterMost.

Jerry -

Re: [Patch, fortran] PR114535 - [13/14 regression] ICE with elemental finalizer

[Jerry D]

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]

[Jerry D]

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

Re: Recommended developer options when building GCC from source

[Jerry D]

On 4/6/24 4:54 PM, Neil Carlson wrote:
What are the recommended options to use (e.g., --enable-libsanitize) 
when building GCC from source for the purpose of locating gfortran bugs? 
I'm trying to pin down a runtime memory corruption error, and I recall 
seeing at various times in the past recommendations for creating a 
suitable gfortran build and the associated gfortran command line options 
for dumping internal info, but I can't seem to find that info now.


Thanks!


I use this:

#! /bin/bash

rm -rf /home/jerry/dev/objdir/*
cd /home/jerry/dev/objdir
../trunk/configure --prefix=/home/jerry/dev/usr 
--enable-languages=c,c++,fortran --enable-libgomp --disable-

bootstrap --enable-valgrind-annotations
make -j10 1>/dev/null && make install 1>/dev/null
echo "Build of trunk complete.."

-fdump-tree-original is one of the options if you intend to do front-end 
work.


More info here:

Must read links for new developers/contributors:

https://gcc.gnu.org/fortran/

https://www.gnu.org/prep/standards/standards.html

https://gcc.gnu.org/gitwrite.html

https://gcc.gnu.org/wiki/GFortranHacking

https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gccint/

Re: [patch, libgfortran] PR114304 - [13/14 Regression] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"

[Jerry D]

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'"

[Jerry D]

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'"

[Jerry D]

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 ;', .true.) ! No error shown
+  call t(.true.,  

Re: [patch, libgfortran] PR114304 - [13/14 Regression] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"

[Jerry D]

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'"

[Jerry D]

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: Invalid "dg-do run" in the testsuite (with 2 blanks)

[Jerry D]

On 4/1/24 11:46 PM, Andrew Pinski wrote:

On Sun, Mar 24, 2024 at 1:19 PM Harald Anlauf  wrote:


Dear all,

I noticed by chance that we have quite a lot of improperly specified do-do
directives in the testsuite.

% grep "dg-do  run" gcc/testsuite/gfortran.dg/ -rl|wc -l
83

Note that with two blanks instead of just one a testcase does not get executed.

Does anybody want to earn the honors to change the directives and
check for "fallout" in the testsuite?


Note this seems related to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28032 (or maybe this is
the "workaround" for not doing torture options on the testcases).

If this gets documented to avoid doing the torture options, then the
testsuite should be auditted for dg-options with `-ON` and add the
extra space for dg-do to get the non torture way.

Thanks,
Andrew



Cheers,
Harald



Thanks for this additional info. I have not settled on exactly what to say in 
the documentation.

I noticed that when I specified a specific -ON it still did them all 
regardless.  I did not know if this was expected or a feature.

Jerry -

Re: [PATCH] Fortran: fix DATA and derived types with pointer components [PR114474]

[Jerry D]

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 -

[patch, libgfortran] PR107031 - endfile truncates file at wrong position

[Jerry D]

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

Re: Aw: Re: Invalid "dg-do run" in the testsuite (with 2 blanks)

[Jerry D]

On 3/25/24 3:30 PM, Harald Anlauf wrote:

On 3/25/24 12:53 PM, Harald Anlauf wrote:

I noticed by chance that we have quite a lot of improperly specified do-do
directives in the testsuite.

% grep "dg-do  run" gcc/testsuite/gfortran.dg/ -rl|wc -l
83



I think this is on purpose.
The idea to use a "feature" in dejagnu to only iterate once and not
over all possible options. So execution time can be lowered a bit.

But I don't know if this hack still works, it definitely did work some years 
ago.

Cheers,
Manfred


Is this "feature" documented somewhere?  I don't see it on

https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gccint/Directives.html

Given that the dg-directives are important and possibly fragile,
and since we had issues in the past, can we check that a test
that was added works the way intended?


Note that with two blanks instead of just one a testcase does not get executed.

Does anybody want to earn the honors to change the directives and
check for "fallout" in the testsuite?

Cheers,
Harald



One failure after fixing all the spaces ( sed is our friend ).

FAIL: gfortran.dg/inline_matmul_1.f90   -O0   scan-tree-dump-times optimized 
"_gfortran_matmul" 0


This does actually point to an issue with the testcase:
it only works properly with optimization enabled.

Manual inspection of this test and the expected dump suggests
that e.g. -O1 could have been added to the dg-options directive.

Shouldn't we fix at least the dg-options of that testcase?

Cheers,
Harald



I restored the one test that appeared to fail so that it had the two
spaces 'trick'.  When run in the test suite, it is compiled with -O
which does invoke the optimization.  I manually checked the tree dump
with this option and it indeed has all the _gfortran_matmul calls removed.

I am inclined to leave these all untouched with the two spaces in place.

  From the test log:

PASS: gfortran.dg/inline_matmul_1.f90   -O  execution test
PASS: gfortran.dg/inline_matmul_1.f90   -O   scan-tree-dump-times
optimized "_gfortran_matmul" 0


Alright, then leave it that way.

I find it somewhat unsatisfactory though, to have a behavior of the
testsuite harness that is so intranparent.

If it is a simple oversight that the behavior of double space was
never documented, it could simply be fixed, for the sake of everybody.

The take-home message for me is - whenever I write a testcase that
relies on this behavior - to add a comment in the header that this
is intended behavior, and set all compiler flags appropriately...

Cheers,
Harald




With two spaces there are 9 tests run at -O, with one space there are 54 
variations executed. Specifying the optimization option in the 
dg-options also runs 54 variations.  It appears that the "feature" was 
done on purpose, but it is frustrating that this is not documented anywhere.


I do remember discussions way back about some tests taking a long time 
to run and needing a way to speed up the overall testing.  I will look 
over the documentation and see if we can get this addressed.


For my own test cases, I have always specified the options I want and 
for front-end work, optimizations don't usually matter except in this 
case.  I don't have time to go through all 83 tests.


From my system here:

Testing of trunk complete. one space

real4m56.294s
user35m51.082s
sys 12m51.283s


Testing of trunk complete. two spaces

real4m44.421s
user34m3.215s
sys 12m38.778s

Not a huge difference.

Jerry

Re: Invalid "dg-do run" in the testsuite (with 2 blanks)

[Jerry D]

On 3/25/24 12:53 PM, Harald Anlauf wrote:

I noticed by chance that we have quite a lot of improperly specified do-do
directives in the testsuite.

% grep "dg-do  run" gcc/testsuite/gfortran.dg/ -rl|wc -l
83



I think this is on purpose.
The idea to use a "feature" in dejagnu to only iterate once and not
over all possible options. So execution time can be lowered a bit.

But I don't know if this hack still works, it definitely did work some years 
ago.

Cheers,
Manfred


Is this "feature" documented somewhere?  I don't see it on

https://gcc.gnu.org/onlinedocs/gcc-13.2.0/gccint/Directives.html

Given that the dg-directives are important and possibly fragile,
and since we had issues in the past, can we check that a test
that was added works the way intended?


Note that with two blanks instead of just one a testcase does not get executed.

Does anybody want to earn the honors to change the directives and
check for "fallout" in the testsuite?

Cheers,
Harald



One failure after fixing all the spaces ( sed is our friend ).

FAIL: gfortran.dg/inline_matmul_1.f90   -O0   scan-tree-dump-times optimized 
"_gfortran_matmul" 0


This does actually point to an issue with the testcase:
it only works properly with optimization enabled.

Manual inspection of this test and the expected dump suggests
that e.g. -O1 could have been added to the dg-options directive.

Shouldn't we fix at least the dg-options of that testcase?

Cheers,
Harald



I restored the one test that appeared to fail so that it had the two 
spaces 'trick'.  When run in the test suite, it is compiled with -O 
which does invoke the optimization.  I manually checked the tree dump 
with this option and it indeed has all the _gfortran_matmul calls removed.


I am inclined to leave these all untouched with the two spaces in place.

From the test log:

PASS: gfortran.dg/inline_matmul_1.f90   -O  execution test
PASS: gfortran.dg/inline_matmul_1.f90   -O   scan-tree-dump-times 
optimized "_gfortran_matmul" 0


Regards,

Jerry

Re: Invalid "dg-do run" in the testsuite (with 2 blanks)

[Jerry D]

On 3/25/24 1:27 AM, Manfred Schwarb wrote:

Am 25.03.24 um 05:53 schrieb Jerry D:

On 3/24/24 1:19 PM, Harald Anlauf wrote:

Dear all,

I noticed by chance that we have quite a lot of improperly specified do-do
directives in the testsuite.

% grep "dg-do  run" gcc/testsuite/gfortran.dg/ -rl|wc -l
83



I think this is on purpose.
The idea to use a "feature" in dejagnu to only iterate once and not
over all possible options. So execution time can be lowered a bit.

But I don't know if this hack still works, it definitely did work some years 
ago.

Cheers,
Manfred



Note that with two blanks instead of just one a testcase does not get executed.

Does anybody want to earn the honors to change the directives and
check for "fallout" in the testsuite?

Cheers,
Harald



One failure after fixing all the spaces ( sed is our friend ).

FAIL: gfortran.dg/inline_matmul_1.f90   -O0   scan-tree-dump-times optimized 
"_gfortran_matmul" 0

Jerry -




Yes it still works, I noticed the tests will do two passes each rather 
than 12 per file.


I will hold off on doing anything with these.

Regards,

Jerry -

Re: Invalid "dg-do run" in the testsuite (with 2 blanks)

[Jerry D]

On 3/24/24 1:19 PM, Harald Anlauf wrote:

Dear all,

I noticed by chance that we have quite a lot of improperly specified do-do
directives in the testsuite.

% grep "dg-do  run" gcc/testsuite/gfortran.dg/ -rl|wc -l
83

Note that with two blanks instead of just one a testcase does not get executed.

Does anybody want to earn the honors to change the directives and
check for "fallout" in the testsuite?

Cheers,
Harald



One failure after fixing all the spaces ( sed is our friend ).

FAIL: gfortran.dg/inline_matmul_1.f90   -O0   scan-tree-dump-times 
optimized "_gfortran_matmul" 0


Jerry -

Re: Invalid "dg-do run" in the testsuite (with 2 blanks)

[Jerry D]

On 3/24/24 1:19 PM, Harald Anlauf wrote:

Dear all,

I noticed by chance that we have quite a lot of improperly specified do-do
directives in the testsuite.

% grep "dg-do  run" gcc/testsuite/gfortran.dg/ -rl|wc -l
83

Note that with two blanks instead of just one a testcase does not get executed.

Does anybody want to earn the honors to change the directives and
check for "fallout" in the testsuite?

Cheers,
Harald



I will do this for the betterment of the order of all good people. I 
need the therapy after beating my head against a wall last week eating 
separators. :)


Cheers,

Jerry -

Re: [patch, libgfortran] Part 2: PR105456 Child I/O does not propage iostat

[Jerry D]

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 -

Re: [patch, libgfortran] Part 2: PR105456 Child I/O does not propage iostat

[Jerry D]

On 3/6/24 9:13 AM, Harald Anlauf wrote:

"The users message containing % and %% and %s and other stuff"


I see what you mean. our standard error messages are expecting values in 
these places and since none are there, fault.


Should we simply output "The users message containing % and %% and %s 
and other stuff" literally? Does intel allow inserting things like error 
locus in these message strings?


Regards,

Jerry

Re: [patch, libgfortran] Part 2: PR105456 Child I/O does not propage iostat

[Jerry D]

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


I do not have the intel compiler.

I will look at this but I do not know what the expectation is.

Is there non-standard treatment of % symbols?

Jerry

Re: [patch, libgfortran] Part 2: PR105456 Child I/O does not propage iostat

[Jerry D]

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

[Jerry D]

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]

[Jerry D]

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

[Jerry D]

On 2/29/24 12:56 PM, Steve Kargl wrote:

On Thu, Feb 29, 2024 at 10:28:19AM -0800, 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?



If I look at the interfaces for UDTIO in F2023 (pp. 254-255),
the declaration for iomsg is

   CHARACTER (LEN=*), INTENT(INOUT) :: iomsg

F2023 (p. 62) has
   An asterisk as a type-param-value specifies that a length type
   parameter is an assumed type parameter.  It is used for a dummy
   argument to assume the type parameter value from the effective
   argument, ...

So, in theory, one should be able to get the required length
from length from the argument.

   CHARACTER(LEN=23) str
   WRITE(6,'(DT)',iomsg=str) derived-type-entity

If the subroutine supplied by the user internally creates
an error message with 300 characters, then from the above I
would think that it will be truncated to 23 characters.
OTOH, if the user is expecting the full 300 characters with

   CHARACTER(LEN=300) str
   WRITE(6,'(DT)',iomsg=str) derived-type-entity

then truncating internally to 256 seems wrong.

Now, that I looked at the interface more closely, the declaration

   CHARACTER (LEN=*), INTENT(INOUT) :: iomsg

seems to block the use of an unallocated deferred-length 'str'
and (re)-allocation does not occur.

  

Without addressing the length discussions above, I did find an existing 
function in libgfortran to trim the spaces at the end (string_len_trim). 
 I am using it as follows:


if ((dtp->u.p.child_saved_iostat != 0) &&
!(dtp->common.flags & IOPARM_HAS_IOMSG) &&
!(dtp->common.flags & IOPARM_HAS_IOSTAT))
  {
char message[IOMSG_LEN];
child_iomsg_len = string_len_trim (IOMSG_LEN, child_iomsg) 
+ 1;
snprintf (message, child_iomsg_len, child_iomsg);
generate_error (>common, dtp->u.p.child_saved_iostat,
message);
goto nml_err_ret;
  }

I will study the len questions further.

Jerry

PS I wish my mail client would not wrap text on me, working on that issue.

Re: [patch, libgfortran] Part 2: PR105456 Child I/O does not propage iostat

[Jerry D]

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?

Jerry

Re: [patch, libgfortran] Part 2: PR105456 Child I/O does not propage iostat

[Jerry D]

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

[Jerry D]

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
+character(*), intent(in) :: iotype
+integer, intent(in) :: v_list(:)

Re: [PATCH] Fortran testsuite: fix invalid Fortran in testcase

[Jerry D]

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]

[Jerry D]

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

[Jerry D]

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

[Jerry D]

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

[Jerry D]

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

[Jerry D]

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'

[Jerry D]

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

[Jerry D]

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]

[Jerry D]

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

[Jerry D]

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] PR109358

[Jerry D]

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]

[Jerry D]

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: Help with installing gfortran in python

[Jerry D]

On 2/7/24 6:20 PM, Aranda Luna, Suzan wrote:
Hello, I need to use a package called "pytmatrix" and for that I have to 
use, numpy, scipy and gfortran...the instructions says to use:


|install gfortran python-numpy python-scipy|

but I cant get it...someone has experience using gfortran in python?

Help...

Thank you.

Suzan


Suzan,

This is not exactly the right place to ask. However, if you let me know 
what Operating System you are on, I may be able to give you some ideas.


This list is primarily for gfortran developers.

Regards,

Jerry

Re: Seeking guidance on contributing to Fortran front-end through GSoc24

[Jerry D]

On 2/4/24 3:31 AM, Anuj Mohite wrote:

Dear Fortran GCC developers,


I am Anuj, a Computer Science student from India. I am interested in 
contributing to the Fortran frontend for GCC during GSoC 2024.



I got to know about this through the Martin J and GCC IRC channel. My 
background is in C/C++ and I have taken compiler construction courses, 
so I am excited to learn Fortran and contribute. Could you please guide 
me further?



I want to understand the architecture and codebase so I can prepare a 
strong project proposal. Any pointers would be greatly appreciated.



Thanks,

Anuj


Thank you for you interest.

All are welcome to contribute.  We do have a Mattermost workspace that 
you may join where you can get some guidance from the team if we happen 
to be online.  I monitor this daily.


Take a look at these links:

https://gcc.gnu.org/contribute.html

Some info on the process.

https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=UNCONFIRMED_status=NEW_status=ASSIGNED_status=SUSPENDED_status=WAITING_status=REOPENED_known_to_fail_type=allwords_known_to_work_type=allwords=fortran=libfortran_id=414162=bug_id%20DESC=gcc_format=advanced=asdefault 



That gets a list of the open fortran bugs.

Get familiar with out git repository:

https://gcc.gnu.org/git.html

Feel free to ask more questions.  Take a look at some of the Problem 
reports on the bugzilla and see if anything catches your attention.


Best regards,

Jerry

Re: [patch, libgfortran] PR111022 ES0.0E0 format gave ES0.dE0 output with d too high.

[Jerry D]

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

Re: [patch, libgfortran] PR111022 ES0.0E0 format gave ES0.dE0 output with d too high.

[Jerry D]

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



An updated patch is attached and gives the expected result.

$ gfc example.f90
$ ./a.out
 0.666E+0
 0.666E+0

I will update the commit log and test cases and re-submit for approval.

Regards,

Jerrydiff --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..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, "<"
-if (buffer.ne.">3.00<") stop 6
+if (buffer.ne.">3.00E+0&

Re: [patch, libgfortran] PR111022 ES0.0E0 format gave ES0.dE0 output with d too high.

[Jerry D]

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

The latter one is a bit ambiguous in F2018, but certainly gfortran's
current output in wrong.

Can you please check, and if you can fix that too, it would be great.
And if we do not want to be dependent on the standard version at
runtime, I'd rather go for F2023.



Certainly will look. This is why we need others checking. Corner cases 
abound.


Cheers,

Jerry

[patch, libgfortran] PR111022 ES0.0E0 format gave ES0.dE0 output with d too high.

[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.


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, "<"
-if (buffer.ne.">3.00<") stop 6
+if (buffer.ne.">3.00E+0<") stop 6
 end
 
diff --git a/gcc/testsuite/gfortran.dg/pr96436_5.f90 b/gcc/testsuite/gfortran.dg/pr96436_5.f90
index a45df8963c8..3870d988f97 100644
--- a/gcc/testsuite/gfortran.dg/pr96436_5.f90
+++ b/gcc/testsuite/gfortran.dg/pr96436_5.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, "<"
-if (buffer.ne.">3.00<") stop 6
+if (buffer.ne.">3.00E+0<") stop 6
 end
 
diff --git 

Re: PR82943 - Suggested patch to fix

[Jerry D]

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

[Jerry D]

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

[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?

Your efforts are appreciated.

Regards,

Jerry

Re: [PATCH] Fortran: SIZE optional DIM argument having OPTIONAL+VALUE attributes [PR113245]

[Jerry D]

On 1/7/24 1:34 PM, Harald Anlauf wrote:

Dear all,

the attached, actually rather obvious patch fixes an issue when
an optional dummy with the value attribute was passed as DIM
argument to the SIZE intrinsic.  Instead of some hand-crafted,
incomplete presence check for the argument, it makes more sense
to rely on gfc_conv_expr_present().

Regtested on x86_64-pc-linux-gnu.  OK for mainline?

Thanks,
Harald



Looks OK, thanks, Jerry

[libgfortran, patch] PR113223 NAMELIST internal write missing leading blank character

[Jerry D]

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.

Re: [PATCH] libgfortran: Bugfix if not define HAVE_ATOMIC_FETCH_ADD

[Jerry D]

On 1/3/24 3:12 AM, Tobias Burnus wrote:

On 22.12.23 03:36, Lipeng Zhu wrote:

This patch try to fix the bug when HAVE_ATOMIC_FETCH_ADD is
not defined in dec_waiting_unlocked function.

libgfortran/ChangeLog:

  * io/io.h (dec_waiting_unlocked): Use
  __gthread_rwlock_wrlock/__gthread_rwlock_unlock or
  __gthread_mutex_lock/__gthread_mutex_unlock functions
  to replace WRLOCK and RWUNLOCK macros.

Signed-off-by: Lipeng Zhu 


The change looks good to me + I assume it will work, but have not tested
it myself.

Downside is that it slightly breaks with the abstraction done with all
the macros, but it seems to be the simplest solution.

What is really missing - and should be included in the commit message
(before the ChangeLog block) - is the following information:

    As io.h does not include async.h, the WRLOCK and RWUNLOCK macros are
undefined.


 snip 

Would it make sense to include or merge async.h into io.h?

Jerry

Re: [PATCH] libgfortran: avoid duplicate libraries in spec

[Jerry D]

On 12/19/23 1:10 PM, FX Coudert wrote:

Hi,


I am getting side notes about people having these issues with gfortran 13. Is 
this something that should be backported.


I have already backported it in the latest Homebrew package (because we have 
many users complaining about it). I intend to backport but will wait for a 
conservative amount of time before doing so.


  Apparently it is causing some none gfortran compilations to break, but I do 
not know if this is the same issue.


Don’t think so. I can have a look if you give me a pointer.

FX


See:

https://github.com/vmagnin/gtk-fortran/issues/280#issuecomment-1863377748

Thanks ahead of time if you have time.

Jerry

Re: [PATCH] libgfortran: avoid duplicate libraries in spec

[Jerry D]

On 12/19/23 12:02 AM, FX Coudert wrote:

When gfortran invokes the linker, it reads the linking spec from libgfortran. 
This ends up doing things like:

-lm -lgcc_s -lgcc -lc -lgcc_s -lgcc

where you can see that libgcc (both -lgcc and -lgcc_s) is linked in twice. This 
wasn’t a problem, until the new macOS linker, which gives a warning for this: 
the warning is innocuous, but having a warning for every time you call gfortran 
for linking clutters the terminal, and makes all the testsuite fail. And 
linking twice is superfluous, so removing it will not be a problem.

I am the author of the original commit to the spec, in 2010, but honestly I 
have no memory: I think I vaguely remember saying “better safe than sorry”, but 
13 years later it could just be a false memory ;)

Anyway, this was tested on x86_64-darwin and x64_86-linux, as well as 
*-*-solaris2.11 by Rainer.
OK to commit? (seems admissible in stage 3 because it fixes regtesting on 
darwin22 and darwin23).

FX



libgfortran/ChangeLog:

PR libfortran/110651
* libgfortran.spec.in: Remove duplicate libraries.
---
  libgfortran/libgfortran.spec.in | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)


I am getting side notes about people having these issues with gfortran 
13.  Is this something that should be backported.  Apparently it is 
causing some none gfortran compilations to break, but I do not know if 
this is the same issue.


I say OK for trunk.

Jerry

GFortran MatterMost Workspace

[Jerry D]

The subject server hosted by the OSU Open Software Lab is being upgraded 
to the latest LTS version of MatterMost (8.1). There may be some 
interruptions of service.


I will send out a notice when this gets completed.

Thanks to the folks at OSU for their support.

Regards,

Jerry

[patch, fortran, committed] PR112873 F2023 degree trig functions

[Jerry D]

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

[Jerry D]

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

[Jerry D]

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: Accept -std=f2023 support, update line-length for Fortran 2023

[Jerry D]

On 11/16/23 5:01 AM, Tobias Burnus wrote:

This adds -std=f2023, which is mostly a prep patch for future changes.

However, Fortran 2023, https://j3-fortran.org/doc/year/23/23-007r1.pdf 
changes two things which is taken

care in this patch:

(A) In "6.3.2.1 Free form line length":

Fortran 2018: "If a line consists entirely of characters of default kind 
(7.4.4), it shall contain at most 132 characters"

Fortran 2023: "A line shall contain at most ten thousand characters."

(B) In "6.3.2.6 Free form statements":
Fortran 2018: "A statement shall not have more than 255 continuation 
lines."
Fortran 2023: "A statement shall not have more than one million 
characters."


I have not added a testcase for exceeding the latter but otherwise there 
are new

tests and I had to add a couple of -std=f2018 to existing tests.

Comments, suggestions, approval?


My only comment is that the Standards Committee seems to have no idea of 
actual good coding practices. I have to assume they want this so people 
can have very very long DATA statements or array constructors or some 
such nonsense.


I always thought data files were for these sorts of things. The software 
engineers I work with would roll there eyes and say, "Hey you users out 
there, stop asking the compiler writers to fix your code for you by 
changing the compiler. Do your code correctly in the first place"


Perhaps AI is being used to generate the source files?

Cheers,

Jerry

Re: [PATCH] Fortran: out of bounds access with nested implied-do IO [PR111837]

[Jerry D]

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]

[Jerry D]

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]

[Jerry D]

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]

[Jerry D via Fortran]

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]

[Jerry D via Fortran]

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: beta gfortran 14.x.y (using -march=native and intrinsic repeat) gives a signal SIGILL

[Jerry D via Fortran]

On 8/12/23 6:41 AM, Jorge D'Elia wrote:

Hi Paul,

- Mensaje original -

De: "Paul Richard Thomas" 
Para: "Jerry" 
CC: "Jorge D'Elia" , "Gfortran List" , 
"Jorge D'Elia"

Enviado: Sábado, 12 de Agosto 2023 3:56:44
Asunto: Re: beta gfortran 14.x.y (using -march=native and intrinsic repeat) 
gives a signal SIGILL

Hi Jorge,


There were some recent patches in this area IIRC.

Jerry


The tree dump is identical to mine, obtained with GNU Fortran (GCC)
14.0.0 20230809 (experimental), so I doubt that any recent patches are
responsible.


It seems so. Furthermore, I have the feeling that the problem is outside
GFortran, between the use of -mtune=native versus -march=native. For example,

$ gfortran --version
GNU Fortran (GCC) 14.0.0 20230808 (experimental)

$ ls -all
total 4
drwxr-xr-x. 1 jdelia jdelia   16 Aug 12 10:06 .
drwxr-xr-x. 1 jdelia jdelia 2782 Aug 12 10:05 ..
-rwxr-xr-x. 1 jdelia jdelia  223 Aug 11 08:28 test.f90

$ gfortran -mtune=native -fcheck=all -std=f2018 -Wall -Werror -Wextra -g 
-fdump-tree-original -o test-mtune.exe test.f90
$ ls -all
total 36
drwxr-xr-x. 1 jdelia jdelia   110 Aug 12 10:17 .
drwxr-xr-x. 1 jdelia jdelia  2782 Aug 12 10:05 ..
-rwxr-xr-x. 1 jdelia jdelia   223 Aug 11 08:28 test.f90
-rwxr-xr-x. 1 jdelia jdelia 26856 Aug 12 10:17 test-mtune.exe
-rw-r--r--. 1 jdelia jdelia  1405 Aug 12 10:17 test-mtune-test.f90.005t.original

$ mv test-mtune-test.f90.005t.original test-mtune.f90.005t.original

$ ls -all
total 36
drwxr-xr-x. 1 jdelia jdelia   100 Aug 12 10:19 .
drwxr-xr-x. 1 jdelia jdelia  2782 Aug 12 10:05 ..
-rwxr-xr-x. 1 jdelia jdelia   223 Aug 11 08:28 test.f90
-rwxr-xr-x. 1 jdelia jdelia 26856 Aug 12 10:17 test-mtune.exe
-rw-r--r--. 1 jdelia jdelia  1405 Aug 12 10:17 test-mtune.f90.005t.original

$ gfortran -march=native -fcheck=all -std=f2018 -Wall -Werror -Wextra -g 
-fdump-tree-original -o test-march.exe test.f90
$ ls -all
total 68
drwxr-xr-x. 1 jdelia jdelia   194 Aug 12 10:19 .
drwxr-xr-x. 1 jdelia jdelia  2782 Aug 12 10:05 ..
-rwxr-xr-x. 1 jdelia jdelia   223 Aug 11 08:28 test.f90
-rwxr-xr-x. 1 jdelia jdelia 28064 Aug 12 10:19 test-march.exe
-rw-r--r--. 1 jdelia jdelia  1405 Aug 12 10:19 test-march-test.f90.005t.original
-rwxr-xr-x. 1 jdelia jdelia 26856 Aug 12 10:17 test-mtune.exe
-rw-r--r--. 1 jdelia jdelia  1405 Aug 12 10:17 test-mtune.f90.005t.original

$ mv test-march-test.f90.005t.original test-march.f90.005t.original

$ ls -all
total 68
drwxr-xr-x. 1 jdelia jdelia   184 Aug 12 10:19 .
drwxr-xr-x. 1 jdelia jdelia  2782 Aug 12 10:05 ..
-rwxr-xr-x. 1 jdelia jdelia   223 Aug 11 08:28 test.f90
-rwxr-xr-x. 1 jdelia jdelia 28064 Aug 12 10:19 test-march.exe
-rw-r--r--. 1 jdelia jdelia  1405 Aug 12 10:19 test-march.f90.005t.original
-rwxr-xr-x. 1 jdelia jdelia 26856 Aug 12 10:17 test-mtune.exe
-rw-r--r--. 1 jdelia jdelia  1405 Aug 12 10:17 test-mtune.f90.005t.original

$ diff test-mtune.f90.005t.original test-march.f90.005t.original
# (nothing is shown, thus both tree dumps ares identical).

$ test-mtune.exe
   cc :

$ test-march.exe

Program received signal SIGILL: Illegal instruction.

Backtrace for this error:
#0  0x15268845fb1f in ???
#1  0x4011c2 in test
at /home/jdelia/TEST/test.f90:6
#2  0x4012ae in main
at /home/jdelia/TEST/test.f90:8
Illegal instruction (core dumped)


Being unable to reproduce the error, there is not much that I can do.
Sorry


Non problem. To avoid this error, for now we exclude the use
of -march=native in our makefiles, and just use -mtune=native.


Paul


Thanks for your time.

Regards.
Jorge.
--


I have not been able to reproduce it here.  I tried on:

gcc version 14.0.0 20230804 (experimental) (GCC)

and

gcc version 14.0.0 20230812 (experimental) (GCC)

I wonder if you caught a version in between changes happening?

$ lscpu
Architecture:x86_64
  CPU op-mode(s):32-bit, 64-bit
  Address sizes: 48 bits physical, 48 bits virtual
  Byte Order:Little Endian

I started to draft a PR this morning, not sure.

I know it is a pain to do, can you build a later version of gfortran and 
see if your results are different?


Also, I have seen times where the libgfortran files were out of sync 
with the build because LD_LIBRARY_PATH was not pointing in the correct 
place.  So check these things.


Regards,

Jerry

Re: beta gfortran 14.x.y (using -march=native and intrinsic repeat) gives a signal SIGILL

[Jerry D via Fortran]

On 8/11/23 5:34 AM, Jorge D'Elia via Fortran wrote:

Dear GFortran developers,

With the beta gfortran 14.x.y versions we are noticing some runtime
errors in a production code.

One type of runtime errors is related to the concurrent use of the
intrinsic "repeat" when the source code is compiled with the
flag -march=native, please, see below:

$ cat test.f90
program test
   implicit none
   integer  , parameter :: iin = kind (1)
   integer (iin), parameter :: pp = 32
   character (len=pp) :: cc
   cc (1:pp) = repeat (" ",pp)
   write (*,*)" cc : " // cc
end program test

$ gfortran --version
GNU Fortran (GCC) 14.0.0 20230808 (experimental)
Copyright (C) 2023 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

a) Compiling with the flag -mtune=native only, without -march=native, the test 
is ok:

$ gfortran -mtune=native -fcheck=all -std=f2018 -Wall -Werror -Wextra -Og -o 
test.exe test.f90
$ test.exe
   cc :

b) However, compiling with the flag -march=native:

$ gfortran -march=native -fcheck=all -std=f2018 -Wall -Werror -Wextra -Og -o 
test.exe test.f90
$ test.exe

Program received signal SIGILL: Illegal instruction.

Backtrace for this error:
#0  0x14fae277fb1f in ???
#1  0x4011ad in ???
#2  0x401272 in ???
#3  0x14fae276a50f in ???
#4  0x14fae276a5c8 in ???
#5  0x4010c4 in ???
#6  0x in ???
Illegal instruction (core dumped)

On the other hand, compiling with the system version (GNU Fortran (GCC)
12.3.1 20230508 (Red Hat 12.3.1-1)) or replacing the intrinsic repeat
with:

do kk = 1, pp
   cc (kk:kk) = " "
end do

both tests are ok. The error occurs on any of Intel or AMD computers,
e.g. in the present case:

$ lscpu
Architecture:   x86_64
   CPU op-mode(s):   32-bit, 64-bit
   Address sizes:46 bits physical, 48 bits virtual
   Byte Order:   Little Endian
CPU(s): 6
   On-line CPU(s) list:  0-5
Vendor ID:  GenuineIntel
   Model name:   Intel(R) Core(TM) i7-3930K CPU @ 3.20GHz
 CPU family: 6
 Model:  45
 Thread(s) per core: 1
 Core(s) per socket: 6
 Socket(s):  1
 Stepping:   7
 BogoMIPS:   6400.22
Caches (sum of all):
   L1d:  192 KiB (6 instances)
   L1i:  192 KiB (6 instances)
   L2:   1.5 MiB (6 instances)
   L3:   12 MiB (1 instance)
NUMA:
   NUMA node(s): 1
   NUMA node0 CPU(s):0-5


By the way, I do not know if the -march=native flag or the intrinsic
repeat would be of deprecated use (or not)...


Regardless, we should never segfault.  Thanks for the code example. We 
need to get a bug report opened on this.  I am on travel this morning, 
but if I have time i will do so this afternnon if someone else does not 
beat me to it.


There were some recent patches in this area IIRC.

Jerry

Re: [Patch, fortran] PR109684 - compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)

[Jerry D via Fortran]

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: Compile antiquated fortran?

[Jerry D via Fortran]

On 7/27/23 1:36 PM, Allin Cottrell via Fortran wrote:
I have old fortran source code (not my own work) for a specialized 
statistical program that I and others find quite useful.


A few years ago I was able to compile it on Linux using gfortran with 
std=legacy (and also cross-compile it for Windows an Mac). Now I'd like 
to rebuild it, but with recent gfortran (I've tried 12.2.1 on Fedora and 
13.1.1 on Arch) it's a no-go. I get lots of errors of the following sort:


ansub9.f:151:44:

   151 |    INTEGER ITYPE,INIT,LAM,IMEAN,IP,ID,Q,BP,BD,BQ,SQG,MQ,L,M,
   |   1
Error: Symbol ‘q’ at (1) already has basic type of REAL

I can understand this complaint. The code contains this sort of thing 
within a given subroutine:


    IMPLICIT  REAL*8 (A-H,O-Z)


Have you considered replacing the above line with IMPLICIT NONE and add 
explicit declarations as needed? The code will be safer in the long run.



Regards,

Jerry

Re: program errors with GNU Fortran

[Jerry D via Fortran]

On 6/16/23 12:18 PM, Michael Schneider via Fortran wrote:

Hello,

I'm looking for a forum that can provide answers to questions arising with GNU 
Fortran.  Is this the right place?

Mike Schneider


We have a Mattermost instance I can invite you to for general 
discussions and other topics. I can send you an invitation if you would 
like.


Send me a note with a little about yourself.

Regards,

Jerry

Re: Possible funding of gfortran work

[Jerry D via Fortran]

On 6/1/23 2:18 AM, Andre Vehreschild wrote:

Hi Damian, all,

thank you for your input. I have incorporated most of it. Due to Germany
stepping out of nuclear use, I have reduced the cites on these to a minimum. I
don't know anything about the people evaluating the proposal and don't want to
be rejected just because of ideological reasons. Here is the proposal so far.
Has any one a good url for the FAST project?



I found this qhich does use Fortran

https://github.com/OpenFAST/openfast/tree/main/modules/beamdyn/src

Is this the one you were referring to?

Also here:

https://www.nrel.gov/wind/nwtc/openfast.html

Re: Possible funding of gfortran work

[Jerry D via Fortran]

On 5/28/23 12:25 PM, Mikael Morin wrote:

Hello,

I would like to apply for 60% of my work time if there is funding for it.

These are the projects that I would like to push (in no particular order):
  - Simplify scalarizer API and usage,
  - Create internal APIs (basically split gfortran.h and/or trans.h to 
different pieces) and add unit testing for them,
  - Move code from class.cc to a trans-class.cc and get rid of the class 
artifacts around the class descriptor and vtable in the whole frontend.
  - Defer all work done at parsing time to resolution time, so that the 
parser's job reduces to just recognizing and recording statements,

  - Avoid simplifying intrinsics before checking they are valid,
  - Improve module loading (there is PR98426, possibly a few others),
  - Array descriptor reform (does it still apply?).

The above are, I think, long and/or difficult, and a bit unrewarding as 
they have virtually no user-visible impact, and it's unlikely to get 
funding for them.  But maybe we could apply for a package project 
including user-visible changes and less visible ones.


The projects proposed by Paul all seem worth pursuing.  If there is only 
one, my vote goes for fixing the PDTs.


Cheers.
Mikael


The original person who contacted me at FortranDiscourse already 
submitted a proposal for something to do with Fortran-Lang and is 
offering to assist with a gfortran proposal. I asked for a direct email 
address so I could relay this to you if you do not have it.  I also gave 
saveral of your emails to him asking to contact you directly.


Regards,

Jerry

Re: Possible funding of gfortran work

[Jerry D via Fortran]

Sorry about my messages getting chopped.

On 5/25/23 9:34 PM, Jerry DeLisle via Fortran wrote:

Hi all,

I found this message in my spam folder tonight.

Please look.  I also sent a note to Damian on this.

Maybe we can get someone to push forward on te native coarrays work?

Other thoughts?

Jerry


 [awvwgk]   awvwgk Regular
May 16

Hi Jerry,

we are currently securing funding for the Fortran community from the 
German government, see this thread:


Application to the Sovereign Tech Fund Projects

We recently had a meeting in Berlin with the Sovereign Tech Fund 
(STF) to evaluate the pilot round of their open source funding program 
which our community participated in. A big thanks to the people in who 
worked on the projects in our community. Now with the pilot round coming 
to an end soon, we have the chance to apply for further funding with the 
STF. Let’s have a look through our community and identity the projects 
with the largest impact on Fortran. A couple of suggestions to get the …


I would like to discuss with the GFortran developer community whether 
there is interest to setup a joint project to pay somebody to work on 
GFortran full time. We have funding available for 18 months with 600k 
EUR starting mid of June (please do not share this numbers publicly 
yet), but we can also ask the fund for more money if needed. What do you 
think? Is it worth to bring this up on the GFortran mailing list or 
mattermost server?


Best,
Sebastian

Visit Message or reply to this email to respond to awvwgk.

Re: [PATCH] Fortran: set shape of initializers of zero-sized arrays [PR95374,PR104352]

[Jerry D via Fortran]

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

[Jerry D via Fortran]

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

[Jerry D via Fortran]

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

Re: [patch, fortran] PR109662 Namelist input with comma after name accepted

[Jerry D via Fortran]

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?



I can easily change this to reject everything else except blanks and I 
suppose the cr  and lf.


Jerry

[patch, fortran] PR109662 Namelist input with comma after name accepted

[Jerry D via Fortran]

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

[Jerry D via Fortran]

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

[Jerry D via Fortran]

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]

[Jerry D via Fortran]

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: replacing hardware?

[Jerry D via Fortran]

On 4/13/23 9:43 AM, Steve Kargl via Fortran wrote:

All,

The systems that I've used while hacking on gfortran
bugs and features are starting to show their age.  I'm
in the early stage of put together the wishlist for
a budget friendly replacement.  While I'll likely go
with a Ryzen7 cpu, NVME M2 drives, and as much memory
as I can afford, I'm looking for recommendations for
a budget friendly video/gpu card that will allow me to
take a deeper dive into openacc/openmp and offloading.
Anyone have a suggestion?

Note, I've mostly used FreeBSD over the last 25+ years.
I suspect that pursuing offloading may  be easier with
a flavor linux.  Any recommendation would also be
appreciated.



Hi Steve,

If you are into building your own, I am using:

https://www.gigabyte.com/Motherboard/X570-AORUS-ELITE-rev-10#kf

It has plenty of sata ports and I am using a 1TB pci4 m2 drive. It 
supports two m2's so no problems on storage. Do get a pci4 drive, rather 
fast.


This motherboard will support the Ryzen 5000 series chips which are 
rather impressive.  I have a Ryzen 3600 which for me is adequate, 
however I have an upgrade path.


I use Fedora which has all the standard tools well supported. Ubuntu is 
as useful, with some differences in the package manager and looks of the 
Gnome Desktop. (All very configurable.


I just bought a cheap video card as I am not exploring the offloading.

Cheers,

Jerry

Re: [PATCH] Fortran: resolve correct generic with TYPE(C_PTR) arguments [PR61615]

[Jerry D via Fortran]

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: gfortran-8

[Jerry D via Fortran]

On 3/17/23 10:12 AM, SANTIAGO JIMENEZ HYDYN wrote:

Good morning, I use the gfortran 8 package for ubuntu 22.10.. however, they
have been removed from the repositories.. do they have a place where I can
download it.

I appreciate your help

M.en C. Hydyn Santiago Jimenez
Centro Universitario de Estudios e Investigaciones de Vulcanologia
Universidad de Colima.
Tel. 312-3161134

Why dont you use the current version available on Ubuntu.  Things should 
work ok.


Jerry

Re: [PATCH] Fortran: fix ICE with bind(c) in block data [PR104332]

[Jerry D via Fortran]

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, fortran] PR37336 finalization

[Jerry D via Fortran]

While recovering from an illness here folks I have been following all of 
these discussions.  I think I will put in my two cents worth.


From what i can see, Paul's patch breaks nothing and fixes many things. 
 The only thing holding us back is fear we might break something. The 
likelihood of actually breaking something is very low. The consequences 
of breaking anything, worst case, is to revert a patch. (ie no consequence)


It is clear to me the value added clearly exceeds the the risks by a 
lot. Therefore, as Spock would say, it is illogical to not make a 
decision and move forward with this finalization patch, and commit it. 
More will be advanced from making this decision from not making this 
decision.


Regards,

Jerry

On 3/9/23 9:30 AM, Thomas Koenig via Fortran wrote:

Hi Paul,


-fdefault-integer-8 does indeed fix the problem with rnflow.f90 but 
breaks tfft2.f90, with a type mismatch at lines 36 and 44.


       integer(8), parameter   :: jmul =  843314861  ! multiplicateur
       integer(8), parameter   :: jadd =  453816693  ! constante additive
Does the job and is portable.



I think -frwapv (as suggested by Jakub) would be the better choice.
The problem is the linear congruential pseudo-random number generators
which were much used in earlier times (and are still present in
legacy code), which violate the Fortran standards by assuming silent
truncation.

If a new optimization breaks this (widespread, but illegal) idiom,
maybe the best way to deal with it is to add -frwapv to -std=legacy.

What do you think?

Best regards

 Thomas

Re: [PATCH][stage1] Remove conditionals around free()

[Jerry D via Fortran]

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()

[Jerry D via Fortran]

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.

[Jerry D via Fortran]

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.

[Jerry D via Fortran]

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.

[Jerry D via Fortran]

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_RANK (array);
 

Re: [PATCH] Fortran: ASSOCIATE variables should not be TREE_STATIC [PR95107]

[Jerry D via Fortran]

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]

[Jerry D via Fortran]

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

Fwd: ☠ Buildbot (Sourceware): gcc - failed configure (failure) (master)

[Jerry D via Fortran]

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

Re: [PATCH] Fortran: diagnose USE associated symbols in COMMON blocks [PR108453]

[Jerry D via Fortran]

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]

[Jerry D via Fortran]

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

[Jerry D via Fortran]

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.

MatterMost Workspace Features

[Jerry D via Fortran]

Built into Mattermost is a feature called Playbooks.

https://docs.mattermost.com/guides/playbooks.html

For those of you who have accepted invitations and have access, I p;an 
to create a Playbook to capture our workflow.


Our workflow in my mind obviously included email for patch approvals and 
Bugzilla for bug tracking. These in my mind are good tools.


Now as an example of how folks are currently using Mattermost, Paul has 
posted preliminary patches for Finalization on that channel and others 
have chimed in with test cases. It is a dialog that is efficient and to 
the topic. It provides a focused discussion not cluttered by emails 
coming in on numerous other topics, that you have to filter out as you 
scan emails.


Vincent has linked the gtk-fortran GitHub repository. This allows issues 
and such show up for those interested without having to go out to GitHub 
and look.


I have a Board setup that I am using to help me keep track of a lot of 
Steve's patches hiding around in Bugzilla. Helpful to me, and others can 
look to see my progress. Certainly others can use the board and take on 
some of those.


I am hoping the Playbook will help new people to understand and follow 
our work flow as well.


I will occasionally ask here if anyone would like to join the 
MatterMost.  I am not looking for lurkers, I am looking for 
contributors, either testing, helping to understand bugs, interpreting 
Fortran Standards, and of course contributing patches.


Regards to all,

Jerry