https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86328
--- Comment #17 from martin ---
Thanks for fixing it! Using class(*) with gfortran is still a bit of a
precarious ride.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86328
Paul Thomas changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86328
--- Comment #15 from Paul Thomas ---
Author: pault
Date: Sat Sep 1 08:11:34 2018
New Revision: 264027
URL: https://gcc.gnu.org/viewcvs?rev=264027=gcc=rev
Log:
2018-09-01 Paul Thomas
PR fortran/86328
PR fortran/86760
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86328
Paul Thomas changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86328
--- Comment #13 from Paul Thomas ---
Author: pault
Date: Fri Aug 31 06:51:31 2018
New Revision: 264008
URL: https://gcc.gnu.org/viewcvs?rev=264008=gcc=rev
Log:
2018-08-31 Paul Thomas
PR fortran/86328
PR fortran/86760
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86328
--- Comment #12 from martin ---
The workaround mentioned by Paul in comment #9 is working only partially. For
character sequences (and possibly other data types), valgrind still complains.
Surprisingly, using a single character works as well. On
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86328
janus at gcc dot gnu.org changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86328
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|8.2 |8.3
--- Comment #10 from Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86328
--- Comment #9 from Paul Thomas ---
(In reply to janus from comment #8)
> Reducing the test case slightly more:
>
>
> program ptr_alloc
>
>type :: t
> class(*), allocatable :: val
>end type
>
>type :: list
> type(t),
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86328
--- Comment #8 from janus at gcc dot gnu.org ---
Reducing the test case slightly more:
program ptr_alloc
type :: t
class(*), allocatable :: val
end type
type :: list
type(t), dimension(:), pointer :: ll
end type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86328
--- Comment #7 from janus at gcc dot gnu.org ---
Created attachment 44376
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44376=edit
dump of new (buggy) version
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86328
--- Comment #6 from janus at gcc dot gnu.org ---
Created attachment 44375
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44375=edit
dump of old (correct) version
I also tried to look at the output of -fdump-tree-original for the code in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86328
--- Comment #5 from janus at gcc dot gnu.org ---
(In reply to janus from comment #4)
> Bisection shows that this regression was introduced by Paul's r251949 on
> 2017-09-10.
I could verify that reverting the expr.c part of that commit does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86328
janus at gcc dot gnu.org changed:
What|Removed |Added
CC||pault at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86328
Richard Biener changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86328
--- Comment #3 from janus at gcc dot gnu.org ---
The code in comment 0 seems to have a small error: a%ll is allocated with only
one element (1:1), which should probably be ten (1:10). So I wonder why it runs
with gfortran-7 at all?!?
In any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86328
janus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
17 matches
Mail list logo
