public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/47463] New: ICE in gfc_add_component_ref
@ 2011-01-25 19:33 townsend at astro dot wisc.edu
2011-01-25 20:33 ` [Bug fortran/47463] [OOP] " burnus at gcc dot gnu.org
` (16 more replies)
0 siblings, 17 replies; 18+ messages in thread
From: townsend at astro dot wisc.edu @ 2011-01-25 19:33 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47463
Summary: ICE in gfc_add_component_ref
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: critical
Priority: P3
Component: fortran
AssignedTo: unassigned@gcc.gnu.org
ReportedBy: townsend@astro.wisc.edu
Created attachment 23124
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23124
Tar file containing source code and Makefile
Compiling the attached code (Makefile included) results in the following
internal compiler error:
gfortran-mp-4.6 -std=f2003 -c hydro_flow.f90
f951: internal compiler error: in gfc_add_component_ref, at fortran/class.c:79
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
make: *** [hydro_flow.mod] Error 1
The code is a stripped-down version of a new F2003 hydrodynamics code; it's v.
important that I get it up and running as soon as possible.
Thanks,
Rich
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/47463] [OOP] ICE in gfc_add_component_ref
2011-01-25 19:33 [Bug fortran/47463] New: ICE in gfc_add_component_ref townsend at astro dot wisc.edu
@ 2011-01-25 20:33 ` burnus at gcc dot gnu.org
2011-01-25 20:53 ` mikael at gcc dot gnu.org
` (15 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: burnus at gcc dot gnu.org @ 2011-01-25 20:33 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47463
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |burnus at gcc dot gnu.org,
| |janus at gcc dot gnu.org
Summary|ICE in |[OOP] ICE in
|gfc_add_component_ref |gfc_add_component_ref
--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-01-25 19:53:04 UTC ---
4.5 fails with:
use hydro_recon
1
Internal Error at (1):
mio_component_ref(): Component not found
Thus, it is not a regression.
* * *
Compiling with Crayftn 7.2.4 shows the error:
call this%init(st, gr)
^
ftn-389 crayftn: ERROR INIT_PARAMS, File = hydro_flow.f90, Line = 55, Column =
14
No specific match can be found for the generic subprogram call "INIT".
* * *
Regarding GCC 4.6:
The ICE occurs in gfc_add_component_ref for e being the EXPR_FUNCTION
"this->_vptr" where "_vptr" is e->ref->u.c.component->name and e->ref->next ==
NULL. Also e->value.function == {actual = 0x0, name = 0x0, isym = 0x0, esym =
0x0}.
The caller is resolve_typebound_subroutine where code->op == EXEC_ASSIGN_CALL;
the call is:
gfc_add_component_ref (code->expr1, name);
with "name" == assign and the expression as shown above.
Somewhat reduced test case:
module hydro_state
type :: state_t
contains
procedure :: assign
generic :: assignment(=) => assign
end type state_t
contains
subroutine assign (this, that)
class(state_t), intent(inout) :: this
class(state_t), intent(in) :: that
end subroutine assign
end module hydro_state
module hydro_flow
use hydro_state
type :: flow_t
class(state_t), allocatable :: st
end type flow_t
contains
subroutine init_comps (this, st)
class(flow_t), intent(out) :: this
class(state_t), intent(in) :: st
allocate(state_t :: this%st)
this%st = st
end subroutine init_comps
end module hydro_flow
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/47463] [OOP] ICE in gfc_add_component_ref
2011-01-25 19:33 [Bug fortran/47463] New: ICE in gfc_add_component_ref townsend at astro dot wisc.edu
2011-01-25 20:33 ` [Bug fortran/47463] [OOP] " burnus at gcc dot gnu.org
@ 2011-01-25 20:53 ` mikael at gcc dot gnu.org
2011-01-27 5:33 ` townsend at astro dot wisc.edu
` (14 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: mikael at gcc dot gnu.org @ 2011-01-25 20:53 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47463
Mikael Morin <mikael at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mikael at gcc dot gnu.org
--- Comment #2 from Mikael Morin <mikael at gcc dot gnu.org> 2011-01-25 20:14:40 UTC ---
(In reply to comment #1)
> 4.5 fails with:
> use hydro_recon
> 1
> Internal Error at (1):
> mio_component_ref(): Component not found
>
This is PR 45827
>
> Regarding GCC 4.6:
>
There have been several PRs like this.
For example PR 45933.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/47463] [OOP] ICE in gfc_add_component_ref
2011-01-25 19:33 [Bug fortran/47463] New: ICE in gfc_add_component_ref townsend at astro dot wisc.edu
2011-01-25 20:33 ` [Bug fortran/47463] [OOP] " burnus at gcc dot gnu.org
2011-01-25 20:53 ` mikael at gcc dot gnu.org
@ 2011-01-27 5:33 ` townsend at astro dot wisc.edu
2011-01-30 16:01 ` janus at gcc dot gnu.org
` (13 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: townsend at astro dot wisc.edu @ 2011-01-27 5:33 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47463
--- Comment #3 from Rich Townsend <townsend at astro dot wisc.edu> 2011-01-27 04:06:10 UTC ---
(In reply to comment #2)
> (In reply to comment #1)
> > 4.5 fails with:
> > use hydro_recon
> > 1
> > Internal Error at (1):
> > mio_component_ref(): Component not found
> >
> This is PR 45827
>
This bug apparently persists in 4.6; I'm experiencing it with a different piece
of code. It seems likely that memory corruption is the issue, since I can get
the bug to appear/disappear by removing unrelated code segments. Reporting this
sort of bug is very difficult, since its manifestation is so platform-specific.
Any suggestions?
cheers,
Rich
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/47463] [OOP] ICE in gfc_add_component_ref
2011-01-25 19:33 [Bug fortran/47463] New: ICE in gfc_add_component_ref townsend at astro dot wisc.edu
` (2 preceding siblings ...)
2011-01-27 5:33 ` townsend at astro dot wisc.edu
@ 2011-01-30 16:01 ` janus at gcc dot gnu.org
2011-01-31 10:48 ` janus at gcc dot gnu.org
` (12 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: janus at gcc dot gnu.org @ 2011-01-30 16:01 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47463
janus at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |ice-on-valid-code
Severity|critical |normal
--- Comment #4 from janus at gcc dot gnu.org 2011-01-30 14:31:14 UTC ---
Slightly reduced/modified test case:
module hydro_state
type :: state_t
contains
procedure :: assign
generic :: assignment(=) => assign
end type
contains
subroutine assign (this, that)
class(state_t), intent(inout) :: this
class(state_t), intent(in) :: that
end subroutine
end module
use hydro_state
type :: flow_t
type(state_t) :: st
end type
class(flow_t),pointer :: this
type(state_t) :: st
this%st = st
end
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/47463] [OOP] ICE in gfc_add_component_ref
2011-01-25 19:33 [Bug fortran/47463] New: ICE in gfc_add_component_ref townsend at astro dot wisc.edu
` (3 preceding siblings ...)
2011-01-30 16:01 ` janus at gcc dot gnu.org
@ 2011-01-31 10:48 ` janus at gcc dot gnu.org
2011-01-31 12:08 ` burnus at gcc dot gnu.org
` (11 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: janus at gcc dot gnu.org @ 2011-01-31 10:48 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47463
janus at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2011.01.31 10:29:20
AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org
|gnu.org |
Ever Confirmed|0 |1
--- Comment #5 from janus at gcc dot gnu.org 2011-01-31 10:29:20 UTC ---
Alright, here is a draft patch:
Index: gcc/fortran/resolve.c
===================================================================
--- gcc/fortran/resolve.c (revision 169407)
+++ gcc/fortran/resolve.c (working copy)
@@ -5877,14 +5877,12 @@ resolve_typebound_subroutine (gfc_code *code)
/* Deal with typebound operators for CLASS objects. */
expr = code->expr1->value.compcall.base_object;
- if (expr && expr->symtree->n.sym->ts.type == BT_CLASS
- && code->expr1->value.compcall.name)
+ if (expr && expr->ts.type == BT_CLASS && code->expr1->value.compcall.name)
{
/* Since the typebound operators are generic, we have to ensure
that any delays in resolution are corrected and that the vtab
is present. */
- ts = expr->symtree->n.sym->ts;
- declared = ts.u.derived;
+ declared = expr->ts.u.derived;
c = gfc_find_component (declared, "_vptr", true, true);
if (c->ts.u.derived == NULL)
c->ts.u.derived = gfc_find_derived_vtab (declared);
@@ -5895,6 +5893,7 @@ resolve_typebound_subroutine (gfc_code *code)
/* Use the generic name if it is there. */
name = name ? name : code->expr1->value.function.esym->name;
code->expr1->symtree = expr->symtree;
+ code->expr1->ref = gfc_copy_ref (expr->ref);
expr->symtree->n.sym->ts.u.derived = declared;
gfc_add_vptr_component (code->expr1);
gfc_add_component_ref (code->expr1, name);
This fixes comment #1 and comment #4. For the original test case I now get:
gfortran-4.6 -std=f2003 -c hydro_types.f90
gfortran-4.6 -std=f2003 -c hydro_state.f90
gfortran-4.6 -std=f2003 -c hydro_speeds.f90
gfortran-4.6 -std=f2003 -c hydro_grid.f90
gfortran-4.6 -std=f2003 -c hydro_flow.f90
hydro_flow.f90:55.13:
call this%init(st, gr)
1
Error: Found no matching specific binding for the call to the GENERIC 'init' at
(1)
Changing this generic call to the corresponding specific type-bound procedure,
I get:
gfortran-4.6 -std=f2003 -c hydro_flow.f90
hydro_flow.f90:55.13:
call this%init_comps(st, gr)
1
Error: Type mismatch in argument 'this' at (1); passed CLASS(flow_t) to
CLASS(grid_t)
And the same without type-binding:
gfortran-4.6 -std=f2003 -c hydro_flow.f90
hydro_flow.f90:55.20:
call init_comps(this, st, gr)
1
Error: Type mismatch in argument 'this' at (1); passed CLASS(flow_t) to
CLASS(grid_t)
The code does look valid to me (unless I'm missing something), so this seems to
be another gfortran bug.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/47463] [OOP] ICE in gfc_add_component_ref
2011-01-25 19:33 [Bug fortran/47463] New: ICE in gfc_add_component_ref townsend at astro dot wisc.edu
` (4 preceding siblings ...)
2011-01-31 10:48 ` janus at gcc dot gnu.org
@ 2011-01-31 12:08 ` burnus at gcc dot gnu.org
2011-01-31 15:13 ` janus at gcc dot gnu.org
` (10 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: burnus at gcc dot gnu.org @ 2011-01-31 12:08 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47463
--- Comment #6 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-01-31 11:03:31 UTC ---
(In reply to comment #5)
> hydro_flow.f90:55.13:
> call this%init(st, gr)
> 1
> Error: Found no matching specific binding for the call to the GENERIC
> 'init' at (1)
That matches Cray's ftn (cf. comment 1):
call this%init(st, gr)
^
ftn-389 crayftn: ERROR INIT_PARAMS, File = hydro_flow.f90, Line = 55, Column =
14
No specific match can be found for the generic subprogram call "INIT".
> Changing this generic call to the corresponding specific type-bound procedure,
I assume s/this%init/this%init_comps/ in that line. With Crayftn I then get the
following, which looks at a glance like a bug in crayftn, though I have not
checked it:
procedure :: init_comps
^
ftn-1130 crayftn: ERROR HYDRO_FLOW, File = hydro_flow.f90, Line = 21, Column =
19
"INIT_COMPS" is specified as a procedure-name in a type bound procedure
statement. It must be a module procedure or an external procedure with an
explicit interface.
subroutine init_comps (this, st, gr)
^
ftn-575 crayftn: ERROR HYDRO_FLOW, File = hydro_flow.f90, Line = 66, Column =
14
"INIT_COMPS" has been used as a subroutine, therefore it must not be declared
as a module procedure subroutine.
> I get:
[ Some gfortran error message, completely different from Crays]
> And the same without type-binding:
> call init_comps(this, st, gr)
> Error: Type mismatch in argument 'this' at (1); passed CLASS(flow_t) to
> CLASS(grid_t)
That version works with Crayftn. It then compiles hydro_flow.f90 - and stops in
hydro_recon.f90 (line 31) for "fl%n" as '"N" is not a component of derived type
"FLOW_T"'
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/47463] [OOP] ICE in gfc_add_component_ref
2011-01-25 19:33 [Bug fortran/47463] New: ICE in gfc_add_component_ref townsend at astro dot wisc.edu
` (5 preceding siblings ...)
2011-01-31 12:08 ` burnus at gcc dot gnu.org
@ 2011-01-31 15:13 ` janus at gcc dot gnu.org
2011-01-31 18:46 ` janus at gcc dot gnu.org
` (9 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: janus at gcc dot gnu.org @ 2011-01-31 15:13 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47463
--- Comment #7 from janus at gcc dot gnu.org 2011-01-31 14:49:00 UTC ---
(In reply to comment #5)
> Alright, here is a draft patch:
The patch in comment #5 regtests cleanly. I will commit as obvious soon ...
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/47463] [OOP] ICE in gfc_add_component_ref
2011-01-25 19:33 [Bug fortran/47463] New: ICE in gfc_add_component_ref townsend at astro dot wisc.edu
` (6 preceding siblings ...)
2011-01-31 15:13 ` janus at gcc dot gnu.org
@ 2011-01-31 18:46 ` janus at gcc dot gnu.org
2011-01-31 21:53 ` burnus at gcc dot gnu.org
` (8 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: janus at gcc dot gnu.org @ 2011-01-31 18:46 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47463
--- Comment #8 from janus at gcc dot gnu.org 2011-01-31 18:11:36 UTC ---
Author: janus
Date: Mon Jan 31 18:11:32 2011
New Revision: 169443
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169443
Log:
2011-01-31 Janus Weil <janus@gcc.gnu.org>
PR fortran/47463
* resolve.c (resolve_typebound_subroutine): Bug fix for the case of
an argument of a typebound assignment being a component.
2011-01-31 Janus Weil <janus@gcc.gnu.org>
PR fortran/47463
* gfortran.dg/typebound_assignment_1.f03: New.
Added:
trunk/gcc/testsuite/gfortran.dg/typebound_assignment_1.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/47463] [OOP] ICE in gfc_add_component_ref
2011-01-25 19:33 [Bug fortran/47463] New: ICE in gfc_add_component_ref townsend at astro dot wisc.edu
` (7 preceding siblings ...)
2011-01-31 18:46 ` janus at gcc dot gnu.org
@ 2011-01-31 21:53 ` burnus at gcc dot gnu.org
2011-02-02 18:25 ` dnovillo at gcc dot gnu.org
` (7 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: burnus at gcc dot gnu.org @ 2011-01-31 21:53 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47463
--- Comment #9 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-01-31 21:42:29 UTC ---
(In reply to comment #6)
> > And the same without type-binding:
> > call init_comps(this, st, gr)
> > Error: Type mismatch in argument 'this' at (1); passed CLASS(flow_t) to
> > CLASS(grid_t)
I looked closer at that version.
a) It works if one reverses the order of subroutines (all versions)
Rich: That's a work around, which is sufficient to compile the whole program.
Note: You need a gfortran, which includes Janus' patch from comment 8.
b) For the failing version. The formal argument in compare_actual_formal alias
compare_parameter is odd:
(gdb) p a->expr->ts.u.derived->name
$17 = 0x2aaaacf0eae0 "__class_hydro_flow_Flow_t"
(gdb) p f->sym->ts.u.derived->name
$18 = 0x2aaaacf0eac0 "__class_hydro_grid_Grid_t_a"
(gdb) p f->sym->name
$19 = 0x2aaaace40fb0 "this"
Namely, the formal argument has the right name, but it is associated with the
wrong typespec!
* * *
Reduced test case:
module hydro_grid
type :: grid_t
contains
procedure :: assign
generic :: assignment(=) => assign
end type grid_t
public :: grid_t
contains
subroutine assign (this, that)
class(grid_t), intent(inout) :: this
class(grid_t), intent(in) :: that
end subroutine assign
end module hydro_grid
module hydro_flow
use hydro_grid
type :: flow_t
class(grid_t), allocatable :: gr ! Computation grid
end type flow_t
contains
subroutine init_params (this)
class(flow_t), intent(out) :: this
type(grid_t) :: gr
call init_comps(this, gr)
end subroutine init_params
subroutine init_comps (this, gr)
class(flow_t), intent(out) :: this
class(grid_t), intent(in) :: gr
this%gr = gr
end subroutine init_comps
end module hydro_flow
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/47463] [OOP] ICE in gfc_add_component_ref
2011-01-25 19:33 [Bug fortran/47463] New: ICE in gfc_add_component_ref townsend at astro dot wisc.edu
` (8 preceding siblings ...)
2011-01-31 21:53 ` burnus at gcc dot gnu.org
@ 2011-02-02 18:25 ` dnovillo at gcc dot gnu.org
2011-02-09 18:11 ` janus at gcc dot gnu.org
` (6 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: dnovillo at gcc dot gnu.org @ 2011-02-02 18:25 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47463
--- Comment #10 from Diego Novillo <dnovillo at gcc dot gnu.org> 2011-02-02 18:12:05 UTC ---
Author: dnovillo
Date: Wed Feb 2 18:11:56 2011
New Revision: 169722
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169722
Log:
2011-01-31 Janus Weil <janus@gcc.gnu.org>
PR fortran/47463
* resolve.c (resolve_typebound_subroutine): Bug fix for the case of
an argument of a typebound assignment being a component.
2011-01-31 Janus Weil <janus@gcc.gnu.org>
PR fortran/47463
* gfortran.dg/typebound_assignment_1.f03: New.
Added:
branches/google/integration/gcc/testsuite/gfortran.dg/typebound_assignment_1.f03
Modified:
branches/google/integration/gcc/fortran/ChangeLog
branches/google/integration/gcc/fortran/resolve.c
branches/google/integration/gcc/testsuite/ChangeLog
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/47463] [OOP] ICE in gfc_add_component_ref
2011-01-25 19:33 [Bug fortran/47463] New: ICE in gfc_add_component_ref townsend at astro dot wisc.edu
` (9 preceding siblings ...)
2011-02-02 18:25 ` dnovillo at gcc dot gnu.org
@ 2011-02-09 18:11 ` janus at gcc dot gnu.org
2011-02-09 18:58 ` burnus at gcc dot gnu.org
` (5 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: janus at gcc dot gnu.org @ 2011-02-09 18:11 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47463
--- Comment #11 from janus at gcc dot gnu.org 2011-02-09 18:08:45 UTC ---
The strange behavior of the test case in comment #9 can be cured by just
removing one peculiar line of code:
Index: gcc/fortran/resolve.c
===================================================================
--- gcc/fortran/resolve.c (revision 169977)
+++ gcc/fortran/resolve.c (working copy)
@@ -5894,7 +5894,6 @@ resolve_typebound_subroutine (gfc_code *code)
name = name ? name : code->expr1->value.function.esym->name;
code->expr1->symtree = expr->symtree;
code->expr1->ref = gfc_copy_ref (expr->ref);
- expr->symtree->n.sym->ts.u.derived = declared;
gfc_add_vptr_component (code->expr1);
gfc_add_component_ref (code->expr1, name);
code->expr1->value.function.esym = NULL;
This line seems completely bogus to me. I have no idea what it's supposed to
do. In any case it came from the following commit:
http://gcc.gnu.org/viewcvs/trunk/gcc/fortran/resolve.c?r1=162313&r2=162312&pathrev=162313
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/47463] [OOP] ICE in gfc_add_component_ref
2011-01-25 19:33 [Bug fortran/47463] New: ICE in gfc_add_component_ref townsend at astro dot wisc.edu
` (10 preceding siblings ...)
2011-02-09 18:11 ` janus at gcc dot gnu.org
@ 2011-02-09 18:58 ` burnus at gcc dot gnu.org
2011-02-09 20:24 ` janus at gcc dot gnu.org
` (4 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: burnus at gcc dot gnu.org @ 2011-02-09 18:58 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47463
Tobias Burnus <burnus at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |pault at gcc dot gnu.org
--- Comment #12 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-02-09 18:52:10 UTC ---
(In reply to comment #11)
> This line seems completely bogus to me. I have no idea what it's supposed to
> do. In any case it came from the following commit:
Cf. PR 42385 / http://gcc.gnu.org/viewcvs?view=revision&revision=162313
which was committed by Paul.
I do not see whether the line makes sense or not. The idea seems to be to fix
not fully resolved TBP -- but it is not completely clear to me whether that is
ever needed in such a way. As the test case [cf. comment 9 (b)] shows, the
current way is definitely wrong.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/47463] [OOP] ICE in gfc_add_component_ref
2011-01-25 19:33 [Bug fortran/47463] New: ICE in gfc_add_component_ref townsend at astro dot wisc.edu
` (11 preceding siblings ...)
2011-02-09 18:58 ` burnus at gcc dot gnu.org
@ 2011-02-09 20:24 ` janus at gcc dot gnu.org
2011-02-09 20:35 ` janus at gcc dot gnu.org
` (3 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: janus at gcc dot gnu.org @ 2011-02-09 20:24 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47463
--- Comment #13 from janus at gcc dot gnu.org 2011-02-09 20:18:31 UTC ---
(In reply to comment #12)
> I do not see whether the line makes sense or not. The idea seems to be to fix
> not fully resolved TBP -- but it is not completely clear to me whether that is
> ever needed in such a way.
Apparently it's not needed, since removing the line does not introduce any
regressions in the testsuite. Perhaps it was making up for another bug which is
fixed by now.
I am going to commit the patch in comment #11 as obvious ...
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/47463] [OOP] ICE in gfc_add_component_ref
2011-01-25 19:33 [Bug fortran/47463] New: ICE in gfc_add_component_ref townsend at astro dot wisc.edu
` (12 preceding siblings ...)
2011-02-09 20:24 ` janus at gcc dot gnu.org
@ 2011-02-09 20:35 ` janus at gcc dot gnu.org
2011-02-09 20:49 ` janus at gcc dot gnu.org
` (2 subsequent siblings)
16 siblings, 0 replies; 18+ messages in thread
From: janus at gcc dot gnu.org @ 2011-02-09 20:35 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47463
--- Comment #14 from janus at gcc dot gnu.org 2011-02-09 20:30:23 UTC ---
Author: janus
Date: Wed Feb 9 20:30:20 2011
New Revision: 169985
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169985
Log:
2011-02-09 Janus Weil <janus@gcc.gnu.org>
PR fortran/47463
* resolve.c (resolve_typebound_subroutine): Remove erroneous line.
2011-02-09 Janus Weil <janus@gcc.gnu.org>
PR fortran/47463
* gfortran.dg/typebound_assignment_2.f03: New.
Added:
trunk/gcc/testsuite/gfortran.dg/typebound_assignment_2.f03
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/resolve.c
trunk/gcc/testsuite/ChangeLog
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/47463] [OOP] ICE in gfc_add_component_ref
2011-01-25 19:33 [Bug fortran/47463] New: ICE in gfc_add_component_ref townsend at astro dot wisc.edu
` (13 preceding siblings ...)
2011-02-09 20:35 ` janus at gcc dot gnu.org
@ 2011-02-09 20:49 ` janus at gcc dot gnu.org
2011-02-09 21:10 ` burnus at gcc dot gnu.org
2011-02-10 6:25 ` paul.richard.thomas at gmail dot com
16 siblings, 0 replies; 18+ messages in thread
From: janus at gcc dot gnu.org @ 2011-02-09 20:49 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47463
janus at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
--- Comment #15 from janus at gcc dot gnu.org 2011-02-09 20:37:04 UTC ---
I think r169985 should fix all remaining problems in this PR. The original test
case now gives me:
gfortran-4.6 -std=f2003 -c hydro_types.f90
gfortran-4.6 -std=f2003 -c hydro_state.f90
gfortran-4.6 -std=f2003 -c hydro_speeds.f90
gfortran-4.6 -std=f2003 -c hydro_grid.f90
gfortran-4.6 -std=f2003 -c hydro_flow.f90
gfortran-4.6 -std=f2003 -c hydro_recon.f90
gfortran-4.6 -std=f2003 -c hydro_evolve.f90
hydro_evolve.f90:10.18:
use hydro_fluxes
1
Fatal Error: Can't open module file 'hydro_fluxes.mod' for reading at (1): No
such file or directory
Closing as fixed.
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/47463] [OOP] ICE in gfc_add_component_ref
2011-01-25 19:33 [Bug fortran/47463] New: ICE in gfc_add_component_ref townsend at astro dot wisc.edu
` (14 preceding siblings ...)
2011-02-09 20:49 ` janus at gcc dot gnu.org
@ 2011-02-09 21:10 ` burnus at gcc dot gnu.org
2011-02-10 6:25 ` paul.richard.thomas at gmail dot com
16 siblings, 0 replies; 18+ messages in thread
From: burnus at gcc dot gnu.org @ 2011-02-09 21:10 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47463
--- Comment #16 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-02-09 21:06:05 UTC ---
(In reply to comment #13)
> I am going to commit the patch in comment #11 as obvious ...
Can you CC the patch to gcc-patches@ & fortran@?
^ permalink raw reply [flat|nested] 18+ messages in thread
* [Bug fortran/47463] [OOP] ICE in gfc_add_component_ref
2011-01-25 19:33 [Bug fortran/47463] New: ICE in gfc_add_component_ref townsend at astro dot wisc.edu
` (15 preceding siblings ...)
2011-02-09 21:10 ` burnus at gcc dot gnu.org
@ 2011-02-10 6:25 ` paul.richard.thomas at gmail dot com
16 siblings, 0 replies; 18+ messages in thread
From: paul.richard.thomas at gmail dot com @ 2011-02-10 6:25 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47463
--- Comment #17 from paul.richard.thomas at gmail dot com <paul.richard.thomas at gmail dot com> 2011-02-10 05:24:24 UTC ---
Dear Janus,
> Apparently it's not needed, since removing the line does not introduce any
> regressions in the testsuite. Perhaps it was making up for another bug which is
> fixed by now.
>
I have no memory of what that was about, at all :-(
Thanks for fixing it.
Paul
^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2011-02-10 5:25 UTC | newest]
Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2011-01-25 19:33 [Bug fortran/47463] New: ICE in gfc_add_component_ref townsend at astro dot wisc.edu
2011-01-25 20:33 ` [Bug fortran/47463] [OOP] " burnus at gcc dot gnu.org
2011-01-25 20:53 ` mikael at gcc dot gnu.org
2011-01-27 5:33 ` townsend at astro dot wisc.edu
2011-01-30 16:01 ` janus at gcc dot gnu.org
2011-01-31 10:48 ` janus at gcc dot gnu.org
2011-01-31 12:08 ` burnus at gcc dot gnu.org
2011-01-31 15:13 ` janus at gcc dot gnu.org
2011-01-31 18:46 ` janus at gcc dot gnu.org
2011-01-31 21:53 ` burnus at gcc dot gnu.org
2011-02-02 18:25 ` dnovillo at gcc dot gnu.org
2011-02-09 18:11 ` janus at gcc dot gnu.org
2011-02-09 18:58 ` burnus at gcc dot gnu.org
2011-02-09 20:24 ` janus at gcc dot gnu.org
2011-02-09 20:35 ` janus at gcc dot gnu.org
2011-02-09 20:49 ` janus at gcc dot gnu.org
2011-02-09 21:10 ` burnus at gcc dot gnu.org
2011-02-10 6:25 ` paul.richard.thomas at gmail dot com
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).