https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43291
janus at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.5.0
--- Comment #13 from pault at gcc dot gnu dot org 2010-03-12 22:01 ---
Subject: Bug 43291
Author: pault
Date: Fri Mar 12 22:00:52 2010
New Revision: 157411
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157411
Log:
2010-03-12 Paul Thomas pa...@gcc.gnu.org
PR
--- Comment #14 from pault at gcc dot gnu dot org 2010-03-12 22:05 ---
Fixed on trunk.
I´ll keep 43326 open for a bit, until I figure out what to do with
fortran-dev.
Thanks for the report.
Cheers
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed
--- Comment #10 from pault at gcc dot gnu dot org 2010-03-10 09:29 ---
In preparing a testcase, I foolishly decided to check the original for correct
execution.
The following gives the wrong result:
module m1
type :: t1
contains
procedure :: sizeof
end type
contains
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
Target Milestone|--- |4.5.0
--- Comment #11 from janus at gcc dot gnu dot org 2010-03-10 20:46 ---
(In reply to comment #6)
If all appears to be well with the regtest and I do not hear back from you,
I
will commit the patch to trunk tonight.
The patch clobbers dynamic_dispatch_4.f03.
Hm, funny. For me
--- Comment #12 from janus at gcc dot gnu dot org 2010-03-10 21:04 ---
(In reply to comment #10)
In preparing a testcase, I foolishly decided to check the original for correct
execution.
The following gives the wrong result:
I guess this is worth a separate PR. It's PR43326 now.
--- Comment #2 from janus at gcc dot gnu dot org 2010-03-09 09:44 ---
The problem here is that when resolving a polymorphic TBP call, we resolve the
call for each member of the CLASS (i.e. the declared type and all its children,
cf. 'resolve_class_compcall'). In 'check_class_members' we
--- Comment #3 from janus at gcc dot gnu dot org 2010-03-09 09:49 ---
(In reply to comment #2)
The problem here is that when resolving a polymorphic TBP call, we resolve the
call for each member of the CLASS (i.e. the declared type and all its
children,
cf.
--- Comment #9 from dominiq at lps dot ens dot fr 2010-03-09 15:20 ---
For the record, the patch in comment #5 won't apply on fortran-dev (no
class_try in the branch).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43291
--- Comment #4 from pault at gcc dot gnu dot org 2010-03-09 11:33 ---
(In reply to comment #3)
Paul, since you were the one who implemented this: Could you me remind me why
this is needed at all? Shouldn't it be enough to resolve the call as is, i.e.
just for the base class?
--- Comment #5 from pault at gcc dot gnu dot org 2010-03-09 13:09 ---
Created an attachment (id=20056)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20056action=view)
Fix for the PR
This is just now regtesting. I believe that it is OK, since it works for
gfortran.dg/class* and
--- Comment #8 from sfilippone at uniroma2 dot it 2010-03-09 14:14 ---
(In reply to comment #6)
If all appears to be well with the regtest and I do not hear back from you,
I
will commit the patch to trunk tonight.
Confidence before the fall and all that.
The patch
--- Comment #6 from pault at gcc dot gnu dot org 2010-03-09 13:34 ---
If all appears to be well with the regtest and I do not hear back from you, I
will commit the patch to trunk tonight.
Confidence before the fall and all that.
The patch clobbers dynamic_dispatch_4.f03.
--- Comment #7 from pault at gcc dot gnu dot org 2010-03-09 13:46 ---
(In reply to comment #6)
The patch clobbers dynamic_dispatch_4.f03. Remember it Salvatore?
I should have said that this is for -O1 and higher.
/svn/trunk/gcc/testsuite/gfortran.dg/dynamic_dispatch_4.f03: In
--- Comment #1 from dominiq at lps dot ens dot fr 2010-03-08 15:57 ---
As noted in http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43256#c9, the third
hunk of the patch for resolve.c in revision 157272 does not apply to
fortran-dev. The test in comment #0 passes with fortran-dev and my
16 matches
Mail list logo
