--- Comment #6 from janus at gcc dot gnu dot org 2010-03-05 09:36 ---
(In reply to comment #5)
> All of these throw error messages like
>
> ABSTRACT INTERFACE '...' must not be referenced at (1)
This was PR41873 and was fixed by querying "expr->value.func
--- Comment #7 from janus at gcc dot gnu dot org 2010-03-05 09:56 ---
(In reply to comment #6)
> > ABSTRACT INTERFACE '...' must not be referenced at (1)
>
> This was PR41873 and was fixed by querying "expr->value.function.name", which
> fai
--- Comment #8 from janus at gcc dot gnu dot org 2010-03-07 14:07 ---
(In reply to comment #7)
> This leaves us with the following regressions:
>
> FAIL: gfortran.dg/dynamic_dispatch_1.f03 -O0 (test for excess errors)
> FAIL: gfortran.dg/dynamic_dispatch_3.f03 -O0 (tes
--- Comment #10 from janus at gcc dot gnu dot org 2010-03-08 09:35 ---
Subject: Bug 43256
Author: janus
Date: Mon Mar 8 09:35:04 2010
New Revision: 157272
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157272
Log:
2010-03-08 Janus Weil
PR fortr
--- Comment #11 from janus at gcc dot gnu dot org 2010-03-08 09:37 ---
Fixed with r157272. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #18 from janus at gcc dot gnu dot org 2010-03-08 15:43 ---
(In reply to comment #17)
> At revision 157277, I no longer see the ICE, but a bunch of errors:
>
> pr42769.f90:5063.10:
>
> res = a%a%csnmi()
> 1
> Error: Type mismatch in argume
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=43291
--- Comment #20 from janus at gcc dot gnu dot org 2010-03-08 15:50 ---
(In reply to comment #18)
> I will open a new PR for this.
This is now PR 43291.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42769
--- Comment #2 from janus at gcc dot gnu dot org 2010-03-09 09:44 ---
The problem here is that when resolving a polymorphic TBP call, we resolve the
call for each member of the CLASS (i.e. the declared type and all its children,
cf. 'resolve_class_compcall'). In 'check_cl
--- Comment #3 from janus at gcc dot gnu dot org 2010-03-09 09:49 ---
(In reply to comment #2)
> The problem here is that when resolving a polymorphic TBP call, we resolve the
> call for each member of the CLASS (i.e. the declared type and all its
> child
--- Comment #11 from janus at gcc dot gnu dot org 2010-03-10 20:46 ---
(In reply to comment #6)
> > If all appears to be well with the regtest and I do not hear back from you,
> > I
> > will commit the patch to trunk tonight.
>
> The patch clobbers dynamic_dis
h CLASS components
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janus at g
--- Comment #12 from janus at gcc dot gnu dot org 2010-03-10 21:04 ---
(In reply to comment #10)
> In preparing a testcase, I foolishly decided to check the original for correct
> execution.
>
> The following gives the wrong result:
I guess this is worth a separate PR.
--- Comment #1 from janus at gcc dot gnu dot org 2010-03-10 22:06 ---
Here is a simple-minded patch:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 157366)
+++ gcc/fortran/resolve.c
--- Comment #2 from janus at gcc dot gnu dot org 2010-03-10 22:50 ---
(In reply to comment #1)
> This fixes the test case. Haven't tested for regressions yet.
Regtest was successful.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43326
Version: 4.6.0
Status: 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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43696
--- Comment #1 from janus at gcc dot gnu dot org 2010-04-08 21:11 ---
Forgot to mention: This one was reported by Hans-Werner Boschmann (thanks!).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43696
--- Comment #5 from janus at gcc dot gnu dot org 2010-04-12 09:50 ---
(In reply to comment #4)
> I've tried to isolate the error message from the ICE. The smallest code is
> a_module for the error and b_module for the ICE.
Thanks. However, ...
> !!$ f951: internal comp
--- Comment #1 from janus at gcc dot gnu dot org 2010-04-15 21:30 ---
Here is a reduced test case, which ICEs with the same backtrace:
module m_string
type t_string
character, dimension(:), allocatable :: string
contains
procedure :: char => string_to_char
end t
--- Comment #3 from janus at gcc dot gnu dot org 2010-04-18 11:09 ---
It turns out this problem is not specific to the OOP stuff on fortran-dev, but
instead is due to an underlying problem with PROCEDURE statements (which
affects procedure pointers as well as PPCs), demonstrated by this
--- Comment #26 from janus at gcc dot gnu dot org 2010-04-18 13:13 ---
(In reply to comment #25)
> A provisional fix for this PR
Actually, what's the issue here? At rev. 158483 the fortran-dev testsuite runs
cleanly on x86_64-unknown-linux-gnu, and the test cases in this PR
(
--- Comment #6 from janus at gcc dot gnu dot org 2010-04-18 16:42 ---
(In reply to comment #5)
> What about pr42274? Is it a duplicate or not?
I don't think so.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43227
--- Comment #3 from janus at gcc dot gnu dot org 2010-04-19 11:07 ---
Confirmed. Backtrace:
#0 gfc_add_component_ref (e=0x17cb5e0, name=0x77f2fe70 "base_transp1") at
/home/jweil/gcc46/fortran-dev/gcc/fortran/expr.c:703
#1 0x00528306 in resolve_class_typebound_
--- Comment #11 from janus at gcc dot gnu dot org 2010-04-19 12:51 ---
(In reply to comment #10)
> AFAICR the problem is specific to the fortran-dev branch.
No, this is definitely not the case! Only the failure of comment #0 is specific
to the branch. However, this failure is caused
--- Comment #13 from janus at gcc dot gnu dot org 2010-04-19 13:21 ---
> I keep forgetting this test!-(on i686-apple-darwin9, it compiles at revision
> 147438, 20090512, and fails at revision 150825, 20090817).
That's a start. I can see two (hypothetical) candidates in
--- Comment #14 from janus at gcc dot gnu dot org 2010-04-19 13:46 ---
(In reply to comment #13)
> > I keep forgetting this test!-(on i686-apple-darwin9, it compiles at revision
> > 147438, 20090512, and fails at revision 150825, 20090817).
>
> That's
--- Comment #17 from janus at gcc dot gnu dot org 2010-04-19 18:47 ---
(In reply to comment #16)
> I think the culprit is:
>
> Date: Sat Jul 25 11:56:35 2009
> New Revision: 150078
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150078
Close, but not
--- Comment #21 from janus at gcc dot gnu dot org 2010-04-19 21:34 ---
(In reply to comment #20)
> Created an attachment (id=20429)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20429&action=view) [edit]
> A provisional fix for the PR
Yes, the following parts
--- Comment #5 from janus at gcc dot gnu dot org 2010-04-20 12:26 ---
(In reply to comment #4)
> Technically this PR, fixed on trunk but not on fortran-dev, is now a
> [fortran-dev Regression]. Could it be marked that way?
Yes.
--
janus at gcc dot gnu dot org c
--- Comment #4 from janus at gcc dot gnu dot org 2010-04-20 20:51 ---
Further reduced test case:
module base_mod
type :: base_mat
contains
procedure :: transp1 => base_transp1
generic :: transp => transp1
end type base_mat
contains
subroutine base_tra
--- Comment #5 from janus at gcc dot gnu dot org 2010-04-20 21:56 ---
Here is a preliminary patch:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 158513)
+++ gcc/fortran/resolve.c (working
--- Comment #16 from janus at gcc dot gnu dot org 2010-04-22 20:58 ---
For completeness, here is a reduced/modified version of the original test case
in comment #1:
module mod_A
type :: t1
contains
procedure,nopass :: fun
end type
contains
logical function fun()
end
--- Comment #17 from janus at gcc dot gnu dot org 2010-04-25 14:32 ---
Created an attachment (id=20482)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20482&action=view)
patch v2
The attached patch extends the one in comment #7, fixing all regressions
related to non-gener
--- Comment #18 from janus at gcc dot gnu dot org 2010-04-25 14:42 ---
Here is a maximally reduced version of comment #8 example 2, which still fails
with the patch in comment #17:
module m
type :: t1
contains
procedure :: make_integer
generic :: extract => make_inte
--- Comment #19 from janus at gcc dot gnu dot org 2010-04-25 14:56 ---
Created an attachment (id=20484)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20484&action=view)
patch v3
Here is an updated patch, which fixes (among others) comment #8 example 2 and
comment #
--- Comment #22 from janus at gcc dot gnu dot org 2010-04-25 16:43 ---
(In reply to comment #21)
> /opt/gcc/work/gcc/testsuite/gfortran.dg/typebound_operator_3.f03:84:0:
> internal
> compiler error: Segmentation fault
Yes, I can confirm that: typebound_operator_{3,4}.f03
--- Comment #23 from janus at gcc dot gnu dot org 2010-04-25 17:09 ---
Created an attachment (id=20485)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20485&action=view)
patch v4
The attached update of the patch removes the ICEs in
typebound_operator_{3,4}.f03.
--
--- Comment #24 from janus at gcc dot gnu dot org 2010-04-25 17:16 ---
(In reply to comment #20)
> My suspicion, which is strengthened by the remaining regressions for version 3
> of your fix, is that the generic components of the vtab should not be marked
> as
> ppc.
--- Comment #25 from janus at gcc dot gnu dot org 2010-04-25 18:23 ---
I just did a full testsuite run, verifying that "dynamic_dispatch_{1-3}.f03"
are indeed the only failures with the patch in comment #23.
This means that, if we can fix the failure in comment #24, the b
--- Comment #30 from janus at gcc dot gnu dot org 2010-04-25 19:50 ---
(In reply to comment #29)
> (In reply to comment #27)
> > Created an attachment (id=20486)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20486&action=view) [edit]
> >
> Tried this pat
--- Comment #31 from janus at gcc dot gnu dot org 2010-04-25 20:17 ---
Ok, back to fixing the remaining regression, namely comment #24. Compiling this
with and without the patch in comment #23 shows the following difference:
--- c24.dump.unpatched 2010-04-25 22:03:44.418204091 +0200
--- Comment #33 from janus at gcc dot gnu dot org 2010-04-25 21:44 ---
Created an attachment (id=20488)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20488&action=view)
patch v5
The attached version of the patch clears the failures of
dynamic_dispatch_{1-3}.f03. It is
--- Comment #34 from janus at gcc dot gnu dot org 2010-04-25 22:26 ---
(In reply to comment #33)
> Will do a full testsuite run now.
The testsuite completed cleanly, without any failures. Paul, if you agree that
this patch is ok, I can commit it tomorrow.
--
http://gcc.gnu.
--- Comment #36 from janus at gcc dot gnu dot org 2010-04-26 09:08 ---
Subject: Bug 42274
Author: janus
Date: Mon Apr 26 09:07:26 2010
New Revision: 158721
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158721
Log:
2010-04-26 Janus Weil
PR fortr
--- Comment #3 from janus at gcc dot gnu dot org 2010-04-26 14:56 ---
Note: There is another OOP PR which fails only with optimization: PR41753.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43895
--- Comment #4 from janus at gcc dot gnu dot org 2010-04-26 15:04 ---
Confirmed.
It seems this fails already with the 4.5 release as well as with current trunk,
which means that it's not specific to the fortran-dev branch.
--
janus at gcc dot gnu dot org changed:
--- Comment #3 from janus at gcc dot gnu dot org 2010-04-26 17:33 ---
Confirmed. The ICE happens with 4.5, trunk and fortran-dev.
Thanks for the report!
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from janus at gcc dot gnu dot org 2010-04-26 19:10 ---
(In reply to comment #3)
> The ICE happens with 4.5, trunk and fortran-dev.
Actually this is only half-true. With fortran-dev one already gets an ICE on
the first file, which is different from the one reported
--- Comment #6 from janus at gcc dot gnu dot org 2010-04-26 19:33 ---
Here is a reduced test case for the fortran-dev failure, which turns out to be
pretty trivial. All it takes is an array-valued TBP (wonder if we don't have
such a thing in the testsuite already):
m
--- Comment #8 from janus at gcc dot gnu dot org 2010-04-26 20:40 ---
Ok, here is a preliminary patch which fixes the fortran-dev problem:
Index: gcc/fortran/symbol.c
===
--- gcc/fortran/symbol.c(revision 158741
--- Comment #10 from janus at gcc dot gnu dot org 2010-04-27 07:38 ---
Subject: Bug 43896
Author: janus
Date: Tue Apr 27 07:38:06 2010
New Revision: 158767
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158767
Log:
2010-04-27 Janus Weil
PR fortr
--- Comment #11 from janus at gcc dot gnu dot org 2010-04-27 07:41 ---
The commit in comment #10 fixes the fortran-dev regression, but not the
original problem in comment #0.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #15 from janus at gcc dot gnu dot org 2010-04-27 21:40 ---
I've reduced the test case to the bare minimum required to trigger the ICE:
module m_rotation_matrix
type t_rotation_matrix
end type
contains
function rotation_matrix_times_vector( left ) resul
--- 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 #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 #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 #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 #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-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
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 #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
--- 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
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 #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
--- 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 #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 #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 #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 #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 #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
--
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 #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
--- 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 #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
: 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 #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
--- 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 #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 #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 #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 #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 #2 from janus at gcc dot gnu dot org 2009-11-30 23:03 ---
(In reply to comment #0)
> This gives
>
> undefined reference to `create_interface_'
>
> when linking. 'create_interface' is the abstract interface of the deferred
> TBP.
> In
--- Comment #3 from janus at gcc dot gnu dot org 2009-12-01 09:11 ---
This simple patch fixes comment #0 (but not comment #1):
Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c(revision 154840)
+++ gcc
--- Comment #5 from janus at gcc dot gnu dot org 2009-12-01 22:09 ---
Btw: The example in comment #1 is affected by PR41829, which can be avoided by
moving the subroutine 'rescale' to the main program. However, this still fails
(also with the patch from comment #3):
module
--- Comment #1 from janus at gcc dot gnu dot org 2009-12-03 07:32 ---
Confirmed. The ICE's backtrace is
#0 0x00504bcf in load_derived_extensions () at
/home/jweil/gcc45/trunk/gcc/fortran/module.c:4019
#1 0x00505938 in read_module () at
/home/jweil/gcc45/trun
--- Comment #6 from janus at gcc dot gnu dot org 2009-12-04 17:06 ---
(In reply to comment #5)
> #3 0x004fa344 in mio_component (c=0x154b880) at
> /home/tob/projects/fortran-dev/gcc/fortran/module.c:2362
The component here is 'is_null', and the parent
--- Comment #7 from janus at gcc dot gnu dot org 2009-12-04 19:43 ---
(In reply to comment #6)
> I think the problem is that c->tb->ppc is not set correctly for the PPCs
> inside
> vtype.
The following patches fixes it:
Index: gcc/f
--- Comment #9 from janus at gcc dot gnu dot org 2009-12-05 11:20 ---
(In reply to comment #8)
> With the patch in comment #7 the tests in pr41829 and the following ones
> segfault at runtime.
Confirmed. This may be an initialization issue of the vtypes. Reduced test
case:
mo
--- Comment #11 from janus at gcc dot gnu dot org 2009-12-05 15:14 ---
(In reply to comment #8)
> With the patch in comment #7 the tests in pr41829 and the following ones
> segfault at runtime.
Since these run fine with a clean fortran-dev, this is a regression of my
patch
--- Comment #17 from janus at gcc dot gnu dot org 2009-12-06 22:57 ---
Subject: Bug 41478
Author: janus
Date: Sun Dec 6 22:57:13 2009
New Revision: 155024
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155024
Log:
libgfortran/
2009-12-06 Janus Weil
PR fortr
--- Comment #3 from janus at gcc dot gnu dot org 2009-12-06 22:57 ---
Subject: Bug 42268
Author: janus
Date: Sun Dec 6 22:57:13 2009
New Revision: 155024
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155024
Log:
libgfortran/
2009-12-06 Janus Weil
PR fortr
--- Comment #4 from janus at gcc dot gnu dot org 2009-12-06 22:59 ---
Fixed on trunk with r155024. Will commit to 4.4 in a few days.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42268
--- Comment #5 from janus at gcc dot gnu dot org 2009-12-07 21:00 ---
Further reduced test case:
type t
integer, allocatable :: d(:)
end type
type(t), allocatable :: a(:)
allocate(a(2))
call sub( (/ a /) )
contains
subroutine sub(b)
type(t) :: b(:)
end
--- Comment #1 from janus at gcc dot gnu dot org 2009-12-09 18:03 ---
> Error: 'bad_id' at (1) is not an accessible derived type
> f951: internal compiler error: Segmentation fault
Confirmed. The same happens for TYPE IS (bad_id).
--
janus at gcc dot gnu
--- Comment #2 from janus at gcc dot gnu dot org 2009-12-09 18:06 ---
Backtrace:
#0 0x00549274 in gfc_find_sym_tree (name=0x7fffd840 "v",
ns=0x17a28b0, parent_flag=1, result=0x7fffd750)
at /home/jweil/gcc45/fortran-dev/gcc/fortran/symbol
--- Comment #3 from janus at gcc dot gnu dot org 2009-12-09 18:17 ---
Mine.
I think this one-liner is all that's needed:
Index: gcc/fortran/symbol.c
===
--- gcc/fortran/symbol.c(revision 155023)
+++ gcc/fo
--- Comment #5 from janus at gcc dot gnu dot org 2009-12-10 20:29 ---
Subject: Bug 42268
Author: janus
Date: Thu Dec 10 20:28:57 2009
New Revision: 155139
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155139
Log:
libgfortran/
2009-12-10 Janus Weil
PR fortr
--- Comment #6 from janus at gcc dot gnu dot org 2009-12-10 20:30 ---
Fixed on trunk and 4.4. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #14 from janus at gcc dot gnu dot org 2009-12-10 21:21 ---
Comparing the dump of the test case in comment #9 with and without the patch in
comment #11 shows that with the patch the following is missing:
@@ -25,10 +25,6 @@ MAIN__ ()
integer(kind=4) itmp;
extern struct
--- Comment #4 from janus at gcc dot gnu dot org 2009-12-11 14:40 ---
Subject: Bug 42335
Author: janus
Date: Fri Dec 11 14:40:36 2009
New Revision: 155162
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155162
Log:
gcc/fortran/
2009-12-11 Janus Weil
PR fortr
501 - 600 of 1036 matches
Mail list logo
