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-
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=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
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=84487
Tomáš Trnka changed:
What|Removed |Added
CC||trnka at scm dot com
--- Comment #12 from
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
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
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
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 #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=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
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 #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 #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 #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
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
: 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
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
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
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=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=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
> @@ -
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
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
: 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
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
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
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.
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=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
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=109684
Tomáš Trnka changed:
What|Removed |Added
CC||trnka at scm dot com
--- Comment #2 from
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
--- 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=37336
Tomáš Trnka changed:
What|Removed |Added
CC||trnka at scm dot com
--- Comment #33 from
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=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
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
41 matches
Mail list logo
