Re: [PATCH] fortran: fix checking of CHARACTER lengths in array constructors [PR70231]
On 9/18/23 1:27 PM, Harald Anlauf via Fortran wrote: Dear all, as correctly analyzed by Jerry, the code for checking the consistency of character lengths in array constructors did not properly initialize the auxiliary variable used in "bounds checking". The attached patch resolves this by initializing this auxiliary variable with a length obtained by scanning the constructor. Interestingly, the failure depended on optimization level and was apparent only at -O0, and could exhibit both false-positives and false-negatives. Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald Wow 2016 when I looked at that one. The patch looks reasonable to me. OK for mainline. Jerry
Re: [PATCH] Fortran: improve bounds checking for DATA with implied-do [PR35095]
On 8/24/23 2:28 PM, Harald Anlauf via Fortran wrote: Dear all, the attached patch adds stricter bounds-checking for DATA statements with implied-do. I chose to allow overindexing (for arrays of rank greater than 1) for -std=legacy, as there might be codes in the wild that need this (and this is accepted by some other compilers, while NAG is strict here). We now get a warning with -std=gnu, and an error with -std=f. Regtested on x86_64-pc-linux-gnu. OK for mainline? (The PR is over 15 years old, so no backport intended... ;-) Thanks, Harald Looks good Harold, OK for mainline.
Re: [Patch, fortran] PR109684 - compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)
On 8/9/23 7:58 AM, Paul Richard Thomas via Fortran wrote: I took a look at my calendar and decided to backport right away. r13-7703-ged049e5d5f36cc0f4318cd93bb6b33ed6f6f2ba7 BTW It is a regression :-) Paul On Wed, 9 Aug 2023 at 12:10, Paul Richard Thomas wrote: Committed to trunk as 'obvious' in r14-3098-gb8ec3c952324f866f191883473922e250be81341 13-branch to follow in a few days. Paul Thanks Paul, I was about ready to do it myself. Jerry
Re: [PATCH] Fortran: set shape of initializers of zero-sized arrays [PR95374,PR104352]
On 5/17/23 11:52 AM, Harald Anlauf via Fortran wrote: Dear all, the attached patch is neat, because it fixes a bug by removing code ;-) When generating the initializer for a parameter array, we excepted the case of size 0, which however prevented the detection of array bounds violations and lead to ICEs in various places. The solution which removes the comparison for size > 0 also has the bonus that it fixes a minor memory leak for the size==0 case... Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald Looks Good To Me. OK, Jerry
Re: [patch, fortran] PR109662 Namelist input with comma after name accepted
I plan to commit the following as simple.
The issue was a value was being modified on a short namelist read. After
tthe first read gives the correct EOF, a second read would give the
error but modify the variable.
diff --git a/libgfortran/io/unit.c b/libgfortran/io/unit.c
index 82664dc5f98..36d025949c2 100644
--- a/libgfortran/io/unit.c
+++ b/libgfortran/io/unit.c
@@ -504,6 +504,7 @@ set_internal_unit (st_parameter_dt *dtp, gfc_unit
*iunit, int kind)
iunit->current_record=0;
iunit->read_bad = 0;
iunit->endfile = NO_ENDFILE;
+ iunit->last_char = 0;
/* Set flags for the internal unit. */
The revised test case attached. It has been regression tested OK.
Regards,
Jerry! { dg-do run }
! { dg-options "-std=f2003" }
! PR109662-a semi-colon after namelist name accepted on input.
program testnmlread
implicit none
character(16) :: line = '&stuff; 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 = "&stuff"
! Problem manifests on two bad reads on same string.
do i = 1, 6
n = -1
ioresult = 0
read (line,nml=stuff,iostat=ioresult)
if (n /= -1) STOP 24
if (ioresult == 0) STOP 25
end do
end program testnmlread
Re: [patch, fortran] PR109662 Namelist input with comma after name accepted
On 5/6/23 11:15 AM, Harald Anlauf via Fortran wrote: Hi Jerry, Steve, I think I have to pour a little water into the wine. The patch fixes the reported issue only for a comma after the namelist name, but we still accept a few other illegal characters, e.g. ';', because: #define is_separator(c) (c == '/' || c == ',' || c == '\n' || c == ' ' \ || c == '\t' || c == '\r' || c == ';' || \ (dtp->u.p.namelist_mode && c == '!')) We don't want that in standard conformance mode, or do we? Cheers, Harald On 5/6/23 06:02, Steve Kargl via Gcc-patches wrote: On Fri, May 05, 2023 at 08:41:48PM -0700, Jerry D via Fortran wrote: The attached patch adds a check for the invalid comma and emits a runtime error if -std=f95,f2003,f2018 are specified at compile time. Attached patch includes a new test case. Regression tested on x86_64-linux-gnu. OK for mainline? Yes. Thanks for the fix. It's been a long time since I looked at libgfortran code and couldn't quite determine where to start to fix this. As I think back, I don't recall ever seeing a semi-colon used after a NAMELIST name, so I think we should reject it always. The other "soft" blanks we should allow. I will make a another patch on trunk to reject the semi-colon and if no one objects here I will test and push it. Regards, Jerry
[patch, fortran] PR109662 Namelist input with comma after name accepted
The attached patch adds a check for the invalid comma and emits a
runtime error if -std=f95,f2003,f2018 are specified at compile time.
Attached patch includes a new test case.
Regression tested on x86_64-linux-gnu.
OK for mainline?
Regards,
Jerry
Author: Jerry DeLisle
Date: Fri May 5 20:12:25 2023 -0700
Fortran: Namelist read with invalid input accepted.
PR fortran/109662
libgfortran/ChangeLog:
* io/list_read.c: Add a check for a comma after a namelist
name in read input. Issue a runtime error message.
gcc/testsuite/ChangeLog:
* gfortran.dg/pr109662.f90: New test.
diff --git a/gcc/testsuite/gfortran.dg/pr109662.f90 b/gcc/testsuite/gfortran.dg/pr109662.f90
new file mode 100644
index 000..988cfab73cc
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr109662.f90
@@ -0,0 +1,15 @@
+! { dg-do run }
+! { dg-options "-std=f2003" }
+! PR109662 a comma after namelist name accepted on input.
+program testnmlread
+ implicit none
+ character(16) :: list = '&stuff, 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 (&dtp->common, LIBERROR_READ_VALUE,
+ "Comma after namelist name not allowed");
+
if (!is_separator(c) && c != '!')
{
unget_char (dtp, c);
Re: [PATCH] testsuite: fix scan-tree-dump patterns [PR83904, PR100297]
On 4/18/23 12:39 PM, Harald Anlauf via Fortran wrote: Dear all, the attached patch adjusts the scan-tree-dump patterns of the reported testcases which likely were run in a location such that a path in an error message showing in the tree-dump might have accidentally matched "free" or "data", respectively. For the testcase gfortran.dg/reshape_8.f90 I checked with a failing gfortran-11 that the pattern is appropriate. OK for mainline? Thanks, Harald Yes, OK Thanks
Re: [PATCH] Fortran: resolve correct generic with TYPE(C_PTR) arguments [PR61615]
On 4/10/23 1:49 PM, Harald Anlauf via Fortran wrote: Dear all, when comparing formal and actual arguments of a procedure, there was no check of rank for derived types from intrinsic module ISO_C_BINDING. This could lead to a wrong resolution of generic procedures with dummy argument of related types, see PR. This was likely an oversight. The attached fix is simple and regtests cleanly on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald Looks good to go. Jerry
Re: [PATCH] Fortran: fix ICE with bind(c) in block data [PR104332]
On 3/9/23 10:08 AM, Harald Anlauf via Fortran wrote: Dear all, the attached almost obvious patch fixes a NULL pointer dereference in a check of a symbol with the bind(c) attribute. Regtested on x86_64-pc-linux-gnu. OK for mainline? This PR is marked as 10/11/12/13 regression, thus it should qualify for a backport. It's simple enough anyway. Thanks, Harald OK, please proceed. Thanks for the patch. Jerry
Re: [PATCH][stage1] Remove conditionals around free()
On 3/3/23 3:32 PM, Iain Sandoe wrote: On 3 Mar 2023, at 23:11, Bernhard Reutner-Fischer via Fortran wrote: On 2 March 2023 02:23:10 CET, Jerry D wrote: On 3/1/23 4:07 PM, Steve Kargl via Fortran wrote: On Wed, Mar 01, 2023 at 10:28:56PM +0100, Bernhard Reutner-Fischer via Fortran wrote: libgfortran/caf/single.c |6 ++ libgfortran/io/async.c |6 ++ libgfortran/io/format.c |3 +-- libgfortran/io/transfer.c|6 ++ libgfortran/io/unix.c|3 +-- The Fortran ones are OK. The only question I have: Is free posix compliant on all platforms? For example ming64 or mac? OSX / macOS are [certified] Posix compliant - but to unix03 (and might be missing features declared as optional at that revision, or features from later Posix versions). In the case of free() man says: "The free() function deallocates the memory allocation pointed to by ptr. If ptr is a NULL pointer, no operation is performed.” Iain It seems sometimes we run into things like this once in a while. I think we have the -liberty to cater even for non compliant systems either way, if you please excuse the pun. That's not an excuse on POSIX systems, imho. I am certainly not a C++ expert but it seems to me this all begs for automatic finalization where one would not have to invoke free at all. I suspect the gfortran frontend is not designed for such things. Otherwise I have no issue at all. It is a lot cleaner. Jerry
Re: [PATCH][stage1] Remove conditionals around free()
On 3/1/23 4:07 PM, Steve Kargl via Fortran wrote: On Wed, Mar 01, 2023 at 10:28:56PM +0100, Bernhard Reutner-Fischer via Fortran wrote: libgfortran/caf/single.c |6 ++ libgfortran/io/async.c |6 ++ libgfortran/io/format.c |3 +-- libgfortran/io/transfer.c|6 ++ libgfortran/io/unix.c|3 +-- The Fortran ones are OK. The only question I have: Is free posix compliant on all platforms? For example ming64 or mac? It seems sometimes we run into things like this once in a while. Otherwise I have no issue at all. It is a lot cleaner. Jerry
Re: [patch, libgfortran] Initailize some variable to get rid of nuisance warnings.
Pushed, thanks for feedback On 2/26/23 11:54 PM, Tobias Burnus wrote: Just side remarks, the 0 init in the patch is fine. On 27.02.23 03:53, Jerry D via Gcc-patches wrote: regarding PACK: since this is a bogus warning as the compiler does not realize that dim >= 1, wouldn't a gcc_assert (dim >= 1); Note: gcc_assert only exists in the compiler itself; in libgfortran, we use GFC_ASSERT or directly 'assert'. You could also use 'if (dim < 1) __builtin_unreachable();' – or since GCC 13: __attribute__((assume (dim >= 1))); Tobias PS: In Fortran, '-fopenmp-simd' plus '!$omp assume holds(dim>=0) ... !$omp end assume' (or !$omp ... + block/end block) can be used to denote such assumptions. '-fopenmp-simd' enables only those bits of OpenMP that do not require any library support (no libgomp, no pthreads), contrary to '-fopenmp'. - Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955
Re: [patch, libgfortran] Initailize some variable to get rid of nuisance warnings.
On 2/26/23 12:59 PM, Harald Anlauf wrote: Hi Jerry, regarding PACK: since this is a bogus warning as the compiler does not realize that dim >= 1, wouldn't a gcc_assert (dim >= 1); in the right place achieve the same effect, since the first argument must be an array? (It's different for SPREAD, though, where SOURCE may be scalar). I should have clarified in my posts that the warnings are on the use of sstride[0], mstride[0] or both. For example. ../../../trunk/libgfortran/generated/pack_i2.c: In function ‘pack_i2’: ../../../trunk/libgfortran/generated/pack_i2.c:129:14: warning: ‘sstride’ may be used uninitialized [-Wmaybe-uninitialized] 129 | if (sstride[0] == 0) | ~~~^~~ ../../../trunk/libgfortran/generated/pack_i2.c:80:14: note: ‘sstride’ declared here 80 | index_type sstride[GFC_MAX_DIMENSIONS]; | ^~~ ../../../trunk/libgfortran/generated/pack_i2.c:131:14: warning: ‘mstride’ may be used uninitialized [-Wmaybe-uninitialized] 131 | if (mstride[0] == 0) | ~~~^~~ ../../../trunk/libgfortran/generated/pack_i2.c:84:14: note: ‘mstride’ declared here 84 | index_type mstride[GFC_MAX_DIMENSIONS]; | ^~~ ../../../trunk/libgfortran/generated/pack_i2.c:131:14: warning: ‘mstride’ may be used uninitialized [-Wmaybe-uninitialized] 131 | if (mstride[0] == 0) | ~~~^~~ ../../../trunk/libgfortran/generated/pack_i2.c:84:14: note: ‘mstride’ declared here 84 | index_type mstride[GFC_MAX_DIMENSIONS]; | ^~~ In a sense it is a regression. It showed up when builds started to use -Wmaybe-unitialized. Cheers, Harald Am 26.02.23 um 20:52 schrieb Jerry D via Gcc-patches: The attached patch is minor and self explanatory. I assume this should wait for gfortran 14 since no regression involved. Please advise otherwise. Regression tested on x86-64. OK for trunk when the time is right? Regards, Jerry Author: Jerry DeLisle Date: Sat Feb 25 20:30:35 2023 -0800 Fortran: Eliminate nuisance warnings by initializing. Set sstride[0] and mstide[0] to zero, eliminating some warnings. libgfortran/ChangeLog: * generated/pack_c10.c (pack_c10): Regenerated. * generated/pack_c16.c (pack_c16): Regenerated. * generated/pack_c17.c (pack_c17): Regenerated. * generated/pack_c4.c (pack_c4): Regenerated. * generated/pack_c8.c (pack_c8): Regenerated. * generated/pack_i1.c (pack_i1): Regenerated. * generated/pack_i16.c (pack_i16): Regenerated. * generated/pack_i2.c (pack_i2): Regenerated. * generated/pack_i4.c (pack_i4): Regenerated. * generated/pack_i8.c (pack_i8): Regenerated. * generated/pack_r10.c (pack_r10): Regenerated. * generated/pack_r16.c (pack_r16): Regenerated. * generated/pack_r17.c (pack_r17): Regenerated. * generated/pack_r4.c (pack_r4): Regenerated. * generated/pack_r8.c (pack_r8): Regenerated. * generated/spread_c10.c (spread_c10): Regenerated. * generated/spread_c16.c (spread_c16): Regenerated. * generated/spread_c17.c (spread_c17): Regenerated. * generated/spread_c4.c (spread_c4): Regenerated. * generated/spread_c8.c (spread_c8): Regenerated. * generated/spread_i1.c (spread_i1): Regenerated. * generated/spread_i16.c (spread_i16): Regenerated. * generated/spread_i2.c (spread_i2): Regenerated. * generated/spread_i4.c (spread_i4): Regenerated. * generated/spread_i8.c (spread_i8): Regenerated. * generated/spread_r10.c (spread_r10): Regenerated. * generated/spread_r16.c (spread_r16): Regenerated. * generated/spread_r17.c (spread_r17): Regenerated. * generated/spread_r4.c (spread_r4): Regenerated. * generated/spread_r8.c (spread_r8): Regenerated. * intrinsics/execute_command_line.c (execute_command_line_i4), (execute_command_line_i8): Set estat_initial to zero. * intrinsics/pack_generic.c (pack_internal): Set sstride[0] and mstride[0] to zero. * intrinsics/spread_generic.c (spread_internal): Set sstride[0]. * m4/pack.m4: Set sstride[0] and mstride[0]. * m4/spread.m4: Set sstride[0].
[patch, libgfortran] Initailize some variable to get rid of nuisance warnings.
The attached patch is minor and self explanatory. I assume this should wait for gfortran 14 since no regression involved. Please advise otherwise. Regression tested on x86-64. OK for trunk when the time is right? Regards, Jerry Author: Jerry DeLisle Date: Sat Feb 25 20:30:35 2023 -0800 Fortran: Eliminate nuisance warnings by initializing. Set sstride[0] and mstide[0] to zero, eliminating some warnings. libgfortran/ChangeLog: * generated/pack_c10.c (pack_c10): Regenerated. * generated/pack_c16.c (pack_c16): Regenerated. * generated/pack_c17.c (pack_c17): Regenerated. * generated/pack_c4.c (pack_c4): Regenerated. * generated/pack_c8.c (pack_c8): Regenerated. * generated/pack_i1.c (pack_i1): Regenerated. * generated/pack_i16.c (pack_i16): Regenerated. * generated/pack_i2.c (pack_i2): Regenerated. * generated/pack_i4.c (pack_i4): Regenerated. * generated/pack_i8.c (pack_i8): Regenerated. * generated/pack_r10.c (pack_r10): Regenerated. * generated/pack_r16.c (pack_r16): Regenerated. * generated/pack_r17.c (pack_r17): Regenerated. * generated/pack_r4.c (pack_r4): Regenerated. * generated/pack_r8.c (pack_r8): Regenerated. * generated/spread_c10.c (spread_c10): Regenerated. * generated/spread_c16.c (spread_c16): Regenerated. * generated/spread_c17.c (spread_c17): Regenerated. * generated/spread_c4.c (spread_c4): Regenerated. * generated/spread_c8.c (spread_c8): Regenerated. * generated/spread_i1.c (spread_i1): Regenerated. * generated/spread_i16.c (spread_i16): Regenerated. * generated/spread_i2.c (spread_i2): Regenerated. * generated/spread_i4.c (spread_i4): Regenerated. * generated/spread_i8.c (spread_i8): Regenerated. * generated/spread_r10.c (spread_r10): Regenerated. * generated/spread_r16.c (spread_r16): Regenerated. * generated/spread_r17.c (spread_r17): Regenerated. * generated/spread_r4.c (spread_r4): Regenerated. * generated/spread_r8.c (spread_r8): Regenerated. * intrinsics/execute_command_line.c (execute_command_line_i4), (execute_command_line_i8): Set estat_initial to zero. * intrinsics/pack_generic.c (pack_internal): Set sstride[0] and mstride[0] to zero. * intrinsics/spread_generic.c (spread_internal): Set sstride[0]. * m4/pack.m4: Set sstride[0] and mstride[0]. * m4/spread.m4: Set sstride[0]. diff --git a/libgfortran/generated/pack_c10.c b/libgfortran/generated/pack_c10.c index a961057a8a6..c01efd11cf8 100644 --- a/libgfortran/generated/pack_c10.c +++ b/libgfortran/generated/pack_c10.c @@ -96,6 +96,9 @@ pack_c10 (gfc_array_c10 *ret, const gfc_array_c10 *array, dim = GFC_DESCRIPTOR_RANK (array); + sstride[0] = 0; /* Avoid warnings if not initialized. */ + mstride[0] = 0; + mptr = mask->base_addr; /* Use the same loop for all logical types, by using GFC_LOGICAL_1 diff --git a/libgfortran/generated/pack_c16.c b/libgfortran/generated/pack_c16.c index 37c062798bb..8ee6b25cbe6 100644 --- a/libgfortran/generated/pack_c16.c +++ b/libgfortran/generated/pack_c16.c @@ -96,6 +96,9 @@ pack_c16 (gfc_array_c16 *ret, const gfc_array_c16 *array, dim = GFC_DESCRIPTOR_RANK (array); + sstride[0] = 0; /* Avoid warnings if not initialized. */ + mstride[0] = 0; + mptr = mask->base_addr; /* Use the same loop for all logical types, by using GFC_LOGICAL_1 diff --git a/libgfortran/generated/pack_c17.c b/libgfortran/generated/pack_c17.c index f9638d640ad..7a1cf5e17e8 100644 --- a/libgfortran/generated/pack_c17.c +++ b/libgfortran/generated/pack_c17.c @@ -96,6 +96,9 @@ pack_c17 (gfc_array_c17 *ret, const gfc_array_c17 *array, dim = GFC_DESCRIPTOR_RANK (array); + sstride[0] = 0; /* Avoid warnings if not initialized. */ + mstride[0] = 0; + mptr = mask->base_addr; /* Use the same loop for all logical types, by using GFC_LOGICAL_1 diff --git a/libgfortran/generated/pack_c4.c b/libgfortran/generated/pack_c4.c index d72717041a1..76c8a853fac 100644 --- a/libgfortran/generated/pack_c4.c +++ b/libgfortran/generated/pack_c4.c @@ -96,6 +96,9 @@ pack_c4 (gfc_array_c4 *ret, const gfc_array_c4 *array, dim = GFC_DESCRIPTOR_RANK (array); + sstride[0] = 0; /* Avoid warnings if not initialized. */ + mstride[0] = 0; + mptr = mask->base_addr; /* Use the same loop for all logical types, by using GFC_LOGICAL_1 diff --git a/libgfortran/generated/pack_c8.c b/libgfortran/generated/pack_c8.c index 9f8e97e4bc8..365c26ed0e8 100644 --- a/libgfortran/generated/pack_c8.c +++ b/libgfortran/generated/pack_c8.c @@ -96,6 +96,9 @@ pack_c8 (gfc_array_c8 *ret, const gfc_array_c8 *array, dim = GFC_DESCRIPTOR_RANK (array);
Re: [PATCH] Fortran: ASSOCIATE variables should not be TREE_STATIC [PR95107]
On 2/6/23 12:10 PM, Harald Anlauf via Fortran wrote: Dear all, as the PR shows, it is likely not a good idea to try to make an ASSOCIATE variable static when -fno-automatic is specified, so rather keep it on the stack. Attached patch regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald Yes, OK Thanks, Jerry
Re: *PING* [PATCH] Fortran: prevent redundant integer division truncation warnings [PR108592]
On 2/5/23 11:33 AM, Harald Anlauf via Fortran wrote: Early gentle ping. Am 30.01.23 um 22:55 schrieb Harald Anlauf via Gcc-patches: Dear Fortranners, the subject says it all: in some cases we emit redundant integer division truncation warnings (2 or 4), where just one would have been sufficient. This is solved by using gfc_warning instead of gfc_warning_now. The testcase uses a suggestion by Andrew to verify that we get the desired warning exactly once. Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald The patch is gentle enough to be OK to commit. Thanks, Jerry
Re: [PATCH] Fortran: diagnose USE associated symbols in COMMON blocks [PR108453]
On 1/28/23 9:07 AM, Harald Anlauf via Fortran wrote: Dear all, a USE associated symbol shall not appear in a COMMON block (F2018:C8121) and needs to be diagnosed. The patch is fairly obvious. Regtested on x86_64-pc-linux-gnu. OK for mainline? As the PR is marked as a 10/11/12/13 regression, I plan to backport as appropriate. Thanks, Harald Yes, this is OK for all. Thanks Jerry
Re: [PATCH] Fortran: fix ICE in compare_bound_int [PR108527]
On 1/24/23 1:48 PM, Harald Anlauf via Fortran wrote: Dear all, when checking expressions for array sections, we need to ensure that these use only type INTEGER. However, it does not make sense to generate an internal error when encountering wrong types, but rather take the ordinary route of error recovery. The initial fix was provided by Steve. While working on the same PR, I found that the comments related to the logic needed a minor adjustment, and the logic could be cleaned up to actually match the intended comment. Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald Harald, this looks OK to me. Good for Mainline.
Re: [patch, gfortran.dg] Adjust numerous tests so that they pass on line endings
Committed: It is not apparent to me that the testsuite/ChangeLog was updated. Maybe there is a time delay on that? Please be patient with me as I figure out how all this works. ommit f963705752e9d0b79a340788166269af417e344e (HEAD -> master, origin/master, origin/HEAD) Author: Jerry DeLisle Date: Sat Jan 21 15:47:19 2023 -0800 Fortran tests: Revise line end tests allowing windows testing. gcc/testsuite/ChangeLog: * gfortran.dg/ISO_Fortran_binding_17.f90: Replace (\n|\r\n|\r) with (\r*\n+). * gfortran.dg/array_temporaries_2.f90: Likewise. * gfortran.dg/bind-c-contiguous-1.f90: Likewise. * gfortran.dg/bind-c-contiguous-4.f90: Likewise. * gfortran.dg/bind-c-contiguous-5.f90: Likewise. * gfortran.dg/fmt_error_4.f90: Likewise. * gfortran.dg/fmt_error_5.f90: Likewise. * gfortran.dg/fmt_float.f90: Likewise. * gfortran.dg/fmt_l.f90: Likewise. * gfortran.dg/fmt_nonchar_2.f90: Likewise. * gfortran.dg/fmt_zero_precision.f90: Likewise. * gfortran.dg/g77/f77-edit-apostrophe-out.f: Likewise. * gfortran.dg/g77/f77-edit-colon-out.f: Likewise. * gfortran.dg/g77/f77-edit-h-out.f: Likewise. * gfortran.dg/g77/f77-edit-i-out.f: Likewise. * gfortran.dg/g77/f77-edit-s-out.f: Likewise. * gfortran.dg/g77/f77-edit-slash-out.f: Likewise. * gfortran.dg/g77/f77-edit-t-out.f: Likewise. * gfortran.dg/g77/f77-edit-x-out.f: Likewise. * gfortran.dg/namelist_40.f90: Likewise. * gfortran.dg/namelist_47.f90: Likewise. * gfortran.dg/namelist_print_1.f: Likewise. * gfortran.dg/parameter_array_dummy.f90: Likewise.
Re: [patch, gfortran.dg] Adjust numerous tests so that they pass on line endings
On 1/22/23 5:38 AM, Mikael Morin wrote: Hello, Le 22/01/2023 à 00:59, Jerry D via Fortran a écrit : (...) Proposed ChangeLog entry using git gcc-commit-mklog: Author: Jerry DeLisle Date: Sat Jan 21 15:47:19 2023 -0800 Revise the line end tests to pass on certain windows test environments which inject spurious /r characters. Adjust (\n|\r\n|\r) to (\r*\n+). gcc/testsuite/ChangeLog: * gfortran.dg/ISO_Fortran_binding_17.f90: As noted above. (...)This part will be integrated in the ChangeLog file, without the preceding text. Don't start with "As noted above", as there will be no "above" to refer to. Thank you, relearning how these things work with the automation scripts. Jerry
Re: [patch, gfortran.dg] Adjust numerous tests so that they pass on line endings
On 1/20/23 6:13 PM, Jerry DeLisle via Fortran wrote: Hi all, The attached patch modifies the following tests to check for line endings. Some test environments inject superfluous /r characters at ends of lines. The expression matching in dg-output tests are changed from: (\n|\r\n|\r) to (\r*\n+) This allows these tests to pass. The failing tests tend to mask the real bugs in these systems. The changes were provided by Nightstrike who has tested on the troublesome environment. I ran the tests successfully on Linux. I do not know if anyone has tested on Mac or some of the other system that use odd line endings. OK for trunk? What about for 12? Regards, Jerry modified: gcc/testsuite/gfortran.dg/ISO_Fortran_binding_17.f90 modified: gcc/testsuite/gfortran.dg/array_temporaries_2.f90 modified: gcc/testsuite/gfortran.dg/bind-c-contiguous-1.f90 modified: gcc/testsuite/gfortran.dg/bind-c-contiguous-4.f90 modified: gcc/testsuite/gfortran.dg/bind-c-contiguous-5.f90 modified: gcc/testsuite/gfortran.dg/fmt_error_4.f90 modified: gcc/testsuite/gfortran.dg/fmt_error_5.f90 modified: gcc/testsuite/gfortran.dg/fmt_float.f90 modified: gcc/testsuite/gfortran.dg/fmt_l.f90 modified: gcc/testsuite/gfortran.dg/fmt_nonchar_2.f90 modified: gcc/testsuite/gfortran.dg/fmt_zero_precision.f90 modified: gcc/testsuite/gfortran.dg/g77/f77-edit-apostrophe-out.f modified: gcc/testsuite/gfortran.dg/g77/f77-edit-colon-out.f modified: gcc/testsuite/gfortran.dg/g77/f77-edit-h-out.f modified: gcc/testsuite/gfortran.dg/g77/f77-edit-i-out.f modified: gcc/testsuite/gfortran.dg/g77/f77-edit-s-out.f modified: gcc/testsuite/gfortran.dg/g77/f77-edit-slash-out.f modified: gcc/testsuite/gfortran.dg/g77/f77-edit-t-out.f modified: gcc/testsuite/gfortran.dg/g77/f77-edit-x-out.f modified: gcc/testsuite/gfortran.dg/namelist_40.f90 modified: gcc/testsuite/gfortran.dg/namelist_47.f90 modified: gcc/testsuite/gfortran.dg/namelist_print_1.f modified: gcc/testsuite/gfortran.dg/parameter_array_dummy.f90 Proposed ChangeLog entry using git gcc-commit-mklog: Author: Jerry DeLisle Date: Sat Jan 21 15:47:19 2023 -0800 Revise the line end tests to pass on certain windows test environments which inject spurious /r characters. Adjust (\n|\r\n|\r) to (\r*\n+). gcc/testsuite/ChangeLog: * gfortran.dg/ISO_Fortran_binding_17.f90: As noted above. * gfortran.dg/array_temporaries_2.f90: As noted above. * gfortran.dg/bind-c-contiguous-1.f90: As noted above. * gfortran.dg/bind-c-contiguous-4.f90: As noted above. * gfortran.dg/bind-c-contiguous-5.f90: As noted above. * gfortran.dg/fmt_error_4.f90: As noted above. * gfortran.dg/fmt_error_5.f90: As noted above. * gfortran.dg/fmt_float.f90: As noted above. * gfortran.dg/fmt_l.f90: As noted above. * gfortran.dg/fmt_nonchar_2.f90: As noted above. * gfortran.dg/fmt_zero_precision.f90: As noted above. * gfortran.dg/g77/f77-edit-apostrophe-out.f: As noted above. * gfortran.dg/g77/f77-edit-colon-out.f: As noted above. * gfortran.dg/g77/f77-edit-h-out.f: As noted above. * gfortran.dg/g77/f77-edit-i-out.f: As noted above. * gfortran.dg/g77/f77-edit-s-out.f: As noted above. * gfortran.dg/g77/f77-edit-slash-out.f: As noted above. * gfortran.dg/g77/f77-edit-t-out.f: As noted above. * gfortran.dg/g77/f77-edit-x-out.f: As noted above. * gfortran.dg/namelist_40.f90: As noted above. * gfortran.dg/namelist_47.f90: As noted above. * gfortran.dg/namelist_print_1.f: As noted above. * gfortran.dg/parameter_array_dummy.f90: As noted above.
Re: [patch. fortran] PR102595 ICE in var_element, at fortran/decl.c
On 1/20/23 9:16 PM, Jerry D wrote:
On 1/20/23 5:46 PM, Jerry D wrote:
A PARAMETER value is not allowed in a DATA statement, similar to an
EQUIVALENCE.
The check for this was in gfc_assign_data_value() in data.cc which
turns out to be too late when trying to assign a zero sized array.
Correction, the chunk in data.cc must remain for one test case. I
spotted this after rerunning check-fortran for several variations.
Attached patch is revised to include a new test case and adjustment of
an existing test case. It also adds in a return MATCH_ERROR I
accidentally left of the first submit when I was cleaning some things up.
Ok for Mainline?
Jeyy
diff --git a/gcc/fortran/data.cc b/gcc/fortran/data.cc
index 443d35da9cf..d29eb12c1b1 100644
--- a/gcc/fortran/data.cc
+++ b/gcc/fortran/data.cc
@@ -244,13 +244,6 @@ gfc_assign_data_value (gfc_expr *lvalue, gfc_expr *rvalue, mpz_t index,
"array-element nor a scalar-structure-component";
symbol = lvalue->symtree->n.sym;
- if (symbol->attr.flavor == FL_PARAMETER)
-{
- gfc_error ("PARAMETER %qs shall not appear in a DATA statement at %L",
- symbol->name, &lvalue->where);
- return false;
-}
-
init = symbol->value;
last_ts = &symbol->ts;
last_con = NULL;
diff --git a/gcc/fortran/primary.cc b/gcc/fortran/primary.cc
index 543d9cc0de4..28ce5fea865 100644
--- a/gcc/fortran/primary.cc
+++ b/gcc/fortran/primary.cc
@@ -4076,8 +4076,14 @@ match_variable (gfc_expr **result, int equiv_flag, int host_flag)
gfc_error ("Named constant at %C in an EQUIVALENCE");
return MATCH_ERROR;
}
- /* Otherwise this is checked for and an error given in the
- variable definition context checks. */
+ if (gfc_in_match_data())
+ {
+ gfc_error ("PARAMETER %qs shall not appear in a DATA statement at %C",
+ sym->name);
+ return MATCH_ERROR;
+ }
+ /* Otherwise this is checked for an error given in the
+ variable definition context checks. */
break;
case FL_PROCEDURE:
diff --git a/gcc/testsuite/gfortran.dg/parameter_data0.f90 b/gcc/testsuite/gfortran.dg/parameter_data0.f90
new file mode 100644
index 000..4f1da9ea42e
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/parameter_data0.f90
@@ -0,0 +1,6 @@
+! { dg-do compile }
+! PR fortran/102595 Similar to 88048 with a zero sized array
+program p
+ complex, parameter:: x(0) = 2
+ data x%im /3.0/ ! { dg-error "shall not appear in a DATA statement" }
+end
diff --git a/gcc/testsuite/gfortran.dg/pr88048.f90 b/gcc/testsuite/gfortran.dg/pr88048.f90
index 11293934330..ad82d45881c 100644
--- a/gcc/testsuite/gfortran.dg/pr88048.f90
+++ b/gcc/testsuite/gfortran.dg/pr88048.f90
@@ -2,6 +2,6 @@
! PR fortran/88048
program p
integer, parameter :: a(2) = 1
- data a(2) /a(1)/ ! { dg-error "definable entity" }
+ data a(2) /a(1)/ ! { dg-error "shall not appear in a DATA statement" }
print *, a
end
Re: [patch. fortran] PR102595 ICE in var_element, at fortran/decl.c
On 1/20/23 5:46 PM, Jerry D wrote: A PARAMETER value is not allowed in a DATA statement, similar to an EQUIVALENCE. The check for this was in gfc_assign_data_value() in data.cc which turns out to be too late when trying to assign a zero sized array. Correction, the chunk in data.cc must remain for one test case. I spotted this after rerunning check-fortran for several variations. Regards, Jerry
[patch. fortran] PR102595 ICE in var_element, at fortran/decl.c
A PARAMETER value is not allowed in a DATA statement, similar to an
EQUIVALENCE.
The check for this was in gfc_assign_data_value() in data.cc which turns
out to be too late when trying to assign a zero sized array.
To correct this, the check is moved to match_variable() in primary.cc
where a similar check for EQUIVALENCE is already being performed.
Regression tested on x86_64-linux-gnu. I will create a test case from
the case presented in the PR which is trivial. There are already two
other tests in the test suite that exercise this check.
OK for trunk?
Regards,
Jerrydiff --git a/gcc/fortran/data.cc b/gcc/fortran/data.cc
index 443d35da9cf..d29eb12c1b1 100644
--- a/gcc/fortran/data.cc
+++ b/gcc/fortran/data.cc
@@ -244,13 +244,6 @@ gfc_assign_data_value (gfc_expr *lvalue, gfc_expr *rvalue, mpz_t index,
"array-element nor a scalar-structure-component";
symbol = lvalue->symtree->n.sym;
- if (symbol->attr.flavor == FL_PARAMETER)
-{
- gfc_error ("PARAMETER %qs shall not appear in a DATA statement at %L",
- symbol->name, &lvalue->where);
- return false;
-}
-
init = symbol->value;
last_ts = &symbol->ts;
last_con = NULL;
diff --git a/gcc/fortran/primary.cc b/gcc/fortran/primary.cc
index 543d9cc0de4..158f039f225 100644
--- a/gcc/fortran/primary.cc
+++ b/gcc/fortran/primary.cc
@@ -4076,6 +4076,11 @@ match_variable (gfc_expr **result, int equiv_flag, int host_flag)
gfc_error ("Named constant at %C in an EQUIVALENCE");
return MATCH_ERROR;
}
+ if (gfc_in_match_data())
+ {
+ gfc_error ("PARAMETER %qs shall not appear in a DATA statement at %C",
+ sym->name);
+ }
/* Otherwise this is checked for and an error given in the
variable definition context checks. */
break;
Re: [Patch] libfortran: Fix execute_command_line for Windows
On 1/18/23 7:42 AM, Tobias Burnus wrote: Reported by nightstrike, who also tested this patch. On Windows, we call system() which works as described at https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/system-wsystem?view=msvc-170 Namely, it only fails with "-1" if the command interpreter could not be started. Otherwise, it has the return value. (Same on Linux.) On POSIX systems, 'sh' calls exit(127) or _exit(127) if it cannot execute the program of the passed string, as documented. Cf. https://www.unix.com/man-page/posix/3p/system/ Thus, the question is what happens on Windows. Our experiments, several webpages (like stackoverflow) and the source code of WINE for cmd.exe indicate that Windows returns 9009 in that case. See for instance https://github.com/wine-mirror/wine/blob/master/programs/cmd/wcmdmain.c#L1262-L1269 Thus, we now do likewise. The code is for MINGW; Cygwin does not set that that var and is likely to use return values closer to POSIX. OK for mainline? Tobias OK, thanks fir fix. Jerry
Re: [PING] nvptx: '-mframe-malloc-threshold', '-Wframe-malloc-threshold' (was: Handling of large stack objects in GPU code generation -- maybe transform into heap allocation?)
On 1/11/23 4:06 AM, Thomas Schwinge wrote: Hi! Ping -- the '-mframe-malloc-threshold' idea, at least. Note that while this issue originally did pop up for Fortran I/O, it's likewise relevant for other functions that maintain big frames, for example in newlib: libc/string/libc_a-memmem.o:.local .align 16 .b8 %frame_ar[2064]; libc/string/libc_a-strcasestr.o:.local .align 16 .b8 %frame_ar[2064]; libc/string/libc_a-strstr.o:.local .align 16 .b8 %frame_ar[2064]; libm/math/libm_a-k_rem_pio2.o:.local .align 16 .b8 %frame_ar[560]; Therefore a generic solution (or, workaround if you'd like) does seem appropriate. ---snip --- AS a gfortranner I have to at least say anyone doing fortran I/O on a GPU is nuts. With that said, a configurable option to address the broader issue makes sense. Perhaps the default threshold should be whatever it is now and if someone has a real situation where it is needed, they can adjust. Regards, Jerry
Re: nvptx: '-mframe-malloc-threshold', '-Wframe-malloc-threshold' (was: Handling of large stack objects in GPU code generation -- maybe transform into heap allocation?)
On 12/23/22 6:08 AM, Thomas Schwinge wrote:
Hi!
On 2022-11-11T15:35:44+0100, Richard Biener via Fortran
wrote:
On Fri, Nov 11, 2022 at 3:13 PM Thomas Schwinge wrote:
For example, for Fortran code like:
write (*,*) "Hello world"
..., 'gfortran' creates:
struct __st_parameter_dt dt_parm.0;
try
{
dt_parm.0.common.filename =
&"source-gcc/libgomp/testsuite/libgomp.oacc-fortran/print-1_.f90"[1]{lb: 1 sz:
1};
dt_parm.0.common.line = 29;
dt_parm.0.common.flags = 128;
dt_parm.0.common.unit = 6;
_gfortran_st_write (&dt_parm.0);
_gfortran_transfer_character_write (&dt_parm.0, &"Hello world"[1]{lb:
1 sz: 1}, 11);
_gfortran_st_write_done (&dt_parm.0);
}
finally
{
dt_parm.0 = {CLOBBER(eol)};
}
The issue: the stack object 'dt_parm.0' is a half-KiB in size (yes,
really! -- there's a lot of state in Fortran I/O apparently). That's a
problem for GPU execution -- here: OpenACC/nvptx -- where typically you
have small stacks. (For example, GCC/OpenACC/nvptx: 1 KiB per thread;
GCC/OpenMP/nvptx is an exception, because of its use of '-msoft-stack'
"Use custom stacks instead of local memory for automatic storage".)
Now, the Nvidia Driver tries to accomodate for such largish stack usage,
and dynamically increases the per-thread stack as necessary (thereby
potentially reducing parallelism) -- if it manages to understand the call
graph. In case of libgfortran I/O, it evidently doesn't. Not being able
to disprove existance of recursion is the common problem, as I've read.
At run time, via 'CU_JIT_INFO_LOG_BUFFER' you then get, for example:
warning : Stack size for entry function 'MAIN__$_omp_fn$0' cannot be
statically determined
That's still not an actual problem: if the GPU kernel's stack usage still
fits into 1 KiB. Very often it does, but if, as happens in libgfortran
I/O handling, there is another such 'dt_parm' put onto the stack, the
stack then overflows; device-side SIGSEGV.
(There is, by the way, some similar analysis by Tom de Vries in
"[nvptx, openacc, openmp, testsuite]
Recursive tests may fail due to thread stack limit".)
Of course, you shouldn't really be doing I/O in GPU kernels, but people
do like their occasional "'printf' debugging", so we ought to make that
work (... without pessimizing any "normal" code).
I assume that generally reducing the size of 'dt_parm' etc. is out of
scope.
There are so many wiggles and turns and corner cases and the like of
nightmares in I/O I would advise not trying to reduce the dt_parm. It
could probably be done.
For debugging GPU, would it not be better to have a way you signal back
to a main thread to do a print from there, like some sort of call back
in the users code under test.
Putting this another way, recommend users debugging to use a different
method than embedding print statements for debugging rather than do a
tone of work to enable something that is not really a legitimate use case.
FWIW,
Jerry
Re: [PATCH] Fortran: incorrect array bounds when bound intrinsic used in decl [PR108131]
On 12/17/22 1:21 PM, Harald Anlauf via Fortran wrote: Dear all, the previous fix for pr103505 introduced a regression that could lead to wrong array bounds when LBOUND/UBOUND were used in the array spec of a declaration. The reason was that we tried to simplify too early the array element spec, which appears to have interfered with the subtle semantics of the bound intrinsics. The solution is to undo the fix for pr103505. It turns out that there are other code changes in place that were put in place to fix related ICEs, and which handle that one, too, and only lead to a change of the emitted error diagnostics. Regtested on x86_64-pc-linux-gnu. OK for mainline? Yes, OK for mainline. My thought is that this is the kind of bug that can go unseen with incorrect array bounds so is a good candidate to backport. At least 12, 10 and 11 if you have time and it is applicable. As this is a 10/11/12/13 regression, I would like to backport as seems fit. Thanks, Harald
[patch, fortran] ICE on automatic array of derived type with DTIO
I have committed the obvious as simple. The master branch has been updated by Jerry DeLisle : https://gcc.gnu.org/g:7e76cd96950f49ce21246d44780e972d86b2bcdd commit r13-4862-g7e76cd96950f49ce21246d44780e972d86b2bcdd Author: Steve Kargl Date: Thu Dec 22 20:38:57 2022 -0800 Remove not needed assert macro which fails. PR fortran/106731 gcc/fortran/ChangeLog: * trans-array.cc (gfc_trans_auto_array_allocation): Remove gcc_assert (!TREE_STATIC()). gcc/testsuite/ChangeLog: * gfortran.dg/pr106731.f90: New test.
Re: [committed] testsuite: Fix up pr107397.f90 test [PR107397]
On 12/19/22 2:29 AM, Jakub Jelinek wrote: On Sat, Dec 17, 2022 at 09:12:43AM -0800, Jerry D via Gcc-patches wrote: The attached patch fixes a regression and is a patch from Steve. I have regression tested it and provided a test case. It is fairly simple and I will commit under the "simple" rule in a little while. Thanks Steve for Patch. Thanks Harald for helping me get back up to speed on the git magic. The pr107397.f90 test FAILs for me, one problem was that the added diagnostics has an indefinite article before BOZ, but the test dg-error didn't. The other problem was that on the other dg-error there was no space between the string and closing }, so it was completely ignored and the error was an excess error. 2022-12-19 Jakub Jelinek PR fortran/107397 * gfortran.dg/pr107397.f90: Adjust expected diagnostic wording and add space between dg-error string and closing }. === snip === Thanks Jakub.
[patch, fortran] PR107397 ICE in gfc_arith_plus, at fortran/arith.cc:654
Hi all,
The attached patch fixes a regression and is a patch from Steve. I have
regression tested it and provided a test case. It is fairly simple and
I will commit under the "simple" rule in a little while.
Thanks Steve for Patch. Thanks Harald for helping me get back up to
speed on the git magic.
Regards,
Jerry
diff --git a/gcc/fortran/decl.cc b/gcc/fortran/decl.cc
index 0f9b2ced4c2..1562dc22bc6 100644
--- a/gcc/fortran/decl.cc
+++ b/gcc/fortran/decl.cc
@@ -2221,6 +2221,14 @@ add_init_expr_to_sym (const char *name, gfc_expr **initp, locus *var_locus)
sym->ts.f90_type = init->ts.f90_type;
}
+ /* Catch the case: type(t), parameter :: x = z'1'. */
+ if (sym->ts.type == BT_DERIVED && init->ts.type == BT_BOZ)
+ {
+ gfc_error ("Entity %qs at %L is incompatible with a BOZ "
+ "literal constant", name, &sym->declared_at);
+ return false;
+ }
+
/* Add initializer. Make sure we keep the ranks sane. */
if (sym->attr.dimension && init->rank == 0)
{
diff --git a/gcc/testsuite/gfortran.dg/pr107397.f90 b/gcc/testsuite/gfortran.dg/pr107397.f90
new file mode 100644
index 000..4592a275e70
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr107397.f90
@@ -0,0 +1,9 @@
+!{ dg-do compile }
+!
+program p
+ type t
+real :: a = 1.0
+ end type
+ type(t), parameter :: x = z'1' ! { dg-error "incompatible with BOZ" }
+ x%a = x%a + 2 ! { dg-error "has no IMPLICIT type"}
+end
Re: [PATCH] Fortran: fix ICE on bad use of statement function [PR107995]
On 12/10/22 1:23 PM, Harald Anlauf via Fortran wrote: Dear all, I'm submitting the attached patch on behalf of Steve. It fixes an ICE that occurs on an obscure use of a statement function as argument to that function. Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald OK, looks good. See my unrelated question on mattermost. Jerry
Re: [PATCH, committed] Fortran: error recovery for bad initializers of implied-shape arrays [PR106209]
Hi Herald, Looks good to me. I have always preferred informative messages. Thanks, Jerry On 7/14/22 1:34 PM, Harald Anlauf via Fortran wrote: Dear all, the attached patch introduces error recovery for two cases of using an invalid array in a declaration of an implied-shape array instead of hitting internal errors. Initial patch by Steve. The final version was approved in the PR by Steve. Committed as: https://gcc.gnu.org/g:748f8a8b145dde59c7b63aa68b5a59515b7efc49 Thanks, Harald
Re: *PING* [PATCH 0/4] Use pointer arithmetic for array references [PR102043]
Yes, Thank you Mikael! On 4/22/22 6:59 AM, Thomas Koenig via Fortran wrote: Hi Mikael, Ping for the four patches starting at https://gcc.gnu.org/pipermail/fortran/2022-April/057759.html : https://gcc.gnu.org/pipermail/fortran/2022-April/057757.html https://gcc.gnu.org/pipermail/fortran/2022-April/057760.html https://gcc.gnu.org/pipermail/fortran/2022-April/057758.html https://gcc.gnu.org/pipermail/fortran/2022-April/057761.html Richi accepted the general direction and the middle-end interaction. I need a fortran frontend ack as well. Looks good to me. Thanks a lot for taking this on! This would have been a serious regression if released with gcc 12. Best regards Thomas
Re: *Ping* [PATCH] PR fortran/104210 - [11/12 Regression] ICE in gfc_zero_size_array, at fortran/arith.cc:1685
On 4/4/22 12:09 PM, Harald Anlauf via Fortran wrote: Am 29.03.22 um 23:41 schrieb Harald Anlauf via Fortran: Dear all, during error recovery on invalid declarations of functions as coarrays we may hit multiple places with NULL pointer dereferences. The attached patch provides a minimal and conservative solution. Regtested on x86_64-pc-linux-gnu. OK for mainline/11-branch? Thanks, Harald Patch looks OK Harald, OK. Thanks, Jerry
Re: [PATCH] PR fortran/105138 - Bogus error when function name does not shadow an intrinsic when RESULT clause is used
On 4/4/22 12:04 PM, Harald Anlauf via Fortran wrote: Dear all, Steve's analysis (see PR) showed that we confused the case when a symbol refererred to a recursive procedure which was named the same as an intrinsic. The standard allows such recursive references (see e.g. F2018:19.3.1). The attached patch is based on Steve's, but handles both functions and subroutines. Testcase verified with NAG and Crayftn. Regtested on x86_64-pc-linux-gnu. OK for mainline? This bug is a rejects-valid, but could also lead to wrong code, see e.g. the PR, comment#4. Would this qualify for a backport to e.g. the 11-branch? Thanks, Harald Yes, looks good, OK to commit Regards, Jerry
Re: [PATCH] PR fortran/84519 - [F2018] STOP and ERROR STOP statements with QUIET specifier
On 2/23/22 2:21 PM, Harald Anlauf via Fortran wrote: Dear Fortranners, Fortran 2018 added a QUIET= specifier to STOP and ERROR STOP statements. Janne already implemented the library side code four (4!) years ago, but so far the frontend implementation was missing. Furthermore, F2018 allows for non-default-integer stopcode expressions (finally!). The attached patch provides this implementation. That was not too much fun for the following reasons: - fixed format vs. free format - F95 and F2003 apparently did not require a blank between STOP and stopcode, while F2008+ do require it. This should explain for the three testcases. Regtested on x86_64-pc-linux-gnu. OK for mainline? One step closer to F2018! Thanks, Harald A minor comment. Is there a way to also have a run-time test case? OK to commit now and additional test case can be added if necessary later. Regards, Jerry
Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization
For what it is worth. On 2/10/22 11:49 AM, Harald Anlauf via Fortran wrote: Hi Paul, Am 10.02.22 um 13:25 schrieb Paul Richard Thomas via Fortran: Conclusions on ifort: (i) The agreement between gfortran, with the patch applied, and ifort is strongest of all the other brands; (ii) The disagreements are all down to the treatment of the parent component of arrays of extended types: gfortran finalizes the parent component as an array, whereas ifort does a scalarization. I have a patch ready to do likewise. Overall conclusions: (i) Sort out whether or not derived type constructors are considered to be functions; (ii) Come to a conclusion about scalarization of parent components of extended type arrays; (iii) Check and, if necessary, correct the ordering of finalization in intrinsic assignment of class arrays. (iv) Finalization is difficult to graft on to existing pre-F2003 compilers, as witnessed by the range of implementations. I would be really grateful for thoughts on (i) and (ii). My gut feeling, as remarked in the submission, is that we should aim to be as close as possible, if not identical to, ifort. Happily, that is already the case. I am really sorry to be such a bother, but before we think we should do the same as Intel, we need to understand what Intel does and whether that is actually correct. Or not inconsistent with the standard. And I would really like to understand even the most simple, stupid case. I did reduce testcase finalize_38.f90 to an almost bare minimum, see attached, and changed the main to type(simple), parameter :: ThyType = simple(21) type(simple) :: ThyType2 = simple(22) type(simple), allocatable :: MyType, MyType2 print *, "At start of program: ", final_count MyType = ThyType print *, "After 1st allocation:", final_count MyType2 = ThyType2 print *, "After 2nd allocation:", final_count Note that "ThyType" is now a parameter. - snip Ignore whether Thytype is a Parameter. Regardless Mytype and Mytype2 are allocated upon the assignment. Now if these are never used anywhere, it seems to me the deallocation can be done by the compiler anywhere after the last time it is used. So it can be either after the PRINT statement before the end if the program or right after the assignment before your PRINT statements that examine the value of final_count. I think the result is arbitrary/undefined in your reduced test case I do not have the Intel compiler yet, so I was going to suggest see what it does if your test program prints something from within MyType and MyType2 after all your current print statements at the end. Try this variation of the main program. program test_final use testmode implicit none type(simple), parameter :: ThyType = simple(21) type(simple) :: ThyType2 = simple(22) type(simple), allocatable :: MyType, MyType2 print *, "At start of program: ", final_count MyType = ThyType print *, "After 1st allocation:", final_count MyType2 = ThyType2 print *, "After 2nd allocation:", final_count print *, MyType%ind, MyType2%ind, final_count deallocate(Mytype) print *, MyType%ind, MyType2%ind, final_count deallocate(Mytype2) print *, MyType%ind, MyType2%ind, final_count end program test_final I get with trunk: $ ./a.out At start of program: 0 After 1st allocation: 0 After 2nd allocation: 0 21 22 0 0 22 1 0 0 2 Which makes sense to me. Regards, Jerry
Re: [Patch, fortran] PR37336 (Finalization) - [F03] Finish derived-type finalization
Remember the days when reading very old cryptic Fortran code? Remember the fixed line lengths and cryptic variable names! I fear the Standards committee has achieved history with the Standard itself it is so difficult to understand sometimes. Cheers to Paul and Harald for digging on this. Jerry On 2/8/22 11:29 AM, Harald Anlauf via Fortran wrote: Hi Paul, Am 08.02.22 um 12:22 schrieb Paul Richard Thomas via Fortran: Hi Harald, Thanks for giving the patch a whirl. the parent components as an array. I strongly suspect that, from reading 7.5.6.2 paragraphs 2 and 3 closely, that ifort has it right. However, this is another issue to come back to in the future. Could you specify which version of Intel you tried? ifort (IFORT) 2021.1 Beta 20201112 ok, that's good to know. Testcase finalize_38.f90 fails for me with ifort 2021.5.0 with: 131 This test also fails with crayftn 11 & 12 and nagfor 7.0, but in a different place. I have run your modified version of finalize_38.f90, and now I see that you can get a bloody head just from scratching too much... crayftn 12.0.2: 1, 3, 1 2, 21, 0 11, 3, 2 12, 21, 1 21, 4, 3 23, 21, 22 | 42, 43 31, 6, 4 41, 7, 5 51, 9, 7 61, 10, 8 71, 13, 10 101, 2, 1 102, 4, 3 111, 3, 2 121, 4, 2 122, 0, 4 123, 5, 6 | 2*0 131, 5, 2 132, 0, 4 133, 7, 8 | 2*0 141, 6, 3 151, 10, 5 161, 16, 9 171, 18, 11 175, 0., 20. | 10., 20. nagfor 7.0: 1 0 1 11 1 2 23 21 22 | 42 43 71 9 10 72 11 99 131 3 2 132 5 4 141 4 3 151 6 5 161 10 9 171 12 11 Intel 2021.5.0: 131 3 2 132 0 4 133 5 6 | 0 0 141 4 3 151 7 5 152 3 0 153 0 0 | 1 3 forrtl: severe (174): SIGSEGV, segmentation fault occurred [...] That got me reading 7.5.6.3, where is says in paragraph 1: "When an intrinsic assignment statement is executed (10.2.1.3), if the variable is not an unallocated allocatable variable, it is finalized after evaluation of expr and before the definition of the variable. ..." Looking at the beginning of the testcase code (abridged): type(simple), allocatable :: MyType, MyType2 type(simple) :: ThyType = simple(21), ThyType2 = simple(22) ! The original PR - one finalization of 'var' before (re)allocation. MyType = ThyType call test(1, 0, [0,0], 0) This is an intrinsic assignment. Naively I would expect MyType to be initially unallocated. ThyType is not allocatable and non-pointer and cannot become undefined here and would not play any role in finalization. I am probably too blind-sighted to see why there should be a finalization here. What am I missing? Could you use the attached version of finalize_38.f90 with crayftn and NAG? All the stop statements are replaced with prints. Ifort gives: 131 3 2 132 0 4 133 5 6 | 0 0 141 4 3 151 7 5 152 3 0 153 0 0 | 1 3 161 13 9 162 20 0 163 0 0 | 10 20 171 14 11 I think it is a good idea to have these prints in the testcase whenever there is a departure from expectations. So print&stop? Furthermore, for the sake of health of people reading the testcases later, I think it would not harm to add more explanations why we expect a certain behavior... ;-) Best regards Paul Best regards, Harald
Re: [PATCH] PR fortran/103782 - [9/10/11/12 Regression] internal error occurs when overloading intrinsic
On 1/13/22 12:56 PM, Harald Anlauf via Fortran wrote: Dear all, there was a regression handling overloaded elemental intrinsics, leading to an ICE on valid code. Reported by Urban Jost. The logic for when we need to scalarize a call to an intrinsic seems to have been broken during the 9-release. The attached patch fixes the ICE and seems to work on the extended testcase as well as regtests fine on x86_64-pc-linux-gnu. OK for mainline? Backport to affected branches? Looks good to me. Go for mainline and backport. Regards, Jerry
Re: [PATCH,FORTRAN 01/29] gdbinit: break on gfc_internal_error
Looks OK. Cheers On 10/29/21 11:58 AM, Bernhard Reutner-Fischer via Fortran wrote: ping On Wed, 5 Sep 2018 14:57:04 + Bernhard Reutner-Fischer wrote: From: Bernhard Reutner-Fischer Aids debugging the fortran FE. gcc/ChangeLog: 2017-11-12 Bernhard Reutner-Fischer * gdbinit.in: Break on gfc_internal_error. --- gcc/gdbinit.in | 1 + 1 file changed, 1 insertion(+) diff --git a/gcc/gdbinit.in b/gcc/gdbinit.in index 4db977f0bab..ac4d7c42e21 100644 --- a/gcc/gdbinit.in +++ b/gcc/gdbinit.in @@ -227,6 +227,7 @@ b fancy_abort # Put a breakpoint on internal_error to help with debugging ICEs. b internal_error +b gfc_internal_error set complaints 0 # Don't let abort actually run, as it will make
Re: [PATCH,FORTRAN 28/29] Free type-bound procedure structs
Looks good and simple. Proceed. Thanks Jerry On 10/28/21 5:05 PM, Bernhard Reutner-Fischer via Fortran wrote: ping [Rebased, re-regtested cleanly. Ok for trunk?] On Wed, 5 Sep 2018 14:57:31 + Bernhard Reutner-Fischer wrote: From: Bernhard Reutner-Fischer compiling gfortran.dg/typebound_proc_31.f90 leaked the type-bound structs: 56 bytes in 1 blocks are definitely lost. at 0x4C2CC05: calloc (vg_replace_malloc.c:711) by 0x151EA90: xcalloc (xmalloc.c:162) by 0x8E3E4F: gfc_get_typebound_proc(gfc_typebound_proc*) (symbol.c:4945) by 0x84C095: match_procedure_in_type (decl.c:10486) by 0x84C095: gfc_match_procedure() (decl.c:6696) ... gcc/fortran/ChangeLog: 2017-12-06 Bernhard Reutner-Fischer * symbol.c (free_tb_tree): Free type-bound procedure struct. (gfc_get_typebound_proc): Use explicit memcpy for clarity. --- gcc/fortran/symbol.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/gcc/fortran/symbol.c b/gcc/fortran/symbol.c index 53c760a6c38..cde34c67482 100644 --- a/gcc/fortran/symbol.c +++ b/gcc/fortran/symbol.c @@ -3845,7 +3845,7 @@ free_tb_tree (gfc_symtree *t) /* TODO: Free type-bound procedure structs themselves; probably needs some sort of ref-counting mechanism. */ - + free (t->n.tb); free (t); } @@ -5052,7 +5052,7 @@ gfc_get_typebound_proc (gfc_typebound_proc *tb0) result = XCNEW (gfc_typebound_proc); if (tb0) -*result = *tb0; +memcpy (result, tb0, sizeof (gfc_typebound_proc));; result->error = 1; latest_undo_chgset->tbps.safe_push (result);
Re: *PING* [PATCH] PR fortran/99348, 102521 - ICEs when initializing DT parameter arrays from scalar
This one looks OK. Sorry I missed it earlier. Thanks again for the patch! Jerry On 10/9/21 12:27 PM, Harald Anlauf via Fortran wrote: *Ping* Am 03.10.21 um 21:20 schrieb Harald Anlauf via Fortran: Dear Fortranners, when initializing parameter arrays from scalars, we did handle only the case init->expr_type == EXPR_CONSTANT, which misses the case of derived types. As a consequence the constructor for the r.h.s. was not set up, which later led to different ICEs. To solve this I looked at gfc_simplify_spread. I was contemplating whether to also copy the logic to make this initialization dependent on -fmax-array-constructor. I chose not to, because there is no sensible and simple fallback available to handle that case while allowing the access to array elements. We could instead make that a warning. Comments / opinions? Regtested on x86_64-pc-linux-gnu. OK for mainline? As this is an ICE on valid, potentially useful code, I'd like to backport this to 11-branch. Thanks, Harald
Re: [PATCH] PR fortran/65454 - accept both old and new-style relational operators
On 10/8/21 2:33 PM, Harald Anlauf via Fortran wrote: Dear Fortranners, F2018:10.1.5.5.1(2) requires the same interpretation of old and new-style relational operators. We internally distinguish between old and new style, but try to map appropriately when used. This mapping was missing when reading a module via USE module, ONLY: OPERATOR(op) where op used a style different from the INTERFACE OPERATOR statement in the declaring module. The attached patch remedies this. Note: we do neither change the module format nor actually remap an operator. We simply improve the check whether the requested operator symbol exists in the old-style or new-style version. Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald Looks all good Harald, OK and thanks for the support! Jerry
Re: [PATCH] PR fortran/102458 - ICE tree check: expected array_type, have pointer_type in gfc_conv_array_initializer, at fortran/trans-array.c:6136
Harald, Looks good. OK and thanks for your time and efforts. Jerry On 9/23/21 12:47 PM, Harald Anlauf via Fortran wrote: Dear Fortranners, we missed certain intrinsics as being disallowed in constant expressions, which lead to an ICE when these intrinsics were used in a specification expression with an initializer. The intrinsics in question are listed in F2018:10.1.2. As discussed in the PR, Steve recommended to omit TRANSFER from that list, as it is special and might need separate treatment. I also could not come up with a case where TRANSFER should not have simplified to a constant and we would run into an issue. (We could leave that job to Gerhard... ;-). However, in testing I encountered a case involving TRANSFER that is not properly simplified, which seems orthogonal to the present case. I would like to handle this separately. This case is mentioned in the testcase, but commented out. Regtested on x86_64-pc-linux-gnu. OK for mainline? Thanks, Harald
Re: *Ping**2 [Patch] Fortran: Fix bind(C) character length checks
Good to go Tobias.
Jerry
On 7/14/21 5:50 AM, Burnus, Tobias wrote:
Ping**2
On Juli 8, 2021 I wrote:
*Ping*
I intent to incorporate Sandra's suggestions, except for the beginning of line
spacing - that's needed to avoid exceeding the 80 character line limit. I did
not include an updated patch as just pinging is easier on a mobile during
vacation :-)
Thanks,
Tobias
Loosemore, Sandra wrote:
On 7/1/21 11:08 AM, Tobias Burnus wrote:
Hi all,
this patch came up when discussing Sandra's TS29113 patch internally.
There is presumably also some overlap with José's patches.
This patch tries to rectify the BIND(C) CHARACTER handling on the
diagnostic side, only. That is: what to accept and what
to reject for which Fortran standard.
The rules are:
* [F2003-F2018] Interoperable is character(len=1)
→ F2018, 18.3.1 Interoperability of intrinsic types
(General, unchanged)
* Fortran 2008: In some cases, const-length chars are
permitted as well:
→ F2018, 18.3.4 Interoperability of scalar variables
→ F2018, 18.3.5 Interoperability of array variables
→ F2018, 18.3.6 Interoperability of procedures and procedure interfaces
[= F2008, 15.3.{4,5,6}
For global vars with bind(C), 18.3.4 + 18.3.5 applies directly (TODO:
Add support, not in this patch)
For passed-by ref dummy arguments, 18.3.4 + 18.3.5 are referenced in
- F2008: R1229 proc-language-binding-spec is language-binding-spec
C1255 (R1229)
- F2018, F2018, C1554
While it is not very clearly spelt out, I regard 'char parm[4]'
interoperable with 'character(len=4) :: a', 'character(len=2) :: b(2)'
and 'character(len=1) :: c(4)' for both global variables and for
dummy arguments.
* Fortran 2018/TS29113: Uses additionally CFI array descriptor
- allocatable, pointer: must be len=:
- nonallocatable/nonpointer: len=* → implies array descriptor also
for assumed-size/explicit-size/scalar arguments.
- All which all passed by an array descriptor already without further
restrictions: assumed-shape, assumed-rank, i.e. len= seems
to be also fine
→ 18.3.6 under item (5) bullet point 2 and 3 plus (6).
I hope I got the conditions right. I also fixed an issue with
character(len=5) :: str – the code in trans-expr.c did crash for
scalars (decl.c did not check any constraints for arrays).
I believe the condition is wrong and for len= no descriptor
is used.
Any comments, remarks?
I gave this patch a try on my TS 29113 last night. Changing the error
messages kind of screwed up my list of FAILs, but I did see that it also
caught some invalid character arguments in
interoperability/typecodes-scalar.f90 and
interoperability/typecodes-scalar-ext.f90 (which are already broken by 2
other major gfortran bugs I still need to file PRs for). :-S
I haven't tried to review the patch WRT correctness with the
requirements of the standard yet, but I have a few nits about error
messages
+ /* F2018, 18.3.6 (6). */
+ if (!sym->ts.deferred)
+ {
+ gfc_error ("Allocatable and pointer character dummy "
+ "argument %qs at %L must have deferred length "
+ "as procedure %qs is BIND(C)", sym->name,
+ &sym->declared_at, sym->ns->proc_name->name);
+ retval = false;
+ }
This is the error the two aforementioned test cases started giving, but
message is confusing and doesn't read well (it was a pointer dummy, not
"allocatable and pointer"). Maybe just s/and/or/, or customize the
message depending on which one it is?
+ gfc_error ("Character dummy argument %qs at %L must be "
+ "of constant length or assumed length, "
+ "unless it has assumed-shape or assumed-rank, "
+ "as procedure %qs has the BIND(C) attribute",
+ sym->name, &sym->declared_at,
+ sym->ns->proc_name->name);
I don't think either "assumed-shape" or "assumed-rank" should be
hyphenated in this context unless that exact hyphenation is a term of
art in the Fortran standard or other technical documentation. In normal
English, adjective phrases are usually only hyphenated when they appear
immediately before the noun they modify; "assumed-shape array", but "an
array with assumed shape".
+ else if (!gfc_notify_std (GFC_STD_F2018,
+ "Character dummy argument %qs at %L"
+ " with nonconstant length as "
+ "procedure %qs is BIND(C)",
+ sym->name, &sym->declared_at,
+ sym->ns->proc_name->name))
+ retval = false;
+ }
Elsewhere the convention seems to be to format strings split across
mu
Re: [patch, fortran] Fix PR 100227, write with implied DO loop
Looks OK Thomas, Good for backport as well. Regards, Jerry On 7/4/21 9:09 AM, Thomas Koenig via Fortran wrote: Hello world, after a bit of an absence, I am now back, at least for some regression fixing (and for reviewing patches, if that is called for). So, here's a regression fix to start with. OK for trunk and affected branches (down to 9)? Best regards Thomas Do not replace variable op variable in I/O implied DO loop replacement. This PR came about because index expressions of the form k+k in implied DO loops in I/O statements were considered for replacement by array slices. Fixed by only doing the transformation if the expression is of the type expr OP contastant. gcc/fortran/ChangeLog: PR fortran/100227 * frontend-passes.c (traverse_io_block): Adjust test for when a variable is eligible for the transformation to array slice. gcc/testsuite/ChangeLog: PR fortran/100227 * gfortran.dg/implied_do_io_7.f90: New test.
Re: [Ping^2, Patch, Fortran] PR98301 Re: RANDOM_INIT() and coarray Fortran
yes, please commit On 5/21/21 8:08 AM, Steve Kargl via Fortran wrote: On Fri, May 21, 2021 at 10:09:02AM +0200, Andre Vehreschild wrote: Ping, ping! Please find attached a rebased version of the patch for the RANDOM_INIT issue with coarray Fortran. Nothing changed to the previous version, just rebased to current master. Regtested fine on x86_64-linux/f33. Ok for trunk? I think you've down your due diligence with 2 pings. I would commit.
