[Bug fortran/116829] Missing default initialization of finalizable non-polymorphic intent(out) arguments

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116829 --- Comment #2 from Tomáš Trnka --- I have sent a candidate fix for this to the mailing list in the past (and then somehow forgot about it): https://gcc.gnu.org/pipermail/fortran/2024-September/061086.html

[Bug fortran/116388] [13/14/15 regression] Finalizer called on uninitialized components of intent(out) argument

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116388 --- Comment #3 from Tomáš Trnka --- (In reply to Paul Thomas from comment #2) > Do you want to apply the fix or shall I do the honours? I'd love to do it, but I don't have commit access. So if I understand it correctly, I would have to send a p

[Bug fortran/116829] New: Missing default initialization of finalizable non-polymorphic intent(out) arguments

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116829 Bug ID: 116829 Summary: Missing default initialization of finalizable non-polymorphic intent(out) arguments Product: gcc Version: 15.0 Status: UNCONFIRMED Seve

[Bug fortran/116388] [13/14/15 regression] Finalizer called on uninitialized components of intent(out) argument

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116388 --- Comment #1 from Tomáš Trnka --- Diagnosing this further, the "comp_byte_stride" temporary created by finalize_component() is never initialized because it is marked .artificial=1, and resolve_symbol() bails out early for artificial symbols in

[Bug fortran/116388] New: [13/14/15 regression] Finalizer called on uninitialized components of intent(out) argument

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116388 Bug ID: 116388 Summary: [13/14/15 regression] Finalizer called on uninitialized components of intent(out) argument Product: gcc Version: 13.3.1 Status: UNCONFIRMED

[Bug fortran/112407] [13 Regression] Fix for PR37336 triggers an ICE in gfc_format_decoder while constructing a vtab

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112407 --- Comment #14 from Tomáš Trnka --- I have been testing my own backport of the master commit on top of current 13 branch for some weeks now and it works great. Our codebase now compiles even without -frecursive without any related warnings/erro

[Bug sanitizer/112730] New: Wrong code generated with Address Sanitizer for a call to a callback in contained subroutine, mapping not executable

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112730 Bug ID: 112730 Summary: Wrong code generated with Address Sanitizer for a call to a callback in contained subroutine, mapping not executable Product: gcc Version

[Bug fortran/112407] [13/14 Regression] Fix for PR37336 triggers an ICE in gfc_format_decoder while constructing a vtab

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112407 --- Comment #5 from Tomáš Trnka --- (In reply to Paul Thomas from comment #4) > Created attachment 56531 [details] > Fix for this PR > > The bug comes about because the vtable is being declared in one of the > specific procedures typebound to t

[Bug fortran/112407] [13/14 Regression] Fix for PR37336 triggers an ICE in gfc_format_decoder while constructing a vtab

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112407 --- Comment #3 from Tomáš Trnka --- Yes, -frecursive makes the build pass and it is a workaround which I have been using ever since upgrading to 13. Should have mentioned that, sorry. I see that something is making the compiler think the routin

[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684 --- Comment #24 from Tomáš Trnka --- (In reply to Steve Kargl from comment #23) > If expr->where is pointing to NULL, then something is definitely not > set up correctly or your code is now going through a different code > path in the compiler.

[Bug fortran/112407] [13 Regression] Fix for PR37336 triggers an ICE in gfc_format_decoder while constructing a vtab

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112407 --- Comment #1 from Tomáš Trnka --- Created attachment 56516 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56516&action=edit Hacky patch working around the issue on this testcase

[Bug fortran/112407] New: [13 Regression] Fix for PR37336 triggers an ICE in gfc_format_decoder while constructing a vtab

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112407 Bug ID: 112407 Summary: [13 Regression] Fix for PR37336 triggers an ICE in gfc_format_decoder while constructing a vtab Product: gcc Version: 13.2.1 Status: UNCONFIRMED

[Bug fortran/112316] New: [13 Regression] Fix for PR87477 rejects valid code with a bogus error about pointer assignment and causes an ICE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112316 Bug ID: 112316 Summary: [13 Regression] Fix for PR87477 rejects valid code with a bogus error about pointer assignment and causes an ICE Product: gcc Version: 13

[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684 --- Comment #22 from Tomáš Trnka --- (In reply to Steve Kargl from comment #21) > I missed your comment #7 as simply grabbed the "slightly > more simplified" attachment and started a bug hunt from there. > Do either of the other testcase attachm

[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684 --- Comment #17 from Tomáš Trnka --- (In reply to kargl from comment #10) > diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc > index 3cd470ddcca..b0bb8bc1471 100644 > --- a/gcc/fortran/resolve.cc > +++ b/gcc/fortran/resolve.cc > @@ -

[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684 --- Comment #7 from Tomáš Trnka --- (In reply to Paul Thomas from comment #5) > Created attachment 55144 [details] > Fix for this PR > > Thanks for reporting this. The patch "fingered" in comment #4 is certainly > responsible for this regressio

[Bug fortran/37336] [F03] Finish derived-type finalization

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336 Tomáš Trnka changed: What|Removed |Added CC||trnka at scm dot com --- Comment #33 from

[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684 --- Comment #4 from Tomáš Trnka --- This is a regression in GCC 13, which bisects to the following commit. Reverting that commit on current releases/gcc-13 tip (together with dependent commits 259bd7686403 and 3e791f45ded8) makes the issue go aw

[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684 --- Comment #3 from Tomáš Trnka --- Created attachment 55134 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55134&action=edit testcase reduced to three files This is the most reduced testcase I have found. It was created from the previous

[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109684 Tomáš Trnka changed: What|Removed |Added CC||trnka at scm dot com --- Comment #2 from

[Bug fortran/108872] New: ICE in main_block_label, missing label when assigning a derived type whose component has a defined assignment

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108872 Bug ID: 108872 Summary: ICE in main_block_label, missing label when assigning a derived type whose component has a defined assignment Product: gcc Version: 12.2.

[Bug fortran/104036] Derived type assigment to allocatable with dynamic type

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104036 Tomáš Trnka changed: What|Removed |Added CC||trnka at scm dot com --- Comment #1 from

[Bug fortran/46897] [OOP] type-bound defined ASSIGNMENT(=) not used for derived type component in intrinsic assign

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46897 Tomáš Trnka changed: What|Removed |Added CC||trnka at scm dot com --- Comment #15 from

[Bug fortran/103931] Type name "c_ptr" is ambiguous when iso_c_binding is imported both directly and indirectly

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103931 --- Comment #5 from Tomáš Trnka --- (In reply to anlauf from comment #2) > Created attachment 52138 [details] > Somewhat reduced reproducer > > The issue can be reproduced with a few less modules FWIW, this reduced testcase doesn't reproduce t

[Bug fortran/103931] New: Type name "c_ptr" is ambiguous when iso_c_binding is imported both directly and indirectly

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103931 Bug ID: 103931 Summary: Type name "c_ptr" is ambiguous when iso_c_binding is imported both directly and indirectly Product: gcc Version: 10.2.1 Status: UNCONFIRMED

[Bug fortran/97320] New: False positive "Array reference out of bounds in loop" in a protecting if block

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97320 Bug ID: 97320 Summary: False positive "Array reference out of bounds in loop" in a protecting if block Product: gcc Version: 10.2.1 Status: UNCONFIRMED Severity