--- Comment #3 from janus at gcc dot gnu dot org 2009-11-30 21:25 ---
Fixed on trunk with r154840.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from janus at gcc dot gnu dot org 2009-11-30 21:24 ---
Fixed on trunk with r154840.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42053
--- Comment #2 from janus at gcc dot gnu dot org 2009-11-30 20:43 ---
Subject: Bug 41631
Author: janus
Date: Mon Nov 30 20:43:06 2009
New Revision: 154840
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154840
Log:
merge from fortran-dev branch:
gcc/fortran/
2009-11-3
--- Comment #4 from janus at gcc dot gnu dot org 2009-11-30 20:43 ---
Subject: Bug 42053
Author: janus
Date: Mon Nov 30 20:43:06 2009
New Revision: 154840
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154840
Log:
merge from fortran-dev branch:
gcc/fortran/
2009-11-3
--- Comment #4 from janus at gcc dot gnu dot org 2009-11-29 12:31 ---
(In reply to comment #2)
> On darwin, the errors appear only in 32 bit mode.
Yes, I can confirm this on x86_64-apple-darwin10.2.0. Also, I just ran the
fortran testsuite for the fortran-dev branch on darwin, but
--- Comment #13 from janus at gcc dot gnu dot org 2009-11-26 21:05 ---
Comment #4 is fixed with r154679. For the issues in comment #6 to #10 I have
opened PR42188, so this one can be closed.
--
janus at gcc dot gnu dot org changed:
What|Removed
: 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=42188
--- Comment #2 from janus at gcc dot gnu dot org 2009-11-26 19:05 ---
Fixed with r154679. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from janus at gcc dot gnu dot org 2009-11-26 19:01 ---
Subject: Bug 42167
Author: janus
Date: Thu Nov 26 19:01:02 2009
New Revision: 154679
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154679
Log:
2009-11-26 Janus Weil
PR fortran/42048
--- Comment #12 from janus at gcc dot gnu dot org 2009-11-26 19:01 ---
Subject: Bug 42048
Author: janus
Date: Thu Nov 26 19:01:02 2009
New Revision: 154679
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154679
Log:
2009-11-26 Janus Weil
PR fortran/42048
--
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 2009-11-24 08:28 ---
(In reply to comment #7)
> b) Implicit typing of procedure components:
This has been fixed in PR42045.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39997
--- Comment #6 from janus at gcc dot gnu dot org 2009-11-24 08:18 ---
Fixed with r154492. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from janus at gcc dot gnu dot org 2009-11-24 08:16 ---
Subject: Bug 42045
Author: janus
Date: Tue Nov 24 08:16:32 2009
New Revision: 154492
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154492
Log:
2009-11-24 Janus Weil
PR fortr
--- Comment #1 from janus at gcc dot gnu dot org 2009-11-23 11:41 ---
Another example (with generics):
module foo_module
implicit none
private
public :: foo,rescale
type ,abstract :: foo
contains
procedure(times_interface) ,deferred :: times
procedure(assign_interface
--- Comment #3 from janus at gcc dot gnu dot org 2009-11-23 08:49 ---
Fixed with r154432. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from janus at gcc dot gnu dot org 2009-11-23 08:47 ---
Subject: Bug 42053
Author: janus
Date: Mon Nov 23 08:47:14 2009
New Revision: 154432
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154432
Log:
2009-11-23 Janus Weil
PR fortr
--- Comment #1 from janus at gcc dot gnu dot org 2009-11-22 13:46 ---
Draft patch:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 154423)
+++ gcc/fortran/resolve.c (working copy
id
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=42144
--- Comment #4 from janus at gcc dot gnu dot org 2009-11-20 17:24 ---
With this patch
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 154369)
+++ gcc/fortran/resolve.c (working copy
--- Comment #8 from janus at gcc dot gnu dot org 2009-11-20 16:08 ---
(In reply to comment #7)
> So the only issue left is the wrong static declaration reported in comment #3.
This is now PR 42122. Closing this one.
--
janus at gcc dot gnu dot org changed:
W
Version: 4.5.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=42122
--- Comment #7 from janus at gcc dot gnu dot org 2009-11-20 15:51 ---
The runtime problem and the obsolete comment in the manual are fixed now. So
the only issue left is the wrong static declaration reported in comment #3.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42072
--- Comment #10 from janus at gcc dot gnu dot org 2009-11-20 06:57 ---
(In reply to comment #8)
> I will take it that this is an OK from you.
Sure thing. Thanks for committing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42104
--- Comment #7 from janus at gcc dot gnu dot org 2009-11-19 21:59 ---
(In reply to comment #6)
> Index: gcc/fortran/trans-expr.c
> ===
> --- gcc/fortran/trans-expr.c(revision 154327)
> +++ gcc/fortran/
--- Comment #6 from janus at gcc dot gnu dot org 2009-11-19 21:09 ---
(In reply to comment #5)
> The fix is to make use of the fact a proc_pointer component call is already
> detected and can be used to suppress the internal_pack. Thusly:
>
> Index: gcc/fortran/
--- Comment #4 from janus at gcc dot gnu dot org 2009-11-19 11:57 ---
Let's have a look at the dump for the test case in comment #2.
The call to 'func' is translated to:
real(kind=4) D.1568;
struct array1_real(kind=4) parm.7;
static rea
--- Comment #3 from janus at gcc dot gnu dot org 2009-11-19 10:45 ---
Confirmed.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #6 from janus at gcc dot gnu dot org 2009-11-18 13:25 ---
Subject: Bug 42072
Author: janus
Date: Wed Nov 18 13:24:54 2009
New Revision: 154292
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154292
Log:
2009-11-18 Janus Weil
PR fortr
--- Comment #5 from janus at gcc dot gnu dot org 2009-11-17 12:00 ---
(In reply to comment #3)
> So inside MAIN__ we have:
> static void setpointer (integer(kind=4) (*) (integer(kind=4)));
> setpointer (&ptype);
>
> That is wrong, unless I am missing a refer
--- Comment #1 from janus at gcc dot gnu dot org 2009-11-17 11:47 ---
Since all regressions are OpenMP related, the following patch works without any
testsuite failures:
Index: gcc/fortran/trans.c
===
--- gcc/fortran
--- Comment #2 from janus at gcc dot gnu dot org 2009-11-16 22:55 ---
Proposed fix:
Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c(revision 154189)
+++ gcc/fortran/trans-expr.c(working copy
--- Comment #1 from janus at gcc dot gnu dot org 2009-11-16 22:51 ---
Side-note on C_F_PROCPOINTER: The manual claims that ...
"Due to the currently lacking support of procedure pointers in GNU Fortran this
function is not fully operable."
... which is a dirty lie.
ssigned at gcc dot gnu dot org
ReportedBy: janus at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42072
reject duplicate CLASS IS blocks
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: accepts-invalid
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedB
--- Comment #2 from janus at gcc dot gnu dot org 2009-11-15 18:49 ---
Backtrace:
#0 gfc_conv_variable (se=0x7fffd860, expr=0x1788a00) at
/home/jweil/gcc45/trunk/gcc/fortran/trans-expr.c:550
#1 0x0059ab0a in gfc_conv_expr (se=0x7fffd860, expr=0x1788a00) at
/home/jweil
--- Comment #1 from janus at gcc dot gnu dot org 2009-11-15 18:30 ---
(In reply to comment #0)
> field_grid.f03:27:0: internal compiler error: in gfc_conv_variable, at
> fortran/trans-expr.c:550
Here is a reduced test case which gives the same ICE:
type grid
end type
co
--- Comment #11 from janus at gcc dot gnu dot org 2009-11-15 16:00 ---
(In reply to comment #4)
> Wouldn't it be more obvious to check for attr.result or something like that?
Tobias, I don't quite see how that would work. Simply checking for attr.result
is surely not enou
--- Comment #10 from janus at gcc dot gnu dot org 2009-11-15 15:49 ---
(In reply to comment #9)
> error #6837: The leftmost part-ref in a data-ref can not be a function
> reference.
This is C612 in the Fortran 2003 standard:
R612 data-ref is part-ref [ % part-ref ] ...
R61
--- Comment #9 from janus at gcc dot gnu dot org 2009-11-15 15:40 ---
(In reply to comment #8)
> Let's hope these beasts are all invalid ;)
At least this one is rejected by ifort and NAG. ifort says:
error #6837: The leftmost part-ref in a data-ref can not be a function
r
--- Comment #8 from janus at gcc dot gnu dot org 2009-11-15 15:32 ---
Uh, it seems we're opening a can of worms here. The following also fails:
type(grid) :: g
g = new_field()%mesh
Let's hope these beasts are all invalid ;)
--
http://gcc.gnu.org/bugzilla/show_
--- Comment #7 from janus at gcc dot gnu dot org 2009-11-15 15:24 ---
(In reply to comment #6)
> OTOH, is this even valid?
At first glance, I don't see why it shouldn't be. Btw, this also fails with
type-bound functions:
integer :: i
i = new_field()%mesh%new_int()
--- Comment #6 from janus at gcc dot gnu dot org 2009-11-15 15:12 ---
(In reply to comment #4)
> Besides, it probably fails for strange constructions such as
Another thing that does not work is:
type(field) function new_field()
! ...
end function
subroutine test
c
--- Comment #5 from janus at gcc dot gnu dot org 2009-11-15 15:05 ---
(In reply to comment #4)
> Besides, it probably fails for strange constructions such as
Ah, indeed. Sorry for comitting too early :(
Seems it was not quite obvious enough ...
--
janus at gcc dot gnu dot
--- Comment #3 from janus at gcc dot gnu dot org 2009-11-15 14:55 ---
Fixed with r154190. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from janus at gcc dot gnu dot org 2009-11-15 14:54 ---
Subject: Bug 42048
Author: janus
Date: Sun Nov 15 14:54:05 2009
New Revision: 154190
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154190
Log:
2009-11-15 Janus Weil
PR fortr
--
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 #3 from janus at gcc dot gnu dot org 2009-11-15 14:24 ---
(In reply to comment #2)
> internal compiler error: in gfc_walk_variable_expr, at
> fortran/trans-array.c:6308
The ICE goes away when adding this:
Index: gcc/fortran/res
--- Comment #2 from janus at gcc dot gnu dot org 2009-11-15 12:50 ---
With the following patch, the errors go away:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 154188)
+++ gcc/fortran
--- Comment #1 from janus at gcc dot gnu dot org 2009-11-15 12:39 ---
Cf. also PR39997, the discussion in
http://j3-fortran.org/pipermail/j3/2009-May/002736.html and follow-ups, and
http://www.j3-fortran.org/doc/year/09/09-236r1.txt (which seems to confirm that
the test case is valid
--- Comment #1 from janus at gcc dot gnu dot org 2009-11-15 10:43 ---
The following patch makes the test case compile:
Index: gcc/fortran/match.c
===
--- gcc/fortran/match.c (revision 154106)
+++ gcc/fortran/match.c
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=42048
procedure pointer dummy
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: rejects-valid
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan
--- Comment #5 from janus at gcc dot gnu dot org 2009-11-11 22:38 ---
Fixed with r154107. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from janus at gcc dot gnu dot org 2009-11-11 22:37 ---
Subject: Bug 41978
Author: janus
Date: Wed Nov 11 22:37:31 2009
New Revision: 154107
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=154107
Log:
2009-11-11 Janus Weil
PR fortr
--- Comment #2 from janus at gcc dot gnu dot org 2009-11-11 21:02 ---
(In reply to comment #1)
> I'm not 100% sure, but I think this also applies to PPCs.
If this is correct, then the fix for this PR is as simple as
Index: gcc/fortran/r
--- Comment #1 from janus at gcc dot gnu dot org 2009-11-11 20:38 ---
Replacing the PPC assignment by a plain pointer component assignment
IMPLICIT NONE
TYPE t
integer, pointer :: p
END TYPE t
integer :: i
TYPE(t) :: arr(2)
arr%p => i
END
is being rejected with:
--- Comment #1 from janus at gcc dot gnu dot org 2009-11-11 09:41 ---
Fixed on the fortran-dev branch as of r154089.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from janus at gcc dot gnu dot org 2009-11-04 20:39 ---
(In reply to comment #2)
> While one might not access (type)%dot_g_g as "dot_g_g" is deferred, using
> (class)%dot_g_g is valid. (And using (type)%dot_g_g is not possible as one
> cannot use "
--- Comment #4 from janus at gcc dot gnu dot org 2009-11-04 20:13 ---
Reduced test case:
implicit none
type, abstract :: inner_product_class
contains
procedure(dot), public, nopass, deferred :: dot_g_g
end type
abstract interface
real function dot ()
end
--- Comment #3 from janus at gcc dot gnu dot org 2009-11-04 19:55 ---
The commit in comment #2 contains the patchlet from comment #1 and fixes the
first of the error messages in comment #0.
At this point, the test case still triggers three error messages:
c0.f90:34.14:
operand
--- Comment #5 from janus at gcc dot gnu dot org 2009-11-04 19:46 ---
Fixed with r153911. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from janus at gcc dot gnu dot org 2009-11-04 19:41 ---
Subject: Bug 41937
Author: janus
Date: Wed Nov 4 19:41:07 2009
New Revision: 153911
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153911
Log:
2009-11-04 Tobias Burnus
Janus Weil
--- Comment #2 from janus at gcc dot gnu dot org 2009-11-04 19:41 ---
Subject: Bug 41556
Author: janus
Date: Wed Nov 4 19:41:07 2009
New Revision: 153911
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153911
Log:
2009-11-04 Tobias Burnus
Janus Weil
--- Comment #3 from janus at gcc dot gnu dot org 2009-11-04 16:43 ---
(In reply to comment #0)
> Error: ABSTRACT INTERFACE 'dot' must not be referenced at (1)
The same error appears in PR 41556.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41873
--- Comment #3 from janus at gcc dot gnu dot org 2009-11-04 16:33 ---
(In reply to comment #2)
> Janus, if you want to do the honour, go ahead.
Yes, I can do it.
--
janus at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #3 from janus at gcc dot gnu dot org 2009-10-26 14:44 ---
Created an attachment (id=18898)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18898&action=view)
another test case
This example nicely illustrates why we need a vtable. Here is a more
compactified ver
5.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=41827
--- Comment #9 from janus at gcc dot gnu dot org 2009-10-26 09:13 ---
Fixed with r153547. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from janus at gcc dot gnu dot org 2009-10-26 09:08 ---
Subject: Bug 41714
Author: janus
Date: Mon Oct 26 09:08:03 2009
New Revision: 153547
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153547
Log:
2009-10-26 Janus Weil
PR fortr
--- Comment #5 from janus at gcc dot gnu dot org 2009-10-25 10:24 ---
(In reply to comment #4)
> internal compiler error: in tree_annotate_all_with_location, at gimplify.c:892
This goes away with the following patchlet:
Index: gcc/fortran/trans-exp
--- Comment #16 from janus at gcc dot gnu dot org 2009-10-24 16:53 ---
Fixed with r153534. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from janus at gcc dot gnu dot org 2009-10-24 16:51 ---
Subject: Bug 41784
Author: janus
Date: Sat Oct 24 16:50:41 2009
New Revision: 153534
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153534
Log:
2009-10-24 Janus Weil
Paul Thomas
--- Comment #11 from janus at gcc dot gnu dot org 2009-10-23 18:35 ---
Created an attachment (id=18883)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18883&action=view)
patch
I propose the attached patch. It's an extended version of Paul's patch from
comment
--- Comment #7 from janus at gcc dot gnu dot org 2009-10-23 16:13 ---
Fixed with r153504. 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 2009-10-23 16:10 ---
Subject: Bug 41800
Author: janus
Date: Fri Oct 23 16:10:08 2009
New Revision: 153504
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153504
Log:
2009-10-23 Janus Weil
PR fortr
--- Comment #5 from janus at gcc dot gnu dot org 2009-10-23 12:26 ---
This patch fixes it:
Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c(Revision 153493)
+++ gcc/fortran/trans-expr.c(Arbeitskopie
--- Comment #4 from janus at gcc dot gnu dot org 2009-10-23 11:27 ---
Further reduced test case:
module abstract_gradient
implicit none
private
type, public, abstract :: gradient_class
contains
procedure, nopass :: inner_product
end type
contains
function
--- Comment #3 from janus at gcc dot gnu dot org 2009-10-23 11:10 ---
Backtrace:
Breakpoint 1, fold_convert_loc (loc=0, type=0x7fd3e16529a0, arg=0x7fd3e1659000)
at /home/jweil/gcc45/trunk/gcc/fold-const.c:2789
2789 gcc_unreachable ();
(gdb) bt
#0 fold_convert_loc (loc=0, type
--- Comment #4 from janus at gcc dot gnu dot org 2009-10-23 11:05 ---
Fixed with r153494. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from janus at gcc dot gnu dot org 2009-10-23 11:01 ---
Subject: Bug 41758
Author: janus
Date: Fri Oct 23 11:01:38 2009
New Revision: 153494
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153494
Log:
2009-10-23 Janus Weil
PR fortr
--
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 #8 from janus at gcc dot gnu dot org 2009-10-22 15:09 ---
(In reply to comment #7)
> If I add [...] to this patch (borrowed from other places in module.c),
> comment #4 and comment #1 are also fixed.
The ICEs do go away, but on Salvatore's original cod
--- Comment #6 from janus at gcc dot gnu dot org 2009-10-22 10:05 ---
(In reply to comment #5)
> Created an attachment (id=18865)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18865&action=view) [edit]
> A fix for the PR
This patch fixes fixes comment #3, but not c
--- Comment #4 from janus at gcc dot gnu dot org 2009-10-22 09:31 ---
Here is an even smaller test case with just one module:
module m
type :: A
end type
type, extends(A) :: B
end type
end module
use m, only: A
end
Backtrace (same as in comment #2):
#0 0x7fb6d07bd6a0
--- Comment #9 from janus at gcc dot gnu dot org 2009-10-22 09:10 ---
With r153446, the codes in comment #1, #2 and #4 work as expected. I wanted to
get this out of the way quickly, so that we can make progress on Salvatore's
PSBLAS code, which still does not compile fully and cont
--- Comment #8 from janus at gcc dot gnu dot org 2009-10-22 08:53 ---
Subject: Bug 41781
Author: janus
Date: Thu Oct 22 08:53:26 2009
New Revision: 153446
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153446
Log:
2009-10-22 Janus Weil
PR fortr
--- Comment #3 from janus at gcc dot gnu dot org 2009-10-21 16:02 ---
Here is a further reduced test case:
module A_mod
type :: A
end type
end module
module B_mod
use A_mod
type, extends(A) :: B
end type
end module
module C_mod
use B_mod
type :: C
end type C
end
--- Comment #2 from janus at gcc dot gnu dot org 2009-10-21 15:41 ---
The ICE also happens with a clean trunk.
Here is the backtrace:
#0 0x7fcacadb56a0 in strcmp () from /lib/libc.so.6
#1 0x005419c6 in gfc_find_symtree (st=0x2bcdf30, name=0x0) at
/home/jweil/gcc45/trunk
--- Comment #7 from janus at gcc dot gnu dot org 2009-10-21 15:32 ---
Created an attachment (id=18860)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18860&action=view)
patch v2
With this updated patch the example in comment #4 is rejected with the correct
error
--- Comment #3 from janus at gcc dot gnu dot org 2009-10-21 13:17 ---
Created an attachment (id=18858)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18858&action=view)
patch
Mine. Preliminary patch attached.
--
janus at gcc dot gnu dot org changed:
--- Comment #3 from janus at gcc dot gnu dot org 2009-10-21 09:02 ---
Fixed with r153049. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #7 from janus at gcc dot gnu dot org 2009-10-21 09:01 ---
Fixed with r153049. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from janus at gcc dot gnu dot org 2009-10-21 08:57 ---
Subject: Bug 41766
Author: janus
Date: Wed Oct 21 08:56:56 2009
New Revision: 153049
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153049
Log:
2009-10-21 Janus Weil
PR fortran/41706
--- Comment #6 from janus at gcc dot gnu dot org 2009-10-21 08:57 ---
Subject: Bug 41706
Author: janus
Date: Wed Oct 21 08:56:56 2009
New Revision: 153049
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153049
Log:
2009-10-21 Janus Weil
PR fortran/41706
--- Comment #12 from janus at gcc dot gnu dot org 2009-10-20 20:54 ---
Here is a simple patch which cures the segfault in comment #9. However it does
not tackle the double-free issue.
Index: libgfortran/intrinsics/pack_generic.c
--- Comment #11 from janus at gcc dot gnu dot org 2009-10-20 20:15 ---
Ok, I have identified the place in libgfortran where the segfault happens:
#0 *_gfortran_pack (ret=0x7fffec3ca650, array=0x7fffec3ca620,
mask=0x7fffec3ca440, vector=0x0) at
/home/jweil/gcc45/trunk/libgfortran
--- Comment #10 from janus at gcc dot gnu dot org 2009-10-20 20:06 ---
I have re-checked the F03 standard to verify that the first argument of PACK
can indeed be of arbitrary type:
13.7.89 PACK (ARRAY, MASK [, VECTOR])
Description. Pack an array into an array of rank one under the
--- Comment #9 from janus at gcc dot gnu dot org 2009-10-20 19:56 ---
Apart from the double free issue, there might be a more fundamental problem
with PACK and arrays of derived types. For me, Tobias' test case from comment
#8 segfaults already in the call to _gfortran_pack, and so
--- Comment #1 from janus at gcc dot gnu dot org 2009-10-20 17:17 ---
Mine. Preliminary patch:
Index: gcc/fortran/match.c
===
--- gcc/fortran/match.c (Revision 153009)
+++ gcc/fortran/match.c (Arbeitskopie)
@@ -4047,9
501 - 600 of 1036 matches
Mail list logo
