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=44110
--- Comment #3 from janus at gcc dot gnu dot org 2010-05-13 14:47 ---
(In reply to comment #0)
fff.f90:26:0: internal compiler error: in gfc_conv_structure, at
fortran/trans-expr.c:4390
It turns out this ICE is actually due to the NULL() initialization of the class
pointer and has
--- Comment #4 from janus at gcc dot gnu dot org 2010-05-13 14:55 ---
When removing the NULL initialization in comment #3, the dump shows:
static struct .class.parent.p this = {.$data=0B};
Zeroing the $data pointer is probably not needed without NULL initialization.
With NULL
--- Comment #5 from janus at gcc dot gnu dot org 2010-05-10 12:54 ---
Subject: Bug 44044
Author: janus
Date: Mon May 10 12:54:25 2010
New Revision: 159217
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159217
Log:
2010-05-10 Janus Weil ja...@gcc.gnu.org
PR fortran
--- Comment #3 from janus at gcc dot gnu dot org 2010-05-10 21:59 ---
For me, compiling the code in comment #0 in a single file seems to get stuck in
an endless loop (trunk rev. 159217 on x86_64-unknown-linux-gnu).
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44064
--- Comment #2 from janus at gcc dot gnu dot org 2010-05-10 22:06 ---
Confirmed.
Compiling via ...
gfortran-4.6 -c module.f90
gfortran-4.6 test.f90
... works, though.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
selector
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janus
--
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
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
--- Comment #1 from janus at gcc dot gnu dot org 2010-05-08 20:13 ---
Side note: Invalid code like
function fun()
class(t1) :: fun
end function
is not rejected, although the polymorphic 'fun' is neither a pointer,
allocatable nor a dummy.
--
http://gcc.gnu.org/bugzilla
--- Comment #2 from janus at gcc dot gnu dot org 2010-05-08 20:20 ---
Bonus feature #1:
Adding this to comment #0 ...
select type ( y = fun(0) )
type is (t1)
print *,t1
type is (t2)
print *,t2
class default
print *,default
end select
... should give a runtime error, since fun(0
--- Comment #3 from janus at gcc dot gnu dot org 2010-05-08 20:23 ---
Bonus feature #2:
select type ( y = fun(1) )
type is (t1)
y%i = 1
type is (t2)
y%i = 2
end select
... should be rejected, due to (F08):
C836 (R847) If selector is not a variable or is a variable that has
--- Comment #7 from janus at gcc dot gnu dot org 2010-05-05 07:45 ---
Subject: Bug 43696
Author: janus
Date: Wed May 5 07:44:33 2010
New Revision: 159056
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=159056
Log:
2010-05-05 Janus Weil ja...@gcc.gnu.org
PR fortran
--- Comment #1 from janus at gcc dot gnu dot org 2010-05-05 08:12 ---
Works for me on x86_64-unknown-linux-gnu.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #8 from janus at gcc dot gnu dot org 2010-05-05 08:13 ---
Fixed with r159056. 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=43990
--- Comment #2 from janus at gcc dot gnu dot org 2010-05-05 13:07 ---
It also works on x86_64-apple-darwin10.3.0.
Does the failure on ia64 only happen with -O3?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43986
--- Comment #6 from janus at gcc dot gnu dot org 2010-05-03 20:03 ---
Mine. I think fixing comment #0 is as easy as the following two-liner:
Index: gcc/fortran/symbol.c
===
--- gcc/fortran/symbol.c(revision 158970
--- 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=gccview=revrev=158767
Log:
2010-04-27 Janus Weil ja...@gcc.gnu.org
PR fortran
--- 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 ) result(res
--- 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=gccview=revrev=158721
Log:
2010-04-26 Janus Weil ja...@gcc.gnu.org
PR fortran
--- 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:
What
--- 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):
module
--- 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 #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=20482action=view)
patch v2
The attached patch extends the one in comment #7, fixing all regressions
related to non-generic TBPs
--- 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_integer
--- 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=20484action=view)
patch v3
Here is an updated patch, which fixes (among others) comment #8 example 2 and
comment #18. The remaining
--- 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 both fail
--- 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=20485action=view)
patch v4
The attached update of the patch removes the ICEs in
typebound_operator_{3,4}.f03.
--
http
--- 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. I have been tempted
--- 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 branch will most
--- 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=20486action=view) [edit]
Tried this patch: compilation goes past
--- 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=20488action=view)
patch v5
The attached version of the patch clears the failures of
dynamic_dispatch_{1-3}.f03. It is free
--- 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.org
--- 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 #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 changed
--- 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_transp1
--- 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 #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_call (code
--- 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 this range
--- 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 a start. I can see two (hypothetical
--- 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=gccview=revrev=150078
Close, but not quite :)
It's actually r150047
--- 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=20429action=view) [edit]
A provisional fix for the PR
Yes, the following parts are approved (they're
--- 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
--- 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
(gfcbug96
--- 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 #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 type
--- 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 compiler error
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 #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_dispatch_4.f03.
Hm, funny. For me
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 gcc dot gnu dot org
http
--- 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. It's PR43326 now
--- 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
--- 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_class_members' we
--- 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
children,
cf. 'resolve_class_compcall
--- 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=gccview=revrev=157272
Log:
2010-03-08 Janus Weil ja...@gcc.gnu.org
PR fortran
--- 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 argument 'a' at (1); passed
CLASS
: 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 #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 (test for excess
--- 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.function.name, which
fails now. We
--- 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
fails now. We should find a better way to silence
--- Comment #7 from janus at gcc dot gnu dot org 2010-03-04 09:17 ---
(In reply to comment #6)
Without looking at the code yet, the matcher must see a space or double colon
after the word FINAL before matching it. If it sees anything else, its a
MATCH_NO not a MATCH_ERROR
--- Comment #10 from janus at gcc dot gnu dot org 2010-03-04 10:35 ---
(In reply to comment #9)
From: F2003, 3.3.2 Fixed source form: Except in a character context, blanks
are insignificant and may be used freely throughout the program.
I guess this is what triggered the famous quote
--- Comment #12 from janus at gcc dot gnu dot org 2010-03-04 12:06 ---
(In reply to comment #11)
I think it dates back to punch cards;
Yes, I've seen those. However, being born too late, I never had the chance to
use them :)
I wouldn't expect anyone to use F03 FINAL statements
--- Comment #14 from janus at gcc dot gnu dot org 2010-03-04 13:42 ---
Subject: Bug 43244
Author: janus
Date: Thu Mar 4 13:42:06 2010
New Revision: 157226
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157226
Log:
2010-03-04 Janus Weil ja...@gcc.gnu.org
PR fortran
--- Comment #15 from janus at gcc dot gnu dot org 2010-03-04 13:58 ---
Fixed with r157226. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
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 gcc dot gnu dot org
http://gcc.gnu.org/bugzilla
--- Comment #1 from janus at gcc dot gnu dot org 2010-03-04 16:04 ---
(In reply to comment #0)
Apparently this only happens for type-bound character-valued functions (but
not
for subroutines or e.g. integer-valued functions).
Actually that is wrong. It does work with subroutines
--- Comment #2 from janus at gcc dot gnu dot org 2010-03-04 16:11 ---
Btw, I just checked an analogous example with a procedure pointer component
instead of a type-bound procedure, and this works.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43256
--- Comment #3 from janus at gcc dot gnu dot org 2010-03-04 21:14 ---
Ok, think I got it. It's a one-liner:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 157225)
+++ gcc/fortran/resolve.c
--- Comment #4 from janus at gcc dot gnu dot org 2010-03-04 22:10 ---
(In reply to comment #3)
Hope this produces no regressions.
Unfortunately it does :(
FAIL: gfortran.dg/dynamic_dispatch_1.f03 -O0 (test for excess errors)
FAIL: gfortran.dg/dynamic_dispatch_3.f03 -O0 (test
--- Comment #5 from janus at gcc dot gnu dot org 2010-03-04 22:44 ---
(In reply to comment #4)
FAIL: gfortran.dg/dynamic_dispatch_1.f03 -O0 (test for excess errors)
FAIL: gfortran.dg/dynamic_dispatch_3.f03 -O0 (test for excess errors)
FAIL: gfortran.dg/dynamic_dispatch_4.f03 -O0
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=43244
--- Comment #1 from janus at gcc dot gnu dot org 2010-03-03 09:49 ---
IIRC the parsing of FINAL declarations was implemented by Daniel Kraft. It was
committed as r136293. Daniel, could you have a look at this bug?
--
janus at gcc dot gnu dot org changed:
What|Removed
--- Comment #2 from janus at gcc dot gnu dot org 2010-03-03 09:54 ---
(In reply to comment #0)
With so many compilers rejecting it, I wonder: Is it actually legal?
I guess not. Changing the line in question to
finalstate(1,1:2)%ID = (/1,103/)
makes all compilers accept it (including
--- Comment #10 from janus at gcc dot gnu dot org 2010-03-03 15:13 ---
Subject: Bug 43169
Author: janus
Date: Wed Mar 3 15:12:40 2010
New Revision: 157196
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=157196
Log:
2010-03-03 Janus Weil ja...@gcc.gnu.org
PR fortran
--- Comment #11 from janus at gcc dot gnu dot org 2010-03-03 15:17 ---
Fixed with r157196. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from janus at gcc dot gnu dot org 2010-03-03 15:40 ---
Quick fix for free form:
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c (revision 157195)
+++ gcc/fortran/decl.c (working copy)
@@ -7810,6
--- Comment #6 from janus at gcc dot gnu dot org 2010-03-02 23:31 ---
Here is another very similar example:
implicit none
type :: lorenz
end type lorenz
type(lorenz) :: attractor
print *,output(attractor)
contains
function output(this) result(coordinates)
class(lorenz
--- Comment #9 from janus at gcc dot gnu dot org 2010-03-01 12:47 ---
Even with the patch from comment #7, another thing goes wrong with BLOCK
statements:
pure subroutine swap
implicit none
real :: r1
block
real :: r2
r1 = 42.
r2 = 43.
end block
--- Comment #1 from janus at gcc dot gnu dot org 2010-02-25 08:38 ---
Confirmed. Here is a reduced test case:
pure subroutine swap(x)
implicit none
type :: myType
real :: a
end type myType
class(myType), intent(inout) :: x
select type(x)
class is (myType
--- Comment #2 from janus at gcc dot gnu dot org 2010-02-25 09:08 ---
The problem lies in gfc_impure_variable (resolve.c), where it is checked if the
namespace of the variable equals the local namespace of the pure procedure.
This check fails if the procedure has sub-namespaces.
We
--- Comment #3 from janus at gcc dot gnu dot org 2010-02-25 09:13 ---
Regarding BLOCK, it seems there is an additional problem: Assignments inside a
BLOCK are not checked at all, as the following case shows ...
implicit none
real :: glob
contains
pure subroutine swap
--- Comment #4 from janus at gcc dot gnu dot org 2010-02-25 09:19 ---
Contained procedures are not affected by this bug, since a procedure contained
in a pure procedure must itself be pure. Therefore something like this is
invalid (as gfortran correctly detects):
module m
implicit
--- Comment #5 from janus at gcc dot gnu dot org 2010-02-25 12:16 ---
(In reply to comment #3)
Seems like statements inside a BLOCK are not being resolved at all?!?
Sorry, this is wrong. They are resolved alright. The problem is just that
'gfc_pure' does not work (checking if we're
--- Comment #6 from janus at gcc dot gnu dot org 2010-02-25 12:54 ---
(In reply to comment #2)
The problem lies in gfc_impure_variable (resolve.c), where it is checked if
the
namespace of the variable equals the local namespace of the pure procedure.
This check fails
--- Comment #7 from janus at gcc dot gnu dot org 2010-02-25 13:40 ---
(In reply to comment #5)
(In reply to comment #3)
Seems like statements inside a BLOCK are not being resolved at all?!?
Sorry, this is wrong. They are resolved alright. The problem is just that
'gfc_pure' does
--- Comment #21 from janus at gcc dot gnu dot org 2010-01-31 21:56 ---
Subject: Bug 42888
Author: janus
Date: Sun Jan 31 21:56:02 2010
New Revision: 156418
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=156418
Log:
gcc/fortran/
2010-01-31 Janus Weil ja...@gcc.gnu.org
--- Comment #22 from janus at gcc dot gnu dot org 2010-01-31 22:01 ---
Fixed with r156418. Thanks for the report!
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #19 from janus at gcc dot gnu dot org 2010-01-30 10:29 ---
(In reply to comment #17)
There is another problem left with the patch. I am not sure whether the
code is legal, but it gives an ICE for me:
implicit none
type t
integer :: X = -999.0 ! Real
301 - 400 of 1015 matches
Mail list logo
