--- 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 #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=gcc&view=rev&rev=156418
Log:
gcc/fortran/
2010-01-31 Janus Weil
PR fortran/42888
--- Comment #20 from janus at gcc dot gnu dot org 2010-01-30 10:31 ---
(In reply to comment #19)
> And the ICE is kind of expected right now, since CLASS arrays
> are not really supported yet (cf. PR42539, PR41600, PR41951; the second one
> contains a similar ALLOCATE statement).
Oops.
--- 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 i
--- Comment #18 from anlauf at gmx dot de 2010-01-30 00:01 ---
(In reply to comment #17)
> I tried this one and compared it to the semi-solution in comment #9.
> Both "work for me", but the patch from comment #16 appears to produce
> a significant performance regression for my code of t
--- Comment #17 from anlauf at gmx dot de 2010-01-29 23:32 ---
(In reply to comment #16)
> Created an attachment (id=19754)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19754&action=view) [edit]
> patch
>
> Here is an updated patch which fixes the test case in the last comment an
--- Comment #16 from janus at gcc dot gnu dot org 2010-01-29 22:41 ---
Created an attachment (id=19754)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19754&action=view)
patch
Here is an updated patch which fixes the test case in the last comment and the
original problem.
--
h
--- Comment #15 from janus at gcc dot gnu dot org 2010-01-29 19:18 ---
(In reply to comment #14)
> Note: There is another call to 'gfc_default_initializer' in
> 'gfc_trans_allocate', which should be moved to resolve.c too, I guess.
Here is a small test case (very similar to comment #0,
--- Comment #14 from janus at gcc dot gnu dot org 2010-01-29 19:01 ---
Ok, I think the best solution is to move the code setting up the initializer
back to resolve.c. Here is a patch which does so (without any testsuite
regressions):
Index: gcc/fortran/trans-stmt.c
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42888
--- Comment #13 from burnus at gcc dot gnu dot org 2010-01-28 18:44 ---
(In reply to comment #11)
> I get a suspicious error:
>
> Error: The NULL in the derived type constructor at (1) is being applied to
> component 'ptr', which is neither a POINTER nor ALLOCATABLE
The problem is that
--- Comment #12 from dominiq at lps dot ens dot fr 2010-01-28 15:39 ---
Created an attachment (id=19742)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19742&action=view)
Test that gives the error in comment #11 (wrongly attached to pr42889).
--
http://gcc.gnu.org/bugzilla/show
--- Comment #11 from dominiq at lps dot ens dot fr 2010-01-28 14:58 ---
> This patch does not induce any regressions in the testsuite. However, the
> question is if there are other problems, e.g. when resolve_structure_cons
> would
> throw an error message.
I did not regtest, but I get
--- Comment #10 from janus at gcc dot gnu dot org 2010-01-28 14:51 ---
(In reply to comment #9)
> Index: gcc/fortran/trans-stmt.c
> ===
> --- gcc/fortran/trans-stmt.c(revision 156258)
> +++ gcc/fortran/trans-stmt.c(w
--- Comment #9 from janus at gcc dot gnu dot org 2010-01-28 13:32 ---
(In reply to comment #7)
> While for the old rev. 'type' and 'orig' are both
> INTEGER_TYPE, 'orig' is REAL_TYPE on current trunk. I'll try to find out how
> that comes about.
Got it. Previously the constructor was cr
--- Comment #8 from burnus at gcc dot gnu dot org 2010-01-28 13:27 ---
(In reply to comment #7)
> Btw: Isn't this whole thing of 'integer component with real initializer'
> invalid in some way? Shouldn't we at least throw a warning?
Well, according to the standard (F2008 because I have
--- Comment #7 from janus at gcc dot gnu dot org 2010-01-28 13:02 ---
(In reply to comment #6)
> #0 fold_convert_loc (loc=0, type=0x77e83498, arg=0x77f65060) at
> /home/jweil/gcc45/trunk/gcc/fold-const.c:2669
> #1 0x005a088a in gfc_trans_scalar_assign (lse=0x7fffd4d
--- Comment #6 from janus at gcc dot gnu dot org 2010-01-28 10:29 ---
(In reply to comment #5)
> I think the relevant part is:
> http://gcc.gnu.org/viewcvs/trunk/gcc/fortran/trans-stmt.c?r1=152345&r2=152344&pathrev=152345
> -- especially around "Add default initializer for those derived
--- Comment #5 from burnus at gcc dot gnu dot org 2010-01-28 08:50 ---
Janus, can you have a look? It is related to your allocatable + class patch.
Fortran-dev commit:
http://gcc.gnu.org/ml/gcc-cvs/2009-09/msg00874.html
Branch merge:
http://gcc.gnu.org/viewcvs?view=revision&revision
--
burnus at gcc dot gnu dot org changed:
What|Removed |Added
OtherBugsDependingO||32834
nThis||
Keyw
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2010-01-28 04:27
---
Confirming.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
Status
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2010-01-28 04:15
---
The breakage is from rev 152345 which looks like a merge from fortran-dev.
Continuing the hunt in fortran-dev gives ...---... ...---... ...---...
r152375 Fails
r152345 Fails < - Regression occurs here on t
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2010-01-28 02:39
---
I have a regression hunt started
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42888
--- Comment #1 from dominiq at lps dot ens dot fr 2010-01-27 23:47 ---
Confirmed. The test compiles with 4.4.2 and 4.5 revision 151462.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42888
24 matches
Mail list logo
