[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=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=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.
[Bug fortran/115788] New: [F2018] Implement OUT_OF_RANGE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115788 Bug ID: 115788 Summary: [F2018] Implement OUT_OF_RANGE 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: --- F2018 has: 16.9.146 OUT_OF_RANGE (X, MOLD [, ROUND]) Description. Whether a value cannot be converted safely. Class. Elemental function. Arguments. X shall be of type integer or real. MOLD shall be an integer or real scalar. If it is a variable, it need not be defined. ROUND (optional) shall be a logical scalar. ROUND shall be present only if X is of type real and MOLD is of type integer. Result Characteristics. Default logical. Result Value. Case(i): If MOLD is of type integer, and ROUND is absent or present with the value false, the result is true if and only if the value of X is an IEEE infinity or NaN, or if the integer with largest magnitude that lies between zero and X inclusive is not representable by objects with the type and kind of MOLD. Case(ii): If MOLD is of type integer, and ROUND is present with the value true, the result is true if and only if the value of X is an IEEE infinity or NaN, or if the integer nearest X, or the integer of greater magnitude if two integers are equally near to X, is not representable by objects with the type and kind of MOLD. Case(iii): Otherwise, the result is true if and only if the value of X is an IEEE infinity or NaN that is not supported by objects of the type and kind of MOLD, or if X is a finite number and the result of rounding the value of X (according to the IEEE rounding mode if appropriate) to the extended model for the kind of MOLD has magnitude larger than that of the largest finite number with the same sign as X that is representable by objects with the type and kind of MOLD. Examples. If INT8 is the kind value for an 8-bit binary integer type, OUT_OF_RANGE (−128.5, 0_INT8) will have the value false and OUT_OF_RANGE (−128.5, 0_INT8, .TRUE.) will have the value true.
[Bug fortran/107996] ICE in gfc_walk_array_ref, at fortran/trans-array.cc:11429
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107996 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2024-07-02 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from anlauf at gcc dot gnu.org --- The testcase in comment#0 is rejected since gcc-14 (but still ICEs in gcc-13): pr107996-z1.f90:3:31: 3 | print *, [character(size(a(:))) :: 'a'] | 1 Error: Scalar variable 'a' has an array reference at (1) The testcases in comment#1 however still fail with a bogus error.
[Bug fortran/115700] [11/12/13/14 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 Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #5 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2024-July/060625.html What the patch does not address is substring references, e.g. associate (tmp4 => x(:)(1:)) if (len (tmp4) /= len (x)) stop 4 end associate I looked at resolve_assoc_var, at the block: /* Fix up the type-spec for CHARACTER types. */ creating a new string length and setting sym->ts.deferred = 1; but could not find suitable restrictions so that no regression occurs. Maybe gfc_conv_expr_descriptor is another place: /* Set the string_length for a character array. */ but gfc_get_expr_charlen (expr) returns a non_lvalue_expr, so this fails for me sooner or later.
[Bug fortran/115700] [11/12/13/14 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 CC||pault at gcc dot gnu.org --- Comment #3 from anlauf at gcc dot gnu.org --- Adding Paul (sorry!), as he knows the associate stuff much better than me.
[Bug fortran/115700] [11/12/13/14 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 CC||anlauf at gcc dot gnu.org --- Comment #2 from anlauf at gcc dot gnu.org --- Created attachment 58553 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58553=edit Draft patch Very hackish patch that sets the character length of the selector at the beginning of the associate block if the target is a variable and thus is known in advance. Not sure if this is the right approach, but it fixes the testcase.
[Bug fortran/115711] Fortran: extra malloc and copy with transfer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115711 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #1 from anlauf at gcc dot gnu.org --- Interesting. At -Ofast and on Skylake, the optimized tree has for the second variant: A.20_11 = __builtin_alloca_with_align (32, 64); and I do not see a call to malloc in the assembler, but at -O3 -mavx2: _9 = __builtin_malloc (32); which is visible in the assembler. Similar findings apply to subroutine foo3(a,b,n) integer, intent(in) :: n complex(kind(1d0)) ::a(n) real(kind(1d0)) ::b(2*n) b=transfer(a,b) end So the questions are: which option of -Ofast does enable the use of alloca, and what can be done to merge the memcpy? Is it potential aliasing/overlap?
[Bug fortran/114019] allocation with source of deferred character length entity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114019 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-15, and backported to 14-branch. Closing. Might be backportable to 13-branch, but not tested.
[Bug fortran/114019] allocation with source of deferred character length entity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114019 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #3 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2024-June/060609.html
[Bug fortran/115689] Missed deallocation before exit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115689 --- Comment #5 from anlauf at gcc dot gnu.org --- (In reply to Jerry DeLisle from comment #4) > (In reply to kargls from comment #3) > > The code you posted is standard conforming, and when > > compiled, executes as expected. > > > > My point is that the program is exiting. The operate system will > > reap the process and reclaim the memory. Valgrind need not warn > > about this. It is just noise. It is not a memory leak. If anything > > it is poor programming on the part of the person that wrote the > > code, and arguably a bug the code. > > > > I agree completely, I would prefer that programmers explicitly deallocate. That's what I do in runtime tests (unless I forget to). > I simply do not know what our expectations should be when testing. Maybe in > this case it is a don't care. I posted the question for clarification from > others. Running the program from comment#0 - compiled with ifx - under valgrind gives here: ==12826== HEAP SUMMARY: ==12826== in use at exit: 60 bytes in 1 blocks ==12826== total heap usage: 13 allocs, 12 frees, 12,926 bytes allocated ==12826== ==12826== LEAK SUMMARY: ==12826==definitely lost: 0 bytes in 0 blocks ==12826==indirectly lost: 0 bytes in 0 blocks ==12826== possibly lost: 60 bytes in 1 blocks But as Steve pointed out: this is irrelevant, just a hint to the programmer.
[Bug fortran/104130] [12/13 Regression] ICE in gfc_add_class_array_ref, at fortran/class.c:274 since r12-4467-g64f9623765da3306
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104130 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 Andre Vehreschild from comment #7) > ifort/ifx (2024.1.2) accepts the code. Well, Intel rejects a bare call s(z) so it should also reject call s(transpose(z)) for multiple reasons. Intel still has a couple of issues with unlimited polymorphism. > My fortran is not very good, but I would expect either a select around the > call to `s` or needing `x` to be of `class(*)`. The latter is what the > changed example errors with: Right. A correct version would be: program p class(*), pointer :: z(:,:) select type (z) type is (integer) call s(z) call s(transpose(z)) end select contains subroutine s(x) bind(c) integer, contiguous :: x(:,:) end end This is happily accepted by all gfortran >= 12. Updating keywords from ice-on-valid-code to ice-on-invalid-code.
[Bug fortran/114019] allocation with source of deferred character length entity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114019
--- Comment #2 from anlauf at gcc dot gnu.org ---
The following - seemingly hackish - change fixes the ICE:
diff --git a/gcc/fortran/trans-stmt.cc b/gcc/fortran/trans-stmt.cc
index 93b633e212e..60275e18867 100644
--- a/gcc/fortran/trans-stmt.cc
+++ b/gcc/fortran/trans-stmt.cc
@@ -6464,7 +6464,10 @@ gfc_trans_allocate (gfc_code * code, gfc_omp_namelist
*omp_allocate)
else if (se.expr != NULL_TREE && temp_var_needed)
{
tree var, desc;
- tmp = GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (se.expr)) || is_coarray ?
+ tmp = (GFC_DESCRIPTOR_TYPE_P (TREE_TYPE (se.expr))
+|| is_coarray
+|| (code->expr3->ts.type == BT_CHARACTER
+&& code->expr3->rank == 0)) ?
se.expr
: build_fold_indirect_ref_loc (input_location, se.expr);
For reasons I do not see the case of source being a scalar character
expression, where we already have created se as a reference a few lines
further up in the code, is not handled by the original code.
This regtests cleanly.
Is there a better solution?
[Bug fortran/55978] class_optional_2.f90 -Os fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55978
--- Comment #33 from anlauf at gcc dot gnu.org ---
I've been repeatedly struggling with the testcase in comment#19.
Since the dump-tree did not reveal anything, I ran a reduced version
under gdb to see why the code crashes at -O0 and -Og but not at higher
optimization. I got them impression that the dump-tree does not tell
the full truth: subroutine one has
{
struct array01_integer(kind=4) * D.4292;
D.4292 = x != 0B ? (struct array01_integer(kind=4) *)
_gfortran_internal_pack (x) : 0B;
two (D.4292);
if (x != 0B && (integer(kind=4)[0:] *) x->data != (integer(kind=4)[0:] *)
D.4292)
{
_gfortran_internal_unpack (x, D.4292);
__builtin_free ((void *) D.4292);
}
}
but to my untrained eye it looked like the test x->data != D.4292 was
executed before x != 0B. This lead me to the following tentative patch:
diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index 19d69aec9c0..06bfea1f461 100644
--- a/gcc/fortran/trans-array.cc
+++ b/gcc/fortran/trans-array.cc
@@ -9025,7 +9100,7 @@ gfc_conv_array_parameter (gfc_se * se, gfc_expr * expr,
bool g77,
fold_convert (TREE_TYPE (tmp), ptr), tmp);
if (fsym && fsym->attr.optional && sym && sym->attr.optional)
- tmp = fold_build2_loc (input_location, TRUTH_AND_EXPR,
+ tmp = fold_build2_loc (input_location, TRUTH_ANDIF_EXPR,
logical_type_node,
gfc_conv_expr_present (sym), tmp);
Strangely enough, this gives exactly the same dump-tree!
(If someone knows why, please enlighten me!)
But it fixed the issue.
The I looked at the optimized tree. The reference version has:
[local count: 1073741824]:
# _5 = PHI <_19(3), y_17(D)(2)>
two (_5);
_1 = y_17(D) != 0B;
_2 = y_17(D)->data;
_3 = _2 != _5;
_4 = _1 & _3;
if (_4 != 0)
goto ; [33.00%]
else
goto ; [67.00%]
[local count: 354334800]:
__builtin_free (_5);
This explains the "boom".
The version with the ANDIF has:
[local count: 1073741824]:
# _2 = PHI <_16(3), y_14(D)(2)>
two (_2);
if (y_14(D) != 0B)
goto ; [70.00%]
else
goto ; [30.00%]
[local count: 751619280]:
_1 = y_14(D)->data;
if (_1 != _2)
goto ; [53.47%]
else
goto ; [46.53%]
[local count: 401890828]:
__builtin_free (_2);
This looks sane to me: the data component is not referenced if the dummy
is seen to be absent.
Regtesting...
[Bug fortran/83865] ICE in wide_int_to_tree_1, at tree.c:1567
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83865 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |13.4 Status|NEW |RESOLVED --- Comment #10 from anlauf at gcc dot gnu.org --- Fixed.
[Bug fortran/115390] Bogus -Wuninitialized warning when using CHARACTER(*) argument in BIND(C) function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115390 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from anlauf at gcc dot gnu.org --- Fixed.
[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639 Bug 24639 depends on bug 115390, which changed state. Bug 115390 Summary: Bogus -Wuninitialized warning when using CHARACTER(*) argument in BIND(C) function https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115390 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/115390] Bogus -Wuninitialized warning when using CHARACTER(*) argument in BIND(C) function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115390 anlauf at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #4 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2024-June/060591.html
[Bug fortran/115390] Bogus -Wuninitialized warning when using CHARACTER(*) argument in BIND(C) function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115390
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 ---
Created attachment 58455
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58455=edit
Patch
The attached patch fixes the ordering such that the bogus warning does no
longer appear and gives for the reduced test:
__attribute__((fn spec (". r ")))
void bar (struct CFI_cdesc_t00 & restrict _s)
{
integer(kind=8) s.0;
character(kind=1)[1:s.0] * s;
bitsizetype D.4279;
sizetype D.4280;
s.0 = (integer(kind=8)) _s->elem_len;
D.4279 = (bitsizetype) (sizetype) NON_LVALUE_EXPR * 8;
D.4280 = (sizetype) NON_LVALUE_EXPR ;
s = (character(kind=1)[1:s.0] *) _s->base_addr;
foo ((character(kind=1)[1:s.0] *) s, s.0);
}
Currently regtesting ...
[Bug fortran/115401] valgrind error in gfc_class_len_get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115401 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2024-06-09 Ever confirmed|0 |1 Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW --- Comment #1 from anlauf at gcc dot gnu.org --- Reduced testcase which ICEs here: module m implicit none type :: t1 integer :: a end type contains function copy(a) result(ty) class(t1), allocatable :: ty(:) integer, intent(in) :: a allocate(t1::ty(a)) ty%a = 1 end function subroutine test() ! class(t1), allocatable :: up(:) ! OK class(*), allocatable :: up(:) ! ICE allocate(up(10), source=copy(10)) end subroutine end module
[Bug fortran/115348] [13/14/15 Regression] -fcheck=recursion issue with intent(out) derived type argument without components with default value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115348 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to fail||15.0 Priority|P3 |P4 Summary|-fcheck=recursion issue |[13/14/15 Regression] |with intent(out) derived|-fcheck=recursion issue |type argument without |with intent(out) derived |components with default |type argument without |value |components with default ||value Ever confirmed|0 |1 Last reconfirmed||2024-06-08 --- Comment #2 from anlauf at gcc dot gnu.org --- Confirmed. Workarounds: - add "recursive" attribute to subroutine myroutine - add a default initialization to component mynumber Might be related to pr115070.
[Bug fortran/107141] ICE: Segmentation fault (in contains_struct_check)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107141 --- Comment #6 from anlauf at gcc dot gnu.org --- (In reply to David Binderman from comment #5) > Bit more detail from valgrind: > > /Lower/derived-type-finalization.f90 > ==687074== Invalid read of size 8 > ==687074==at 0x856D97: gfc_class_len_get(tree_node*) (trans-expr.cc:273) > ==687074==by 0x86F37B: trans_class_vptr_len_assignment(stmtblock_t*, > gfc_expr*, gfc_expr*, gfc_se*, tree_node**, tree_node**, tree_node**) > (trans-expr.cc:10169) Judging from the name of the testcase this could be a quite different issue. Please open a separate PR and attach the source there.
[Bug fortran/115390] Bogus -Wuninitialized warning when using CHARACTER(*) argument in BIND(C) function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115390
--- Comment #2 from anlauf at gcc dot gnu.org ---
Slightly rewritten (we only need the interface of foo):
module test
implicit none
interface
subroutine foo(s)
character(*), intent(in) :: s
end subroutine foo
end interface
contains
subroutine bar(s) bind(c)
character(*), intent(in) :: s
call foo(s)
end
end
This gives:
__attribute__((fn spec (". r ")))
void bar (struct CFI_cdesc_t00 & restrict _s)
{
integer(kind=8) s.0;
character(kind=1)[1:s.0] * s;
bitsizetype D.4279;
sizetype D.4280;
D.4279 = (bitsizetype) (sizetype) NON_LVALUE_EXPR * 8;
D.4280 = (sizetype) NON_LVALUE_EXPR ;
s.0 = (integer(kind=8)) _s->elem_len;
s = (character(kind=1)[1:s.0] *) _s->base_addr;
foo ((character(kind=1)[1:s.0] *) s, s.0);
}
[Bug fortran/114019] allocation with source of deferred character length entity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114019
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Last reconfirmed||2024-06-07
Keywords||ice-on-valid-code
CC||anlauf at gcc dot gnu.org
--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed. Reduced testcase:
subroutine s
character(1) :: w = "4"
character(:), pointer :: chr_pointer
allocate (chr_pointer, source="123"//w ) ! ICE at -O0,-Og
! allocate (chr_pointer, source=adjustl("123"//w) ) ! ICE at -O0,-Og
! allocate (chr_pointer, source=trim ("123"//w) ) ! OK
! allocate (chr_pointer, source=repeat ("123"//w,1)) ! OK
end
In the indicated cases where we ICE at -O0 or -Og the length of source
is determined to be 4 at compile time, in the others it is an expression.
Setting a breakpoint in gfc_allocate_using_malloc:
(gdb) p debug_tree(size)
constant 4>
I do not see anything being obviously wrong with the dump-tree...
[Bug fortran/115260] Corruption of derived type data when array temporarys of type occur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115260 --- Comment #3 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #2) > Created attachment 58346 [details] > Reduced testcase > > Reduced for subsequent analysis. Further datapoint: replacing the dummy argument type(field_type), intent(inout) :: fieldset(1:4) by type(field_type), contiguous:: fieldset( : ) always leads to corruption.
[Bug fortran/115260] Corruption of derived type data when array temporarys of type occur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115260 --- Comment #2 from anlauf at gcc dot gnu.org --- Created attachment 58346 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58346=edit Reduced testcase Reduced for subsequent analysis.
[Bug fortran/83865] ICE in wide_int_to_tree_1, at tree.c:1567
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83865 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #6 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2024-June/060544.html
[Bug fortran/83865] ICE in wide_int_to_tree_1, at tree.c:1567
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83865
--- Comment #5 from anlauf at gcc dot gnu.org ---
The ICE is fixed by:
diff --git a/gcc/fortran/trans-stmt.cc b/gcc/fortran/trans-stmt.cc
index 9b497d6bdc6..605107b5168 100644
--- a/gcc/fortran/trans-stmt.cc
+++ b/gcc/fortran/trans-stmt.cc
@@ -6451,6 +6451,7 @@ gfc_trans_allocate (gfc_code * code, gfc_omp_namelist
*omp_allocate)
/* Special case when string in expr3 is zero. */
if (code->expr3->ts.type == BT_CHARACTER
+ && code->expr3->rank == 0
&& integer_zerop (se.string_length))
{
gfc_init_se (, NULL);
Needs further testing.
[Bug fortran/115315] [PDT] valgrind error in gfc_simplify_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115315
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
Summary|valgrind error in |[PDT] valgrind error in
|gfc_simplify_expr |gfc_simplify_expr
Priority|P3 |P4
Last reconfirmed||2024-06-01
--- Comment #1 from anlauf at gcc dot gnu.org ---
Reduced testcase:
subroutine p2
type t1(n1,n2)
integer,kind :: n1,n2
integer :: c2(iachar('ABCDEFGHIJ'(n1:n1)))
end type
end
The current implementation is known to be incomplete.
[Bug fortran/104130] [12/13 Regression] ICE in gfc_add_class_array_ref, at fortran/class.c:274 since r12-4467-g64f9623765da3306
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104130 anlauf at gcc dot gnu.org changed: What|Removed |Added Known to fail||12.3.1, 13.3.0 Known to work||14.1.0, 15.0 CC||anlauf at gcc dot gnu.org Summary|[12/13/14/15 Regression]|[12/13 Regression] ICE in |ICE in |gfc_add_class_array_ref, at |gfc_add_class_array_ref, at |fortran/class.c:274 since |fortran/class.c:274 since |r12-4467-g64f9623765da3306 |r12-4467-g64f9623765da3306 | --- Comment #5 from anlauf at gcc dot gnu.org --- I doubt that the code is valid. NAG rejects it: NAG Fortran Compiler Release 7.2(Shin-Urayasu) Build 7200 Warning: pr104130.f90, line 7: Unused dummy variable X Error: pr104130.f90, line 3: Incorrect data type CLASS(*) (expected INTEGER) for argument X (no. 1) of S Starting with r14-870, the testcase is also rejected by gfortran: pr104130.f90:3:9: 3 | call s(transpose(z)) | 1 Error: Unlimited polymorphic actual argument at (1) is not matched with either an unlimited polymorphic or assumed type dummy argument Updating known-to-work.
[Bug fortran/103139] [12/13/14/15 Regression] ICE in fold_convert_loc, at fold-const.c:2573 since r12-4464-g017665f63047ce47
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103139 anlauf at gcc dot gnu.org changed: What|Removed |Added Known to fail||11.4.1, 12.3.1, 13.3.0 Known to work||14.1.0, 15.0 --- Comment #6 from anlauf at gcc dot gnu.org --- Seems to be fixed in gcc-14 and later. Adjusting known-to-work.
[Bug fortran/115260] Corruption of derived type data when array temporarys of type occur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115260 anlauf at gcc dot gnu.org changed: What|Removed |Added Known to work||9.5.0 Last reconfirmed||2024-05-28 Priority|P3 |P4 Known to fail||10.5.0, 11.4.0, 12.3.0, ||13.3.0, 14.1.0, 15.0 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Keywords||wrong-code --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. The tree-dump suggests that the unpack frees the component arrays data, idata so that the final prints access freed memory. In the testcase this only happens for the explicit-size dummies when they are intent(inout), but not for intent(in).
[Bug fortran/102619] [11/12/13/14/15 Regression] ICE in gfc_conv_descriptor_dtype, at fortran/trans-array.c:215 since r9-6493-g0e3088806577e805
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102619 --- Comment #6 from anlauf at gcc dot gnu.org --- Created attachment 58302 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58302=edit Partial patch This change prevents the ICE and leads to a correct shape of the function result for the following testcase: program p implicit none real :: w(2,3) real, allocatable :: y(:) y = h(w) print *, size (y) ! Should print 6 print *, y deallocate (y) contains function h(x) result (g) real :: x(..) real :: g(product(shape(x))) integer :: i print *, shape (x) print *, size (g) g = [(real(i),i=1,size(g))] print *, g end end After the patch this prints: 2 3 6 1. 2. 3. 4. 5. 6. 1 1. So the function result is not allocated correctly.
[Bug fortran/102619] [11/12/13/14/15 Regression] ICE in gfc_conv_descriptor_dtype, at fortran/trans-array.c:215 since r9-6493-g0e3088806577e805
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102619
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--- Comment #5 from anlauf at gcc dot gnu.org ---
The ICE occurs for both SUM and PRODUCT of SHAPE,LBOUND,UBOUND of the
assumed-rank dummy.
The ICE points to gfc_conv_intrinsic_arith:
4929 gfc_conv_ss_startstride ();
The difference between assumed-shape vs. assumed-rank argument is:
(gdb) p *loop->ss->info->expr->shape->_mp_d
$86 = 1
vs.
(gdb) p loop->ss->info->expr->shape
$88 = (mpz_t *) 0x0
Now gfc_conv_ss_startstride should be able to handle assumed-rank,
but then we die here:
(gdb) l 4811,4826
4811arg = expr->value.function.actual->expr;
4812if (arg->rank == -1)
4813 {
4814gfc_se se;
4815tree rank, tmp;
4816
4817/* The rank (hence the return value's shape) is
unknown,
4818 we have to retrieve it. */
4819gfc_init_se (, NULL);
4820se.descriptor_only = 1;
4821gfc_conv_expr (, arg);
4822/* This is a bare variable, so there is no
preliminary
4823 or cleanup code. */
4824gcc_assert (se.pre.head == NULL_TREE
4825&& se.post.head == NULL_TREE);
4826rank = gfc_conv_descriptor_rank (se.expr);
[Bug fortran/115107] f951: internal compiler error: Segmentation fault 0xcf878f crash_signal toplev.cc:314
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115107 --- Comment #16 from anlauf at gcc dot gnu.org --- (In reply to Natalie Perlin from comment #15) > Quick update: > > Software stack and model build with gnu/13.3.0 was clear from all previous > issues! So issue with the gnu/13.x.0 compiler could be considered as fixed, > thank you so much for the help here. Good! > Build with gnu/14.1.0 generated more ICEs, however. > FYI, the compiler errors looked as following: > > - > ...register_variable_attribute.inc:56:60: > > internal compiler error: in gfc_walk_array_ref, at > fortran/trans-array.cc:11870 > 0x75dffb gfc_walk_array_ref(gfc_ss*, gfc_expr*, gfc_ref*) > ../../gcc/fortran/trans-array.cc:11870 > 0x8d5f90 gfc_walk_expr(gfc_expr*) > ../../gcc/fortran/trans-array.cc:12232 > 0x75dffb gfc_walk_array_ref(gfc_ss*, gfc_expr*, gfc_ref*) > ../../gcc/fortran/trans-array.cc:11870 > 0x8d5f90 gfc_walk_expr(gfc_expr*) > ../../gcc/fortran/trans-array.cc:12232 > 0x8fb2c8 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*, > gfc_expr*, vec*) > ../../gcc/fortran/trans-expr.cc:6578 > 0x8fb2c8 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*, > gfc_expr*, vec*) > ../../gcc/fortran/trans-expr.cc:6578 > 0x90c46a gfc_conv_expr_reference(gfc_se*, gfc_expr*) > ../../gcc/fortran/trans-expr.cc:9979 > 0x8fd2f4 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*, > gfc_expr*, vec*) > ../../gcc/fortran/trans-expr.cc:6756 > 0x90f4b8 gfc_trans_assignment_1 > ../../gcc/fortran/trans-expr.cc:12287 > 0x90c46a gfc_conv_expr_reference(gfc_se*, gfc_expr*) > ../../gcc/fortran/trans-expr.cc:9979 > 0x8fd2f4 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*, > gfc_expr*, vec*) > ../../gcc/fortran/trans-expr.cc:6756 > 0x90f4b8 gfc_trans_assignment_1 > ../../gcc/fortran/trans-expr.cc:12287 > 0x8c3897 trans_code > ... > ... (more diagnostic prints) > ... > Please submit a full bug report, with preprocessed source (by using > -freport-bug). > Please include the complete backtrace with any bug report. > See <https://gcc.gnu.org/bugs/> for instructions. > 0x8657ad translate_all_program_units > ../../gcc/fortran/parse.cc:7086 > Please submit a full bug report, with preprocessed source (by using > -freport-bug). > Well, that is a different traceback and likely a different error. Can you provide a reduced reproducer? As you write, the ICE does not occur in 13.3 but is new at 14.1, so having the new bug in a different PR might make it easier to track than keeping it here.
[Bug fortran/93635] Get ICE instead of error message if user incorrectly equivalences allocateable variables that are in a NAMELIST group
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93635 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #9 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-15.
[Bug fortran/27766] [meta-bug] -fbounds-check related bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27766 Bug 27766 depends on bug 86100, which changed state. Bug 86100 Summary: Spurious error with -fcheck=bounds and allocatable class(*) array components https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86100 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/86100] Spurious error with -fcheck=bounds and allocatable class(*) array components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86100 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|--- |14.2 Status|NEW |RESOLVED --- Comment #7 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-15, and backported to 14-branch. Closing. Thanks for the report, and sorry that it took so long to fix.
[Bug fortran/103368] [11/12/13 Regression] ICE in gimplify_expr, at gimplify.c:15668 since r12-4464-g017665f63047ce47
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103368 --- Comment #9 from anlauf at gcc dot gnu.org --- (In reply to paul.richard.tho...@gmail.com from comment #8) > I simply copied all the associated functions in trans-expr.cc from mainline > and plonked them in 13-branch. That's why I said that I hadn't done any > weeding. There is also a commit from Jakub in there as well. I'll check to > see if the associated PRs are fixed. > > I got into regression fixing before the 14.1 release and this was one of > the low hanging fruit. To be honest, I am not especially bothered about > fixing it or not. Up until the ICE of the PR it was giving an error on > valid code. I would prefer though that the ICE went away! Well, if the ICE is resolved and there is no regression, go ahead. The commits I mentioned on 14-branch address some more, so it may be a waste of time to see if any issue was fixed along the way.
[Bug fortran/103368] [11/12/13 Regression] ICE in gimplify_expr, at gimplify.c:15668 since r12-4464-g017665f63047ce47
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103368 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 Paul Thomas from comment #6) > Created attachment 58277 [details] > Fix for this PR > > This was substantially fixed on 14-branch by the patch for PR49213. However, > there have been many subsequent changes to gfc_trans_structure_assign and > its subsidiary functions as the attachment demonstrates. > > I haven't attempted to do any weeding of the changes to separate those > responsible for fixing this PR. However, 13-branch regtests successfuly with > the patch applied. > > Should I commit this with a testcase or just close the PR? > > Paul Paul, can you summarize where you gathered the pieces of this patch from? >From a quick glance, r14-870 and r14-2160 (both yours) seem to be involved. Does it also fix any of the issues addressed by the respective PRs?
[Bug fortran/114827] Valgrind reports errors with class(*) assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |13.4 --- Comment #16 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #14) > Backporting to 13-branch requires backporting of r14-5931-gb247e917ff1332, > see pr110415. After a successful backport of the above, the present patch also applied smoothly to 13-branch. Closing. Thanks for the report!
[Bug fortran/110415] (Re)allocation on assignment to allocatable polymorphic variable from allocatable polymorphic function result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110415 anlauf at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |13.4 --- Comment #8 from anlauf at gcc dot gnu.org --- Backported to 13-branch after encouragement by Tobias off-list.
[Bug fortran/115193] using indices with character type within a select type causes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115193 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED Keywords|wrong-code |ice-on-valid-code --- Comment #2 from anlauf at gcc dot gnu.org --- This bug has already been reported as pr114874 and just been fixed last week. *** This bug has been marked as a duplicate of bug 114874 ***
[Bug fortran/114874] [14/15 Regression] ICE with select type, type is (character(*)), and substring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114874 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||ryan.mulhall at noaa dot gov --- Comment #12 from anlauf at gcc dot gnu.org --- *** Bug 115193 has been marked as a duplicate of this bug. ***
[Bug fortran/115107] f951: internal compiler error: Segmentation fault 0xcf878f crash_signal toplev.cc:314
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115107
--- Comment #14 from anlauf at gcc dot gnu.org ---
(In reply to Natalie Perlin from comment #9)
> All rebuilt, gnu/14.1.0 with openmpi/4.1.6, revised configuration of the
> software stack (spack-stack). Still the same error with
> [-Wimplicit-function-declaration].
>
> Verified a build of the same stack with gnu/13.2.0 and openmpi/4.1.6. The
> same location in the code gives warning, instead of the error, during the
> build. Same package, different version of gcc. Please see below snippets of
> the builds:
>
> 1. Build with gnu/13.2.0 gives the following:
> ---
> ...
> /scratch2/NCEPDEV/stmp1/role.epic/spack-stack/spack-stack-1.6.0/spack/lib/
> spack/env/gcc/gcc -DHAVE_CONFIG_H -I. -I.
> -I../../../src/libjasper/include/jasper -I../../../src/libjasper/include -g
> -O2 -MT jas_getopt.lo -MD -MP -MF .deps/jas_getopt.Tpo -c jas_getopt.c -o
> jas_getopt.o
> jas_getopt.c: In function 'jas_getopt':
> jas_getopt.c:129:49: warning: implicit declaration of function
> 'jas_eprintf'; did you mean 'vsnprintf'? [-Wimplicit-function-declaration]
> 129 | jas_eprintf("unknown
> long option %s\n", s);
> | ^~~
> | vsnprintf
> ...
> ---
>
> 2. Build with gnu/14.1.0 gives the following:
> ---
> ...
> /scratch2/NCEPDEV/stmp1/role.epic/spack-stack/spack-stack-1.6.0_gnu14/spack/
> lib/spack/env/gcc/gcc -DHAVE_CONFIG_H -I. -I.
> -I../../../src/libjasper/include/jasper -I../../../src/libjasper/include -g
> -O2 -MT jas_getopt.lo -MD -MP -MF .deps/jas_getopt.Tpo -c jas_getopt.c -o
> jas_getopt.o
> jas_getopt.c: In function 'jas_getopt':
> jas_getopt.c:129:49: error: implicit declaration of function 'jas_eprintf';
> did you mean 'vsnprintf'? [-Wimplicit-function-declaration]
> 129 | jas_eprintf("unknown
> long option %s\n", s);
> | ^~~
> | vsnprintf
> make[4]: *** [Makefile:349: jas_getopt.lo] Error 1
> ...
> ---
>
> Any suggestions?..
The original jasper files look fine to me:
https://github.com/jasper-software/jasper/blob/master/src/libjasper/base/jas_getopt.c
which includes
https://github.com/jasper-software/jasper/blob/master/src/libjasper/include/jasper/jas_debug.h
Looks like spack either does not generate proper include paths, or a
bad include file is found.
> Has a version of gnu/13.3.0 become available that might have the ICE fix?..
See https://gcc.gnu.org/gcc-13/ .
[Bug fortran/114827] Valgrind reports errors with class(*) assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827 --- Comment #14 from anlauf at gcc dot gnu.org --- Backporting to 13-branch requires backporting of r14-5931-gb247e917ff1332, see pr110415.
[Bug fortran/110415] (Re)allocation on assignment to allocatable polymorphic variable from allocatable polymorphic function result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110415 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 Andrew Jenner from comment #5) > Fixed on mainline and OG13. I will apply the commit to GCC 13 after the > grace period. This never happened... Are you still planning to do it?
[Bug fortran/115039] Statement function with inquiry refs rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115039 anlauf at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |13.4 Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from anlauf at gcc dot gnu.org --- Fixed in gcc-15, and backported to 14.2 and 13.4.
[Bug fortran/115107] f951: internal compiler error: Segmentation fault 0xcf878f crash_signal toplev.cc:314
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115107
--- Comment #7 from anlauf at gcc dot gnu.org ---
(In reply to Natalie Perlin from comment #6)
> (In reply to anlauf from comment #3)
> > The traceback is essentially identical to that in pr114467.
> >
> > Can you please try the 14-release like the other reporter, or the upcoming
> > 13.3 release next week?
>
> Thank you for the comment. Yes, this indeed looks similar to pr114467.
> I did try to use gnu/14.1.0 + openmpi/4.1.6, but was not able to build a
> software stack needed for building the model that produced the original
> error.
>
> The issue with the gnu/14.1.0 compiler was that it produced an error where
> the gnu/13.2.0 had only a warning. The error with the gnu/14.1.0 compiler
> was as shown below, and is related to -Wimplicit-function-declaration.
> Could it be that a certain compiler flag helps to avoid such an error?..
>
>
> And yes, I'd gladly try the upcoming v13.3 release next week!
>
>
> ===
> /scratch2/NCEPDEV/stmp1/role.epic/spack-stack/spack-stack-1.6.0_gnu14/spack/
> lib/spack/env/gcc/gcc -DHAVE_CONFIG_H -I. -I.
> -I../../../src/libjasper/include/jasper -I../../../src/libjasper/include -g
> -O2 -MT jas_getopt.lo -MD -MP -MF .deps/jas_getopt.Tpo -c jas_getopt.c -o
> jas_getopt.o
> jas_getopt.c: In function 'jas_getopt':
> jas_getopt.c:129:49: error: implicit declaration of function 'jas_eprintf';
> did you mean 'vsnprintf'? [-Wimplicit-function-declaration]
> 129 | jas_eprintf("unknown
> long option %s\n", s);
> | ^~~
> | vsnprintf
> make[4]: *** [Makefile:349: jas_getopt.lo] Error 1
> =
This looks like the header file jas_debug.h is not found or not included.
(On my Linux system it is /usr/include/jasper/jas_debug.h).
[Bug fortran/115107] f951: internal compiler error: Segmentation fault 0xcf878f crash_signal toplev.cc:314
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115107 --- Comment #3 from anlauf at gcc dot gnu.org --- The traceback is essentially identical to that in pr114467. Can you please try the 14-release like the other reporter, or the upcoming 13.3 release next week?
[Bug fortran/67740] Wrong association status of allocatable character pointer in derived types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67740 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||clange001 at gmail dot com --- Comment #15 from anlauf at gcc dot gnu.org --- *** Bug 106317 has been marked as a duplicate of this bug. ***
[Bug fortran/106317] deferred-length character array pointer in derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106317 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #2 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #1) > Confirmed to fail on 13-branch at r13-7813, but working at r13-8592. > > Also 14-mainline is ok, so must have been fixed there and backported, > possibly as r13-7986. Indeed a duplicate of 67740. Thus fixed in 13.3 and later. *** This bug has been marked as a duplicate of bug 67740 ***
[Bug fortran/86100] Spurious error with -fcheck=bounds and allocatable class(*) array components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86100 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Keywords||wrong-code --- Comment #4 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2024-May/060512.html
[Bug fortran/115070] [13/14/15 Regression] ICE using IEEE_ARITHMETIC in a derived type method with class, intent(out)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115070 --- Comment #2 from anlauf at gcc dot gnu.org --- Replacing the scalar argument 'obs' by something with rank > 0 avoids the ICE, but then assumed-rank is not accepted with intent(out). Another bug...
[Bug fortran/115070] [13/14/15 Regression] ICE using IEEE_ARITHMETIC in a derived type method with class, intent(out)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115070 anlauf at gcc dot gnu.org changed: What|Removed |Added Known to work||12.3.1 Ever confirmed|0 |1 Target Milestone|--- |13.3 Priority|P3 |P4 Last reconfirmed||2024-05-13 Known to fail||13.2.1, 14.1.0, 15.0 Summary|ICE using IEEE_ARITHMETIC |[13/14/15 Regression] ICE |in a derived type method|using IEEE_ARITHMETIC in a |with intent(out) statement |derived type method with ||class, intent(out) Status|UNCONFIRMED |NEW --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed as a regression. 12-branch works here, current 13-branch fails. Replacing class by type also avoids the ICE.
[Bug fortran/115072] Memory leak with unlimited polymorphic function result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115072 anlauf at gcc dot gnu.org changed: What|Removed |Added Summary|Memory link with unlimited |Memory leak with unlimited |polymorphic function result |polymorphic function result Priority|P3 |P4 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||anlauf at gcc dot gnu.org Last reconfirmed||2024-05-13 --- Comment #1 from anlauf at gcc dot gnu.org --- Runtime memleak confirmed, also seen with -fsanitize=address . Affects all versions up to 15-mainline.
[Bug fortran/115039] Statement function with inquiry refs rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115039 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #1 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2024-May/060500.html
[Bug fortran/115039] Statement function with inquiry refs rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115039 anlauf at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Keywords||rejects-valid
[Bug fortran/115039] New: Statement function with inquiry refs rejected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115039 Bug ID: 115039 Summary: Statement function with inquiry refs rejected Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: anlauf at gcc dot gnu.org Target Milestone: --- As reported in: https://fortran-lang.discourse.group/t/real-and-imaginary-parts-of-complex-number/1113/18 an inquiry reference (%re, %im) is incorrectly reported as a recursive reference. Testcase: program testit implicit none complex :: x real:: img img(x) = x%im write (*, *) img((1.0,3.0) + (2.0,4.0)) end program testit Tentative fix: diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc index 66edad58278..94ec2ce21dd 100644 --- a/gcc/fortran/expr.cc +++ b/gcc/fortran/expr.cc @@ -5500,7 +5546,8 @@ gfc_traverse_expr (gfc_expr *expr, gfc_symbol *sym, break; case REF_INQUIRY: - return true; + /* An inquiry_ref does not collide with a symbol. */ + return false; default: gcc_unreachable ();
[Bug fortran/86100] Spurious error with -fcheck=bounds and allocatable class(*) array components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86100 --- Comment #3 from anlauf at gcc dot gnu.org --- The code fragment in comment#2 was added in r7-3760-g92c5266bbd5378.
[Bug fortran/86100] Spurious error with -fcheck=bounds and allocatable class(*) array components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86100
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--- Comment #2 from anlauf at gcc dot gnu.org ---
The problem seems to generally occur for class components of derived types.
program p
implicit none
type t
integer :: i = 0
end type t
type any_matrix
class(t), allocatable :: m(:,:)
end type any_matrix
type(any_matrix) :: a, b
allocate(a%m(3,4))
call foo ()
contains
subroutine foo ()
b = a ! Array bound mismatch for dimension 1 of array '<>'
(12/3)
!b%m = a%m ! no runtime error with -fcheck=bounds
end subroutine foo
end
This fails as indicated.
Note that 12=3*4 is the total size of the array, and 3 is the size of the
first dimension, which - along with the '<>' - points to
gfc_copy_class_to_class:
from_len = gfc_conv_descriptor_size (from_data, 1);
from_len = fold_convert (TREE_TYPE (orig_nelems), from_len);
tmp = fold_build2_loc (input_location, NE_EXPR,
logical_type_node, from_len, orig_nelems);
msg = xasprintf ("Array bound mismatch for dimension %d "
"of array '%s' (%%ld/%%ld)",
1, name);
gfc_trans_runtime_check (true, false, tmp, ,
_current_locus, msg,
fold_convert (long_integer_type_node,
orig_nelems),
fold_convert (long_integer_type_node,
from_len));
So we compare dimension 1 and the full size of the rhs?
Shouldn't we compare lhs and rhs shapes?
[Bug fortran/114922] fsyntax-only need the modules
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114922 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from anlauf at gcc dot gnu.org --- The documentation says: -fsyntax-only Check the code for syntax errors, but do not actually compile it. This will generate module files for each module present in the code, but no other output file. So if you do not provide the needed modules, you should get exactly the same errors as when compiling without -fsyntax-only.
[Bug fortran/114874] [14/15 Regression] ICE with select type, type is (character(*)), and substring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114874 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #3 from anlauf at gcc dot gnu.org --- Adding Paul, hoping that he can tell what changed for SELECT TYPE recently.
[Bug fortran/114874] [14/15 Regression] ICE with select type, type is (character(*)), and substring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114874 --- Comment #2 from anlauf at gcc dot gnu.org --- The dump-fortran-original shows the following difference between 13 and 14: @@ -58,7 +58,7 @@ code: ASSIGN p:c 'abc' - BLOCK + SELECT TYPE symtree: '__tmp_CHARACTER_0_1'|| symbol: '__tmp_CHARACTER_0_1' type spec : (CHARACTER () 1) attributes: (VARIABLE SELECT-TYPE-TEMPORARY ASSOCIATE-VAR) @@ -66,7 +66,7 @@ type spec : (UNKNOWN 0) attributes: (LABEL ) -SELECT TYPE _loc[((p:c % _vptr))] +SELECT CASE _loc[((p:c % _vptr))] CASE (_loc[((p:__vtab_CHARACTER_1_))] 85893463) ASSOCIATE = p:c % _data @@ -74,11 +74,11 @@ type spec : (UNKNOWN 0) attributes: (LABEL ) WRITE UNIT=6 FMT=-1 - TRANSFER block@1:__tmp_CHARACTER_0_1(2:2) + TRANSFER block@1:__tmp_CHARACTER_0_1(UNKNOWN) DT_END END ASSOCIATE END SELECT - END BLOCK + END SELECT TYPE CONTAINS
[Bug fortran/114859] [14/15 Regression] Seeing new segmentation fault in same_type_as since r14-9752
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114859 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code --- Comment #17 from anlauf at gcc dot gnu.org --- For reference: the commit is r15-46-gbca41a8d55e830 commit bca41a8d55e830c882b0f39246afead4fcfae6f7 Author: Paul Thomas Date: Mon Apr 29 11:52:11 2024 +0100 Fortran: Fix regression caused by r14-9752 [PR114959] 2024-04-29 Paul Thomas gcc/fortran PR fortran/114959 * trans-expr.cc (gfc_trans_class_init_assign): Return NULL_TREE if the default initializer has all NULL fields. Guard this by a requirement that the code not be EXEC_INIT_ASSIGN and that the object be an INTENT_OUT dummy. * trans-stmt.cc (gfc_trans_allocate): Change the initializer code for allocate with mold to EXEC_ALLOCATE to allow an initializer with all NULL fields. gcc/testsuite/ PR fortran/114959 * gfortran.dg/pr114959.f90: New test.
[Bug fortran/114827] Valgrind reports errors with class(*) assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827 --- Comment #11 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2024-April/060464.html
[Bug fortran/114827] Valgrind reports errors with class(*) assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827 anlauf at gcc dot gnu.org changed: What|Removed |Added Attachment #58048|0 |1 is obsolete|| Attachment #58056|0 |1 is obsolete|| Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #9 from anlauf at gcc dot gnu.org --- Created attachment 58061 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58061=edit Corrected patch This fixes the issue for scalar and array assignments and does not regress on intrinsic types when compiling with -fsanitize=address.
[Bug fortran/114874] [14/15 Regression] ICE with select type, type is (character(*)), and substring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114874 --- Comment #1 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #0) > The following code fails for me with latest 14-branch/15-release candidate: Oops, I meant: 14-release candidate/15-mainline after branching...
[Bug fortran/114874] [14/15 Regression] ICE with select type, type is (character(*)), and substring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114874 anlauf at gcc dot gnu.org changed: What|Removed |Added Known to work||10.5.0, 11.4.1, 12.3.1, ||13.2.1 Keywords||ice-on-valid-code Priority|P3 |P4
[Bug fortran/114874] New: [14/15 Regression] ICE with select type, type is (character(*)), and substring
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114874 Bug ID: 114874 Summary: [14/15 Regression] ICE with select type, type is (character(*)), and substring Product: gcc Version: 14.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: anlauf at gcc dot gnu.org Target Milestone: --- The following code fails for me with latest 14-branch/15-release candidate: program p implicit none class(*), allocatable :: c c = 'abc' select type (c) type is (character(*)) print *, c print *, c(2:2) ! ICE end select end p __copy_character_1hhh.f90:8:22: 8 | print *, c(2:2) ! ICE | 1 internal compiler error: Segmentation fault 0x10c6f6f crash_signal ../../gcc-14/gcc/toplev.cc:319 0xa7e6f1 gfc_conv_scalarized_array_ref ../../gcc-14/gcc/fortran/trans-array.cc:3938 0xa7f596 gfc_conv_array_ref(gfc_se*, gfc_array_ref*, gfc_expr*, locus*) ../../gcc-14/gcc/fortran/trans-array.cc:4094 0xac25ea gfc_conv_variable ../../gcc-14/gcc/fortran/trans-expr.cc:3181 0xac5be2 gfc_conv_expr_reference(gfc_se*, gfc_expr*) ../../gcc-14/gcc/fortran/trans-expr.cc:9935 0xaf00b6 gfc_trans_transfer(gfc_code*) ../../gcc-14/gcc/fortran/trans-io.cc:2609 0xa73157 trans_code ../../gcc-14/gcc/fortran/trans.cc:2583 0xaed036 build_dt ../../gcc-14/gcc/fortran/trans-io.cc:2053 0xa73177 trans_code ../../gcc-14/gcc/fortran/trans.cc:2555 0xb1471f gfc_trans_block_construct(gfc_code*) ../../gcc-14/gcc/fortran/trans-stmt.cc:2377 0xa73337 trans_code ../../gcc-14/gcc/fortran/trans.cc:2459 0xb0abf7 gfc_trans_select_type_cases ../../gcc-14/gcc/fortran/trans-stmt.cc:3020 0xb15ff4 gfc_trans_select_type(gfc_code*) ../../gcc-14/gcc/fortran/trans-stmt.cc:3729 0xa730a7 trans_code ../../gcc-14/gcc/fortran/trans.cc:2479 0xb1471f gfc_trans_block_construct(gfc_code*) ../../gcc-14/gcc/fortran/trans-stmt.cc:2377 0xa73337 trans_code ../../gcc-14/gcc/fortran/trans.cc:2459 0xaa8ed1 gfc_generate_function_code(gfc_namespace*) ../../gcc-14/gcc/fortran/trans-decl.cc:7880 0xa1b65f translate_all_program_units ../../gcc-14/gcc/fortran/parse.cc:7099 0xa1b65f gfc_parse_file() ../../gcc-14/gcc/fortran/parse.cc:7413 0xa6fe7f gfc_be_parse_file ../../gcc-14/gcc/fortran/f95-lang.cc:241
[Bug fortran/114827] Valgrind reports errors with class(*) assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827 --- Comment #8 from anlauf at gcc dot gnu.org --- Created attachment 58056 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58056=edit Patch part 2. This part fixes the array case. Needs further testing.
[Bug fortran/114827] Valgrind reports errors with class(*) assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827 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 --- Created attachment 58048 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58048=edit Partial patch This patch fixes the scalar case in comment#0 by computing _size*_len and regtests cleanly. It does not cover the array case.
[Bug fortran/102620] [12 Regression] ICE in gfc_get_array_span, at fortran/trans-array.c:865 since r12-1233-gd514626ee2566c68
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102620 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #13 from anlauf at gcc dot gnu.org --- Also fixed on 12-branch: commit r12-10398-gb482968801158116dd8ba3b15a4c29143b2a423a Author: Paul Thomas Date: Tue May 23 06:46:37 2023 +0100 Fortran: Fix assumed length chars and len inquiry [PR103716] 2023-05-23 Paul Thomas gcc/fortran PR fortran/103716 * resolve.cc (gfc_resolve_ref): Conversion of array_ref into an element should be done for all characters without a len expr, not just deferred lens, and for integer expressions. * trans-expr.cc (conv_inquiry): For len and kind inquiry refs, set the se string_length to NULL_TREE. gcc/testsuite/ PR fortran/103716 * gfortran.dg/pr103716.f90 : New test. (cherry picked from commit 842a432b02238361ecc601d301ac400a7f30f4fa) The ICE is gone. A remaining accepts-invalid on 11-branch could be fixed by backporting the above if needed. Thanks for the report to Gerhard, and to Paul for the above patch. Closing.
[Bug fortran/102620] [12 Regression] ICE in gfc_get_array_span, at fortran/trans-array.c:865 since r12-1233-gd514626ee2566c68
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102620 --- Comment #12 from anlauf at gcc dot gnu.org --- (In reply to Paul Thomas from comment #11) > It would be splendid if you would backport the patch. In the last week or > so, I have built up quite a list of backports to do, which I will attend to > over the weekend. Hi Paul, I've checked and found that your r14-1082-g842a432b022383 also needs to be backported to get all testcases here fixed on 12-branch. When regtesting completes successfully, I will push it.
[Bug fortran/102620] [12 Regression] ICE in gfc_get_array_span, at fortran/trans-array.c:865 since r12-1233-gd514626ee2566c68
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102620 --- Comment #10 from anlauf at gcc dot gnu.org --- (In reply to Paul Thomas from comment #9) > (In reply to anlauf from comment #8) > > I get the same behavior at r13-8559 as 14-mainline. There seems to be > > another commit that fixed it independently. > > > > Removing 13-branch from the regression list. > > Mark as fixed or backport fixes? Either I did something wrong, or the bug reappeared on 13-branch... Anyway, I tried backporting Andre's patch to 13- and 12-branch. Works fine and regtests fine. How to proceed? I can push those changes, so that we are finally done with this PR.
[Bug fortran/114815] internal compiler error: Segmentation fault - on creating type with len parameter and dependent on it character array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114815 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Keywords||ice-on-invalid-code Last reconfirmed||2024-04-24 Priority|P3 |P4 --- Comment #2 from anlauf at gcc dot gnu.org --- The code in comment#0 is invalid. Intel: pr114815.f90(5): error #8737: For a default initialized component every type parameter and array bound must be a constant expression. [GENDERS] end type Student_Group ^ NAG: Error: pr114815.f90, line 4: Type STUDENT_GROUP default-initialised component GENDERS has a non-constant array bound Errors in declarations, no further processing for LAB_1_4 When commenting the default initialization, the code compiles with gfortran.
