[Bug fortran/55057] [OOP] wrong result with abstract type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55057 janus at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug fortran/55057] [OOP] wrong result with abstract type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55057 janus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from janus at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #7) It has been fixed between revisions 194721 and 195140. I can confirm that it is fixed on trunk, so let's close it! Btw, it even works for me with: gcc version 4.8.1 20130806 [gcc-4_8-branch revision 201525] (SUSE Linux)
[Bug fortran/55057] [OOP] wrong result with abstract type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55057 --- Comment #9 from janus at gcc dot gnu.org --- (In reply to janus from comment #8) (In reply to Dominique d'Humieres from comment #7) It has been fixed between revisions 194721 and 195140. I can confirm that it is fixed on trunk, so let's close it! Btw, it even works for me with: gcc version 4.8.1 20130806 [gcc-4_8-branch revision 201525] (SUSE Linux) ... and, without testing, I assume it also works with the 4.8.0 release. This assumption also matches Dominique's revision range (the 4.8 branch was created only at r196696).
[Bug fortran/55057] [OOP] wrong result with abstract type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55057
Mikael Morin mikael at gcc dot gnu.org changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #6 from Mikael Morin mikael at gcc dot gnu.org ---
(In reply to janus from comment #3)
Here is a reduced test case, which is not usable as a runtime test, but
shows the wrong dump:
[...]
The dump of 'sub2' is wrong in 4.8, while 'sub1' is ok. With 4.7, both are
wrong.
sub2's dump is now:
sub2 (struct __class_m_T2 restrict b)
{
{
struct __class_m_T1 class.7;
class.7._data = (struct t1 *) b-_data-work._data.data + (sizetype)
((b-_data-work._data.offset + 1) * (integer(kind=8))
b-_data-work._vptr-_size);
class.7._vptr = b-_data-work._vptr;
alt (class.7);
}
}
This appears correct to me. At least, it involves _vptr-_size.
And the output of comment #0 is now:
$ ./comment_0
All the following values should be 2.0
2.
2.
2.
All the following values should be 2.0
2.
2.
2.
FIXED?
[Bug fortran/55057] [OOP] wrong result with abstract type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55057 --- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr --- It has been fixed between revisions 194721 and 195140.
[Bug fortran/55057] [OOP] wrong result with abstract type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55057 janus at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|UNCONFIRMED |NEW Last reconfirmed||2012-10-25 CC||janus at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from janus at gcc dot gnu.org 2012-10-25 11:35:20 UTC --- Confirmed. I think this one is closely related to (if not a duplicate of) PR 54992, even though the case here is not a regression (it ICEs with 4.7).
[Bug fortran/55057] [OOP] wrong result with abstract type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55057
--- Comment #2 from janus at gcc dot gnu.org 2012-10-25 11:58:15 UTC ---
-fdump-tree-original shows that the correct code is generated for the call to
alt in the main program (involving _vptr-_size):
{
struct __class_m_At1 class.17;
static real(kind=4) C.2125 = 1.5e+0;
struct __class_m_At1 class.16;
struct __class_m_At1 class.15;
class.15._data = (struct at1 *) aa.at2.work._data.data + (sizetype)
((aa.at2.work._data.offset + 2) * (integer(kind=8)) aa.at2.work._vptr-_size);
class.15._vptr = aa.at2.work._vptr;
class.16._data = (struct at1 *) aa.at2.work._data.data + (sizetype)
((aa.at2.work._data.offset + 1) * (integer(kind=8)) aa.at2.work._vptr-_size);
class.16._vptr = aa.at2.work._vptr;
class.17._data = (struct at1 *) aa.at2.work._data.data + (sizetype)
((aa.at2.work._data.offset + 1) * (integer(kind=8)) aa.at2.work._vptr-_size);
class.17._vptr = aa.at2.work._vptr;
aa.at2.work._vptr-alt (class.15, class.16, C.2125, class.17);
}
while wrong code is generated for the call to alt in sub:
sub (struct __class_m_At2 restrict var)
{
{
struct __class_m_At1 class.2;
static real(kind=4) C.1988 = 1.5e+0;
struct __class_m_At1 class.1;
struct __class_m_At1 class.0;
class.0._data = (*(struct at1[0:] * restrict)
var-_data-work._data.data)[var-_data-work._data.offset + 2];
class.0._vptr = var-_data-work._vptr;
class.1._data = (*(struct at1[0:] * restrict)
var-_data-work._data.data)[var-_data-work._data.offset + 1];
class.1._vptr = var-_data-work._vptr;
class.2._data = (*(struct at1[0:] * restrict)
var-_data-work._data.data)[var-_data-work._data.offset + 1];
class.2._vptr = var-_data-work._vptr;
var-_data-work._vptr-alt (class.0, class.1, C.1988, class.2);
}
}
[Bug fortran/55057] [OOP] wrong result with abstract type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55057 --- Comment #3 from janus at gcc dot gnu.org 2012-10-25 14:51:44 UTC --- Here is a reduced test case, which is not usable as a runtime test, but shows the wrong dump: module m implicit none type :: t1 end type type :: t2 class(t1), allocatable :: work(:) end type contains subroutine alt(x) class(t1), intent(in) :: x end subroutine subroutine sub1(a) type(t2) :: a call alt(a%work(1)) end subroutine subroutine sub2(b) class(t2) :: b call alt(b%work(1)) end subroutine end module The dump of 'sub2' is wrong in 4.8, while 'sub1' is ok. With 4.7, both are wrong.
[Bug fortran/55057] [OOP] wrong result with abstract type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55057 janus at gcc dot gnu.org changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #4 from janus at gcc dot gnu.org 2012-10-25 17:17:48 UTC --- I think there is a problem with build_array_ref which was created by Paul in this commit: http://gcc.gnu.org/viewcvs?view=revisionrevision=187192 Apparently it only handles expressions correctly, where the base symbol is CLASS, but fails for those where it is TYPE. This also seems to be the reason for the problems in PR 54992. Paul, what would be the best way to fix this?
[Bug fortran/55057] [OOP] wrong result with abstract type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55057 --- Comment #5 from janus at gcc dot gnu.org 2012-10-25 17:23:17 UTC --- (In reply to comment #4) Apparently it only handles expressions correctly, where the base symbol is CLASS, but fails for those where it is TYPE. Sorry, I meant the other way around.
