[Bug fortran/117473] Issue with OpenMP workshare and -fsanitize=thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117473 anlauf at gcc dot gnu.org changed: What|Removed |Added Attachment #59547|0 |1 is obsolete|| Attachment #59548|0 |1 is obsolete|| --- Comment #2 from anlauf at gcc dot gnu.org --- Created attachment 59556 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59556&action=edit Ensure schedule(static), sharing of work arrays
[Bug fortran/117473] Issue with OpenMP workshare and -fsanitize=thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117473 --- Comment #1 from anlauf at gcc dot gnu.org --- Created attachment 59548 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59548&action=edit Fix missing initialization outside of the parallel region
[Bug fortran/117473] New: Issue with OpenMP workshare and -fsanitize=thread
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117473 Bug ID: 117473 Summary: Issue with OpenMP workshare and -fsanitize=thread Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: anlauf at gcc dot gnu.org Target Milestone: --- Created attachment 59547 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59547&action=edit Reproducer This may be a dup of pr66553 or not, but I am reporting this anyway. The attached code runs fine when compiled with gfc-15 -fopenmp -O2 -g gfc-omp-workshare.f90 -fsanitize=thread when executing with OMP_NUM_THREADS=1: Max.threads: 1 -0.165948499762316132.8431552110569240E-002 However, with more threads I get a sanitizer warning: OMP_NUM_THREADS=2 ./a.out Max.threads: 2 == WARNING: ThreadSanitizer: data race (pid=6436) Read of size 8 at 0x72cc00044610 by main thread (mutexes: write M0): #0 test /home/anlauf/gcc-bugs/gfc-omp-workshare.f90:19 (a.out+0x4040b1) #1 main /home/anlauf/gcc-bugs/gfc-omp-workshare.f90:2 (a.out+0x402d95) Previous write of size 8 at 0x72cc00044610 by thread T1: #0 spline_init_vec.0._omp_fn.0 /home/anlauf/gcc-bugs/gfc-omp-workshare.f90:45 (a.out+0x40381a) #1 gomp_thread_start ../../../gcc-trunk/libgomp/team.c:129 (libgomp.so.1+0x22c97) Location is heap block of size 101400 at 0x72cc00038000 allocated by main thread: #0 malloc ../../../../gcc-trunk/libsanitizer/tsan/tsan_interceptors_posix.cpp:665 (libtsan.so.2+0x56917) #1 test /home/anlauf/gcc-bugs/gfc-omp-workshare.f90:9 (a.out+0x403a3a) #2 main /home/anlauf/gcc-bugs/gfc-omp-workshare.f90:2 (a.out+0x402d95) Mutex M0 (0x725803e0) created at: #0 pthread_mutex_lock ../../../../gcc-trunk/libsanitizer/tsan/tsan_interceptors_posix.cpp:1341 (libtsan.so.2+0x5af6e) #1 __gthread_mutex_lock ../libgcc/gthr-default.h:795 (a.out+0x40c72b) #2 insert_unit ../../../gcc-trunk/libgfortran/io/unit.c:250 (a.out+0x40c72b) Thread T1 (tid=6438, running) created by main thread at: #0 pthread_create ../../../../gcc-trunk/libsanitizer/tsan/tsan_interceptors_posix.cpp:1022 (libtsan.so.2+0x5c0f5) #1 gomp_team_start ../../../gcc-trunk/libgomp/team.c:859 (libgomp.so.1+0x2329f) #2 main /home/anlauf/gcc-bugs/gfc-omp-workshare.f90:2 (a.out+0x402d95) SUMMARY: ThreadSanitizer: data race /home/anlauf/gcc-bugs/gfc-omp-workshare.f90:19 in test == -0.165948499762316132.8431552110569240E-002 So is this a bug in the program source code, or a false positive in the thread sanitizer?
[Bug fortran/115700] [12/13 regression] Bogus warning for associate with assumed-length character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115700 --- Comment #14 from anlauf at gcc dot gnu.org --- (In reply to GCC Commits from comment #13) > The master branch has been updated by Paul Thomas : > > https://gcc.gnu.org/g:7f93910a8b5d606ad742a3594750f0c2b20d8bda > > commit r15-4835-g7f93910a8b5d606ad742a3594750f0c2b20d8bda > Author: Paul Thomas > Date: Fri Nov 1 07:45:00 2024 + > > Fortran: Fix problems with substring selectors in ASSOCIATE [PR115700] > > 2024-11-01 Paul Thomas > > gcc/fortran > PR fortran/115700 > * resolve.cc (resolve_assoc_var): Extract a substring reference > with missing as well as non-constant start or end. > > gcc/testsuite/ > PR fortran/115700 > * gfortran.dg/associate_69.f90: Activate commented out tests. > * gfortran.dg/associate_70.f90: Test correct functioning of > references in associate_69.f90 tests. Paul, the addition to testcase gfortran.dg/associate_69.f90 fails on 32-bit targets (or using -m32), which can be seen by comparing the dumps: for -m32 the final "stop 6" gets optimized away already at -Og, but not at -m64. So the pattern needs to be reconsidered. Can you have a look?
[Bug fortran/117381] -fmax-identifier-length= is completely ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117381 --- Comment #11 from anlauf at gcc dot gnu.org --- (In reply to kargls from comment #10) > (In reply to anlauf from comment #9) > > (In reply to kargls from comment #8) > > > One could set GFC_MAX_SYMBOL_LEN to a value larger than 63, but what > > > value makes sense? (Note it will be less than 1, which is the > > > longest statement length allowed under the standard) > > > > You sure? > > > > F2023: 6.3.2.1 ... A line shall contain at most ten thousand characters. > > > > But can't you break a line like in: > > > > a& > > &b& > > &c = 1 > > > > ? > > Ugh, indeed, you are correct! I forgot that one could split > a token across a line. The question still remains. What > value does one use; especially given the 145 static buffers? I am not sure. We could use 255 as a hard limit, and emit a warning for any -std=fxyz option when the respective limit is exceeded, at least for -pedantic.
[Bug fortran/117381] -fmax-identifier-length= is completely ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117381 --- Comment #9 from anlauf at gcc dot gnu.org --- (In reply to kargls from comment #8) > One could set GFC_MAX_SYMBOL_LEN to a value larger than 63, but what > value makes sense? (Note it will be less than 1, which is the > longest statement length allowed under the standard) You sure? F2023: 6.3.2.1 ... A line shall contain at most ten thousand characters. But can't you break a line like in: a& &b& &c = 1 ? So do we want a limit close to 6.3.2.6 ... A statement shall not have more than one million characters. ?
[Bug fortran/112459] gfortran -w option causes derived-type finalization at creation time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112459 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #6 from anlauf at gcc dot gnu.org --- (In reply to Jürgen Reuter from comment #5) > so this is "just" the backport to older versions missing? Yes. The fix backports cleanly here. @Paul: push, set target milestone, and close?
[Bug fortran/117381] -fmax-identifier-length= is completely ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117381
--- Comment #5 from anlauf at gcc dot gnu.org ---
While Nvidia and flang seem to allow the sample code, even the latest
Intel ifx 2025.0 rejects it:
pr117381.f90(5): error #6439: This symbol has too many characters.
[VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ACCELERAT]
integer ::
VK_STRUCTURE_TYPE_PHYSICAL_DEVICE_ACCELERATION_STRUCTURE_PROPERTIES_KHR = 1
-^
compilation aborted for pr117381.f90 (code 1)
With the following patch we could adjust the documentation:
diff --git a/gcc/fortran/invoke.texi b/gcc/fortran/invoke.texi
index ff4040732d8..b25976c7026 100644
--- a/gcc/fortran/invoke.texi
+++ b/gcc/fortran/invoke.texi
@@ -407,8 +407,9 @@ lines in the source file. The default value is 132.
@opindex fmax-identifier-length=@var{n}
@item -fmax-identifier-length=@var{n}
-Specify the maximum allowed identifier length. Typical values are
-31 (Fortran 95) and 63 (Fortran 2003 and later).
+Specify the maximum allowed identifier length. Standard values are
+31 (Fortran 95) and 63 (Fortran 2003 and later). Values larger than
+63 are not supported.
@opindex fimplicit-none
@item -fimplicit-none
[Bug fortran/117347] Associate with derived type array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117347 --- Comment #2 from anlauf at gcc dot gnu.org --- Slightly reduced testcase: program pr117347_red implicit none type :: point real :: x = 42. end type point type(point) :: mypoint real:: pi(1) associate (points => mypoint ) ! accepted pi(:) = points% x end associate associate (points => (mypoint)) ! accepted pi(:) = points% x end associate associate (points => [mypoint]) ! REJECTED pi(:) = points% x end associate print *, pi end program
[Bug fortran/117347] Associate with derived type array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117347 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Last reconfirmed||2024-10-29 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed.
[Bug fortran/117303] Link-time optimization optimizes away subroutine referred to via C_FUNLOC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117303 --- Comment #2 from anlauf at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #1) > I suspect this might be a front end bug. The decls for the two functions > should be the same but I think they are different and that is causing the > issue. Can you give some hint where to look for? And what is relevant? (Note that I have zero experience with lto). In trans-decl.cc::build_function_decl we have: 2507 /* Initialize DECL_EXTERNAL and TREE_PUBLIC before calling decl_attributes; 2508 TREE_PUBLIC specifies whether a function is globally addressable (i.e. 2509 the opposite of declaring a function as static in C). */ 2510 DECL_EXTERNAL (fndecl) = 0; ... 2518 if (!current_function_decl 2519 && !sym->attr.entry_master && !sym->attr.is_main_program 2520 && (sym->attr.access != ACCESS_PRIVATE || sym->binding_label 2521 || sym->attr.public_used)) 2522TREE_PUBLIC (fndecl) = 1; For procedures with C binding (here:S1): (gdb) p sym->binding_label $43 = 0x7682b130 "s1" so we declare it globally addressable. What else do we need?
[Bug fortran/108434] [12/13/14/15 Regression] ICE in class_allocatable, at fortran/expr.cc:5000
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108434
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Assignee|anlauf at gcc dot gnu.org |unassigned at gcc dot
gnu.org
Status|ASSIGNED|NEW
--- Comment #11 from anlauf at gcc dot gnu.org ---
(In reply to Paul Thomas from comment #10)
> Created attachment 59454 [details]
> Potential fix for comment 1
Hi Paul,
this is an interesting attempt! It fixes the testcases here, but ICEs when
adding the following obvious declaration
> program p
>type c
> integer :: i
>end type
>type t
> class(c), allocatable :: a(2)
>end type
>type s
> class(d), allocatable :: a(2)
>end type
type u
type(e), allocatable :: b(2)
end type
>class(t), pointer :: y1
>class(t), allocatable :: x1
>class(s), pointer :: y2
>class(s), allocatable :: x2
> end
> I am not sure that the chunk in resolve.cc is needed any more but it doesn't
> do any harm!
I also do not see that it is needed nor doing any harm, but why don't you
protect the line before the for loop?
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 565d4aa5fe9..0db6f0b2f1e 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -14599,7 +14599,7 @@ gfc_resolve_finalizers (gfc_symbol* derived, bool
*finalizable)
/* Ensure that derived-type components have a their finalizers resolved. */
bool has_final = derived->f2k_derived && derived->f2k_derived->finalizers;
- for (c = derived->components; c; c = c->next)
+ for (c = derived ? derived->components : NULL; c; c = c->next)
if (c->ts.type == BT_DERIVED
&& !c->attr.pointer && !c->attr.proc_pointer && !c->attr.allocatable)
{
If we were to get here with derived == NULL, one could use:
bool has_final = (derived
&& derived->f2k_derived
&& derived->f2k_derived->finalizers);
just to be consistent.
I am unassigning for now to pass this PR to you! :-)
(BTW: running f951 under valgrind shows many invalid reads for my extension
of your testcase above.)
[Bug fortran/117264] Segfault when using assignment for allocatable class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117264 anlauf at gcc dot gnu.org changed: What|Removed |Added Known to fail||13.3.0 --- Comment #9 from anlauf at gcc dot gnu.org --- After some search, I found a gfortran 13.3.0 (openSUSE 15.5, r13-8781), that fails also for program p type,abstract::t end type t type,extends(t)::tt end type tt class(t),allocatable::o o=f() contains function f() result(r) ! works class(t), allocatable :: r r=tt() end end the same as for the example in comment#0. Note that it works with 12.3.0 and 12.4.1, 13.3.1 (at r13-9145), 14.2.1 (at r14-10831), and 15-trunk. It looks like a temporary regression. Can you update your compiler installation?
[Bug fortran/117258] tree check fail in gfc_trans_structure_assign, at fortran/trans-expr.cc:9691
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117258 --- Comment #3 from anlauf at gcc dot gnu.org --- (In reply to David Binderman from comment #2) > I had a quick look: > > BUILD $ find elk* -name libxcifc.f90 -print > elk-9.2.12/src.orig/libxcifc.f90 > elk-9.2.12/src/libxcifc.f90 > BUILD $ find elk-9.2.12 -name xc_f03_lib_m.mod -print > BUILD $ > > So where should this file be ? I am not a FORTRAN programmer. There should be another file that contains that module with header: module xc_f03_lib_m ... end module Without having a testcase that resolves all module references it is impossible to see what is going on.
[Bug fortran/117264] Segfault when using assignment for allocatable class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117264 --- Comment #5 from anlauf at gcc dot gnu.org --- (In reply to Vladimir Terzi from comment #4) > (In reply to kargls from comment #3) > > Works for me with 13.2.0, 14.2.0, and top of tree on x86_64-*-freebsd. > > > > You can also do the allocation explicitly instead of allocation > > on assignment. > > > > function f() > > class(t), allocatable :: f > > allocate(tt :: f) > > end > > That's strange... For some reason, the behavior is different on Rocky Linux > 8.7 (same architecture: x86_64). > > Yes, I'm using the explicit allocation in my code with `source` (and a > constructor with arguments). Please show the exact failing code.
[Bug fortran/117258] tree check fail in gfc_trans_structure_assign, at fortran/trans-expr.cc:9691
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117258 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2024-10-22 Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING --- Comment #1 from anlauf at gcc dot gnu.org --- The testcase is incomplete / not self-contained: libxcifc.f90:8:5: 8 | use xc_f03_lib_m | 1 Fatal Error: Cannot open module file 'xc_f03_lib_m.mod' for reading at (1): No such file or directory
[Bug fortran/117264] Segfault when using assignment for allocatable class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117264 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Priority|P3 |P4 Ever confirmed|0 |1 Last reconfirmed||2024-10-22 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed up to current trunk. As a workaround, you may try the result clause on function f, e.g.: function f() result(r) class(t), allocatable :: r r=tt() end
[Bug fortran/104827] [12/13/14/15 Regression] ICE in gfc_conv_array_constructor_expr, at fortran/trans-expr.cc:8329 since r12-4409-g724ee5a0093da443
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104827
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |WAITING
Keywords||ice-on-invalid-code
--- Comment #6 from anlauf at gcc dot gnu.org ---
(In reply to kargls from comment #5)
> This appears to be fixed in that the ICE no longer occurs.
Intel also rejects both variants as invalid code:
% ifx pr104827-z1.f90 -fopenmp
pr104827-z1.f90(2): error #5082: Syntax error, found IDENTIFIER 'F' when
expecting one of: VENDOR EXTENSION REQUIRES
!$omp declare variant(a) match(implementation={f([1])})
--^
pr104827-z1.f90(2): error #9091: An OpenMP* trait-property-name must be an
identifier or a string-literal.
!$omp declare variant(a) match(implementation={f([1])})
-^
pr104827-z1.f90(2): error #8952: The name is not found or is inaccessible.
[A]
!$omp declare variant(a) match(implementation={f([1])})
-^
compilation aborted for pr104827-z1.f90 (code 1)
%ifx pr104827-z2.f90 -fopenmp
pr104827-z2.f90(2): error #5082: Syntax error, found IDENTIFIER 'F' when
expecting one of: VENDOR EXTENSION REQUIRES
!$omp declare variant(a) match(implementation={f(1)})
--^
pr104827-z2.f90(2): error #9091: An OpenMP* trait-property-name must be an
identifier or a string-literal. [1]
!$omp declare variant(a) match(implementation={f(1)})
^
pr104827-z2.f90(2): error #8952: The name is not found or is inaccessible.
[A]
!$omp declare variant(a) match(implementation={f(1)})
-^
compilation aborted for pr104827-z2.f90 (code 1)
Adding ice-on-invalid to keywords.
Likely fixed during 15-development.
[Bug fortran/117188] ICE when OUT variable dimension is defined by a IN variable member
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117188 anlauf at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-10-17 Status|UNCONFIRMED |WAITING --- Comment #2 from anlauf at gcc dot gnu.org --- No ICE here with all tested versions >= 7.5.0. (Example 2 does crash ifx, however.) The code is invalid as explained by Steve. Compiling with -g -fsanitize=undefined,address, I get: pr117188-z1.f90:13:23: runtime error: member access within null pointer of type 'struct base_type'
[Bug fortran/117136] ice for gfortran.dg/typebound_operator_11.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117136 --- Comment #1 from anlauf at gcc dot gnu.org --- Running f951 under valgrind I see: ==5119== Conditional jump or move depends on uninitialised value(s) ==5119==at 0xAF2DFC: gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*, gfc_expr*, vec*) (trans-expr.cc:8256) ==5119==by 0xAF7DDD: gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*, gfc_expr*, vec*) (trans-expr.cc:6831) ==5119==by 0xB51AE2: gfc_trans_call(gfc_code*, bool, tree_node*, tree_node*, bool) (trans-stmt.cc:425) ==5119==by 0xAB0F13: trans_code(gfc_code*, tree_node*) (trans.cc:2434) ==5119==by 0xAE8214: gfc_generate_function_code(gfc_namespace*) (trans-decl.cc:7958) ==5119==by 0xAB64C1: gfc_generate_module_code(gfc_namespace*) (trans.cc:2780) ==5119==by 0xA56F8A: translate_all_program_units(gfc_namespace*) (parse.cc:7159) ==5119==by 0xA57989: gfc_parse_file() (parse.cc:7489) ==5119==by 0xAADBEF: gfc_be_parse_file() (f95-lang.cc:241) ==5119==by 0x111DB4D: compile_file() (toplev.cc:451) ==5119==by 0x99CEDE: do_compile (toplev.cc:2209) ==5119==by 0x99CEDE: toplev::main(int, char**) (toplev.cc:2369) ==5119==by 0x99E89A: main (main.cc:39) The offending line is traced back to r15-4298-g3269a722b7a036 by Tobias. Can you try the following patch? diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc index b9f585d0d2f..2f6d3b06889 100644 --- a/gcc/fortran/trans-expr.cc +++ b/gcc/fortran/trans-expr.cc @@ -6378,7 +6381,7 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym, gfc_actual_arglist *arg; int has_alternate_specifier = 0; bool need_interface_mapping; - bool is_builtin; + bool is_builtin = false; bool callee_alloc; bool ulim_copy; gfc_typespec ts;
[Bug fortran/117077] ICE due to allocatable component in hidden type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117077 anlauf at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-10-11 Status|UNCONFIRMED |NEW Keywords||ice-on-valid-code Priority|P3 |P4 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. Moving the declaration of type foo_type from the function to the module prevents the ICE, even if it is declared private. Otherwise we miss the result type information of function foo in the generated .mod file.
[Bug fortran/116875] Internal compiler error: in make_decl_rtl, at varasm.cc:1443
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116875 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #3 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #2) > I think I've seen at least one other PR with the same pattern. The following PRs may have a different traceback, but might suffer from the same or related problem with missings/losts decls within a block..end block: pr92975 - ICE in convert_nonlocal_reference_op pr105582 - ICE on procedure pointer assignment inside block pr107075 - ICE in get, at cgraph.h
[Bug libfortran/116886] maxval/minval should not return empty result for empty array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116886 --- Comment #4 from anlauf at gcc dot gnu.org --- (In reply to Thomas Koenig from comment #2) > The behavior for simplification is correct, as far as I understand: > > $ cat mv2.f90 > program memain > integer, dimension(0,0), parameter :: empty = reshape([(0,i=1,0)],[0,0]) > print *,maxval(empty) > print *,minval(empty) > end program memain > $ gfortran mv2.f90 && ./a.out > -2147483648 > 2147483647 I guess you meant to add dim=1 as in: program memain integer, dimension(0,0), parameter :: empty = reshape([(0,i=1,0)],[0,0]) print *,maxval(empty,dim=1) print *,minval(empty,dim=1) end program memain This prints 2 empty lines (as expected).
[Bug fortran/116875] Internal compiler error: in make_decl_rtl, at varasm.cc:1443
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116875 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2024-09-28 Status|UNCONFIRMED |NEW Known to fail||15.0, 7.5.0 Ever confirmed|0 |1 --- Comment #2 from anlauf at gcc dot gnu.org --- Confirmed. It is an old bug that affects all gfortran versions since at least gcc-7. The issue is triggered by the BLOCK construct. The dump-tree suggests that a decl for S1_POINTER is lost or not generated. I think I've seen at least one other PR with the same pattern.
[Bug fortran/116858] gfortran.dg/initialization_25.f90 test failure (exposed by r15-3890-g34bf6aa41ba539)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116858 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #5 from anlauf at gcc dot gnu.org --- I am seeing the following on x86_64-pc-linux-gnu: Running /work/gnu/git/gcc-trunk/gcc/testsuite/gfortran.dg/dg.exp ... FAIL: gfortran.dg/initialization_25.f90 -O xfail *-*-* (test for errors, line 11) Also seen on gcc-testresults... Can you please check again?
[Bug testsuite/116701] [15 Regression] gfortran.dg/write_check3.f90 suddenly fails for non-fd_truncate targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116701 --- Comment #3 from anlauf at gcc dot gnu.org --- I meant: diff --git a/gcc/testsuite/gfortran.dg/unsigned_22.f90 b/gcc/testsuite/gfortran.dg/unsigned_22.f90 index bc2f810238d..17ebb973cf1 100644 --- a/gcc/testsuite/gfortran.dg/unsigned_22.f90 +++ b/gcc/testsuite/gfortran.dg/unsigned_22.f90 @@ -22,4 +22,5 @@ program memain read (10,*,iostat=iostat,iomsg=iomsg) u if (iostat == 0) error stop 7 if (iomsg /= "Unsigned integer overflow while reading item 1 of list input") error stop 8 + close(10, status="delete") end program memain
[Bug testsuite/116701] [15 Regression] gfortran.dg/write_check3.f90 suddenly fails for non-fd_truncate targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116701 --- Comment #2 from anlauf at gcc dot gnu.org --- (In reply to Hans-Peter Nilsson from comment #1) > The cause is that the unsigned_22 test (added in the named commit) leaves an > output file "fort.10", which is picked up by write_check3 which then calls > libgfortran raw_truncate. I guess the gfortran "unit-machinery" wants to > clear that file if it exists. > > Some option is needed to make the "fort.10" file name unique or something to > that effect in a way that it isn't picked up by write_check3. A dg- cleanup > function might do, perhaps one exists? A "git grep -w fort" in > testsuite/lib catches nothing though. Well observed. Can you test if adding a line close(10, status="delete") before the end program memain fixes the issue? If so, such a fix is pre-approved; you can also ask Thomas.
[Bug fortran/116679] Memory leak when creating derived type instance with allocatable component within array expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116679 anlauf at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-09-20 Status|UNCONFIRMED |NEW --- Comment #2 from anlauf at gcc dot gnu.org --- Confirmed. The testcase in comment#1 needs fixing (remove 'use bugdemo'). The memleak there depends on array being a pointer. Changing it to allocatable seems to plug the leak here. Note that replacing in the block items = [wrapper(1)] by items(1)% val = 1 also does not leak.
[Bug fortran/100273] [12/13/14 Regression] ICE in gfc_create_module_variable, at fortran/trans-decl.c:5352
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100273 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #16 from anlauf at gcc dot gnu.org --- Fixed on all open branches. Closing. Thanks for the report!
[Bug fortran/100273] [12/13/14 Regression] ICE in gfc_create_module_variable, at fortran/trans-decl.c:5352
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100273 anlauf at gcc dot gnu.org changed: What|Removed |Added Summary|[12/13/14/15 Regression]|[12/13/14 Regression] ICE |ICE in |in |gfc_create_module_variable, |gfc_create_module_variable, |at |at |fortran/trans-decl.c:5352 |fortran/trans-decl.c:5352 --- Comment #12 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-15.
[Bug fortran/100273] [12/13/14/15 Regression] ICE in gfc_create_module_variable, at fortran/trans-decl.c:5352
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100273 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #10 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2024-September/060949.html
[Bug fortran/100273] [12/13/14/15 Regression] ICE in gfc_create_module_variable, at fortran/trans-decl.c:5352
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100273 --- Comment #9 from anlauf at gcc dot gnu.org --- Patch that fixes the ICE: diff --git a/gcc/fortran/trans-decl.cc b/gcc/fortran/trans-decl.cc index 6692ac7ef4c..ee41d66e6d2 100644 --- a/gcc/fortran/trans-decl.cc +++ b/gcc/fortran/trans-decl.cc @@ -5540,7 +5540,8 @@ gfc_create_module_variable (gfc_symbol * sym) /* Create the variable. */ pushdecl (decl); gcc_assert (sym->ns->proc_name->attr.flavor == FL_MODULE - || (sym->ns->parent->proc_name->attr.flavor == FL_MODULE + || ((sym->ns->parent->proc_name->attr.flavor == FL_MODULE + || sym->ns->parent->proc_name->attr.flavor == FL_PROCEDURE) && sym->fn_result_spec)); DECL_CONTEXT (decl) = sym->ns->proc_name->backend_decl; rest_of_decl_compilation (decl, 1, 0);
[Bug fortran/98454] Apparent wrong initialization in function result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98454 anlauf at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |15.0 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-15.
[Bug fortran/116530] [14/15 Regression] ICE with member of namelist renamed by use module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116530 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #12 from anlauf at gcc dot gnu.org --- Backported to 14-branch. Closing. Thanks for the report!
[Bug fortran/98454] Apparent wrong initialization in function result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98454 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #13 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2024-August/060931.html
[Bug fortran/116530] [14/15 Regression] ICE with member of namelist renamed by use module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116530 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #10 from anlauf at gcc dot gnu.org --- Fixed on mainline so far.
[Bug fortran/116530] [14/15 Regression] ICE with member of namelist renamed by use module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116530 --- Comment #8 from anlauf at gcc dot gnu.org --- (In reply to kargls from comment #6) > (In reply to anlauf from comment #3) > > Tentative obvious fix for NULL pointer dereference: > > > > diff --git a/gcc/fortran/trans-io.cc b/gcc/fortran/trans-io.cc > > index 7ab82fa2f5b..de38f4a808f 100644 > > --- a/gcc/fortran/trans-io.cc > > +++ b/gcc/fortran/trans-io.cc > > @@ -1692,7 +1692,8 @@ transfer_namelist_element (stmtblock_t * block, const > > char * var_name, > >gcc_assert (sym || c); > > > >/* Build the namelist object name. */ > > - if (sym && !sym->attr.use_only && sym->attr.use_rename) > > + if (sym && !sym->attr.use_only && sym->attr.use_rename > > + && sym->ns->use_stmts->rename) > > string = gfc_build_cstring_const > > (sym->ns->use_stmts->rename->local_name); > >else > > string = gfc_build_cstring_const (var_name); > > Patch looks good. If it passes regression testing, you can commit it you > want. Yes, it passed. I was just packaging it for submission, but given your OK I will push to master and inform the list.
[Bug fortran/116530] [14/15 Regression] ICE with member of namelist renamed by use module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116530 --- Comment #7 from anlauf at gcc dot gnu.org --- (In reply to kargls from comment #5) > (In reply to anlauf from comment #4) > > (In reply to kargls from comment #1) > > > (In reply to philippe.wautelet from comment #0) > > > > > > > > > > > I'm not sure it is conforming to the Fortran standard but it shouldn't > > > > trigger an ICE. > > > > > > > > > > I agree with you about the ICE should not happen. Staring at F2023, > > > I find the following constraint. > > > > > > C8107 (R871) The namelist-group-name shall not be a name accessed by use > > > association. > > > > > > If I understand it, your code is nonstandard. But, I don't use namelist, > > > so > > > will need to read through the Fortran standard a bit more. > > > > This constraint applies to the namelist statement and does not apply to the > > issue here. > > Yeah, I needed to review more the Fortran, and you beat me > to working out a patch. The '(R871)' above restricts the > constraint to namelist statement. However, this did lead to > > module mod_nml1 >implicit none >logical :: ldiag >namelist /nam_nml1/ldiag > end module mod_nml1 > > program ice_nml >use mod_nml1 >implicit none >integer :: ilu, j >namelist /nam_nml1/j !<-- Does this violates C8107? Yes, that is illegal and rejected by Intel and NAG, e.g.: NAG Fortran Compiler Release 7.2(Shin-Urayasu) Build 7200 Error: iii.f90, line 11: Redeclaration of symbol NAM_NML1 from USEd module MOD_NML1 detected at /@NAM_NML1 Warning: iii.f90, line 15: Unused local variable ILU [NAG Fortran Compiler pass 1 error termination, 1 error, 1 warning] I think we should track that constraint violation separately (no regression) from the present PR (regression). >ldiag = .false. >j = 42 >write(*,nml=nam_nml1) > end program ice_nml > > % gfcx -o z a.f90 && ./z > &NAM_NML1 > LDIAG=F, > J=42 , > /
[Bug fortran/116530] [14/15 Regression] ICE with member of namelist renamed by use module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116530 --- Comment #4 from anlauf at gcc dot gnu.org --- (In reply to kargls from comment #1) > (In reply to philippe.wautelet from comment #0) > > > > > I'm not sure it is conforming to the Fortran standard but it shouldn't > > trigger an ICE. > > > > I agree with you about the ICE should not happen. Staring at F2023, > I find the following constraint. > > C8107 (R871) The namelist-group-name shall not be a name accessed by use > association. > > If I understand it, your code is nonstandard. But, I don't use namelist, so > will need to read through the Fortran standard a bit more. This constraint applies to the namelist statement and does not apply to the issue here.
[Bug fortran/116530] [14/15 Regression] ICE with member of namelist renamed by use module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116530 --- Comment #3 from anlauf at gcc dot gnu.org --- Tentative obvious fix for NULL pointer dereference: diff --git a/gcc/fortran/trans-io.cc b/gcc/fortran/trans-io.cc index 7ab82fa2f5b..de38f4a808f 100644 --- a/gcc/fortran/trans-io.cc +++ b/gcc/fortran/trans-io.cc @@ -1692,7 +1692,8 @@ transfer_namelist_element (stmtblock_t * block, const char * var_name, gcc_assert (sym || c); /* Build the namelist object name. */ - if (sym && !sym->attr.use_only && sym->attr.use_rename) + if (sym && !sym->attr.use_only && sym->attr.use_rename + && sym->ns->use_stmts->rename) string = gfc_build_cstring_const (sym->ns->use_stmts->rename->local_name); else string = gfc_build_cstring_const (var_name);
[Bug fortran/116530] [14/15 Regression] ICE with member of namelist renamed by use module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116530 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Summary|ICE with member of namelist |[14/15 Regression] ICE with |renamed by use module |member of namelist renamed ||by use module Ever confirmed|0 |1 CC||anlauf at gcc dot gnu.org Status|UNCONFIRMED |NEW Priority|P3 |P4 Known to work||13.3.0 Target Milestone|--- |14.3 Known to fail||14.1.0, 14.2.0, 15.0 Last reconfirmed||2024-08-29 --- Comment #2 from anlauf at gcc dot gnu.org --- Reduced testcase: module mod_nml1 logical :: ldiag namelist /nam_nml1/ldiag end module mod_nml1 module mod_interm use mod_nml1 end module mod_interm program ice_nml ! Interchanging the following two lines fixes the ICE: use mod_nml1, ldiag_nml1 => ldiag use mod_interm integer :: ilu read(unit=ilu,nml=nam_nml1) end program ice_nml Works with Intel, NAG, Nvidia, flang. As written above, interchanging the use statements fixes the ICE.
[Bug fortran/98454] Apparent wrong initialization in function result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98454 --- Comment #12 from anlauf at gcc dot gnu.org --- Created attachment 59021 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59021&action=edit Patch Revisiting this one, I arrived at the attached patch. This seems to fix the present issues and regtests fine, needing only minor adjustments to: gfortran.dg/alloc_comp_class_4.f03 (need to remove a bogus warning) gfortran.dg/pdt_26.f03 (adjust the count of __builtin_malloc)
[Bug fortran/113412] ATAN(Y,X) does not check arguments and generates wrong error message.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113412
--- Comment #12 from anlauf at gcc dot gnu.org ---
(In reply to kargls from comment #11)
I tried a simpler variation of your patch that aims at a more coherent
error message:
diff --git a/gcc/fortran/intrinsic.cc b/gcc/fortran/intrinsic.cc
index f7cbb4bb5e2..28b27874298 100644
--- a/gcc/fortran/intrinsic.cc
+++ b/gcc/fortran/intrinsic.cc
@@ -4377,10 +4377,22 @@ sort_actual (const char *name, gfc_actual_arglist **ap,
if (a == NULL)
goto do_sort;
+ /* The generic interface of the following intrinsics was extended in F2008.
+ A specific interface may not be available at a selected standard. */
+ if ((gfc_option.allow_std & GFC_STD_F2008) != 0
+ && (strcmp (name, "atan") == 0
+ || strcmp (name, "atand") == 0))
+goto no_specific;
+
whoops:
gfc_error ("Too many arguments in call to %qs at %L", name, where);
return false;
+no_specific:
+ gfc_error ("Generic function %qs at %L is not consistent with a "
+"specific intrinsic interface", name, where);
+ return false;
+
keywords:
/* Associate the remaining actual arguments, all of which have
to be keyword arguments. */
With this you get the message:
Error: Generic function 'atan' at (1) is not consistent with a specific
intrinsic interface
whether atan is explicitly declared as intrinsic or not.
> Now, to real cause so head scratching. keywords are not honored!
>
> subroutine s3
> real :: r = 1.
> print *, atan (y=-1.d0,x=r) ! Should give error similar to s1 case
> end
>
> % gfcx -c a.f90
> a.f90:3:10:
>
> 3 | print *, atan (y=-1.d0,x=r) ! Should give error similar to
> s1 case
> | 1
> Error: Cannot find keyword named ‘y’ in call to ‘atan’ at (1)
>
> I think we need to rethink the handling of the 2 argument case, where we
> make the second argument optional. Then, in gfc_check_atan, we need to
> swap expressions to align Y with arg1 and X with arg2.
Yes, this is because once a keyword is used, we never reach the check.
Which makes me think whether sort_actual is the right place for the check.
Is there any generic intrinsic where a keyword is needed for resolving?
Besides the weird ALLOCATED(), where there can be only one argument
(ARRAY or SCALAR), but then this is a fixed number.
[Bug fortran/116128] missed optimisation: fortran sum instrinsic performed in order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116128
--- Comment #6 from anlauf at gcc dot gnu.org ---
Guided by the dump-tree for the inlining code, I played a little to see
what kind of code the middle-end expects. To this end I used C code.
The reference for the sum over a rank-1 array (given stride and count):
double __attribute__ ((noipa,noinline))
sum_v1 (double x[], int stride, int n)
{
double sum = 0.;
for (int i = 0; i < n; i++)
sum += x[i*stride];
return sum;
}
An optimizer might see a pattern in the array access. I guess that for
stride=1 it generates a separate path like:
double __attribute__ ((noipa,noinline))
sum_v2 (double x[], int stride, int n)
{
double sum = 0.;
if (stride == 1)
{
for (int i = 0; i < n; i++)
sum += x[i];
}
else
{
for (int i = 0; i < n; i++)
sum += x[i*stride];
}
return sum;
}
Unit stride should give faster loads (it does on vector machines).
I wonder if gcc does that rather obvious transformation if stride can
be 1 and the loop is "hot".
Another optimization could be partial sums with reordering - which is what
you mention - but only if associative math is enabled. Code might look like:
double __attribute__ ((noipa,noinline))
sum_v4 (double x[], int stride, int n)
{
double sum;
double tmp[4];
int i, off, n4;
if (n <= 0)
return 0.;
for (int i = 0; i < 4; i++)
tmp[i] = 0.;
n4 = n & ~0x3;
off = 0;
for (i = 0; i < n4; i += 4)
{
tmp[0] += x[off];
tmp[1] += x[off+1*stride];
tmp[2] += x[off+2*stride];
tmp[3] += x[off+3*stride];
off += 4*stride;
}
sum = (tmp[0] + tmp[1]) + (tmp[2] + tmp[3]);
for (; i < n; i++)
sum += x[off + (i-n4)*stride];
return sum;
}
While this may look natural when memory bandwidth is "infinite" and SIMD
performance is limited, I do not know what the situation is for common
scalar architectures.
Ideally, if annotation of a reduction loop (e.g. "associative math") could
tell the middle-end that any of the above transformations is allowed, the
generation of inline code could be rather target-agnostic.
Doing code transforms as above when generating inline code in the frontend
could end up in a nightmare.
[Bug fortran/116359] Nested contained procedures rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116359 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2024-08-26 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #2 from anlauf at gcc dot gnu.org --- There seems nothing wrong with gfortran here, it is the Fortran standard which is not as regular as you expect. (I am also bothered by this limitation, but it has there for quite some time.) Can we close this one?
[Bug fortran/113412] ATAN(Y,X) does not check arguments and generates wrong error message.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113412 --- Comment #8 from anlauf at gcc dot gnu.org --- I looked at this one again, also at the fortran-dump. Consider: subroutine s1 intrinsic :: atan real :: r = 1. print *, atan (-1.d0,r) end subroutine s2 external :: atan real :: r = 1. print *, atan (-1.d0,r) end subroutine s3 real :: r = 1. print *, atan (-1.d0,r) ! Should give error similar to s1 case end subroutine s4 real :: r = 1. print *, atan (-1.d0,r) ! Reasonable diagnostics contains elemental function atan (x, y) real, intent(in) :: x, y real :: atan atan = atan2 (x, y) end function atan end Subroutine s1 gets diagnosed with: pr113412.f90:4:10: 4 | print *, atan (-1.d0,r) | 1 Error: Generic function 'atan' at (1) is not consistent with a specific intrinsic interface which is correct. The fortran-dump therefore correctly shows: TRANSFER atan[((-1._8) (s1:r))] Subroutine s3 gives pr113412.f90:15:10: 15 | print *, atan (-1.d0,r) ! Should give error similar to s1 case | 1 Error: Too many arguments in call to 'atan' at (1) which looks like resolution happens slightly different. Subroutine s4 shows that regular interfaces are handled reasonably: pr113412.f90:20:10: 20 | print *, atan (-1.d0,r) ! Should give error similar to s1 case | 1 Error: Type mismatch in argument 'x' at (1); passed REAL(8) to REAL(4) NAG gives consistent diagnostics for s1 and s3, as does flang. (Nvidia is not so consistent, and Intel ICEs).
[Bug fortran/107145] Indefinite recursion in gfc_check_dummy_characteristics/gfc_compare_interfaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107145
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Priority|P3 |P4
Last reconfirmed||2024-08-20
--- Comment #1 from anlauf at gcc dot gnu.org ---
The following patch breaks the recursion:
diff --git a/gcc/fortran/interface.cc b/gcc/fortran/interface.cc
index b592fe4f6c7..80c7239eec7 100644
--- a/gcc/fortran/interface.cc
+++ b/gcc/fortran/interface.cc
@@ -1384,6 +1396,10 @@ gfc_check_dummy_characteristics (gfc_symbol *s1,
gfc_symbol *s2,
return false;
}
+ /* Short-cut for same symbols. */
+ if (s1 == s2)
+return true;
+
/* Check type and rank. */
if (type_must_agree)
{
However, we then miss the circular dependency, which is detected by NAG:
NAG Fortran Compiler Release 7.2(Shin-Urayasu) Build 7200
Warning: pr107145.f90, line 9: Unused dummy procedure P2
Error: pr107145.f90, line 8: Named interface P for entity P2 depends on P2
itself via SUB
Errors in declarations, no further processing for CIRCULAR
[Bug fortran/107508] Invalid bounds due to bogus reallocation on assignment with KIND=4 characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107508 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED Known to fail||12.3.0 Known to work||13.3.0 --- Comment #3 from anlauf at gcc dot gnu.org --- Fixed in gcc-13.
[Bug fortran/99884] Double spaces in warning message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99884 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING --- Comment #3 from anlauf at gcc dot gnu.org --- Fixed almost 2 years ago. Anything left?
[Bug fortran/106603] Problem with character(:), allocatable, intent(out) :: err for functions which return fixed arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106603 anlauf at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2024-08-18 Status|UNCONFIRMED |WAITING Keywords||wrong-code Known to fail||12.3.0, 7.5.0 Priority|P3 |P4 Known to work||13.3.0, 14.2.0, 15.0 --- Comment #1 from anlauf at gcc dot gnu.org --- While this error goes back to at least 7.5.0 and is present in 12.3.0, it appears fixed on 13-branch and newer. Can you please verify that newer gfortran releases fix your problem?
[Bug fortran/114781] Error in ALLOCATE with MOLD=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114781 --- Comment #2 from anlauf at gcc dot gnu.org --- Update: at r15-2986 the allocation errors are no longer present. Likely fixed by r15-1704 and r15-2910. Older branches are still affected. Replacing mold= by source=, or using parentheses around polymorphic mold argument we hit issues with the ALLOCATE statement: MODULE mold_test_mo IMPLICIT NONE CONTAINS SUBROUTINE aalloc(sample) CLASS(*),INTENT(in) :: sample INTEGER :: localsample CLASS(*),ALLOCATABLE :: arr(:), tmparr(:) ! ALLOCATE(arr(1), mold=sample) ALLOCATE(arr(1), source=sample) CALL MOVE_ALLOC(arr, tmparr) SELECT TYPE(tmparr) TYPE is (INTEGER) PRINT *,tmparr END SELECT ! ALLOCATE(arr(2), mold=tmparr(1)) ! OK ! ALLOCATE(arr(2), mold=(tmparr(1))) ! ICE ALLOCATE(arr(2), source=tmparr(1)) ! runtime segfault SELECT TYPE(arr) TYPE is (INTEGER) PRINT *,arr END SELECT END SUBROUTINE aalloc END MODULE mold_test_mo PROGRAM mold_test USE mold_test_mo IMPLICIT NONE CALL aalloc(3) END PROGRAM mold_test
[Bug fortran/114146] REPEATABLE argument of RANDOM_INIT and repeated execution of the program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114146 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from anlauf at gcc dot gnu.org --- The updated docomentation is visible at https://gcc.gnu.org/onlinedocs/gfortran/RANDOM_005fINIT.html Thus fixed. Thanks for the report!
[Bug fortran/114146] REPEATABLE argument of RANDOM_INIT and repeated execution of the program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114146 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org CC||anlauf at gcc dot gnu.org --- Comment #2 from anlauf at gcc dot gnu.org --- (In reply to kargls from comment #1) > Looks like someone needs to update the gfortran manual. Submitted: https://gcc.gnu.org/pipermail/fortran/2024-August/060848.html
[Bug fortran/99837] ICE in parse_associate, at fortran/parse.c:4780
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99837 --- Comment #4 from anlauf at gcc dot gnu.org --- The following variation (valid code) which compiles here with 14-branch fails at r15-2937: program p type t !integer, allocatable :: a(:) integer :: b end type class(t), allocatable :: x[:] select type (y => x) end select end % gfc-15 pr99837-zz.f90 -fcoarray=single pr99837-zz.f90:1:9: 1 | program p | 1 internal compiler error: in fold_convert_loc, at fold-const.cc:2768 0x24a75c6 internal_error(char const*, ...) ../../gcc-trunk/gcc/diagnostic-global-context.cc:491 0x97a1c2 fancy_abort(char const*, int, char const*) ../../gcc-trunk/gcc/diagnostic.cc:1772 0x7ab36c fold_convert_loc(unsigned int, tree_node*, tree_node*) ../../gcc-trunk/gcc/fold-const.cc:2768 0xb2ee7a trans_associate_var ../../gcc-trunk/gcc/fortran/trans-stmt.cc:2212 0xb33c81 gfc_trans_block_construct(gfc_code*) ../../gcc-trunk/gcc/fortran/trans-stmt.cc:2423 0xa8f537 trans_code ../../gcc-trunk/gcc/fortran/trans.cc:2463 0xac6964 gfc_generate_function_code(gfc_namespace*) ../../gcc-trunk/gcc/fortran/trans-decl.cc:7961 0xa3696f translate_all_program_units ../../gcc-trunk/gcc/fortran/parse.cc:7145 0xa3696f gfc_parse_file() ../../gcc-trunk/gcc/fortran/parse.cc:7459 0xa8c07f gfc_be_parse_file ../../gcc-trunk/gcc/fortran/f95-lang.cc:241
[Bug fortran/116221] -Wmaybe-uninitialized in symbol.cc's gfc_get_ha_symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116221 --- Comment #12 from anlauf at gcc dot gnu.org --- (In reply to Sam James from comment #10) > /var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/fortran/ > interface.cc: In function ‘gfc_get_formal_from_actual_arglist’: > /var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/fortran/ > interface.cc:5726:21: warning: ‘s’ may be used uninitialized > [-Wmaybe-uninitialized] > 5726 | s->ts = a->expr->ts; > | ^ > /var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/fortran/ > interface.cc:5708:15: note: ‘s’ was declared here > 5708 | gfc_symbol *s; > | ^ OK, initialize. > /var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/fortran/ > intrinsic.cc: In function ‘gfc_get_intrinsic_function_symbol’: > /var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/fortran/ > intrinsic.cc:156:22: warning: ‘sym’ may be used uninitialized > [-Wmaybe-uninitialized] > 156 | sym->attr.external = 1; > | ^ > /var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/fortran/ > intrinsic.cc:153:15: note: ‘sym’ was declared here > 153 | gfc_symbol *sym; > | ^ Likewise. > In function ‘gfc_get_intrinsic_function_symbol’, > inlined from ‘specific_intrinsic_symbol’ at > /var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/fortran/ > trans-intrinsic.cc:4322:47: > /var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/fortran/ > intrinsic.cc:158:29: warning: ‘sym’ may be used uninitialized > [-Wmaybe-uninitialized] > 158 | sym->attr.always_explicit = 1; > | ^ > /var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/fortran/ > intrinsic.cc: In function ‘specific_intrinsic_symbol’: > /var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/fortran/ > intrinsic.cc:153:15: note: ‘sym’ was declared here > 153 | gfc_symbol *sym; > | ^ > > ``` OK. It makes sense to initialize sym in gfc_find_intrinsic_symbol.
[Bug fortran/116221] -Wmaybe-uninitialized in symbol.cc's gfc_get_ha_symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116221
--- Comment #11 from anlauf at gcc dot gnu.org ---
(In reply to Sam James from comment #9)
> A handful more:
> ```
> In function ‘gfc_restore_backend_locus’,
> inlined from ‘gfc_trans_if_1’ at
> /var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/fortran/
> trans-stmt.cc:1485:31:
> /var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/fortran/
> trans.cc:2323:39: warning: ‘saved_loc.lb’ may be used uninitialized
> [-Wmaybe-uninitialized]
> 2323 | gfc_current_backend_file = loc->lb->file;
> | ^
> /var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/fortran/
> trans-stmt.cc: In function ‘gfc_trans_if_1’:
> /var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/fortran/
> trans-stmt.cc:1464:9: note: ‘saved_loc.lb’ was declared here
> 1464 | locus saved_loc;
> | ^
This one is a false-positive. The code in question is:
if (code->expr1->where.lb)
{
gfc_save_backend_locus (&saved_loc);
gfc_set_backend_locus (&code->expr1->where);
}
gfc_conv_expr_val (&if_se, code->expr1);
if (code->expr1->where.lb)
gfc_restore_backend_locus (&saved_loc);
Maybe LTO does not understand that gfc_conv_expr_val (my guess) does not have
a side-effect that changes the condition (code->expr1->where.lb != NULL).
> /var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/fortran/
> parse.cc: In function ‘parse_contained’:
> /var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/fortran/
> parse.cc:6578:15: warning: ‘sym’ may be used uninitialized
> [-Wmaybe-uninitialized]
> 6578 | if (!sym->attr.pure)
> | ^
> /var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/fortran/
> parse.cc:6507:15: note: ‘sym’ was declared here
> 6507 | gfc_symbol *sym;
> | ^
That could be solved by initializing sym.
> /var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/fortran/
> match.cc: In function ‘gfc_match_call’:
> /var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/fortran/
> match.cc:5132:33: warning: ‘select_st’ may be used uninitialized
> [-Wmaybe-uninitialized]
> 5132 | select_sym = select_st->n.sym;
> | ^
> /var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/fortran/
> match.cc:5124:20: note: ‘select_st’ declared here
> 5124 | gfc_symtree *select_st;
> |^
That's again because gfc_get_ha_sym_tree is complicated and can be fixed
by initializing select_st.
[Bug fortran/114308] ICE in fold_convert_loc, at fold-const.cc:2627
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114308 anlauf at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |15.0 Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #17 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-15.
[Bug fortran/116261] [15 regression] gfortran.dg/sizeof_6.f90 -O1 timeout since r15-2739-g4cb07a38233
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116261 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-08-13 --- Comment #3 from anlauf at gcc dot gnu.org --- Running the resulting executable under valgrind shows issues that were not present in gcc-14: there are many reports of the type ==11462== Conditional jump or move depends on uninitialised value(s) ==11462==at 0x48386ED: malloc (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so) ==11462==by 0x428DF0: __final_MAIN___T.1 (sizeof_6.f90:5) ==11462==by 0x42AF7C: __final_MAIN___T2.5 (sizeof_6.f90:5) ==11462==by 0x426D1E: MAIN__ (sizeof_6.f90:281) ==11462==by 0x42D581: main (sizeof_6.f90:287) ==11462== [...] ==11462== Use of uninitialised value of size 8 ==11462==at 0x428FD3: __final_MAIN___T.1 (sizeof_6.f90:5) ==11462==by 0x42AF7C: __final_MAIN___T2.5 (sizeof_6.f90:5) ==11462==by 0x426D1E: MAIN__ (sizeof_6.f90:281) ==11462==by 0x42D581: main (sizeof_6.f90:287) ==11462== [...] Commenting lines 281..287 (six deallocates at the end of the main), the issues seems to disappears. A bookkeeping issue in the finalization?
[Bug fortran/114308] ICE in fold_convert_loc, at fold-const.cc:2627
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114308 --- Comment #14 from anlauf at gcc dot gnu.org --- (In reply to kargls from comment #13) > (In reply to anlauf from comment #11) > > Created attachment 58926 [details] > > Patch > > > > This patch applies the check of the declared type in resolve_array_list, > > where there is already a check for unlimited polymorphic elements. > > > > Will submit if it regtests ok. > > Looks good except don't you also need to check c->expr->ts.type == > BT_DERIVED. > > One can have > > type, abstract :: a > ... > end type a > > Or, does the 'abstract' attribute cause gfortran to use BT_CLASS? Can you construct a testcase which is missed? type(a) :: a_instance is already rejected with Error: 'a_instance' at (1) is of the ABSTRACT type 'a' from which I took over the wording. See also F2018:C703: The derived-type-spec shall not specify an abstract type (7.5.7).
[Bug fortran/114308] ICE in fold_convert_loc, at fold-const.cc:2627
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114308 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #12 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2024-August/060824.html
[Bug fortran/114308] ICE in fold_convert_loc, at fold-const.cc:2627
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114308 --- Comment #11 from anlauf at gcc dot gnu.org --- Created attachment 58926 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58926&action=edit Patch This patch applies the check of the declared type in resolve_array_list, where there is already a check for unlimited polymorphic elements. Will submit if it regtests ok.
[Bug fortran/114308] ICE in fold_convert_loc, at fold-const.cc:2627
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114308
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--- Comment #10 from anlauf at gcc dot gnu.org ---
(In reply to kargls from comment #9)
> I had
>
> gfc_error ("Declared type of %qs has an ABSTRACT attribute, "
>"it cannot appear in the array constructor at %L",
>expr->symtree->name, &expr->where);
>
> but the word 'it' seemed too vague to me. Using NAG's message
> would have
>
> gfc_error ("Array constructor value %qs at %L is of abstract type %qs",
>expr->symtree->name, &expr->where, expr->ts.u.derived->name);
>
> with the output
>
> Array constructor value A_ARRAY is of abstract type __CLASS_MY_MODULE_A_1_0A
>
> gfortran mangles names. I suppose we can do
>
> gfc_error ("Array constructor value %qs at %L is of abstract type,
>expr->symtree->name, &expr->where);
>
> and leave out the name of the derived type.
There is already a solution: gfc_typename
gfc_error ("Array constructor value %qs at %L is of abstract type %qs",
expr->symtree->name, &expr->where, gfc_typename (&expr->ts));
This gives:
Error: Array constructor value 'a_array' at (1) is of abstract type 'CLASS(a)'
[Bug fortran/114308] ICE in fold_convert_loc, at fold-const.cc:2627
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114308
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Keywords|ice-on-valid-code |ice-on-invalid-code
--- Comment #8 from anlauf at gcc dot gnu.org ---
(In reply to kargls from comment #7)
> I can no longer edit meta data for a PR. The keyword: field is wrong. This
> is an ice-on-invalid-code. Please change.
I think you need to login with your @gcc.gnu.org address now, if you have
one.
Regarding your patch, is there a reason you emit the symbol name twice?
gfc_error ("Declared type of %qs has an ABSTRACT attribute, "
"%qs cannot appear in the array constructor at %L",
expr->symtree->name, expr->symtree->name, &expr->where);
How about just doing it once (see e.g. NAG)?
[Bug fortran/114308] ICE in fold_convert_loc, at fold-const.cc:2627
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114308 --- Comment #3 from anlauf at gcc dot gnu.org --- There may be some doubt on the validity of the testcase. Intel ifx: pr114308.f90(20): warning #9108: Polymorphic values in array constructors will be converted to their declared type. [A_ARRAY] a_array = [a_array, b_instance] ! This one throws an ICE -^ pr114308.f90(20): error #6315: The array-constructor has ac-values of differing types. [B_INSTANCE] a_array = [a_array, b_instance] ! This one throws an ICE --^ compilation aborted for pr114308.f90 (code 1) NAG: NAG Fortran Compiler Release 7.2(Shin-Urayasu) Build 7200 Warning: pr114308.f90, line 21: Symbol B_INSTANCE referenced but never set Error: pr114308.f90, line 20: Array constructor value A_ARRAY is of abstract type A [NAG Fortran Compiler error termination, 1 error, 1 warning]
[Bug fortran/116221] -Wmaybe-uninitialized in symbol.cc's gfc_get_ha_symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116221 anlauf at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING Last reconfirmed||2024-08-11 --- Comment #8 from anlauf at gcc dot gnu.org --- Patches from comment#3 and comment#5 have been applied. If the LTO warnings are fixed, please close this PR. Otherwise we should look into remaining warnings.
[Bug fortran/116292] [15 regression] ICE in build_function_decl, at fortran/trans-decl.cc:2486
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116292 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||vehre at gcc dot gnu.org --- Comment #7 from anlauf at gcc dot gnu.org --- OK, this is weird: Breakpoint 3, conv_intrinsic_move_alloc (code=) at ../../gcc-trunk/gcc/fortran/trans-intrinsic.cc:12769 12769 from_se.expr = gfc_get_symbol_decl (vtab); (gdb) l 12764 gfc_symbol *vtab; 12765 from_tree = from_se.expr; 12766 12767 vtab = gfc_find_vtab (&from_expr->ts); 12768 gcc_assert (vtab); 12769 from_se.expr = gfc_get_symbol_decl (vtab); 12770 } 12771 gfc_add_block_to_block (&block, &from_se.pre); 12772 12773 to_se.want_pointer = 1; The offending code here was added in r15-1704-gaa3599a10cab34: commit aa3599a10cab34104c0b9bd6951c5f0c420795d8 Author: Andre Vehreschild Date: Tue Jun 11 12:52:26 2024 +0200 Add gfc_class_set_vptr. First step to adding a general assign all class type's data members routine. Having a general routine prevents forgetting to tackle the edge cases, e.g. setting _len. gcc/fortran/ChangeLog: * trans-expr.cc (gfc_class_set_vptr): Add setting of _vptr member. * trans-intrinsic.cc (conv_intrinsic_move_alloc): First use of gfc_class_set_vptr and refactor very similar code. * trans.h (gfc_class_set_vptr): Declare the new function. CC'ing Andre.
[Bug fortran/116292] [15 regression] ICE in build_function_decl, at fortran/trans-decl.cc:2486
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116292 --- Comment #6 from anlauf at gcc dot gnu.org --- Note that the ICE also happens for other variable types (e.g. integer), and disappears for rank > 0. This works: program p character, allocatable :: buffer, dummy ! integer, allocatable :: buffer, dummy dimension :: buffer(:), dummy(:) contains subroutine s call move_alloc (dummy, buffer) end end
[Bug fortran/116292] [15 regression] ICE in build_function_decl, at fortran/trans-decl.cc:2486
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116292
--- Comment #5 from anlauf at gcc dot gnu.org ---
Breakpoint 1, build_function_decl (sym=0x3316310, global=global@entry=false)
at ../../gcc-trunk/gcc/fortran/trans-decl.cc:2486
2486 gcc_assert (current_function_decl == NULL_TREE
(gdb) l
2481 /* Set the line and filename. sym->declared_at seems to point to the
2482 last statement for subroutines, but it'll do for now. */
2483 gfc_set_backend_locus (&sym->declared_at);
2484
2485 /* Allow only one nesting level. Allow public declarations. */
2486 gcc_assert (current_function_decl == NULL_TREE
2487 || DECL_FILE_SCOPE_P (current_function_decl)
2488 || (TREE_CODE (DECL_CONTEXT (current_function_decl))
2489 == NAMESPACE_DECL));
2490
The ICE comes after:
(gdb) p debug_tree(current_function_decl)
>
QI
size
unit-size
align:8 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x76a327e0
attributes
value >>
arg-types >>
static QI pr116292.f90:4:14 align:8 warn_if_not_align:0 context
result
ignored VOID pr116292.f90:4:14
align:8 warn_if_not_align:0 context >
(mem:QI (symbol_ref:DI ("s.0") [flags 0x3] ) [0 S1 A8])
struct-function 0x7680a0c0>
[Bug fortran/116292] [15 regression] ICE in build_function_decl, at fortran/trans-decl.cc:2486
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116292 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2024-08-08 Keywords||ice-on-valid-code CC||anlauf at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Priority|P3 |P4 --- Comment #4 from anlauf at gcc dot gnu.org --- Confirmed. Reduced testcase: program p character, allocatable :: buffer, dummy contains subroutine s call move_alloc (dummy, buffer) end end % gfc-15 pr116292.f90 pr116292.f90:5:35: 5 | call move_alloc (dummy, buffer) | 1 internal compiler error: in build_function_decl, at fortran/trans-decl.cc:2486 0x24a0a76 internal_error(char const*, ...) ../../gcc-trunk/gcc/diagnostic-global-context.cc:491 0x9799d6 fancy_abort(char const*, int, char const*) ../../gcc-trunk/gcc/diagnostic.cc:1772 0x75758c build_function_decl ../../gcc-trunk/gcc/fortran/trans-decl.cc:2486 0xac17bc gfc_get_symbol_decl(gfc_symbol*) ../../gcc-trunk/gcc/fortran/trans-decl.cc:1861 0xadfe3e gfc_conv_variable ../../gcc-trunk/gcc/fortran/trans-expr.cc:3155 0xa8 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool, bool) ../../gcc-trunk/gcc/fortran/trans-expr.cc:8912 0xade1dd gfc_conv_structure(gfc_se*, gfc_expr*, int) ../../gcc-trunk/gcc/fortran/trans-expr.cc:9857 0xaddcef gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool, bool) ../../gcc-trunk/gcc/fortran/trans-expr.cc:8927 0xac11db gfc_get_symbol_decl(gfc_symbol*) ../../gcc-trunk/gcc/fortran/trans-decl.cc:2031 0xb00d5d conv_intrinsic_move_alloc ../../gcc-trunk/gcc/fortran/trans-intrinsic.cc:12769 0xb00d5d gfc_conv_intrinsic_subroutine(gfc_code*) ../../gcc-trunk/gcc/fortran/trans-intrinsic.cc:12918 0xa8e752 trans_code ../../gcc-trunk/gcc/fortran/trans.cc:2425 0xac5b24 gfc_generate_function_code(gfc_namespace*) ../../gcc-trunk/gcc/fortran/trans-decl.cc:7961 0xac58dc gfc_generate_contained_functions ../../gcc-trunk/gcc/fortran/trans-decl.cc:6076 0xac58dc gfc_generate_function_code(gfc_namespace*) ../../gcc-trunk/gcc/fortran/trans-decl.cc:7893 0xa3615f translate_all_program_units ../../gcc-trunk/gcc/fortran/parse.cc:7132 0xa3615f gfc_parse_file() ../../gcc-trunk/gcc/fortran/parse.cc:7446 0xa8b3cf gfc_be_parse_file ../../gcc-trunk/gcc/fortran/f95-lang.cc:241
[Bug fortran/116128] missed optimisation: fortran sum instrinsic performed in order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116128 --- Comment #4 from anlauf at gcc dot gnu.org --- (In reply to mjr19 from comment #3) > It seems that most of these are in-line expanded by gfortran-14.1, at least > in some cases. > > function foo(a,n) > real(kind(1d0))::a(*),foo > integer::n > > foo=sum(a(1:n)) > end function foo > > and > > function foo(a) > real(kind(1d0)), contiguous::a(:) > real(kind(1d0)):: foo > > foo=sum(a) > end function foo > > are both inline expanded, and with gfortran-14.1 -O3 -mavx2 -S give > > .L5: > vaddsd (%rax), %xmm0, %xmm0 > addq$32, %rax > vaddsd -24(%rax), %xmm0, %xmm0 > vaddsd -16(%rax), %xmm0, %xmm0 > vaddsd -8(%rax), %xmm0, %xmm0 > cmpq%rdx, %rax > jne .L5 > > and > > .L5: > movq%rdx, %rax > addq$1, %rdx > salq$5, %rax > addq%rcx, %rax > vaddsd (%rax), %xmm0, %xmm0 > vaddsd 8(%rax), %xmm0, %xmm0 > vaddsd 16(%rax), %xmm0, %xmm0 > vaddsd 24(%rax), %xmm0, %xmm0 > cmpq%rdx, %rsi > jne .L5 > > At -O2 there is no unrolling, but the benefits of unrolling whilst retaining > the data dependency on %xmm0 must be very slight. (I am also slightly > confused that using contiguous is not equivalent to the a(*) version.) Indeed, this is an interesting observation! Comparing the generated tree code and assembler for the second (contiguous) version, using either foo = sum (a) or foo = sum (a(1:size(a))) show slight differences which might be worth to investigate. > At -Ofast one gets > > .L5: > vaddpd (%rax), %ymm0, %ymm0 > addq$32, %rax > cmpq%rdx, %rax > jne .L5 > > and > > .L5: > movq%rax, %rdx > addq$1, %rax > salq$5, %rdx > vaddpd (%rcx,%rdx), %ymm0, %ymm0 > cmpq%rax, %rsi > jne .L5 I played with your examples. Indeed, the generated code looks conservative, with improvements going from -O2 -> -O3 -> -O3 -ffast-math -> -Ofast . The frontend generates straightforward tree code, so even allowing reassociation by the optimizer will not make it possible to take full advantage of vectorization similar to nvfortran. Unless the middle-end allowed to annotate loops/loop nests to make a transformation of the loop. Of course such an optimization would only be allowable for types for which reassociation is allowed (or with -ffast-math). (Compilers for real vector machines do generate code for recursively calculating partial sums, otherwise these machines would be painfully slow.) What gcc seems to lack is support for annotating loop nests to collapse loops - I only see mentioning of the explicit OMP annotation. If we loop over elements of a contiguous array, this may result in reduction of a significant loop overhead. > In contrast nvfortran at -O2 and above produces > > .LBB0_7: > movq%rdx, %r8 > vaddpd (%rsi), %ymm0, %ymm0 > vaddpd 32(%rsi), %ymm1, %ymm1 > vaddpd 64(%rsi), %ymm2, %ymm2 > vaddpd 96(%rsi), %ymm3, %ymm3 > subq$-128, %rsi > addq$-16, %rdx > addq$-15, %r8 > cmpq$16, %r8 > jg .LBB0_7 > > I am not sure that I like the loop control instructions, but the vaddpd's to > four separate sums look good as this breaks the data dependencies between > the longish-latency vaddpd's. One could emulate this by switching to a fast library version of sum for sufficiently large array arguments (with a threshold to be determined, like we do e.g. for using dgemm from blas instead of matmul). > If the code had been written with an explicit loop > > foo=0 > do i=1,n > foo=foo+a(i) > enddo > > then it would not be standard-conformant to rearrange into partial sums as > gfortran does at -Ofast, and nvfortran does at -O2. Right. > But my understanding is > that the intrinsic sum function does not specify the ordering, and hence any > ordering would be standard-compliant, Agree here. > and, arguably, the use of partial sums > actually increases the accuracy for general data, and so should be > preferable from an accuracy point of view, as well as for performance. I do not see this. Why should it increase accuracy for *general* data? It's just faster but numerically different, isn't it? > Gfortran appears not to support the newly-introduced "reduce" qualifier of > "do concurrent". No, not yet. But there are open pr's on this, and I think there was a project. Do not know about it's status, though. However, how is "do concurrent" going to help here? Parallel reduction operations do have their own overhead and normally try to generate the same result independent of the number of threads, which looks orthogonal to the transformation into SIMD operations with partial sums. > Other simple reduction intrinsics are expanded inline in simple cases,
[Bug fortran/116221] -Wmaybe-uninitialized in symbol.cc's gfc_get_ha_symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116221
--- Comment #5 from anlauf at gcc dot gnu.org ---
(In reply to Sam James from comment #4)
> That works, thanks!
Did you also need to apply an equivalent initialization to silence the
warnings in comment#1:
diff --git a/gcc/fortran/intrinsic.cc b/gcc/fortran/intrinsic.cc
index 40f4c4f4b0b..62c349da7f6 100644
--- a/gcc/fortran/intrinsic.cc
+++ b/gcc/fortran/intrinsic.cc
@@ -131,7 +131,7 @@ gfc_type_abi_kind (bt type, int kind)
gfc_symbol *
gfc_get_intrinsic_sub_symbol (const char *name)
{
- gfc_symbol *sym;
+ gfc_symbol *sym = NULL;
gfc_get_symbol (name, gfc_intrinsic_namespace, &sym);
sym->attr.always_explicit = 1;
If this solves the issues reported here, I can push these changes.
[Bug fortran/116128] missed optimisation: fortran sum instrinsic performed in order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116128 anlauf at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P5 --- Comment #2 from anlauf at gcc dot gnu.org --- Can you provide testcases for discussion? The library versions have to deal with different situations: - non-unit strides. Vectorization on many architectures only works for unit stride, or for those processors with support for gather/(scatter). - minval/maxval need to deal with NaNs etc. for proper IEEE support. One could try different paths for better vectorization: (1) add runtime library versions/code paths for unit stride (2) generate inline code instead of calling the runtime library (3) create avx2/... versions of the runtime library code (this was done for matmul so far). Among these options, (2) is probably the hardest one. Option (1) would allow auto-vectorization by the compiler, while (3) looks like a natural but manual solution for x86. > makes me think that the optimisations of omp simd reduce(+) would be > permitted. omp simd is something which could be tried for 'sum', but to get full performance needs a rewrite of the related library code. > The same comment applies to dot_product, and probably the other intrinsic > reduction operations. dot_product is inline-expanded.
[Bug fortran/116221] -Wmaybe-uninitialized in symbol.cc's gfc_get_ha_symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116221
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--- Comment #3 from anlauf at gcc dot gnu.org ---
(In reply to Sam James from comment #0)
> With an LTO bootstrap, I saw the following:
> ```
> /var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/fortran/
> symbol.cc: In function ‘gfc_get_ha_symbol’:
> /var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/fortran/
> symbol.cc:3606:7: warning: ‘st’ may be used uninitialized
> [-Wmaybe-uninitialized]
> 3606 | if (st)
> | ^
> /var/tmp/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/fortran/
> symbol.cc:3602:16: note: ‘st’ declared here
> 3602 | gfc_symtree *st;
> |^
> ```
>
> At a glance, it looks like it might be right.
>
> ```
> int
> gfc_get_ha_symbol (const char *name, gfc_symbol **result)
> {
> int i;
> gfc_symtree *st;
>
> i = gfc_get_ha_sym_tree (name, &st);
>
> if (st)
> *result = st->n.sym;
> else
> *result = NULL;
>
> return i;
> }
> ```
>
> We always test st after calling gfc_get_ha_sym_tree, but gfc_get_ha_sym_tree
> doesn't _always_ initialise st (result):
>
> int
> gfc_get_ha_sym_tree (const char *name, gfc_symtree **result)
> {
> gfc_symtree *st;
> int i;
>
> i = gfc_find_sym_tree (name, gfc_current_ns, 0, &st);
>
> if (st != NULL)
> {
> gfc_save_symbol_data (st->n.sym);
> *result = st;
> return i;
> }
>
> i = gfc_find_sym_tree (name, gfc_current_ns, 1, &st);
> if (i)
> return i;
>
> if (st != NULL)
> {
> *result = st;
> return 0;
> }
>
> return gfc_get_sym_tree (name, gfc_current_ns, result, false);
> }
I can imagine that it is difficult to prove that in gfc_get_ha_symbol
st always gets set before the test. Does it help to initialize it?
diff --git a/gcc/fortran/symbol.cc b/gcc/fortran/symbol.cc
index b5143d9f790..a8b623dd92a 100644
--- a/gcc/fortran/symbol.cc
+++ b/gcc/fortran/symbol.cc
@@ -3599,7 +3599,7 @@ int
gfc_get_ha_symbol (const char *name, gfc_symbol **result)
{
int i;
- gfc_symtree *st;
+ gfc_symtree *st = NULL;
i = gfc_get_ha_sym_tree (name, &st);
[Bug fortran/101919] Inconsistent -Wstringop-overread warning with -flto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101919 anlauf at gcc dot gnu.org changed: What|Removed |Added Known to fail||8.5.0 Known to work||7.5.0 --- Comment #7 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #4) > This fixes comment#2: > > diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c However, it does not fix the following even simpler example: subroutine foo (d, e) implicit none character(len=10) :: d character(len=*) :: e integer :: i = 0 d = '1234567890'(6:10+i) ! Warning d = '1234567890'(6+0*i:10+i) ! Warning d = '1234567890'(6+1*i:10+i) ! OK e = '1234567890'(6:10+i) ! OK end The code appears to work as expected, but I cannot find a way to suppress the warning at -flto -O0.
[Bug fortran/109345] [12/13/14/15 Regression] class(*) variable that is a string array is not handled correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109345 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Target Milestone|--- |12.5 Known to fail||12.4.0, 13.3.0, 14.1.0, ||15.0 Known to work||11.5.0 Summary|class(*) variable that is a |[12/13/14/15 Regression] |string array is not handled |class(*) variable that is a |correctly |string array is not handled ||correctly Ever confirmed|0 |1 Keywords||wrong-code Priority|P3 |P4 Last reconfirmed||2024-07-23 --- Comment #1 from anlauf at gcc dot gnu.org --- Interesting bug. This does work in 11.5.0 but fails in 12+. Slightly rewritten to exhibit the issue more clearly: program test implicit none character(len=12) :: str_array(4) !< Array of strings str_array(:) = "" str_array(1) = "12345678" str_array(2) = "@ABCDEFG" call foo2(str_array) !< char type call foo (str_array) !< class(*) call foo3(str_array) !< class(*) with str copy contains subroutine foo ( var) !< Uses class(*) class(*), intent(in) :: var(:) integer :: i print *, "Using class(*)" select type (var) type is (character(len=*)) do i = 1, size(var) print *, len_trim(var(i)), var(i)==str_array(i), "data:", trim(var(i)) enddo end select end subroutine foo2 (var) !< Uses char type character(len=*), intent(in) :: var(:) integer :: i print *, "Using character(*)" do i = 1, size(var) print *, len_trim(var(i)), var(i)==str_array(i), "data:", trim(var(i)) enddo end subroutine foo3 (var) !< Uses class(*) with a workaround class(*), intent(in) :: var(:) integer :: i character(len=:), dimension(:), allocatable :: str select type (var) type is (character(len=*)) str = var !< copy class(*) var to an allocatable string print *, "Using class(*), with string copy workaround" do i = 1, size(str) print *, len_trim(str(i)), str(i)==str_array(i), "data:", trim(str(i)) enddo print *, (str(i)==var(i),i=1,size(str)) print *, (str(:)==var(:)) end select end end This prints with 11.5.0: Using character(*) 8 T data:12345678 8 T data:@ABCDEFG 0 T data: 0 T data: Using class(*) 8 T data:12345678 8 T data:@ABCDEFG 0 T data: 0 T data: Using class(*), with string copy workaround 8 T data:12345678 8 T data:@ABCDEFG 0 T data: 0 T data: T T T T T T T T With 12+: Using character(*) 8 T data:12345678 8 T data:@ABCDEFG 0 T data: 0 T data: Using class(*) 8 T data:12345678 12 F data:2345678@ 12 F data:345678@A 12 F data:45678@AB Using class(*), with string copy workaround 8 T data:12345678 8 T data:@ABCDEFG 0 T data: 0 T data: T F F F T T T T The issue seems to require a class(*) dummy involved.
[Bug fortran/113363] ICE on ASSOCIATE and unlimited polymorphic function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113363 --- Comment #15 from anlauf at gcc dot gnu.org --- Paul, the fix was fine for 15-mainline and 14-branch. There seems to be testsuite fallout on 13-branch (pr116040), because this fix apparently depends on the fix for pr89645, which is quite large (too large for 13-branch I am afraid). If you revert r13-8926, you might fix pr116040.
[Bug fortran/59104] Wrong result with SIZE specification expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59104 --- Comment #23 from anlauf at gcc dot gnu.org --- (In reply to Paul Thomas from comment #22) > (In reply to anlauf from comment #21) > > (In reply to Paul Thomas from comment #20) > > > OK the regression is fixed - thanks for the green light, Harald. > > > > > > It's a pity that I have missed the 4.2 release :-( > > > > > > Paul > > > > It is more important that 14.2 gets regression-free out of the door. > > Indeed! I reverted the patch but it doesn't seem to have been recorded here > (Is that normal?). I just checked that my tree is synched with the release > branch and that dependent_decls_2.f90 fails while dependent_decls_3.f90 > compiles and runs successfully. I don't know why it is not recorded here. The auto-generated ChangeLog nevertheless got it. > My original plan was to update with the regression fix but, being ultra > careful, recompiled and regtested, which caused me to time out on the > release. No, that's fine. It's better to wait until after the 14.2 release. Did you fully understand why the ordering of the treatment of the dummy arguments changed the way we observed? I got lost when I compared the tree dumps before and after the 1st committed patch. Was it because one dummy was used in the declaration of another one? I'll try to gather some more ideas to stress-test the robustness of the handling of dummy declarations. > Paul Cheers, Harald
[Bug fortran/115997] Findloc does not find the result of a function with a deferred-length character return value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115997 --- Comment #3 from anlauf at gcc dot gnu.org --- The original issue was reported for findloc, but did occur with several other intrinsics accepting deferred-length character. If you edit the bugzilla search to include resolved issues, you will also see the mentioned one. You have several options to go beyond 13.1: - try upgrading to 13.3 - wait for the upcoming 14.2 release (expected soon)
[Bug fortran/103115] [12/13/14/15 Regression] reallocation of character array fails when appending a constant size 4 array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103115 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #20 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-15, and backported to all open branches. Closing. Thanks for the report!
[Bug fortran/59104] Wrong result with SIZE specification expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59104 --- Comment #21 from anlauf at gcc dot gnu.org --- (In reply to Paul Thomas from comment #20) > OK the regression is fixed - thanks for the green light, Harald. > > It's a pity that I have missed the 4.2 release :-( > > Paul It is more important that 14.2 gets regression-free out of the door. Unfortunately I test my codes less with trunk than with the latest release branch, otherwise I would have discovered the issue in comment#12 earlier. It takes too much time to regularly rebuild a larger software stack with trunk on my notebook, so I normally do this later in the development cycle. Just did that, and it seems to look good. :-) Anyway, the complete fix for this PR still looks like a candidate for 14-branch to me, maybe for a more quiet time with sufficient distance to release dates... Thanks for the quick reaction and the fix on trunk! Harald
[Bug fortran/59104] 15 Regression - Wrong result with SIZE specification expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59104 --- Comment #17 from anlauf at gcc dot gnu.org --- (In reply to Paul Thomas from comment #16) > Created attachment 58717 [details] > Fix for the regression > > The mechanism in the original fix was OK but the use of the locus location > was not. I will investigate why this is the case but the attached works and > is very close to the first thing that I tried for the PR! > > It regtests fine. I will dejagnu-ify the testcase and will commit to > mainline in 24 hours, if I don't hear objections. I've just tested that fix and it works here. Fixes also the full module where I extracted the reproducer from. OK from my side. Thanks, Paul!
[Bug fortran/59104] 15 Regression - Wrong result with SIZE specification expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59104 --- Comment #15 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #14) > Seems to affect only dummies, not local arrays. Comparing the dump tree between working and failing, the order of the generation of the descriptors seems reversed, i.e. a bound is set from a variable that is set later, which is why one sees a 0 or junk. I haven't figured out yet how the patch leads to that effect...
[Bug fortran/59104] 15 Regression - Wrong result with SIZE specification expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59104 --- Comment #14 from anlauf at gcc dot gnu.org --- Further reduced: program p implicit none integer, parameter :: nx = 64 real, dimension(nx) :: x, s, d, f print *, shape (x), shape (s), shape (d), shape (f) call sub (x,s,d,f) contains subroutine sub (v, w, e, g) real, intent(in):: v(:) real, intent(out), dimension (size (v)) :: w ! OK real, intent(out), dimension (size (v)) :: e ! not OK real, intent(out), dimension (size (v)) :: g ! not OK real, dimension (size (v)) :: x real, dimension (size (v)) :: y print *, shape (v), shape (w), shape (e), shape (g), shape (x), shape (y) end subroutine sub end Should print: 64 64 64 64 64 64 64 64 64 64 Now prints: 64 64 64 64 64 64 0 0 64 64 It looks like only the first intent(out) argument of sub has the right size, the second and third do not. Replacing in the size() expressions in the declarations of dummies e or g array v by w does not fix the problem. Seems to affect only dummies, not local arrays.
[Bug fortran/59104] Wrong result with SIZE specification expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59104 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED|REOPENED --- Comment #12 from anlauf at gcc dot gnu.org --- Paul, can I ask you to revert commit r14-10477 asap? The following code - extracted from a larger code base - miscompiles with it: program p implicit none integer, parameter :: nx = 64, ny = 32 real :: x(nx,ny), s(nx/2,ny), d(nx/2,ny) print *, shape (x), shape (s), shape (d) call sub (x,s,d) contains subroutine sub (v, w, d) real, intent(in) :: v(:,:) real, intent(out), dimension (size (v,dim=1)/2,size (v,dim=2)) :: w, d print *, shape (v), shape (w), shape (d) end subroutine sub end Correct output should be: 64 32 32 32 32 32 64 32 32 32 32 32 With 15-trunk and 14 after the above commit I get - dependent on -Ox: 64 32 32 32 32 32 64 32 32 32 363993500 0 or 64 32 32 32 32 32 64 32 32 32 0 0 Reducing the testcase further make the commit look innocent, however...
[Bug fortran/32834] [Meta-bug] 'Fortran 95'-only failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32834 Bug 32834 depends on bug 59104, which changed state. Bug 59104 Summary: Wrong result with SIZE specification expression https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59104 What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |---
[Bug fortran/55858] When scalarizing contiguous whole-arrays, consider folding into a single loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55858 anlauf at gcc dot gnu.org changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=115935 CC||anlauf at gcc dot gnu.org --- Comment #2 from anlauf at gcc dot gnu.org --- See also pr115935 on missed optimizations when zeroing of contiguous whole arrays that are components of derived types.
[Bug fortran/110288] [11/12/13/14] Regression: segfault in findloc with allocatable array of allocatable characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110288 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||mscfd at gmx dot net --- Comment #12 from anlauf at gcc dot gnu.org --- *** Bug 115997 has been marked as a duplicate of this bug. ***
[Bug fortran/115997] Findloc does not find the result of a function with a deferred-length character return value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115997 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from anlauf at gcc dot gnu.org --- Fixed in newer releases. Please consider upgrading. *** This bug has been marked as a duplicate of bug 110288 ***
[Bug fortran/103115] [12/13/14/15 Regression] reallocation of character array fails when appending a constant size 4 array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103115 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #15 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2024-July/060703.html
[Bug fortran/103115] [12/13/14/15 Regression] reallocation of character array fails when appending a constant size 4 array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103115 anlauf at gcc dot gnu.org changed: What|Removed |Added Attachment #58695|0 |1 is obsolete|| --- Comment #14 from anlauf at gcc dot gnu.org --- Created attachment 58702 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58702&action=edit Better fix. This is a much safer fix and also much simpler. Currently regtesting. Will submit later if it passes.
[Bug fortran/103115] [12/13/14/15 Regression] reallocation of character array fails when appending a constant size 4 array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103115 --- Comment #13 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #12) > Created attachment 58695 [details] > Tentative patch > > This patch fixes the ICE by ensuring to derive the element size of constant > character elements in the array constructor from these and not trying > to guess from the deferred-length element. > > Currently reg-testing. Regtest was OK.
[Bug fortran/103115] [12/13/14/15 Regression] reallocation of character array fails when appending a constant size 4 array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103115 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #12 from anlauf at gcc dot gnu.org --- Created attachment 58695 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58695&action=edit Tentative patch This patch fixes the ICE by ensuring to derive the element size of constant character elements in the array constructor from these and not trying to guess from the deferred-length element. Currently reg-testing.
[Bug fortran/115781] Error with passing array of derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115781 --- Comment #2 from anlauf at gcc dot gnu.org --- Interesting observation: replacing call use_mats(mats) by call use_mats(mats(lbound(mats,1):)) leads to apparently correct output: top level: mats, lbound= 2, ubound= 4 top level, 2: nRows= 2 top level, 3: nRows= 3 top level, 4: nRows= 4 in use_mats: mats, lbound= 1, ubound= 3 use_mats, 1: nRows= 2 use_mats, 2: nRows= 3 use_mats, 3: nRows= 4
[Bug fortran/115781] Error with passing array of derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115781 anlauf at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Last reconfirmed||2024-07-16 Keywords||wrong-code Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed.
[Bug fortran/115884] overload when one specific subroutine has no arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115884 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #3 from anlauf at gcc dot gnu.org --- (In reply to john.harper from comment #2) > Thank you kargls. My test program compiled and ran OK with another > machine which has gfortran 14.1.1. My Ubuntu system doesn't make it > easy for me to upgrade from gfortran 13.1. That's not your problem. Closing then as WORKSFORME.
[Bug fortran/115935] Extend lowering to memset for zeroing array when it's used as a component reference
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115935 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-07-16 Ever confirmed|0 |1 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed.
[Bug fortran/100273] [11/12/13/14/15 Regression] ICE in gfc_create_module_variable, at fortran/trans-decl.c:5352
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100273 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #7 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #2) > Looks very related to the len_trim issue in pr84868. Possibly a duplicate. After the fix for pr84868, the issue still persists. Reduced testcase: module m implicit none private contains subroutine s() ! character, parameter :: c(3) = ['*', '+', '-'] ! works when placed here contains function f(n) result(z) integer, intent(in) :: n character, parameter :: c(3) = ['*', '+', '-'] ! ICE when here character(len_trim(c(n))) :: z z = c(n) end end end We hit the assert in gfc_create_module_variable: gcc_assert (sym->ns->proc_name->attr.flavor == FL_MODULE || (sym->ns->parent->proc_name->attr.flavor == FL_MODULE && sym->fn_result_spec)); (gdb) p sym->ns->proc_name->attr.flavor $1 = FL_PROCEDURE (gdb) p sym->ns->parent->proc_name->attr.flavor $2 = FL_PROCEDURE For the working version from above, one finds: (gdb) p sym->ns->proc_name->attr.flavor $3 = FL_PROCEDURE (gdb) p sym->ns->parent->proc_name->attr.flavor $4 = FL_MODULE
[Bug fortran/113363] ICE on ASSOCIATE and unlimited polymorphic function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113363 --- Comment #11 from anlauf at gcc dot gnu.org --- (In reply to Paul Thomas from comment #10) > Leave open partly because it is awaiting backporting to 14-branch but also > because there are remaining, pre-existing issues involving parentheses > around selector/source expressions: > https://gcc.gnu.org/pipermail/fortran/2024-May/060510.html Paul, is this still on your list of backports?
[Bug fortran/59104] Wrong result with SIZE specification expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59104 --- Comment #8 from anlauf at gcc dot gnu.org --- Paul, are you planning to backport your fix?
[Bug fortran/115700] [11/12/13 regression] Bogus warning for associate with assumed-length character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115700 anlauf at gcc dot gnu.org changed: What|Removed |Added Summary|[11/12/13/14 regression]|[11/12/13 regression] Bogus |Bogus warning for associate |warning for associate with |with assumed-length |assumed-length character |character array |array --- Comment #8 from anlauf at gcc dot gnu.org --- Original issue fixed on mainline for gcc-15, and on 14-branch so far. Backporting further seems to depend on backporting at least the changes to trans-stmt.cc from r14-1629. I'd rather not do this. Leaving open to track the issues mentioned in comment#5.
