public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/41951] New: [OOP] ICE in gfc_match_varspec, at fortran/primary.c:1815
@ 2009-11-05 17:00 burnus at gcc dot gnu dot org
2009-11-05 17:01 ` [Bug fortran/41951] " burnus at gcc dot gnu dot org
` (2 more replies)
0 siblings, 3 replies; 10+ messages in thread
From: burnus at gcc dot gnu dot org @ 2009-11-05 17:00 UTC (permalink / raw)
To: gcc-bugs
The following program is an extension to the one in PR 41539. It finally
requires to many features that ifort 11.1 does not like it - nor the dated NAG
f95 5.1 (current is 5.2). And while gfortran should have everything needed, it
still does not work.
I have no idea whether the code is correct - probably not - but an ICE is
definitely wrong. (For other issues see PR 41539.)
$ gfortran sort.f90
f951: internal compiler error: in gfc_match_varspec, at fortran/primary.c:1815
Please submit a full bug report
--
Summary: [OOP] ICE in gfc_match_varspec, at
fortran/primary.c:1815
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: burnus at gcc dot gnu dot org
BugsThisDependsOn: 41539
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41951
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug fortran/41951] [OOP] ICE in gfc_match_varspec, at fortran/primary.c:1815
2009-11-05 17:00 [Bug fortran/41951] New: [OOP] ICE in gfc_match_varspec, at fortran/primary.c:1815 burnus at gcc dot gnu dot org
@ 2009-11-05 17:01 ` burnus at gcc dot gnu dot org
2009-11-06 10:36 ` janus at gcc dot gnu dot org
2009-12-05 22:15 ` tkoenig at gcc dot gnu dot org
2 siblings, 0 replies; 10+ messages in thread
From: burnus at gcc dot gnu dot org @ 2009-11-05 17:01 UTC (permalink / raw)
To: gcc-bugs
------- Comment #1 from burnus at gcc dot gnu dot org 2009-11-05 17:01 -------
Created an attachment (id=18974)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18974&action=view)
Test case - see marked line for the ICE
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41951
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug fortran/41951] [OOP] ICE in gfc_match_varspec, at fortran/primary.c:1815
2009-11-05 17:00 [Bug fortran/41951] New: [OOP] ICE in gfc_match_varspec, at fortran/primary.c:1815 burnus at gcc dot gnu dot org
2009-11-05 17:01 ` [Bug fortran/41951] " burnus at gcc dot gnu dot org
@ 2009-11-06 10:36 ` janus at gcc dot gnu dot org
2009-12-05 22:15 ` tkoenig at gcc dot gnu dot org
2 siblings, 0 replies; 10+ messages in thread
From: janus at gcc dot gnu dot org @ 2009-11-06 10:36 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from janus at gcc dot gnu dot org 2009-11-06 10:35 -------
Created an attachment (id=18978)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18978&action=view)
legalized test case
The test case in comment #1 is clearly illegal (and rejected by NAG 5.2). This
version should be valid.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41951
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug fortran/41951] [OOP] ICE in gfc_match_varspec, at fortran/primary.c:1815
2009-11-05 17:00 [Bug fortran/41951] New: [OOP] ICE in gfc_match_varspec, at fortran/primary.c:1815 burnus at gcc dot gnu dot org
2009-11-05 17:01 ` [Bug fortran/41951] " burnus at gcc dot gnu dot org
2009-11-06 10:36 ` janus at gcc dot gnu dot org
@ 2009-12-05 22:15 ` tkoenig at gcc dot gnu dot org
2 siblings, 0 replies; 10+ messages in thread
From: tkoenig at gcc dot gnu dot org @ 2009-12-05 22:15 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from tkoenig at gcc dot gnu dot org 2009-12-05 22:14 -------
Reduced test case, from c2.f90:
module m_sort
implicit none
type, abstract :: sort_t
contains
procedure(gt_cmp), deferred :: gt_cmp
end type sort_t
contains
subroutine bsort(a)
class(sort_t), intent(inout) :: a(:)
if (a(1)%gt_cmp(a(2))) then ! ICE
end if
end subroutine bsort
end module m_sort
--
tkoenig at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|0000-00-00 00:00:00 |2009-12-05 22:14:52
date| |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41951
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug fortran/41951] [OOP] ICE in gfc_match_varspec, at fortran/primary.c:1815
[not found] <bug-41951-4@http.gcc.gnu.org/bugzilla/>
` (4 preceding siblings ...)
2011-12-13 12:04 ` burnus at gcc dot gnu.org
@ 2011-12-16 14:32 ` burnus at gcc dot gnu.org
5 siblings, 0 replies; 10+ messages in thread
From: burnus at gcc dot gnu.org @ 2011-12-16 14:32 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41951
--- Comment #9 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-12-16 14:30:15 UTC ---
(In reply to comment #8)
> I failed to nail it in the standard, but I am sure that "12.4.3.4.5
> Restrictions on generic declarations" somehow must apply.
Thus I have now asked at
http://j3-fortran.org/pipermail/j3/2011-December/004946.html
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug fortran/41951] [OOP] ICE in gfc_match_varspec, at fortran/primary.c:1815
[not found] <bug-41951-4@http.gcc.gnu.org/bugzilla/>
` (3 preceding siblings ...)
2011-12-12 13:29 ` burnus at gcc dot gnu.org
@ 2011-12-13 12:04 ` burnus at gcc dot gnu.org
2011-12-16 14:32 ` burnus at gcc dot gnu.org
5 siblings, 0 replies; 10+ messages in thread
From: burnus at gcc dot gnu.org @ 2011-12-13 12:04 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41951
--- Comment #8 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-12-13 11:40:51 UTC ---
(In reply to comment #6)
> Given that NAG 5.2 compiles it and as "assign" is only called via
> "assignment(=)", there must be some issue with the assignment resolution.
Actually, I wonder whether the code is valid. One has:
type, abstract :: sort_t
contains
generic :: assignment(=) => assign
...
interface assignment(=)
procedure assign
end interface
Thus, one defines twice a generic name with the same (= identical) interface,
once as TBP and once as external procedure. Thus, when one encounters:
tmp = a(i)
the compiler has the choice between "assign_" and "tmp->_vtab->assign".
I failed to nail it in the standard, but I am sure that "12.4.3.4.5
Restrictions on generic declarations" somehow must apply.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug fortran/41951] [OOP] ICE in gfc_match_varspec, at fortran/primary.c:1815
[not found] <bug-41951-4@http.gcc.gnu.org/bugzilla/>
` (2 preceding siblings ...)
2011-12-12 8:07 ` burnus at gcc dot gnu.org
@ 2011-12-12 13:29 ` burnus at gcc dot gnu.org
2011-12-13 12:04 ` burnus at gcc dot gnu.org
2011-12-16 14:32 ` burnus at gcc dot gnu.org
5 siblings, 0 replies; 10+ messages in thread
From: burnus at gcc dot gnu.org @ 2011-12-12 13:29 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41951
--- Comment #7 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-12-12 13:14:24 UTC ---
(In reply to comment #6)
> However, while the example of comment 2 (attachment 18978 [details]) compiles,
> it fails to link with: undefined reference to `assign_'
The problem is in "subroutine bsort(a,tmp)": The line
tmp = a(i)
should call tmp->_vtr->assign. However, it calls a simple external "assign"
procedure. If one uses:
call tmp%assign(a(i))
one finds the correct dump, namely:
tmp->_vptr->assign ((struct __class_m_sort_Sort_t *) tmp, &class.2);
The "assign" is found when resolve_ordinary_assign calls gfc_extend_assign,
which runs:
3452 sym = gfc_search_interface (ns->op[INTRINSIC_ASSIGN], 1, &actual);
That returns the INTERFACE instead of the type bound procedure:
(gdb) p sym->name
$9 = 0x2aaaacde8fd0 "assign"
(gdb) p sym->attr.external
$11 = 1
If one changes the interface to an abstract one, one gets
ERROR: ABSTRACT INTERFACE 'assign' must not be referenced
Using "assign" instead of the type-bound "assign" is definitely a bug as no
"INTERFACE ASSIGNMENT(=)" exists - there is only the type-based "generic ::
assignment(=) => assign".
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug fortran/41951] [OOP] ICE in gfc_match_varspec, at fortran/primary.c:1815
[not found] <bug-41951-4@http.gcc.gnu.org/bugzilla/>
2011-01-23 11:17 ` tkoenig at gcc dot gnu.org
2011-01-23 13:02 ` dominiq at lps dot ens.fr
@ 2011-12-12 8:07 ` burnus at gcc dot gnu.org
2011-12-12 13:29 ` burnus at gcc dot gnu.org
` (2 subsequent siblings)
5 siblings, 0 replies; 10+ messages in thread
From: burnus at gcc dot gnu.org @ 2011-12-12 8:07 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41951
--- Comment #6 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-12-12 08:03:41 UTC ---
STATUS:
With the commit for PR 41539, there is no longer an ICE.
However, while the example of comment 2 (attachment 18978) compiles, it fails
to link with: undefined reference to `assign_'
Given that NAG 5.2 compiles it and as "assign" is only called via
"assignment(=)", there must be some issue with the assignment resolution.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug fortran/41951] [OOP] ICE in gfc_match_varspec, at fortran/primary.c:1815
[not found] <bug-41951-4@http.gcc.gnu.org/bugzilla/>
2011-01-23 11:17 ` tkoenig at gcc dot gnu.org
@ 2011-01-23 13:02 ` dominiq at lps dot ens.fr
2011-12-12 8:07 ` burnus at gcc dot gnu.org
` (3 subsequent siblings)
5 siblings, 0 replies; 10+ messages in thread
From: dominiq at lps dot ens.fr @ 2011-01-23 13:02 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41951
--- Comment #5 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-01-23 10:57:05 UTC ---
> Another test case, from ...
It is pr47399.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug fortran/41951] [OOP] ICE in gfc_match_varspec, at fortran/primary.c:1815
[not found] <bug-41951-4@http.gcc.gnu.org/bugzilla/>
@ 2011-01-23 11:17 ` tkoenig at gcc dot gnu.org
2011-01-23 13:02 ` dominiq at lps dot ens.fr
` (4 subsequent siblings)
5 siblings, 0 replies; 10+ messages in thread
From: tkoenig at gcc dot gnu.org @ 2011-01-23 11:17 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41951
Thomas Koenig <tkoenig at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |tkoenig at gcc dot gnu.org
--- Comment #4 from Thomas Koenig <tkoenig at gcc dot gnu.org> 2011-01-23 10:10:33 UTC ---
Another test case, from
http://groups.google.com/group/comp.lang.fortran/msg/e6a865eda59e86db?hl=de
module mytypes
implicit none
private
public :: mytype, get_i
integer, save :: i_priv = 13
type :: mytype
integer :: dummy
contains
procedure, nopass :: i => get_i
end type mytype
contains
pure function get_i () result (i)
integer :: i
i = i_priv
end function get_i
end module mytypes
program test
use mytypes
implicit none
type(mytype) :: a
type(mytype), parameter :: a_const = mytype (0)
! integer, dimension (get_i()) :: x ! #1
! integer, dimension (a%i()) :: x ! #2
integer, dimension (a_const%i()) :: x ! #3
print *, size (x)
end program test
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2011-12-16 14:31 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-11-05 17:00 [Bug fortran/41951] New: [OOP] ICE in gfc_match_varspec, at fortran/primary.c:1815 burnus at gcc dot gnu dot org
2009-11-05 17:01 ` [Bug fortran/41951] " burnus at gcc dot gnu dot org
2009-11-06 10:36 ` janus at gcc dot gnu dot org
2009-12-05 22:15 ` tkoenig at gcc dot gnu dot org
[not found] <bug-41951-4@http.gcc.gnu.org/bugzilla/>
2011-01-23 11:17 ` tkoenig at gcc dot gnu.org
2011-01-23 13:02 ` dominiq at lps dot ens.fr
2011-12-12 8:07 ` burnus at gcc dot gnu.org
2011-12-12 13:29 ` burnus at gcc dot gnu.org
2011-12-13 12:04 ` burnus at gcc dot gnu.org
2011-12-16 14:32 ` burnus at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).