oduct: 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: janus at gcc dot gnu dot org
http://gcc.gnu.or
--- Comment #5 from janus at gcc dot gnu dot org 2009-10-20 12:29 ---
(In reply to comment #4)
> Oh bother! I completely forgot to test the subroutine branch - thanks Janus
But in your patch you do the argument resolution both in resolve_class_compcall
and resolve_class_typebound_c
--- Comment #3 from janus at gcc dot gnu dot org 2009-10-20 11:30 ---
Reopening. Salvatore's code still fails with the same error, which is due to
the analogous case with a subroutine:
module m
type :: t
contains
procedure, nopass :: a
procedure, nopass :: b
end type
con
allocate
Product: gcc
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=41758
--- Comment #6 from janus at gcc dot gnu dot org 2009-10-19 19:23 ---
Fixed with r152988. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from janus at gcc dot gnu dot org 2009-10-19 19:21 ---
Subject: Bug 41586
Author: janus
Date: Mon Oct 19 19:21:18 2009
New Revision: 152988
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152988
Log:
2009-10-19 Janus Weil
PR fortr
--- Comment #4 from janus at gcc dot gnu dot org 2009-10-19 18:46 ---
Mine. Have a patch:
http://gcc.gnu.org/ml/fortran/2009-10/msg00171.html
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from janus at gcc dot gnu dot org 2009-10-16 21:25 ---
(In reply to comment #3)
> In addition to this there are two more test cases failing:
Sorry, these were fake (my local source tree was messed up). The only real
failure is class_allocate_1.f03, from which one
--- Comment #8 from janus at gcc dot gnu dot org 2009-10-16 21:12 ---
Fixed with r152919. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--
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 #7 from janus at gcc dot gnu dot org 2009-10-16 21:10 ---
Subject: Bug 41719
Author: janus
Date: Fri Oct 16 21:10:43 2009
New Revision: 152919
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152919
Log:
2009-10-16 Janus Weil
PR fortr
--- Comment #3 from janus at gcc dot gnu dot org 2009-10-16 21:04 ---
> AND ALSO FOR:
>
> type t0
> end type t0
> type(t0), allocatable :: m(:)
> allocate(t0 :: m(3))
> end
No, this one actually works (since 'm' is not a scalar):
if (m.data != 0B)
--- Comment #5 from janus at gcc dot gnu dot org 2009-10-16 19:19 ---
(In reply to comment #4)
> Note: It seems this will be legal again in F08.
That is: for certain cases (ALLOCATABLE). The example in comment #0 is still
illegal.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi
--- Comment #4 from janus at gcc dot gnu dot org 2009-10-16 19:10 ---
Note: It seems this will be legal again in F08.
7.2.1.2 Intrinsic assignment statement
An intrinsic assignment statement is an assignment statement that is not a
defined assignment statement (7.2.1.4).
In an
--- Comment #3 from janus at gcc dot gnu dot org 2009-10-16 18:55 ---
Actually the following two test cases are invalid according to this PR:
typebound_operator_2.f03
typebound_operator_4.f03
Both include an intrinsic assignment with a polymorphic (dummy) variable.
--
http
--- Comment #2 from janus at gcc dot gnu dot org 2009-10-16 18:44 ---
Preliminary patch:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (Revision 152915)
+++ gcc/fortran/resolve.c (Arbeitskopie
--- Comment #3 from janus at gcc dot gnu dot org 2009-10-16 16:22 ---
(In reply to comment #2)
> Problem: The patch in comment #1 regresses on class_allocate_1.f03:
In addition to this there are two more test cases failing:
Native configuration is x86_64-unknown-linux-
--- Comment #2 from janus at gcc dot gnu dot org 2009-10-15 20:27 ---
Problem: The patch in comment #1 regresses on class_allocate_1.f03:
gfortran-4.5 class_allocate_1.f03 -O1
class_allocate_1.f03: In function MAIN__:
class_allocate_1.f03:57:0: internal compiler error: in
--- Comment #1 from janus at gcc dot gnu dot org 2009-10-15 13:14 ---
Certainly mine. I should have thought of this case when fixing PR41581. The
cure is for sure:
Index: gcc/fortran/trans-stmt.c
===
--- gcc/fortran/trans
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janus at gcc dot gnu dot org
--- Comment #5 from janus at gcc dot gnu dot org 2009-10-13 16:14 ---
Fixed with r152715. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #4 from janus at gcc dot gnu dot org 2009-10-13 16:12 ---
Subject: Bug 41581
Author: janus
Date: Tue Oct 13 16:12:24 2009
New Revision: 152715
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152715
Log:
2009-10-13 Janus Weil
PR fortr
--- Comment #9 from janus at gcc dot gnu dot org 2009-10-13 14:22 ---
(In reply to comment #8)
> Yup, works for me at revision 152697 + pr41656.diff
> Nice to see it fixed so fast :-)
Ok, so I assume it was indeed fixed by the patch for PR41583. Closing.
--
janus at gcc d
--- Comment #6 from janus at gcc dot gnu dot org 2009-10-12 16:40 ---
(In reply to comment #0)
> Interestingly enough if I glue the files together the ICE disappears
> (which is inconvenient for testing).
Hm, that sounds curiously like it may be connected to PR41583 (which was
--- Comment #3 from janus at gcc dot gnu dot org 2009-10-11 19:07 ---
Mine.
The plan: Add a '$size' field to the class container, which will be used at
runtime to determine the size of the memory block to be allocated.
--
janus at gcc dot gnu dot org changed:
--- Comment #4 from janus at gcc dot gnu dot org 2009-10-09 22:39 ---
Fixed with r152608. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from janus at gcc dot gnu dot org 2009-10-09 22:35 ---
Subject: Bug 41585
Author: janus
Date: Fri Oct 9 22:35:11 2009
New Revision: 152608
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152608
Log:
2009-10-09 Janus Weil
PR fortr
--- Comment #3 from janus at gcc dot gnu dot org 2009-10-09 20:31 ---
Fixed with r152600. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from janus at gcc dot gnu dot org 2009-10-09 20:25 ---
Subject: Bug 41579
Author: janus
Date: Fri Oct 9 20:25:19 2009
New Revision: 152600
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152600
Log:
2009-10-09 Janus Weil
PR fortr
--- Comment #1 from janus at gcc dot gnu dot org 2009-10-09 12:17 ---
The problem here is that the error check comes too late: It should happen
already before the call to encapsulate_class_symbol.
This is effectively fixed by the patch for PR41629:
http://gcc.gnu.org/ml/fortran/2009
--
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 #1 from janus at gcc dot gnu dot org 2009-10-08 20:27 ---
Mine (have a patch).
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
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=41629
--- Comment #1 from janus at gcc dot gnu dot org 2009-10-07 21:58 ---
The fix:
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c (Revision 152525)
+++ gcc/fortran/decl.c (Arbeitskopie)
@@ -3751,7 +3751,8
--- Comment #2 from janus at gcc dot gnu dot org 2009-10-07 21:50 ---
This can be fixed by:
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c (Revision 152525)
+++ gcc/fortran/decl.c (Arbeitskopie)
@@ -1465,7 +1465,7
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=41618
--- Comment #1 from janus at gcc dot gnu dot org 2009-10-06 13:22 ---
The first error message can be trivially fixed by:
Index: interface.c
===
--- interface.c (Revision 152488)
+++ interface.c (Arbeitskopie)
@@ -626,6
--- Comment #10 from janus at gcc dot gnu dot org 2009-10-02 22:24 ---
(In reply to comment #9)
> Can this be closed as FIXED?
I think so.
--
janus at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #7 from janus at gcc dot gnu dot org 2009-09-22 11:40 ---
Subject: Bug 40996
Author: janus
Date: Tue Sep 22 11:40:30 2009
New Revision: 151975
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151975
Log:
2009-09-22 Janus Weil
PR fortr
--- Comment #5 from janus at gcc dot gnu dot org 2009-09-18 15:10 ---
(In reply to comment #4)
> --enable-checking=assert is the key configure option.
Are you sure about that? For me, configuring with --enable-checking=no still
yields loads of regressions in the Fortran testsu
--- Comment #3 from janus at gcc dot gnu dot org 2009-09-18 10:47 ---
With r151837 the bootstrap works again, but the testsuite still shows a large
number of failures, already with check-gfortran (which was clean recently):
=== gfortran Summary ===
# of expected passes
--- Comment #18 from janus at gcc dot gnu dot org 2009-09-10 22:51 ---
Fixed with r151620. Thanks to Juergen for the report.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from janus at gcc dot gnu dot org 2009-09-10 22:47 ---
Subject: Bug 41242
Author: janus
Date: Thu Sep 10 22:47:03 2009
New Revision: 151620
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151620
Log:
2009-09-11 Janus Weil
PR fortr
--- Comment #16 from janus at gcc dot gnu dot org 2009-09-10 21:09 ---
Ok, here goes an extended patch which fixes the testsuite regressions:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision
--- Comment #14 from janus at gcc dot gnu dot org 2009-09-10 18:29 ---
> If trunk bootstraps and regtests, commit as "obvious".
As I said, I get two ICEs in the testsuite with the patch from comment #8.
Backtrace for typebound_operator_3.f03:
#0 0x0050de83 i
--- Comment #12 from janus at gcc dot gnu dot org 2009-09-10 18:13 ---
(In reply to comment #10)
> But I also think that maybe fixing the code so that the double resolve is no
> harm in this case is the better way to go; something like adding a flag that
> code is from
--- Comment #11 from janus at gcc dot gnu dot org 2009-09-10 18:04 ---
(In reply to comment #9)
> > - resolve_code (code, ns);
> >return true;
>
> I had wondered about the function of that resolve_code. If it can be safely
> removed, do it.
Unfor
--- Comment #8 from janus at gcc dot gnu dot org 2009-09-10 16:05 ---
Ok, I think I know what's going on here.
Some background: A PPC call is usually parsed as EXPR_PPC, which happens in
gfc_match_varspec. At resolution stage this is transformed to an EXPR_FUNCTION
(if the PPC
--- Comment #7 from janus at gcc dot gnu dot org 2009-09-10 12:57 ---
This reduced test case shows the same weird behavior as the original:
type :: nf_t
procedure(integer), nopass, pointer :: get_n_in
end type
interface assignment(=)
procedure op_assign
end interface
--- Comment #6 from janus at gcc dot gnu dot org 2009-08-31 19:19 ---
r151244 fixes comment #3 and #4. The items in comment #2 have to wait for a
full implementation of polymorphism. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed
--- Comment #5 from janus at gcc dot gnu dot org 2009-08-31 19:08 ---
Subject: Bug 40940
Author: janus
Date: Mon Aug 31 19:08:03 2009
New Revision: 151244
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151244
Log:
2009-08-31 Janus Weil
Paul Thomas
--- Comment #6 from janus at gcc dot gnu dot org 2009-08-31 10:36 ---
r151240 implements basic allocatable scalars. Allocatable scalar components are
still missing.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40996
--- Comment #5 from janus at gcc dot gnu dot org 2009-08-31 10:22 ---
Subject: Bug 40996
Author: janus
Date: Mon Aug 31 10:22:32 2009
New Revision: 151240
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151240
Log:
2009-08-31 Janus Weil
PR fortr
--- Comment #3 from janus at gcc dot gnu dot org 2009-08-27 20:56 ---
(In reply to comment #1)
> Janus, how's that also related to PPCs?
At first glance it seems we have the same problems for PPCs also.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41177
--- Comment #2 from janus at gcc dot gnu dot org 2009-08-27 19:53 ---
Fixed with r151147. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from janus at gcc dot gnu dot org 2009-08-27 19:49 ---
Subject: Bug 40869
Author: janus
Date: Thu Aug 27 19:48:46 2009
New Revision: 151147
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151147
Log:
2009-08-27 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 #18 from janus at gcc dot gnu dot org 2009-08-25 14:29 ---
Fixed with r151081. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #17 from janus at gcc dot gnu dot org 2009-08-25 14:27 ---
Subject: Bug 41139
Author: janus
Date: Tue Aug 25 14:26:44 2009
New Revision: 151081
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151081
Log:
2009-08-25 Janus Weil
PR fortr
--- Comment #6 from janus at gcc dot gnu dot org 2009-08-25 09:38 ---
Fixed with r151075. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #5 from janus at gcc dot gnu dot org 2009-08-25 09:35 ---
Subject: Bug 41149
Author: janus
Date: Tue Aug 25 09:35:41 2009
New Revision: 151075
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151075
Log:
2009-08-25 Janus Weil
PR middle-e
--- Comment #3 from janus at gcc dot gnu dot org 2009-08-25 09:08 ---
The patch in comment #2 was successfully bootstrapped and regtested. Ok for
trunk?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41149
--- Comment #2 from janus at gcc dot gnu dot org 2009-08-24 19:44 ---
(In reply to comment #1)
> Seems like by design, see tree-pretty-print.c:print_call_name
Thanks for pointing me at the right place.
> Likely for printing prettier member function names. IMHO we should just
--- Comment #2 from janus at gcc dot gnu dot org 2009-08-24 13:55 ---
> However, I cannot reproduce the problem with a program consisting only of:
>
> 2000 format (1X,1P,E14.6,3E12.4,0P)
> end
Hm, funny. For me the error *does* appear already for this two-liner
ects-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=41154
--- Comment #3 from janus at gcc dot gnu dot org 2009-08-24 11:24 ---
(In reply to comment #0)
> Due to committal:
>
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=151021
For me r151028 seems to work, but r151039 shows the error.
--
http://gcc
--- Comment #2 from janus at gcc dot gnu dot org 2009-08-24 11:19 ---
Another test case:
character(100), parameter :: subchapter='(79("-"),/,5("-")," ",A,/,79("-"),/)'
write(*,subchapter) 'test'
--- Comment #16 from janus at gcc dot gnu dot org 2009-08-23 21:15 ---
(In reply to comment #15)
> > D.1533 = f (&C.1531, &C.1532);
>
> In principle the 'f' here should be an 'o.f'.
I opened PR 41149 to track this issue.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41139
nent: middle-end
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=41149
--- Comment #15 from janus at gcc dot gnu dot org 2009-08-22 09:43 ---
(In reply to comment #14)
> Is this what you want?
Jep.
> D.1533 = f (&C.1531, &C.1532);
In principle the 'f' here should be an 'o.f'. Maybe we can postpone this issue
until t
--- Comment #13 from janus at gcc dot gnu dot org 2009-08-22 09:19 ---
(In reply to comment #12)
> @@ -3512,8 +3513,7 @@ gfc_get_proc_ptr_comp (gfc_se *se, gfc_e
>e2 = gfc_copy_expr (e);
>e2->expr_type = EXPR_VARIABLE;
>gfc_conv_expr (&comp_se, e2)
--- Comment #11 from janus at gcc dot gnu dot org 2009-08-21 20:27 ---
Here is another variant of the test case which fails at runtime:
PROGRAM test
type :: t
PROCEDURE(three), POINTER, nopass :: f
end type
type(t) :: o
logical :: g
o%f => three
g=greater(4.,o%f())
pr
--- Comment #7 from janus at gcc dot gnu dot org 2009-08-21 15:11 ---
(In reply to comment #4)
> D.1571 = o.f;
> D.1572 = D.1571 (&C.1569, &C.1570);
> g = (logical(kind=4)) greater (&C.1568, &&D.1572);
Btw, it seems unnecessary to me th
--- Comment #6 from janus at gcc dot gnu dot org 2009-08-21 14:50 ---
This simple patch fixes comment #2:
Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c(revision 150987)
+++ gcc/fortran/trans-expr.c
--- Comment #5 from janus at gcc dot gnu dot org 2009-08-21 14:03 ---
> (1) I had to make the change you have posted in comment #2 to run a test.
>
> (2) The code in comment #0 is illegal and should not be used for the test
> suite.
Of course. Thanks for point
--- Comment #4 from janus at gcc dot gnu dot org 2009-08-21 14:00 ---
Side note: If one constructs an analogous test case with PPCs, this does not
have the missing-temporary problem. But it has a different one:
PROGRAM test
type :: t
PROCEDURE(add), POINTER, nopass :: f
end type
--- Comment #2 from janus at gcc dot gnu dot org 2009-08-21 13:51 ---
> Beware the forbidden recursive I/Os!
This is not the issue here. The following variation has no recursive I/O, but
gives the same segfault:
PROGRAM test
PROCEDURE(add), POINTER :: f
logical :: g
! Pass
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
CC||barron dot bichon at swri
argument
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://gcc.gnu.org/bugzilla/show_bug.cgi?id=41139
--- Comment #2 from janus at gcc dot gnu dot org 2009-08-21 12:17 ---
Fixed with r150987. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from janus at gcc dot gnu dot org 2009-08-21 09:43 ---
Subject: Bug 41106
Author: janus
Date: Fri Aug 21 09:43:04 2009
New Revision: 150987
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150987
Log:
2009-08-21 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
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
Severity|critical|normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41053
--- Comment #9 from janus at gcc dot gnu dot org 2009-08-20 13:11 ---
> Maybe r150934?
Indeed: I just verified that r150934 is the source of this regression.
--
janus at gcc dot gnu dot org changed:
What|Removed |Ad
--- Comment #8 from janus at gcc dot gnu dot org 2009-08-20 12:53 ---
(In reply to comment #5)
> r150856 | domob | 2009-08-17 20:55:30 +0200 (Mon, 17 Aug 2009) | 14 lines
> r150858 | pault | 2009-08-17 22:17:12 +0200 (Mon, 17 Aug 2009) | 13 lines
> r150875 | janus | 2009-08-18
--- Comment #7 from janus at gcc dot gnu dot org 2009-08-20 12:23 ---
(In reply to comment #5)
> but I don't dare to guess this time :-)
Awww, come on, don't be shy ;)
Seriously, though, I'd bet that r150875 is not the culprit. Not because it's
mine, but b
--- Comment #4 from janus at gcc dot gnu dot org 2009-08-20 11:54 ---
(In reply to comment #1)
> guessing:
>
> 2009-08-17 Janus Weil
>
> PR fortran/40877
This was r150823, which seems to be working for me.
However, I don't see why r150825 fail
--- Comment #7 from janus at gcc dot gnu dot org 2009-08-20 09:36 ---
Fixed with r150957. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #6 from janus at gcc dot gnu dot org 2009-08-20 09:33 ---
Subject: Bug 41121
Author: janus
Date: Thu Aug 20 09:33:01 2009
New Revision: 150957
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150957
Log:
2009-08-20 Janus Weil
PR fortr
--- Comment #5 from janus at gcc dot gnu dot org 2009-08-20 08:59 ---
(In reply to comment #4)
> does it fully fix the original, i.e. a1 and a2 shouldn't be warned for either.
It does.
Btw these 'a1' and 'a2' don't appear anywhere in dgbmv.f. I think
--- Comment #3 from janus at gcc dot gnu dot org 2009-08-20 08:04 ---
Here's the fix:
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c (revision 150933)
+++ gcc/fortran/resolve.c (working
--- Comment #2 from janus at gcc dot gnu dot org 2009-08-20 07:45 ---
Curiously, this does not happen when using the IMPLICIT NONE statement, instead
of -fimplicit-none:
IMPLICIT NONE
INTRINSIC MIN
INTEGER :: I,J
print *,MIN(I,J)
END
--
http://gcc.gnu.org/bugzilla
results
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: janus at
--- Comment #2 from janus at gcc dot gnu dot org 2009-08-18 14:25 ---
Fixed with r150875. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #1 from janus at gcc dot gnu dot org 2009-08-18 14:23 ---
Subject: Bug 40870
Author: janus
Date: Tue Aug 18 14:23:35 2009
New Revision: 150875
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150875
Log:
2009-08-18 Janus Weil
Paul Thomas
mary: memory leaks with gfc_namespace
Product: gcc
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
--- Comment #10 from janus at gcc dot gnu dot org 2009-08-17 09:14 ---
Fixed with r150823. Closing.
--
janus at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from janus at gcc dot gnu dot org 2009-08-17 09:11 ---
Subject: Bug 40877
Author: janus
Date: Mon Aug 17 09:11:00 2009
New Revision: 150823
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150823
Log:
2009-08-17 Janus Weil
PR fortr
--- Comment #4 from janus at gcc dot gnu dot org 2009-08-16 08:41 ---
class_2.f03 ICEs with -std=f95.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40940
--- Comment #3 from janus at gcc dot gnu dot org 2009-08-16 08:39 ---
One thing which was forgotten in the first patch: CLASS should be rejected with
-std=f95.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40940
601 - 700 of 1036 matches
Mail list logo
