--- 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-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=gcc&view=rev&rev=164462
Log:
2010-09-20 Janus Weil
PR fortr
--- 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 #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 #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 #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=gcc&view=rev&rev=164338
Log:
2010-09-16 Janus Weil
PR fortr
--- 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 Domini
--- 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 (
--- 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 #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 #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=gcc&view=rev&rev=164305
Log:
2010-09-15 Janus Weil
PR fortr
--- 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 #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 #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 on
--- 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.
--- 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
--- 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=gcc&view=rev&rev=163856
Log:
2010-09-04 Janus Weil
PR fortr
--- 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 at
--- 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
: 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 #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), allocata
--- 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 #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 #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=gcc&view=rev&rev=163773
Log:
2010-09-02 Janus Weil
PR fortr
--- 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=gcc&view=rev&rev=163744
Log:
2010-09-01 Janus Weil
PR fortr
--- 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
--- 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 M
--- 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 #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=gcc&view=rev&rev=163661
Log:
2010-08-30 Janus Weil
PR fortr
--- 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 :: a
--- 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 @@
mal
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
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--- 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
--- 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=gcc&view=rev&rev=163631
Log:
2010-08-29 Janus Weil
PR fortr
--- 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 #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 09:57 ---
Fixed with r163626. 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=gcc&view=rev&rev=163626
Log:
2010-08-29 Janus Weil
PR fortr
--- 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
--- 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
subrout
--- 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 #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 #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 #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
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
CC||janus at gcc dot gnu dot org
Status|UNCONFIRMED
--- 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
--- 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=gcc&view=rev&rev=163599
Log:
2010-08-27 Janus Weil
PR fortr
--- 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 #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 #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 #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=gcc&view=rev&rev=163594
Log:
2010-08-27 Janus Weil
PR fortr
--- 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 l
--
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 #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 ch
--- 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&#
ponent: 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=45420
--- 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|Re
--- 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 oth
--- 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
--- 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 #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 #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
obje
--- 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 #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=gcc&view=rev&rev=163468
Log:
2010-08-23 Janus Weil
PR fortr
--- 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
--- 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 #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 #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 defa
--- 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 #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 #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=gcc&view=rev&rev=163445
Log:
2010-08-21 Janus Weil
PR fortran/45271
--- 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=gcc&view=rev&rev=163445
Log:
2010-08-21 Janus Weil
PR fortran/45271
--- 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=gcc&view=rev&rev=163445
Log:
2010-08-21 Janus Weil
PR fortran/45271
--- 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 t
--- 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
--- 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 mo
--- 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=gcc&view=rev&rev=163356
Log:
2010-08-19 Janus Weil
PR fortr
--- 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 a
--- 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 pr
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/show_bug.cgi?id=45290
--- 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 #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 #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
t
--- 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_
oduct: gcc
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 #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:
--- 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 #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 #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 #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 #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=gcc&view=rev&rev=163096
Log:
2010-08-11 Janus Weil
PR fortr
--- 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, sin
--- 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 #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=gcc&view=rev&rev=162914
Log:
2010-08-05 Janus Weil
Steven
--- 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 #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
--- Comment #12 from janus at gcc dot gnu dot org 2010-08-04 20:05 ---
r162879 seems to fix all the test cases for me. Can anyone confirm that comment
#0 works now without any linking errors?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44065
--- Comment #21 from janus at gcc dot gnu dot org 2010-08-04 20:00 ---
Fixed with r162879. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
1 - 100 of 1036 matches
Mail list logo
