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
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
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: trnka at scm dot com
Target Milestone: ---
When a derived type dummy argument with intent(out) is finalizable (e.g. has a
final subroutine), gfortran (at least as
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
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
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
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
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
routine is recursive,
even though it very clearly is not. The full original source of that module is
available from
https://github.com/SCM-NV/ftl/blob/master/src/ftlDynArray.F90_template, but
even if I make the two affected routines (NewCopyOther and AssignOther)
completely empty, the issue persists
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.
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
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
: 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
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
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
> @@ -
ne is a defined assignment in the ftlDynArray class, used in
this case to hold ordinary integers:
https://github.com/SCM-NV/ftl/blob/master/src/ftlDynArray.F90_template
Th
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
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
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
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
: 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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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
eTrust Secure Content Manager SMTPMAIL could not deliver the e-mail below
because at least one of recipients was rejected by the mail server
Please check the recipients e-mail address before you try again:
[EMAIL PROTECTED]
Original message header:
===
X-eSCM-
41 matches
Mail list logo
