https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98454
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |15.0
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98454
--- Comment #14 from GCC Commits ---
The master branch has been updated by Harald Anlauf :
https://gcc.gnu.org/g:b222122d4e93de2238041a01b1886c7dfd9944da
commit r15-3323-gb222122d4e93de2238041a01b1886c7dfd9944da
Author: Harald Anlauf
Date: T
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98454
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
Assignee
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98454
--- Comment #12 from anlauf at gcc dot gnu.org ---
Created attachment 59021
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59021&action=edit
Patch
Revisiting this one, I arrived at the attached patch.
This seems to fix the present issues a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98454
--- Comment #11 from anlauf at gcc dot gnu.org ---
The following hack fixes the testcase in comment#10,
but not the testcase in comment#2:
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 249f402b8d9..2c9570d4641 100644
--- a/gcc/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98454
--- Comment #10 from anlauf at gcc dot gnu.org ---
(In reply to martin from comment #9)
> Problems with default initialisation of function result were fixed with
> PR45489. The relevant testcase added by this PR is initialization_27.f90
> which lo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98454
martin changed:
What|Removed |Added
CC||mscfd at gmx dot net
--- Comment #9 from martin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98454
--- Comment #8 from Steve Kargl ---
On Sun, Dec 27, 2020 at 10:15:56PM +, ffadrique at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98454
>
> --- Comment #6 from Fran Martinez Fadrique ---
> I have raised the issue wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98454
--- Comment #7 from Fran Martinez Fadrique ---
By the way, thanks for the workaround. It cleanly solves the problem, at least
temporarily.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98454
--- Comment #6 from Fran Martinez Fadrique ---
I have raised the issue with respect to 4.5.3.4 of the ISO standard that
stablishes how the type component are initialized. Not just my expectations.
I have further developed my test case and any lo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98454
--- Comment #5 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #4)
> Should be closed as invalid as the original code contains a number
> of issues caused by invalid code.
Steve, stop it!
My reduced testcase shows that there i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98454
--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #2)
> I think there already exists at least one PR with issues with initializers.
>
> A reduced testcase shows that default initialization works for intent(out),
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98454
--- Comment #3 from anlauf at gcc dot gnu.org ---
According to the tree-dump, adding a
print *, res% unit
to the function body invokes the implicit initializer, while the line
res = t()
actually invokes the initializer effectively twice!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98454
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Last reconfirmed||2020-12-27
CC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98454
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
CC|
15 matches
Mail list logo
