Re: Unusual Behavior in Fortran Compiled Program.
The screenshot did not make it (restrictions probably of the email service), but in any case: - Why store an executable that you created in the installation directory of gfortran? - If you want to do that, why not simply copy it with your favourite file manager or via a copy command? - Your question has nothing to do with gfortran as such ;) Regards, Arjen Op wo 28 feb 2024 om 22:16 schreef Stanton Easley : > For reasons that make no sense, I am using a Text Editor to save a > recently created Fortran program in the Binary Folder where the gfortran > Complier is located; when I look in the folder where the saved file located > with File explorer, the file isn't present, which isn't what the Text > editor I'm using (ConText) states that it is. Here are screenshots of what > I mean: > > > > > > > > Thanks, Stanton E. Easley Σταντον Cogito Ergo Sum "Regard without ill > will, despite an offense". FORGIVE implies that one gives up all claim to > requital and to resentment or vengeful feelings. Sent from iCloud > > >
Re: [patch, libgfortran] Part 2: PR105456 Child I/O does not propage iostat
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 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()? 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? thanks! > > 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.
Re: [patch, libgfortran] Part 2: PR105456 Child I/O does not propage iostat
On 2/29/24 1:47 AM, Bernhard Reutner-Fischer wrote: On Wed, 28 Feb 2024 21:29:06 -0800 Jerry D wrote: The attached patch adds the error checks similar to the first patch previously committed. I noticed a redundancy in some defines MSGLEN and IOMSG_LEN so I consolidated this to one define in io.h. This is just cleanup stuff. I have added test cases for each of the places where UDTIO is done in the library. Regressions tested on x86_64. OK for trunk? I think the commit hooks will complain about several missing spaces before open brace; See contrib/check_GNU_style.py /tmp/pr105456-3.diff I was given the OK from git gcc-verify. Regardless if hooks fail I just fix and try again. Would it make sense to introduce and use an internal helper like trim()? Or would it be possible to trim the message in generate_error_common()? I was debating this and what would be the best approach. I was not sure where to put it. I like the idea of doing in the generate_error_common. I will try that and see how it plays. And, just for my own education, the length limitation of iomsg to 255 chars is not backed by the standard AFAICS, right? It's just our STRERR_MAXSZ? Yes, its what we have had for a long lone time. Once you throw an error things get very processor dependent. I found MSGLEN set to 100 and IOMSG_len to 256. Nothing magic about it. I appreciate the comments. --- snip --- Jerry -
Re: [patch, libgfortran] Part 2: PR105456 Child I/O does not propage iostat
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 -- Steve
Re: [patch, libgfortran] Part 2: PR105456 Child I/O does not propage iostat
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
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. -- Steve
[PATCH] Fortran: improve checks of NULL without MOLD as actual argument [PR104819]
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
From ce7199b16872b3014be68744329a8f19ddd64b05 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Thu, 29 Feb 2024 21:43:53 +0100
Subject: [PATCH] Fortran: improve checks of NULL without MOLD as actual
argument [PR104819]
gcc/fortran/ChangeLog:
PR fortran/104819
* check.cc (gfc_check_null): Handle nested NULL()s.
(is_c_interoperable): Check for MOLD argument of NULL() as part of
the interoperability check.
* interface.cc (gfc_compare_actual_formal): Extend checks for NULL()
actual arguments for presence of MOLD argument when required by
Interp J3/22-146.
gcc/testsuite/ChangeLog:
PR fortran/104819
* gfortran.dg/pr101329.f90: Adjust testcase to conform to interp.
* gfortran.dg/null_actual_4.f90: New test.
---
gcc/fortran/check.cc| 5 ++-
gcc/fortran/interface.cc| 30 ++
gcc/testsuite/gfortran.dg/null_actual_4.f90 | 35 +
gcc/testsuite/gfortran.dg/pr101329.f90 | 4 +--
4 files changed, 71 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/gfortran.dg/null_actual_4.f90
diff --git a/gcc/fortran/check.cc b/gcc/fortran/check.cc
index d661cf37f01..db74dcf3f40 100644
--- a/gcc/fortran/check.cc
+++ b/gcc/fortran/check.cc
@@ -4384,6 +4384,9 @@ gfc_check_null (gfc_expr *mold)
if (mold == NULL)
return true;
+ if (mold->expr_type == EXPR_NULL)
+return true;
+
if (!variable_check (mold, 0, true))
return false;
@@ -5216,7 +5219,7 @@ is_c_interoperable (gfc_expr *expr, const char **msg, bool c_loc, bool c_f_ptr)
{
*msg = NULL;
- if (expr->expr_type == EXPR_NULL)
+ if (expr->expr_type == EXPR_NULL && expr->ts.type == BT_UNKNOWN)
{
*msg = "NULL() is not interoperable";
return false;
diff --git a/gcc/fortran/interface.cc b/gcc/fortran/interface.cc
index 231f2f252af..64b90550be2 100644
--- a/gcc/fortran/interface.cc
+++ b/gcc/fortran/interface.cc
@@ -3296,6 +3296,36 @@ gfc_compare_actual_formal (gfc_actual_arglist **ap, gfc_formal_arglist *formal,
&& a->expr->ts.type != BT_ASSUMED)
gfc_find_vtab (&a->expr->ts);
+ /* Interp J3/22-146:
+ "If the context of the reference to NULL is an
+ corresponding to an dummy argument, MOLD shall be
+ present." */
+ if (a->expr->expr_type == EXPR_NULL
+ && a->expr->ts.type == BT_UNKNOWN
+ && f->sym->as
+ && f->sym->as->type == AS_ASSUMED_RANK)
+ {
+ gfc_error ("Intrinsic % without % argument at %L "
+ "passed to assumed-rank dummy %qs",
+ &a->expr->where, f->sym->name);
+ ok = false;
+ goto match;
+ }
+
+ if (a->expr->expr_type == EXPR_NULL
+ && a->expr->ts.type == BT_UNKNOWN
+ && f->sym->ts.type == BT_CHARACTER
+ && !f->sym->ts.deferred
+ && f->sym->ts.u.cl
+ && f->sym->ts.u.cl->length == NULL)
+ {
+ gfc_error ("Intrinsic % without % argument at %L "
+ "passed to assumed-length dummy %qs",
+ &a->expr->where, f->sym->name);
+ ok = false;
+ goto match;
+ }
+
if (a->expr->expr_type == EXPR_NULL
&& ((f->sym->ts.type != BT_CLASS && !f->sym->attr.pointer
&& (f->sym->attr.allocatable || !f->sym->attr.optional
diff --git a/gcc/testsuite/gfortran.dg/null_actual_4.f90 b/gcc/testsuite/gfortran.dg/null_actual_4.f90
new file mode 100644
index 000..e03d5c8f7de
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/null_actual_4.f90
@@ -0,0 +1,35 @@
+! { dg-do compile }
+! PR fortran/104819
+!
+! Reject NULL without MOLD as actual to an assumed-rank dummy.
+! See also interpretation request at
+! https://j3-fortran.org/doc/year/22/22-101r1.txt
+!
+! Test nested NULL()
+
+program p
+ implicit none
+ integer, pointer :: a, a3(:,:,:)
+ character(10), pointer :: c
+
+ call foo (a)
+ call foo (a3)
+ call foo (null (a))
+ call foo (null (a3))
+ call foo (null (null (a))) ! Valid: nested NULL()s
+ call foo (null (null (a3))) ! Valid: nested NULL()s
+ call foo (null ()) ! { dg-error "passed to assumed-rank dummy" }
+
+ call str (null (c))
+ call str (null (null (c)))
+ call str (null ()) ! { dg-error "passed to assumed-length dummy" }
+contains
+ subroutine foo (x)
+integer, pointer, intent(in) :: x(..)
+print *, rank (x)
+ end
+
+ subroutine str (x)
+character(len=*), pointer, intent(in) :: x
+ end
+end
diff --git a/gcc/testsuite/gfortran.dg/pr101329.f90 b/gcc/testsuite/gfortran.dg/pr101329.f90
index b82210d4e28..aca171bd4f8 100644
---
Re: [patch, libgfortran] Part 2: PR105456 Child I/O does not propage iostat
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 (&dtp->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] Fortran: improve checks of NULL without MOLD as actual argument [PR104819]
On 2/29/24 12:56 PM, Harald Anlauf wrote: Dear all, here's a first patch addressing issues with NULL as actual argument: if the dummy is assumed-rank or assumed length, MOLD shall be present. There is also an interp on interoperability of c_sizeof and NULL pointers, for which we have a partially incorrect testcase (gfortran.dg/pr101329.f90) which gets fixed. See https://j3-fortran.org/doc/year/22/22-101r1.txt for more. Furthermore, nested NULL()s are now handled. Regtested on x86_64-pc-linux-gnu. OK for mainline? I consider this part as safe and would like to backport to 13-branch. Objections? Thanks, Harald Looks good to me. I think backport is OK as well. Jerry -
