--- Comment #28 from janus at gcc dot gnu dot org 2010-07-11 09:40 ---
I'll take over this one. Have a fix.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #29 from janus at gcc dot gnu dot org 2010-07-13 06:57 ---
Subject: Bug 43945
Author: janus
Date: Tue Jul 13 06:57:17 2010
New Revision: 162125
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162125
Log:
2010-07-13 Janus Weil
PR fortran/44434
PR fo
--- Comment #31 from sfilippone at uniroma2 dot it 2010-07-13 09:07 ---
(In reply to comment #30)
> Most test cases seem to be fixed, except of:
>
> (In reply to comment #19)
> > Created an attachment (id=20927)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20927&action=view) [edi
--- Comment #32 from burnus at gcc dot gnu dot org 2010-07-13 09:12 ---
(In reply to comment #31)
> Yup, but after discussion with Janus, it seems the failing part is not dynamic
> dispatching, but compile-time resolution. Accordingly, I have appended the
> test
> case to PR 42385.
OK
--- Comment #1 from sfilippone at uniroma2 dot it 2010-04-30 09:23 ---
(In reply to comment #0)
> Another OOP problem found by Salvatore.
>
>
Whoa, you beat me in opening the bug!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43945
--- Comment #2 from burnus at gcc dot gnu dot org 2010-04-30 09:35 ---
"4.5.7.3 Type-bound procedure overriding" (F2008 FDIS):
"If a specific type-bound procedure specified in a type definition has the same
binding name as a type-bound procedure from the parent type then the binding
spe
--- Comment #3 from sfilippone at uniroma2 dot it 2010-04-30 09:41 ---
(In reply to comment #1)
> (In reply to comment #0)
> > Another OOP problem found by Salvatore.
> >
> >
> Whoa, you beat me in opening the bug!
>
If I modify the source code as in the next attachment, I get an ICE
--- Comment #4 from sfilippone at uniroma2 dot it 2010-04-30 09:42 ---
Created an attachment (id=20522)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20522&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43945
--- Comment #5 from sfilippone at uniroma2 dot it 2010-04-30 09:43 ---
(In reply to comment #3)
> (In reply to comment #1)
> > (In reply to comment #0)
> > > Another OOP problem found by Salvatore.
> > >
> > >
> > Whoa, you beat me in opening the bug!
> >
> If I modify the source cod
--- Comment #6 from pault at gcc dot gnu dot org 2010-04-30 14:33 ---
(In reply to comment #0)
> Another OOP problem found by Salvatore.
>
> Jim Xia confirms that NAG f95 gives the correct result, cf.
> http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/e18d0434c46598
--- Comment #7 from pault at gcc dot gnu dot org 2010-05-01 17:16 ---
I do not see any reason not to confirm this one.
This
Index: gcc/fortran/resolve.c
===
*** gcc/fortran/resolve.c (revision 158958)
--- gcc/fortran
--- Comment #8 from pault at gcc dot gnu dot org 2010-05-05 21:04 ---
Created an attachment (id=20571)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20571&action=view)
Fix for the PR
Boostraps and regtests on RHEL5.4/i686
Will add testcase and ChangeLogs tomorrow.
Paul
--
h
--- Comment #9 from janus at gcc dot gnu dot org 2010-06-06 02:04 ---
Subject: Bug 43945
Author: janus
Date: Sun Jun 6 02:04:04 2010
New Revision: 160335
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=160335
Log:
2010-06-05 Paul Thomas
Janus Weil
PR fo
--- Comment #10 from janus at gcc dot gnu dot org 2010-06-06 02:28 ---
Comment #0 is fixed by r160335, but the ICE in comment #4 is still there.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43945
--- Comment #11 from janus at gcc dot gnu dot org 2010-06-06 02:49 ---
Reduced test case for comment #4:
module foo_mod
type foo
contains
procedure, pass(a) :: doit
generic :: do => doit
end type
contains
subroutine doit(a)
class(foo) :: a
end subroutine
end mod
--- Comment #12 from janus at gcc dot gnu dot org 2010-06-06 03:02 ---
(In reply to comment #11)
> Reduced test case for comment #4:
Even further reduced:
module foo_mod
type foo
contains
procedure :: doit
generic :: do => doit
end type
contains
subroutine doit(a)
--- Comment #13 from janus at gcc dot gnu dot org 2010-06-06 16:20 ---
The remaining issue (comment #4/#11/#12) is being tracked by PR 44434, so this
one can be closed.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #14 from sfilippone at uniroma2 dot it 2010-06-07 08:26 ---
(In reply to comment #13)
> The remaining issue (comment #4/#11/#12) is being tracked by PR 44434, so this
> one can be closed.
>
The attached variation of generic_23 still does not work.
[sfili...@donald bug15]$
--- Comment #15 from sfilippone at uniroma2 dot it 2010-06-07 08:27 ---
Created an attachment (id=20853)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20853&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43945
--- Comment #16 from burnus at gcc dot gnu dot org 2010-06-07 09:41 ---
(In reply to comment #14)
> The attached variation of generic_23 still does not work.
>
> [sfili...@donald bug15]$ ./generic_23_1
> FOO%DOIT base version
Aborted (core dumped)
(In reply to comment #15)
> Create
--- Comment #17 from sfilippone at uniroma2 dot it 2010-06-08 14:09 ---
(In reply to comment #16)
> (In reply to comment #14)
> > The attached variation of generic_23 still does not work.
> >
> > [sfili...@donald bug15]$ ./generic_23_1
> > FOO%DOIT base version
> Aborted (core dumpe
--- Comment #18 from sfilippone at uniroma2 dot it 2010-06-16 10:32 ---
(In reply to comment #17)
Dear All,
The attached source file contains the same kind of test as the original
testd15, and yet it fails. So, there's something missing from the patch, even
without considering the alloc
--- Comment #19 from sfilippone at uniroma2 dot it 2010-06-16 10:32 ---
Created an attachment (id=20927)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20927&action=view)
test-case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43945
--- Comment #20 from janus at gcc dot gnu dot org 2010-06-21 11:01 ---
(In reply to comment #14)
> The attached variation of generic_23 still does not work.
... and the dump shows why:
if (vtab$foo2.get == 0B)
{
vtab$vtype$foo2$get.getit = getit;
vtab$foo2.ge
--- Comment #21 from sfilippone at uniroma2 dot it 2010-06-23 12:20 ---
(In reply to comment #20)
> (In reply to comment #14)
> > The attached variation of generic_23 still does not work.
>
> ... and the dump shows why:
>
>
>
> The specific PPCs of 'foo2' point to the right procedu
--- Comment #22 from sfilippone at uniroma2 dot it 2010-06-25 15:31 ---
(In reply to comment #21)
Ok, I bit the bullet, and fooled around with the internals to see what was
happening. I did a very naive thing of adding warnings in
resolve.c:resolve_typebound_generic_call, and I think I h
--- Comment #23 from sfilippone at uniroma2 dot it 2010-06-25 15:34 ---
(In reply to comment #22)
>
generic_23.f03 obviously works becase the binding name DOIT and the procedure
name are one and the same
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43945
--- Comment #24 from sfilippone at uniroma2 dot it 2010-07-06 10:14 ---
(In reply to comment #23)
> (In reply to comment #22)
> >
> generic_23.f03 obviously works becase the binding name DOIT and the procedure
> name are one and the same
>
Hi all
Another variation to the test case
--- Comment #25 from sfilippone at uniroma2 dot it 2010-07-06 10:15 ---
Created an attachment (id=21101)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21101&action=view)
test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43945
--- Comment #26 from sfilippone at uniroma2 dot it 2010-07-07 13:15 ---
(In reply to comment #25)
This fixes test_vt2 but not test_coo. Will keep investigating.(and of
course it should be done for functions as well as subroutines...)
Index: gcc/fortran/resolve.c
===
--- Comment #27 from sfilippone at uniroma2 dot it 2010-07-07 14:25 ---
(In reply to comment #26)
For the test_coo.f03 case, what happens is shown in the following dump.
{
struct class$base_sparse_mat class.6;
if (vtab$d_coo_sparse_mat.allocate == 0B)
{
vtab$d_co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43945
janus at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |4.6.0
32 matches
Mail list logo
