[Bug fortran/94672] [10/11 Regression] gfortran/OpenMP chokes on PRESENT(array) despite of SHARED(array): Error: ‘array’ not specified in enclosing ‘parallel’

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

[Bug libfortran/94143] [9/10/11 Regression] Asynchronous execute_command_line() breaks following synchronous calls

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94143 --- Comment #4 from Tomáš Trnka --- (In reply to anlauf from comment #3) > Funny. I do not get failures when compiling with -fsanitize=thread. I don't think TSAN can help here. This is not a data race between two threads, but between our SIGCHL

[Bug libfortran/94143] New: [9/10 Regression] Asynchronous execute_command_line() breaks following synchronous calls

Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: trnka at scm dot com Target Milestone: --- Since PR90038 introduced a SIGCHLD handler into execute_command_line(), calling an asynchronous

[Bug fortran/84487] [8/9 Regression] Large rodate section increase in 465.tonto with r254427

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

[Bug fortran/89092] New: Host-associated generic used instead of use-associated TBP in call

Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: trnka at scm dot com Target Milestone: --- GFortran rejects the following testcase because it only considers the host-associated generic interface when resolving the call to y%Foo

[Bug fortran/90744] New: [9/10 Regression] Bogus length for character temporaries passed to external procedures since r268992

Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: trnka at scm dot com Target Milestone: --- The fix for PR87689 in r268992 broke some of our code that passes character

[Bug fortran/90744] [7/8/9/10 Regression] Bogus length for character temporaries passed to external procedures since r268992

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90744 --- Comment #2 from Tomáš Trnka --- Looks like the issue appears if a particular external procedure is called for the second time. Replacing the seemingly useless "if" with just two calls leads to one correct and one miscompiled call: subrout

[Bug fortran/90744] [7/8/9/10 Regression] Bogus length for character temporaries passed to external procedures since r268992

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90744 --- Comment #3 from Tomáš Trnka --- I think the issue stems from this code in gfc_conv_procedure_call(): /* Deferred length dummies pass the character length by reference so that the value can be returned. */ if (parmse.str

[Bug fortran/90744] [7/8/9/10 Regression] Bogus length for character temporaries passed to external procedures since r268992

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90744 --- Comment #5 from Tomáš Trnka --- (In reply to Thomas Koenig from comment #4) > Good analysis, and this is indeed the correct fix. OK. I thought that perhaps get_formal_from_actual_arglist() should be done already before processing the argumen

[Bug fortran/87937] [8/9 Regression] LHS reallocation broken inside "select type" and "associate"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87937 --- Comment #5 from Tomáš Trnka --- Could you please kindly suggest what do I need to do to get this out of WAITING? I will gladly assist with any debugging and testing, but I'm not well versed enough with GCC internals to fix the underlying issu

[Bug fortran/87937] [8/9 Regression] LHS reallocation broken inside "select type" and "associate"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87937 --- Comment #6 from Tomáš Trnka --- The above is from GNU Fortran (GCC) 8.2.1 20181126

[Bug fortran/87937] [8/9 Regression] LHS reallocation broken inside "select type" and "associate"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87937 --- Comment #8 from Tomáš Trnka --- (In reply to Dominique d'Humieres from comment #7) > > Could you please kindly suggest what do I need to do to get this out of > > WAITING? ... > > AFAIK you can do it yourself. > > WAITING is not a punishme

[Bug fortran/87937] [8/9 Regression] LHS reallocation broken inside "select type" and "associate"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87937 --- Comment #11 from Tomáš Trnka --- (In reply to Paul Thomas from comment #10) > As I read that, or its equivalent in earlier standards, reallocation on > assignment cannot occur for the likes of the testcase in comments #5 and #8. Good catch,

[Bug fortran/87937] [8/9 Regression] LHS reallocation broken inside "select type" and "associate"

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87937 --- Comment #13 from Tomáš Trnka --- (In reply to Dominique d'Humieres from comment #12) > I finally got it: the problem has been introduced in trunk by revision > r264358 and fixed by r264725. Good catch! (How could I have missed that?) Backpo

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

NCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: trnka at scm dot com Target Milestone: --- Compiling the following testcase with "gfortran -c -Wdo-subscript do-subscript-test.f90" leads to a bu

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

NCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: trnka at scm dot com Target Milestone: --- Created attachment 52135 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52135&action=e

[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/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/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/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/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 --- 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/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 #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/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 fortran/108872] New: ICE in main_block_label, missing label when assigning a derived type whose component has a defined assignment

: 12.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: trnka at scm dot com Target Milestone: --- gfortran (tested versions 9 through 12.2.1 20221121) crashes when

[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 #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/112316] New: [13 Regression] Fix for PR87477 rejects valid code with a bogus error about pointer assignment and causes an ICE

: 13.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: trnka at scm dot com Target Milestone: --- Current releases/gcc-13 rejects the following testcase (compiled

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

Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: trnka at scm dot com Target Milestone: --- Created attachment 56515 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56515&acti

[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/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/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/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 sanitizer/112730] New: Wrong code generated with Address Sanitizer for a call to a callback in contained subroutine, mapping not executable

Version: 13.2.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: trnka at scm dot com CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org

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

Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: trnka at scm dot com Target Milestone: --- Created attachment 58935 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58935&action=edit t