--- Comment #3 from janus at gcc dot gnu dot org 2010-09-20 16:29 ---
Here is a reduced test case:
module base_mat_mod
type :: base_sparse_mat
contains
procedure :: get_fmt
end type
contains
function get_fmt(a) result(res)
implicit none
class(base_sparse_mat
--- Comment #4 from janus at gcc dot gnu dot org 2010-09-20 17:41 ---
Mine (have a patch).
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from janus at gcc dot gnu dot org 2010-09-20 21:43 ---
Subject: Bug 45438
Author: janus
Date: Mon Sep 20 21:42:54 2010
New Revision: 164462
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164462
Log:
2010-09-20 Janus Weil ja...@gcc.gnu.org
PR fortran
--- Comment #6 from janus at gcc dot gnu dot org 2010-09-20 21:44 ---
Fixed with r164462. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from janus at gcc dot gnu dot org 2010-09-16 12:10 ---
(In reply to comment #3)
Thanks for the quick fix!
Well, it was *your* fix, so *I* should thank *you* :)
Anyway, I think the patch in comment #2 qualifies as obvious, and has no
regressions, as noted by Dominique
--- Comment #6 from janus at gcc dot gnu dot org 2010-09-16 13:13 ---
Subject: Bug 45674
Author: janus
Date: Thu Sep 16 13:12:59 2010
New Revision: 164338
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164338
Log:
2010-09-16 Janus Weil ja...@gcc.gnu.org
PR fortran
--- Comment #7 from janus at gcc dot gnu dot org 2010-09-16 13:14 ---
Fixed with r164338. Closing.
Thanks for the report!
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from janus at gcc dot gnu dot org 2010-09-15 13:50 ---
Subject: Bug 45577
Author: janus
Date: Wed Sep 15 13:50:15 2010
New Revision: 164305
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=164305
Log:
2010-09-15 Janus Weil ja...@gcc.gnu.org
PR fortran
--- Comment #10 from janus at gcc dot gnu dot org 2010-09-15 13:52 ---
Fixed with r164305. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from janus at gcc dot gnu dot org 2010-09-15 13:57 ---
Confirmed. From a quick glimpse it seems the patch goes in the right direction.
Will have a closer look soon.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from janus at gcc dot gnu dot org 2010-09-15 14:46 ---
(In reply to comment #0)
Index: fortran/interface.c
===
--- fortran/interface.c (revision 164288)
+++ fortran/interface.c (working copy)
@@ -1428,10
--- Comment #1 from janus at gcc dot gnu dot org 2010-09-08 09:49 ---
This problem is apparently related to type extension (but not to abstract
types). The following still fails:
implicit none
type :: pointGen
end type pointGen
type, extends(pointGen) :: point2d
--- Comment #2 from janus at gcc dot gnu dot org 2010-09-07 10:26 ---
(In reply to comment #1)
Hi Janus. I wonder whether it could be due to the fix PR fortran/45507; could
you have a look?
Yes. This seems to be the same problem reported by Salvatore (cf.
http://gcc.gnu.org/ml
--- Comment #4 from janus at gcc dot gnu dot org 2010-09-07 22:13 ---
(In reply to comment #3)
I posted a patch at http://gcc.gnu.org/ml/fortran/2010-09/msg00176.html.
The patch fixes this pr.
Well, unfortunately the patch does not really fix the problem, but only defers
--- Comment #5 from janus at gcc dot gnu dot org 2010-09-07 22:34 ---
Here is a better patch:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 163946)
+++ gcc/fortran/resolve.c (working copy
--- Comment #5 from janus at gcc dot gnu dot org 2010-09-04 09:29 ---
Subject: Bug 45507
Author: janus
Date: Sat Sep 4 09:29:11 2010
New Revision: 163856
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163856
Log:
2010-09-04 Janus Weil ja...@gcc.gnu.org
PR fortran
--- Comment #6 from janus at gcc dot gnu dot org 2010-09-04 09:31 ---
Fixed with r163856. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janus at gcc dot gnu dot org
OtherBugsDependingO 39627
nThis:
http://gcc.gnu.org/bugzilla
--- Comment #1 from janus at gcc dot gnu dot org 2010-09-03 09:59 ---
Here is a patch to accept the type declaration in comment #0:
Index: decl.c
===
--- decl.c (revision 163798)
+++ decl.c (working copy
--- Comment #4 from janus at gcc dot gnu dot org 2010-09-03 10:29 ---
Mine.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned
--- Comment #8 from janus at gcc dot gnu dot org 2010-09-02 12:34 ---
Subject: Bug 44541
Author: janus
Date: Thu Sep 2 12:34:26 2010
New Revision: 163773
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163773
Log:
2010-09-02 Janus Weil ja...@gcc.gnu.org
PR fortran
--- Comment #2 from janus at gcc dot gnu dot org 2010-09-02 12:55 ---
Confirmed.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #1 from janus at gcc dot gnu dot org 2010-09-02 19:45 ---
Reduced test case:
use, intrinsic :: iso_c_binding
type :: cType
type(c_ptr) :: accelPtr = c_null_ptr
end type cType
type(cType), allocatable, dimension(:) :: filters
allocate(filters(1))
end
The failure
--- Comment #3 from janus at gcc dot gnu dot org 2010-09-02 19:59 ---
(In reply to comment #1)
Reduced test case:
Sorry, I messed this one up. Should be:
use, intrinsic :: iso_c_binding
type :: cType
type(c_ptr) :: accelPtr = c_null_ptr
end type cType
type(cType), allocatable
--- Comment #1 from janus at gcc dot gnu dot org 2010-09-01 14:26 ---
(In reply to comment #0)
Invalid read of size 1
I don't see this at r163721 (probably has been fixed by r159445).
Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed
--- Comment #6 from janus at gcc dot gnu dot org 2010-09-01 20:51 ---
Subject: Bug 44541
Author: janus
Date: Wed Sep 1 20:50:46 2010
New Revision: 163744
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163744
Log:
2010-09-01 Janus Weil ja...@gcc.gnu.org
PR fortran
--- Comment #6 from janus at gcc dot gnu dot org 2010-08-31 14:17 ---
(In reply to comment #5)
In the meantime, I tried with MOLD= in place of SOURCE=, and in the full
application it still gives a segfault; I think that variant should be checked
as well.
Note that for MOLD
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Severity: normal
Priority: P3
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=45456
--- Comment #1 from janus at gcc dot gnu dot org 2010-08-30 20:36 ---
Here' the fix:
Index: resolve.c
===
--- resolve.c (revision 163648)
+++ resolve.c (working copy)
@@ -1083,7 +1083,8 @@
comp
--- Comment #4 from janus at gcc dot gnu dot org 2010-08-30 20:48 ---
Ok, I could reduce this quite a bit:
program bug23
implicit none
type :: psb_base_sparse_mat
integer, allocatable :: irp(:)
end type psb_base_sparse_mat
class(psb_base_sparse_mat), allocatable
--- Comment #2 from janus at gcc dot gnu dot org 2010-08-30 21:56 ---
Subject: Bug 45456
Author: janus
Date: Mon Aug 30 21:56:28 2010
New Revision: 163661
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163661
Log:
2010-08-30 Janus Weil ja...@gcc.gnu.org
PR fortran
--- Comment #3 from janus at gcc dot gnu dot org 2010-08-30 21:58 ---
Fixed with r163661. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from janus at gcc dot gnu dot org 2010-08-29 09:56 ---
Subject: Bug 45439
Author: janus
Date: Sun Aug 29 09:56:45 2010
New Revision: 163626
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163626
Log:
2010-08-29 Janus Weil ja...@gcc.gnu.org
PR fortran
--- Comment #5 from janus at gcc dot gnu dot org 2010-08-29 09:57 ---
Fixed with r163626. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from janus at gcc dot gnu dot org 2010-08-29 17:22 ---
cf. PR 44529
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45440
--- Comment #5 from janus at gcc dot gnu dot org 2010-08-29 21:10 ---
Mine (working on a patch).
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #29 from janus at gcc dot gnu dot org 2010-08-29 21:29 ---
Subject: Bug 42769
Author: janus
Date: Sun Aug 29 21:29:38 2010
New Revision: 163631
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163631
Log:
2010-08-29 Janus Weil ja...@gcc.gnu.org
PR fortran
--- Comment #30 from janus at gcc dot gnu dot org 2010-08-29 21:36 ---
r163631 fixes comment #27, but the other stuff still fails:
1) the original test case (comment #1, ICE)
2) the reduced version (comment #8, ICE)
3) the variant in comment #24 (wrong-code)
--
http://gcc.gnu.org
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
CC||janus at gcc dot gnu dot org
Status|UNCONFIRMED
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--- Comment #1 from janus at gcc dot gnu dot org 2010-08-28 11:34 ---
Confirmed. One does not even need allocatable components for this. The
following also fails:
logical, allocatable :: z(:)
allocate ( z, source = [ .true., .false., .true.]) ! ICE(segfault)
print *, z
end
--- Comment #2 from janus at gcc dot gnu dot org 2010-08-28 11:46 ---
valgrind says:
==29743== Invalid read of size 4
==29743==at 0x52B37DB: __gmpz_set (in /usr/lib/libgmp.so.3.5.2)
==29743==by 0x532C37: conformable_arrays (resolve.c:6525)
==29743==by 0x533175
--- Comment #3 from janus at gcc dot gnu dot org 2010-08-28 11:51 ---
The following variant segfaults as well (same backtrace):
logical, allocatable :: z(:)
logical, dimension(1:3) :: src = (/ .true., .false., .true. /)
allocate ( z, source = src)
print *, z
end
--
http
--- Comment #4 from janus at gcc dot gnu dot org 2010-08-28 11:55 ---
It works though when explicitly specifying the size of z to allocate:
logical, allocatable :: z(:)
allocate ( z(3), source = [ .true., .false., .true. ] )
print *, z
end
--
http://gcc.gnu.org/bugzilla
--- Comment #2 from janus at gcc dot gnu dot org 2010-08-28 12:18 ---
Reduced test case:
module d_base_mat_mod
implicit none
type :: d_base_sparse_mat
contains
procedure, pass(a) :: mv_to_coo = d_base_mv_to_coo
end type d_base_sparse_mat
interface
subroutine
--- Comment #3 from janus at gcc dot gnu dot org 2010-08-28 12:49 ---
Here's the fix:
Index: match.c
===
--- match.c (revision 163612)
+++ match.c (working copy)
@@ -4532,6 +4532,7 @@ gfc_match_select_type (void
--- Comment #4 from janus at gcc dot gnu dot org 2010-08-27 09:06 ---
(In reply to comment #3)
First, the patch did not apply cleanly, the first hunk was rejected. I applied
it by hand, and I got a problem down the road in my library
--- Comment #7 from janus at gcc dot gnu dot org 2010-08-27 19:02 ---
Subject: Bug 45420
Author: janus
Date: Fri Aug 27 19:02:15 2010
New Revision: 163594
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163594
Log:
2010-08-27 Janus Weil ja...@gcc.gnu.org
PR fortran
--- Comment #8 from janus at gcc dot gnu dot org 2010-08-27 19:14 ---
Fixed with r163594. Closing.
(Salvatore, please open a new PR for your problem in comment #3 if you have
reduced it.)
--
janus at gcc dot gnu dot org changed:
What|Removed
--- Comment #9 from janus at gcc dot gnu dot org 2010-08-27 19:15 ---
Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #1 from janus at gcc dot gnu dot org 2010-08-27 19:40 ---
This should fix it (it was some kind of double-free problem):
Index: gcc/fortran/match.c
===
--- gcc/fortran/match.c (revision 163594)
+++ gcc/fortran
--- Comment #2 from janus at gcc dot gnu dot org 2010-08-27 21:51 ---
Subject: Bug 45432
Author: janus
Date: Fri Aug 27 21:50:47 2010
New Revision: 163599
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163599
Log:
2010-08-27 Janus Weil ja...@gcc.gnu.org
PR fortran
--- Comment #3 from janus at gcc dot gnu dot org 2010-08-27 21:51 ---
Fixed with r163599. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
ReportedBy: janus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45420
--- Comment #1 from janus at gcc dot gnu dot org 2010-08-26 17:54 ---
The dump shows that the first call to 'get_fmt' is executed dynamically as
'a.$vptr-get_fmt(...)', while the ones inside the SELECT TYPE block are
resolved statically to 'd_base_get_fmt'. For the TYPE IS clause
--- Comment #2 from janus at gcc dot gnu dot org 2010-08-26 19:55 ---
It turns out this bug is rather easy to fix. The problem was the we used the
temporary needed for the TYPE IS clause also in the CLASS DEFAULT clause (where
we need none). The following patch fixes it (haven't checked
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
Summary|[OOP] poylmorphic TBP calls |[OOP] polymorphic TBP call
|in a CLASS DEFAULT
--- Comment #6 from janus at gcc dot gnu dot org 2010-08-25 19:09 ---
Ok, I'll close this as fixed since it works on 4.6. And I think we already have
similar test cases from the PRs mentioned above.
--
janus at gcc dot gnu dot org changed:
What|Removed
--- Comment #4 from janus at gcc dot gnu dot org 2010-08-24 11:32 ---
(In reply to comment #3)
Could be a duplicate of PR41784, PR44662 or PR44584.
The fixes for those PRs were not backported to 4.5.
Might be. I'm rather guessing for PR 44064/44065. Actually most of the 34
OOP
--- Comment #6 from janus at gcc dot gnu dot org 2010-08-24 12:57 ---
(In reply to comment #5)
However, when the same change is applied to the original library, a double
free
pops up in another place, unrelated to this issue; this would indicate that
there are other instances
--- Comment #4 from janus at gcc dot gnu dot org 2010-08-23 12:26 ---
Subject: Bug 45366
Author: janus
Date: Mon Aug 23 12:26:42 2010
New Revision: 163468
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163468
Log:
2010-08-23 Janus Weil ja...@gcc.gnu.org
PR fortran
--- Comment #5 from janus at gcc dot gnu dot org 2010-08-23 12:29 ---
Fixed with r163468. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #27 from janus at gcc dot gnu dot org 2010-08-23 13:25 ---
(In reply to comment #24)
Here is a somewhat modified version of comment #14, which compiles but
produces
wrong code:
The example in comment #24 contains a statically-resolved TBP call (the pass
object is non
--- Comment #28 from janus at gcc dot gnu dot org 2010-08-23 13:32 ---
Comment #27 can be fixed by:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 163468)
+++ gcc/fortran/resolve.c
--- Comment #3 from janus at gcc dot gnu dot org 2010-08-23 15:36 ---
Reduced test case:
program bug20
type :: d_base_sparse_mat
integer :: v(10) = 0.
end type d_base_sparse_mat
class(d_base_sparse_mat),allocatable :: a
allocate (d_base_sparse_mat :: a)
select type(aa
--- Comment #1 from janus at gcc dot gnu dot org 2010-08-22 10:50 ---
Confirmed. Thanks for reporting.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from janus at gcc dot gnu dot org 2010-08-22 11:10 ---
(In reply to comment #2)
The problems seems to be that resolve_symbol is called later than the
resolve_formal_arglist check for pureness, i.e. one first checks whether p
is
pure before one copies the attr.pure
--- Comment #4 from janus at gcc dot gnu dot org 2010-08-21 14:51 ---
Subject: Bug 44863
Author: janus
Date: Sat Aug 21 14:50:57 2010
New Revision: 163445
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163445
Log:
2010-08-21 Janus Weil ja...@gcc.gnu.org
PR fortran
--- Comment #11 from janus at gcc dot gnu dot org 2010-08-21 14:51 ---
Subject: Bug 45271
Author: janus
Date: Sat Aug 21 14:50:57 2010
New Revision: 163445
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163445
Log:
2010-08-21 Janus Weil ja...@gcc.gnu.org
PR fortran
--- Comment #7 from janus at gcc dot gnu dot org 2010-08-21 14:51 ---
Subject: Bug 45290
Author: janus
Date: Sat Aug 21 14:50:57 2010
New Revision: 163445
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163445
Log:
2010-08-21 Janus Weil ja...@gcc.gnu.org
PR fortran
--- Comment #5 from janus at gcc dot gnu dot org 2010-08-21 14:59 ---
r163445 adds comment #1 to the testsuite, because it uncovered a regression in
my recent patch for PR 45271 (thanks to Dominique for noticing).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44863
--- Comment #12 from janus at gcc dot gnu dot org 2010-08-21 15:00 ---
Fixed with r163445. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from janus at gcc dot gnu dot org 2010-08-21 15:14 ---
(In reply to comment #3)
Is this now fixable using the default pointer initialization?
At least pointer initialization enables us to initalize the $def_init pointer
component. But still we will need a default
--- Comment #8 from janus at gcc dot gnu dot org 2010-08-21 16:21 ---
Comment #6 is fixed by r163445, but comment #5 is still open.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45290
--- Comment #6 from janus at gcc dot gnu dot org 2010-08-19 11:11 ---
There are also still problems with procedure pointers:
module m
implicit none
procedure(f1), pointer :: pp = f1
contains
integer function f1()
f1 = 42
end function
end module
use m
implicit none
if (pp()/=42
--- Comment #10 from janus at gcc dot gnu dot org 2010-08-19 13:08 ---
(In reply to comment #9)
(In reply to comment #4)
Possible solutions:
1) Make sure we use the right symbol from the right module.
2) Do the vtab initialization inside the module that defines the class, i.e
--- Comment #4 from janus at gcc dot gnu dot org 2010-08-18 22:32 ---
Subject: Bug 45290
Author: janus
Date: Wed Aug 18 22:32:22 2010
New Revision: 163356
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163356
Log:
2010-08-19 Janus Weil ja...@gcc.gnu.org
PR fortran
--- Comment #5 from janus at gcc dot gnu dot org 2010-08-18 22:37 ---
r163356 implements pointer initialization.
Leftover To-Do items:
(1) ICE on
module m
implicit none
integer, target, save :: t1
integer, pointer :: p1 = t
integer, pointer :: p2 = p1! ICE
end module m
(2
--- Comment #3 from janus at gcc dot gnu dot org 2010-08-16 09:37 ---
(In reply to comment #2)
(In reply to comment #0)
Note: For procedure-pointer components I was not able to find any specific
reference to non-NULL default initialization.
It is allowed per:
R440 proc
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janus at gcc dot gnu dot org
OtherBugsDependingO 39627
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45290
--- Comment #9 from janus at gcc dot gnu dot org 2010-08-15 20:01 ---
(In reply to comment #4)
Possible solutions:
1) Make sure we use the right symbol from the right module.
2) Do the vtab initialization inside the module that defines the class, i.e.
add a module procedure like
--- Comment #2 from janus at gcc dot gnu dot org 2010-08-13 08:22 ---
Confirmed.
-fdump-tree-original shows only one difference when exchanging the use
statements:
--- c1.f90.003t.original2010-08-13 10:05:17.720283742 +0200
+++ c1.f90.003t.original.bug2010-08-13 10:04
--- Comment #3 from janus at gcc dot gnu dot org 2010-08-13 09:29 ---
Here is a reduced test case:
module abstract_vector
implicit none
type, abstract :: vector_class
contains
procedure(op_assign_v_v), deferred :: assign
end type vector_class
abstract interface
--- Comment #4 from janus at gcc dot gnu dot org 2010-08-13 09:50 ---
The problem is the following:
We have two routines called 'my_assign' (in two different modules). When
initializing the vtabs in the main program, we happen to use the wrong one:
if (vtab
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
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=45275
--- Comment #5 from janus at gcc dot gnu dot org 2010-08-13 12:36 ---
We have two routines called 'my_assign' (in two different modules). When
initializing the vtabs in the main program, we happen to use the wrong one:
This is because the 'f2k_derived' namespace
--- Comment #7 from janus at gcc dot gnu dot org 2010-08-13 14:31 ---
(In reply to comment #6)
There is code to prevent duplicate names to be imported, but it is bypassed by
vtab and vtype stuff:
This is fine. The problem is not in importing the vtab symbols, but importing
the TBP
--- Comment #8 from janus at gcc dot gnu dot org 2010-08-13 17:23 ---
Actually I think it's a duplicate of PR42769, or at least related.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45271
--- Comment #26 from janus at gcc dot gnu dot org 2010-08-13 17:28 ---
cf. also PR45271
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769
--- Comment #4 from janus at gcc dot gnu dot org 2010-08-11 10:50 ---
Subject: Bug 44595
Author: janus
Date: Wed Aug 11 10:49:56 2010
New Revision: 163096
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=163096
Log:
2010-08-11 Janus Weil ja...@gcc.gnu.org
PR fortran
--- Comment #5 from janus at gcc dot gnu dot org 2010-08-11 11:01 ---
Fixed with r163096. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from janus at gcc dot gnu dot org 2010-08-11 19:30 ---
Both comment #0 and comment #6 work for me without ICE on 4.6 trunk r163095.
Closing as fixed.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from janus at gcc dot gnu dot org 2010-08-09 17:41 ---
(In reply to comment #0)
The problem is in check_variable() in check.c. The first if-statement
prevents the second one from being reached.
Right. However, exchanging them produces lots of regressions, since
--- Comment #14 from janus at gcc dot gnu dot org 2010-08-05 11:58 ---
(In reply to comment #13)
On x86_64-apple-darwin10.4.0 at r162881, I have tested all the codelets I have
for the PRs fixed by r162879 with both -m32 and -m64 without linking error.
Great. So I guess we can close
--- Comment #23 from janus at gcc dot gnu dot org 2010-08-05 12:11 ---
For me all the test cases seems to be working now. Mikael, can we close this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42051
--- Comment #21 from janus at gcc dot gnu dot org 2010-08-05 13:56 ---
Subject: Bug 44929
Author: janus
Date: Thu Aug 5 13:56:00 2010
New Revision: 162914
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=162914
Log:
2010-08-05 Janus Weil ja...@gcc.gnu.org
Steven G
--- Comment #22 from janus at gcc dot gnu dot org 2010-08-05 13:57 ---
Fixed on trunk an 4.5. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #19 from janus at gcc dot gnu dot org 2010-08-04 07:31 ---
(In reply to comment #16)
Here is a better patch:
This patch also fixes the error messages in comment #0 on darwin with -m32.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42207
--- Comment #10 from janus at gcc dot gnu dot org 2010-08-04 08:32 ---
(In reply to comment #9)
With the patch in comment #5 there is one regression:
FAIL: gfortran.dg/typebound_operator_4.f03 -O (test for excess errors)
the extra errors are:
/opt/gcc/work/gcc/testsuite
1 - 100 of 1015 matches
Mail list logo
