--- Comment #7 from janus at gcc dot gnu dot org 2010-06-20 00:06 ---
Subject: Bug 44584
Author: janus
Date: Sun Jun 20 00:05:35 2010
New Revision: 161041
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161041
Log:
2010-06-19 Janus Weil ja...@gcc.gnu.org
PR fortran
--- Comment #8 from janus at gcc dot gnu dot org 2010-06-20 00:12 ---
(In reply to comment #6)
It will be while before I can check it on ia64. However if your patch fixes
valgrind issue on x86, it won't hurt to check it in. Thanks.
Ok, the patch has landed on trunk. Please let me
--- Comment #1 from janus at gcc dot gnu dot org 2010-06-18 21:18 ---
Works for me on x86_64-unknown-linux-gnu at r160947.
Can you show the backtrace for the ICE?
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from janus at gcc dot gnu dot org 2010-06-18 21:24 ---
(In reply to comment #0)
On Linux/ia64, revision 160858 gave
...
Revision 160826 is OK.
The only Fortran-related change in this range is
r160834 | janus | 2010-06-16 14:54:54 +0200 (Wed, 16 Jun 2010) | 17 lines
--- Comment #5 from janus at gcc dot gnu dot org 2010-06-18 23:54 ---
(In reply to comment #3)
/export/gnu/import/svn/gcc-test/src-trunk/gcc/testsuite/gfortran.dg/typebound_proc_15.f03:15.23:
procedure :: bar, baz { dg-error PROCEDURE list }
1
Error
--- Comment #3 from janus at gcc dot gnu dot org 2010-06-17 22:15 ---
Subject: Bug 44558
Author: janus
Date: Thu Jun 17 22:15:30 2010
New Revision: 160948
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160948
Log:
2010-06-17 Janus Weil ja...@gcc.gnu.org
PR fortran
--- Comment #4 from janus at gcc dot gnu dot org 2010-06-17 22:18 ---
Fixed with r160948. Closing.
Thanks for the report!
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--- Comment #2 from janus at gcc dot gnu dot org 2010-06-17 22:34 ---
Reduced test case:
module ice6
type :: t
contains
procedure :: get_array
generic :: get_something = get_array
end type
contains
function get_array(this)
class(t) :: this
real,dimension
--- Comment #8 from janus at gcc dot gnu dot org 2010-06-17 22:38 ---
*** Bug 44570 has been marked as a duplicate of this bug. ***
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from janus at gcc dot gnu dot org 2010-06-17 22:38 ---
*** This bug has been marked as a duplicate of 43969 ***
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from janus at gcc dot gnu dot org 2010-06-17 22:46 ---
This is not expected to work right now, as polymorphic arrays are not really
implemented yet.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from janus at gcc dot gnu dot org 2010-06-17 22:59 ---
(In reply to comment #1)
The modified code compile with 4.5.0, hence
a regression I can trace between revisions 158215 (working) and 158921 (ICE).
The regression is most probably due to the merging of the fortran
--- Comment #2 from janus at gcc dot gnu dot org 2010-06-16 12:55 ---
Subject: Bug 44549
Author: janus
Date: Wed Jun 16 12:54:54 2010
New Revision: 160834
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160834
Log:
2010-06-16 Janus Weil ja...@gcc.gnu.org
PR fortran
--- Comment #3 from janus at gcc dot gnu dot org 2010-06-16 12:56 ---
Fixed with r160834. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from janus at gcc dot gnu dot org 2010-06-16 20:50 ---
Confirmed. Btw the same thing happens if you treat a type-bound function as if
it were a subroutine:
module ice5
type::a_type
contains
procedure::a_subroutine_1
procedure::a_subroutine_2
end type
--- Comment #2 from janus at gcc dot gnu dot org 2010-06-16 20:58 ---
This is easily fixed by the following patch:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 160833)
+++ gcc/fortran
--- Comment #3 from janus at gcc dot gnu dot org 2010-06-15 18:35 ---
Subject: Bug 43388
Author: janus
Date: Tue Jun 15 18:33:58 2010
New Revision: 160801
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160801
Log:
2010-06-15 Janus Weil ja...@gcc.gnu.org
PR fortran
--- Comment #1 from janus at gcc dot gnu dot org 2010-06-15 18:40 ---
(In reply to comment #0)
Follow up to PR 43388 (ALLOCATE with MOLD, a F2008 feature)
For the MOLD problem we already have a test case in allocate_alloc_opt_10.f90
(which is put behind comments right now, but should
--- Comment #4 from janus at gcc dot gnu dot org 2010-06-15 18:42 ---
Fixed with r160801. Remaining problems are tracked by PR 44541.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from janus at gcc dot gnu dot org 2010-06-15 19:08 ---
Comment #1 is fixed by r160622, but the original test case still does not work
(hangs in some kind of infinite loop for me, at r160801 on
x86_64-unknown-linux-gnu).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #11 from janus at gcc dot gnu dot org 2010-06-15 19:38 ---
Here is a reduced test case, based on comment #0:
module grid_module
implicit none
type grid
end type
type field
type(grid) :: mesh
end type
contains
real function return_x(this)
class(grid
--- Comment #12 from janus at gcc dot gnu dot org 2010-06-15 19:41 ---
(In reply to comment #11)
This gives me a segfault ICE.
... with the following backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x00553b5d in gfc_find_symtree (st=0x41, name=0x77f2de50
--- Comment #1 from janus at gcc dot gnu dot org 2010-06-15 21:05 ---
Dominique, thanks for reporting this. I can confirm the error you're seeing and
I already see what's wrong: In 'match_procedure_in_type' the handling of the
gfc_typebound_proc structures is not correct (each procedure
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44529
--- Comment #1 from janus at gcc dot gnu dot org 2010-06-13 21:38 ---
(In reply to comment #0)
First example:
integer, allocatable :: a(:), b(:)
allocate (a, source = b)
end
This is rejected with
allocate (a, source = b)
1
Error: Array specification required
--- Comment #2 from janus at gcc dot gnu dot org 2010-06-13 02:46 ---
I'll assign this to myself (working on a patch ...)
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #19 from janus at gcc dot gnu dot org 2010-06-11 16:46 ---
Subject: Bug 43896
Author: janus
Date: Fri Jun 11 16:45:48 2010
New Revision: 160622
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160622
Log:
2010-06-11 Paul Thomas pa...@gcc.gnu.org
PR fortran
--- Comment #9 from janus at gcc dot gnu dot org 2010-06-11 16:46 ---
Subject: Bug 42051
Author: janus
Date: Fri Jun 11 16:45:48 2010
New Revision: 160622
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160622
Log:
2010-06-11 Paul Thomas pa...@gcc.gnu.org
PR fortran
--- Comment #20 from janus at gcc dot gnu dot org 2010-06-11 16:50 ---
Fixed with r160622. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #24 from janus at gcc dot gnu dot org 2010-06-11 21:33 ---
Here is a somewhat modified version of comment #14, which compiles but produces
wrong code:
module mod1
type :: t1
contains
procedure, nopass :: get = my_get
end type
contains
subroutine my_get
--- Comment #25 from janus at gcc dot gnu dot org 2010-06-11 22:16 ---
This seems to be a module-loading bug. When reading the specific binding of the
TBP 'get' from 'mod1' (which happens in module.c, mio_typebound_proc), we
expect to get the symbol 'my_get' from 'mod1', but instead we
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org
|dot org
--- Comment #9 from janus at gcc dot gnu dot org 2010-06-12 04:02 ---
Subject: Bug 44430
Author: janus
Date: Sat Jun 12 04:02:27 2010
New Revision: 160645
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160645
Log:
2010-06-12 Janus Weil ja...@gcc.gnu.org
PR fortran
--- Comment #10 from janus at gcc dot gnu dot org 2010-06-12 04:03 ---
Fixed on trunk and 4.5. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from janus at gcc dot gnu dot org 2010-06-12 04:10 ---
Subject: Bug 40117
Author: janus
Date: Sat Jun 12 04:10:25 2010
New Revision: 160646
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160646
Log:
2010-06-12 Janus Weil ja...@gcc.gnu.org
PR fortran
--- Comment #3 from janus at gcc dot gnu dot org 2010-06-12 04:12 ---
Fixed with r160646. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from janus at gcc dot gnu dot org 2010-06-11 01:42 ---
Subject: Bug 44207
Author: janus
Date: Fri Jun 11 01:42:38 2010
New Revision: 160589
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160589
Log:
2010-06-10 Janus Weil ja...@gcc.gnu.org
PR fortran
--- Comment #7 from janus at gcc dot gnu dot org 2010-06-11 02:50 ---
At r160588 of gfortran 4.6 trunk, the patch in comment #3 fixes the codes in
comment #1 and #6, but comment #0 seems to get stuck in some kind of infinite
loop.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id
--- Comment #8 from janus at gcc dot gnu dot org 2010-06-11 02:56 ---
(In reply to comment #7)
At r160588 of gfortran 4.6 trunk, the patch in comment #3 fixes the codes in
comment #1 and #6, but comment #0 seems to get stuck in some kind of infinite
loop.
Btw, it also fixes the test
--- Comment #4 from janus at gcc dot gnu dot org 2010-06-09 14:15 ---
Subject: Bug 44211
Author: janus
Date: Wed Jun 9 14:14:08 2010
New Revision: 160478
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160478
Log:
2010-06-09 Janus Weil ja...@gcc.gnu.org
PR fortran
--- Comment #5 from janus at gcc dot gnu dot org 2010-06-09 14:16 ---
Fixed with r160478. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from janus at gcc dot gnu dot org 2010-06-09 18:38 ---
Subject: Bug 44430
Author: janus
Date: Wed Jun 9 18:38:11 2010
New Revision: 160504
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160504
Log:
2010-06-09 Janus Weil ja...@gcc.gnu.org
PR fortran
--- Comment #4 from janus at gcc dot gnu dot org 2010-06-09 21:17 ---
Here's a quick shot at fixing the ICE:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 160503)
+++ gcc/fortran/resolve.c
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org
|dot org
--- Comment #4 from janus at gcc dot gnu dot org 2010-06-08 14:22 ---
Actually this seems to be a duplicate of PR 44211. It is fixed by the patch I
submitted yesterday:
http://gcc.gnu.org/ml/fortran/2010-06/msg00060.html
The patch has been approved by Tobias, and I will commit it once
--- Comment #3 from janus at gcc dot gnu dot org 2010-06-08 14:22 ---
*** Bug 44465 has been marked as a duplicate of this bug. ***
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from janus at gcc dot gnu dot org 2010-06-08 01:19 ---
The backtrace for comment #3 is:
#0 gfc_add_component_ref (e=0x1806e80, name=0x77e7ceb8 doit) at
/home/jweil/gcc46/trunk/gcc/fortran/class.c:77
#1 0x0052b323 in resolve_typebound_subroutine (code
--- Comment #2 from janus at gcc dot gnu dot org 2010-06-08 02:32 ---
Ok, this one took me a while to figure out, but in the end it turns out the fix
is actually pretty simple, once you found out where the problem is:
Index: gcc/fortran/resolve.c
--- Comment #3 from janus at gcc dot gnu dot org 2010-06-06 16:16 ---
(In reply to comment #2)
It looks like a duplicate of the unfixed part of pr43945.
It is. One can reduce the test case here to something equivalent to PR 43945
comment #12, which is:
module foo_mod
type foo
--- 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 #5 from janus at gcc dot gnu dot org 2010-06-06 21:31 ---
I'm afraid you're right. r149586 indeed seems to be the culprit. The bug goes
away when reverting a part of that commit, more precisely this one:
Index: gcc/fortran/resolve.c
--- Comment #6 from janus at gcc dot gnu dot org 2010-06-06 21:45 ---
A simple way to fix this:
Index: gcc/fortran/dump-parse-tree.c
===
--- gcc/fortran/dump-parse-tree.c (revision 160347)
+++ gcc/fortran/dump-parse
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org
|dot org
--- Comment #7 from janus at gcc dot gnu dot org 2010-06-06 21:50 ---
(In reply to comment #5)
The bug goes away when reverting a part of that commit
Of course simply reverting that part causes a couple of regressions, e.g.
proc_ptr_1,10,22 and others.
--
http://gcc.gnu.org
--- 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=gccview=revrev=160335
Log:
2010-06-05 Paul Thomas pa...@gcc.gnu.org
Janus Weil
--- 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
--- 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
--- Comment #15 from janus at gcc dot gnu dot org 2010-06-06 03:17 ---
I guess we can close this, right?
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from janus at gcc dot gnu dot org 2010-06-06 03:26 ---
At r160335, I don't see the failure on x86_64-unknown-linux-gnu. Maybe it has
been fixed by some middle-end changes by now. Can anyone confirm that the error
is gone?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #3 from janus at gcc dot gnu dot org 2010-06-06 03:37 ---
Here is a related test case (by Salvatore):
module s_mat_mod
implicit none
type :: s_sparse_mat
end type
contains
subroutine s_set_triangle(a)
class(s_sparse_mat), intent(inout) :: a
end subroutine
end
--- Comment #3 from janus at gcc dot gnu dot org 2010-05-22 10:21 ---
Subject: Bug 44213
Author: janus
Date: Sat May 22 10:21:32 2010
New Revision: 159695
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159695
Log:
2010-05-22 Janus Weil ja...@gcc.gnu.org
PR fortran
--- Comment #4 from janus at gcc dot gnu dot org 2010-05-22 10:25 ---
Fixed with r159695. Closing.
Thanks to Hans for the report!
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from janus at gcc dot gnu dot org 2010-05-22 19:01 ---
Subject: Bug 44212
Author: janus
Date: Sat May 22 18:55:53 2010
New Revision: 159745
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159745
Log:
2010-05-22 Janus Weil ja...@gcc.gnu.org
PR fortran
--- Comment #5 from janus at gcc dot gnu dot org 2010-05-22 19:31 ---
Fixed with r159745. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from janus at gcc dot gnu dot org 2010-05-20 18:45 ---
Note: The ICE happens with 4.5 and trunk. With 4.4 one gets
allocate(this%list(dim),source=[(i,i=1,dim)])
1
Error: Syntax error in ALLOCATE statement at (1)
since support for the SOURCE
--- Comment #1 from janus at gcc dot gnu dot org 2010-05-20 19:01 ---
Confirmed. Backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x00571d67 in gfc_conv_scalarized_array_ref (se=0x7fffd6a0,
ar=0x17f6048) at /home/jweil/gcc46/trunk/gcc/fortran/trans-array.c
--- Comment #1 from janus at gcc dot gnu dot org 2010-05-20 19:15 ---
Confirmed.
I think the code is valid. At least 'A_type' being defined after 'B_type' is
not a problem, since the Fortran 2003 standard says:
C438 (R440) If the POINTER attribute is not speci#64257;ed for a component
--- Comment #2 from janus at gcc dot gnu dot org 2010-05-20 20:14 ---
To fix this, one basically has to defer the generation of the vtype symbol to
resolution stage, which is what the following patch does:
Index: gcc/fortran/resolve.c
--- Comment #1 from janus at gcc dot gnu dot org 2010-05-20 20:24 ---
My first feeling was that this would be illegal, but I could not find anything
in the standard supporting this feeling. F03 only has the following
restrictions:
C427 (R429) If the type de#64257;nition contains
--- Comment #2 from janus at gcc dot gnu dot org 2010-05-20 20:36 ---
The ICE is fixed by this more or less obvious patch:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 159561)
+++ gcc/fortran
--- Comment #10 from janus at gcc dot gnu dot org 2010-05-18 12:19 ---
(In reply to comment #9)
Btw, after the recent patch for PR43969, this might well be fixed already
...
Unfortunately, no, I still get the ICE.
Sure. Actually my comment was only targeted towards Tobias
--- Comment #6 from janus at gcc dot gnu dot org 2010-05-17 08:25 ---
Subject: Bug 44044
Author: janus
Date: Mon May 17 08:25:06 2010
New Revision: 159476
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159476
Log:
2010-05-17 Janus Weil ja...@gcc.gnu.org
PR fortran
--- Comment #7 from janus at gcc dot gnu dot org 2010-05-17 08:31 ---
Comment #0 and #1 are fixed at this point. I think the runtime checking in
comment #2 one can ignore for the moment, since most usage cases of ordinary
pointers are also not checked for.
So the only ToDo item left
--- Comment #7 from janus at gcc dot gnu dot org 2010-05-17 17:41 ---
(In reply to comment #6)
but it does not fix PR43895 (see comments #3 and #4).
... which I take as an indication that the two are indeed not so much related.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43990
--- Comment #8 from janus at gcc dot gnu dot org 2010-05-17 19:59 ---
Subject: Bug 43990
Author: janus
Date: Mon May 17 19:58:48 2010
New Revision: 159511
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159511
Log:
2010-05-17 Janus Weil ja...@gcc.gnu.org
PR fortran
--- Comment #9 from janus at gcc dot gnu dot org 2010-05-17 20:05 ---
Fixed with r159511. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from janus at gcc dot gnu dot org 2010-05-17 20:35 ---
(In reply to comment #7)
If one adds b = ALLOCATED(x) one finds:
Where do you add this? I don't see a test case where this fits into. Can you
give a complete example?
Btw, after the recent patch for PR43969
--- Comment #6 from janus at gcc dot gnu dot org 2010-05-17 21:02 ---
Another slight variation:
module module_myclass
implicit none
type :: inner
contains
procedure :: set
end type
type :: myclass
type(inner) :: slice
end type
contains
--- Comment #18 from janus at gcc dot gnu dot org 2010-05-16 20:33 ---
(In reply to comment #17)
So it seems tht the bug is not gone. I have tried again with version from May
8th and I still get the problem on line 556.
Yes, the issue is not fixed yet. The commit in comment #16
--- Comment #5 from janus at gcc dot gnu dot org 2010-05-16 22:11 ---
The ICE is fixed by removing this unneeded (and buggy) piece of code:
Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c(revision
--- Comment #6 from janus at gcc dot gnu dot org 2010-05-15 10:21 ---
(In reply to comment #5)
Wild shot: has this anything to do with 43969?
Actually I don't think so. At least the patch I posted yesterday does not fix
PR43969:
http://gcc.gnu.org/ml/fortran/2010-05/msg00155.html
--- Comment #3 from janus at gcc dot gnu dot org 2010-05-15 10:25 ---
(In reply to comment #1)
Created an attachment (id=20542)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20542action=view) [edit]
Looking at the dump of this code shows:
The $data component of int is being set
--- Comment #4 from janus at gcc dot gnu dot org 2010-05-15 10:46 ---
Turns out that fixing this one is completely trivial, once you actually have a
look at it :)
The ALLOCATED intrinsic was just not adjusted to handle CLASS variables yet.
The patch is as simple as this:
Index: gcc
--- Comment #6 from janus at gcc dot gnu dot org 2010-05-15 13:52 ---
Subject: Bug 43969
Author: janus
Date: Sat May 15 13:52:33 2010
New Revision: 159431
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159431
Log:
2010-05-15 Janus Weil ja...@gcc.gnu.org
PR fortran
--- Comment #7 from janus at gcc dot gnu dot org 2010-05-15 13:52 ---
Subject: Bug 43207
Author: janus
Date: Sat May 15 13:52:33 2010
New Revision: 159431
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159431
Log:
2010-05-15 Janus Weil ja...@gcc.gnu.org
PR fortran
--- Comment #8 from janus at gcc dot gnu dot org 2010-05-15 14:08 ---
r159431 fixes the ICE. Comment #0 is now accepted without an error message.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from janus at gcc dot gnu dot org 2010-05-15 14:18 ---
r159431 fixes the problems with allocatable scalar class variables in comment
#1 and #2, and also the wording of the error message reported in comment #5.
However, the ALLOCATED intrinsic still gives a gimplification
--- Comment #5 from janus at gcc dot gnu dot org 2010-05-15 20:02 ---
Here is a slightly reduced test case:
module module_myclass
implicit none
type :: inner
contains
procedure :: set
end type
type :: myclass
type(inner) :: slice
end type
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44154
--- Comment #1 from janus at gcc dot gnu dot org 2010-05-15 20:43 ---
Here is the fix:
Index: gcc/fortran/trans-decl.c
===
--- gcc/fortran/trans-decl.c(revision 159433)
+++ gcc/fortran/trans-decl.c(working copy
--- Comment #3 from janus at gcc dot gnu dot org 2010-05-15 22:03 ---
Subject: Bug 44154
Author: janus
Date: Sat May 15 22:03:09 2010
New Revision: 159445
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159445
Log:
2010-05-15 Janus Weil ja...@gcc.gnu.org
PR fortran
--- Comment #6 from janus at gcc dot gnu dot org 2010-05-15 22:03 ---
Subject: Bug 42647
Author: janus
Date: Sat May 15 22:03:09 2010
New Revision: 159445
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159445
Log:
2010-05-15 Janus Weil ja...@gcc.gnu.org
PR fortran
--- Comment #4 from janus at gcc dot gnu dot org 2010-05-15 22:05 ---
(In reply to comment #2)
This PR looks related to pr42647.
Thanks for the remark, Dominique. I think they're pretty much identical. The
commit (r159445) includes PR42647 comment #2/#3 as a test case.
--
janus
--- Comment #7 from janus at gcc dot gnu dot org 2010-05-15 22:16 ---
r159445 should fix all the initialization trouble. Comment #2/#3 has been
included as a test case.
For the automatic deallocation there is be a problem remaining:
In comment #0, a itself is now automatically
--- Comment #8 from janus at gcc dot gnu dot org 2010-05-15 22:29 ---
(In reply to comment #7)
For the automatic deallocation there is be a problem remaining:
In comment #0, a itself is now automatically deallocated, but not a%d any
more.
This is fixed by this patchlet (which
--- Comment #23 from janus at gcc dot gnu dot org 2010-05-14 11:53 ---
(In reply to comment #22)
Janus, is there something left to do here?
Yes, sure. The ICE has not been fixed yet. With 4.6 trunk (r159368) I still get
the same ICE on comment #8/#14:
internal compiler error
--- Comment #2 from janus at gcc dot gnu dot org 2010-05-14 12:04 ---
(In reply to comment #1)
Copying your code into uh.f90 gives
laptop:kargl[204] gfc4x -o z uh.f90
laptop:kargl[205] ./z
Derived DoIt
with i686-*-freebsd and x86_64-*-freebsd on trunk.
Yes, the failure
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org
|dot org
201 - 300 of 1015 matches
Mail list logo
