--- Comment #38 from dfranke at gcc dot gnu dot org 2010-06-01 20:53
---
*** Bug 44351 has been marked as a duplicate of this bug. ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #37 from kargl at gcc dot gnu dot org 2010-05-17 21:46 ---
*** Bug 44177 has been marked as a duplicate of this bug. ***
--
kargl at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #36 from dfranke at gcc dot gnu dot org 2010-05-05 19:41
---
(In reply to comment #35)
> Fixed in trunk. No backport to 4.5 as the required constructor rework is not
> ported either. Closing.
2nd try,
--
dfranke at gcc dot gnu dot org changed:
What|Remov
--- Comment #35 from dfranke at gcc dot gnu dot org 2010-05-05 19:03
---
Fixed in trunk. No backport to 4.5 as the required constructor rework is not
ported either. Closing.
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #34 from dfranke at gcc dot gnu dot org 2010-05-05 18:54
---
Subject: Bug 24978
Author: dfranke
Date: Wed May 5 18:53:23 2010
New Revision: 159076
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=159076
Log:
gcc/fortran/:
2010-05-05 Daniel Franke
PR fortr
--- Comment #33 from dominiq at lps dot ens dot fr 2010-05-02 09:31 ---
> That's a leftover from PR40472 - Jerry asked to leave the check for array size
> in, so please revert that change in your tree. No more regressions :)
This change fixed an ICE for the test in
http://gcc.gnu.org/bu
--- Comment #32 from dfranke at gcc dot gnu dot org 2010-05-02 09:23
---
(In reply to comment #31)
> FAIL: gfortran.dg/spread_size_limit.f90 -O scan-tree-dump-times original
> "_gfortran_spread" 1
> where the test should be updated/removed due to the change in simplify.c.
That's a le
--- Comment #31 from dominiq at lps dot ens dot fr 2010-05-02 08:52 ---
> Updated patch. Fixes the multiplication of errors shown in comment #29. Not
> yet
> regtested.
The patch in comment #30 fixes the multiplication of errors. The only
regression I have found is
FAIL: gfortran.dg/
--- Comment #30 from dfranke at gcc dot gnu dot org 2010-05-01 13:13
---
Created an attachment (id=20525)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20525&action=view)
updated patch
Updated patch. Fixes the multiplication of errors shown in comment #29. Not yet
regtested.
--
--- Comment #29 from dominiq at lps dot ens dot fr 2010-05-01 12:59 ---
>Could you post the full test? I can't reproduce this?!
[macbook] lin/test% cat ../../../g95bench/win/f90/bug/pr24978_4_ma_i2_db_1.f90
SUBROUTINE data_init_matrix_invalid()
! full array initializer, re-initialize
--- Comment #28 from dfranke at gcc dot gnu dot org 2010-05-01 12:36
---
(In reply to comment #27)
> Apparently the repetition is along the last dimension:
> i(5,10) gives 10 errors/warnings and i(10,5) gives 5 ones.
Could you post the full test? I can't reproduce this?!
--
http:/
--- Comment #27 from dominiq at lps dot ens dot fr 2010-05-01 12:30 ---
> With the changes in comment #25, I get only warnings/errors along one
> dimension
> (probably the first, but have to check)
Apparently the repetition is along the last dimension:
i(5,10) gives 10 errors/warnings
--- Comment #26 from dominiq at lps dot ens dot fr 2010-05-01 12:20 ---
> Dominique, if you apply this hunk ...
With the changes in comment #25, I get only warnings/errors along one dimension
(probably the first, but have to check): a(3,3) gives 3 warnings/errors and
a(10,10) gives 10 o
--- Comment #25 from dfranke at gcc dot gnu dot org 2010-05-01 10:36
---
Dominique, if you apply this hunk
Index: data.c
===
--- data.c (revision 158958)
+++ data.c (working copy)
@@ -352,8 +352,10 @@ gfc_assign_
--- Comment #24 from dfranke at gcc dot gnu dot org 2010-05-01 10:24
---
(In reply to comment #23)
> are only detected with the -pedantic option.
Or -std=f95; data.c has:
/* Overwriting an existing initializer is non-standard but usually only
provokes a warning from other compil
--- Comment #23 from dominiq at lps dot ens dot fr 2010-05-01 09:57 ---
I have applied the patch in comment #22 and it fixes all the ICE I have in
store with DATA initialization (including those remaining after the patch in
comment #19: see comment #20).
I have also found that codes suc
--- Comment #22 from dfranke at gcc dot gnu dot org 2010-04-30 21:02
---
Proposed patch:
http://gcc.gnu.org/ml/fortran/2010-04/msg00328.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24978
--- Comment #21 from dominiq at lps dot ens dot fr 2009-12-06 14:58 ---
Note that comment #20 confirms comment #12.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24978
--- Comment #20 from dominiq at lps dot ens dot fr 2009-12-06 14:56 ---
With the patch in comment #19, the test in comment #14 no longer gives ICEs.
However I noticed that several invalid cases are not detected (a and b in
data_init_(scalar|array|matrix)_invalid, and c and d in
data_in
--- Comment #19 from jvdelisle at gcc dot gnu dot org 2009-12-05 17:01
---
Try this patch:
Index: data.c
===
--- data.c (revision 155006)
+++ data.c (working copy)
@@ -497,7 +497,13 @@ gfc_assign_data_value_range
--- Comment #18 from jvdelisle at gcc dot gnu dot org 2009-12-01 03:01
---
As an update, gfortran currently passes the data-valid.f90 test and ices on the
data-invalid.f90 case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24978
--- Comment #17 from dfranke at gcc dot gnu dot org 2008-06-23 09:53
---
*** Bug 36604 has been marked as a duplicate of this bug. ***
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #16 from riccardo dot scorretti at univ-lyon1 dot fr
2008-05-13 12:42 ---
Hi! I think I'm experiencing a similar bug: the source code is:
program test_vecteurs
implicit none
integer :: n
integer, dimension(0:9) :: x = (/ (n, n=1,10,2), (0,n=1,5) /)
data (x(n), n=0
--- Comment #15 from bdavis at gcc dot gnu dot org 2007-12-23 03:07 ---
the test cases are great...but they show too many bugs !! can't decide whether
to go for the 'grand unified solution' or just hit them one at a time :)
--bud
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=249
--- Comment #14 from dfranke at gcc dot gnu dot org 2007-12-21 17:41
---
Created an attachment (id=14805)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14805&action=view)
set of invalid testcases
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24978
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|dfranke at gcc dot gnu dot |unassigned at gcc dot gnu
|org
--- Comment #13 from dfranke at gcc dot gnu dot org 2007-12-21 17:41
---
Created an attachment (id=14804)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14804&action=view)
set of valid testcases
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24978
--- Comment #12 from dfranke at gcc dot gnu dot org 2007-12-21 17:40
---
Getting rid of the ICEs does not seem to be too difficult. Unfortunately,
internal reworking seems to be necessary to actually solve every aspect of this
PR.
I will attach two sets of testcases; a list of valid D
--- Comment #11 from dfranke at gcc dot gnu dot org 2007-12-19 00:53
---
Having a look ...
--
dfranke at gcc dot gnu dot org changed:
What|Removed |Added
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|jvdelisle at gcc dot gnu dot|unassigned at gcc dot gnu
|org
--- Comment #9 from pault at gcc dot gnu dot org 2006-10-30 21:34 ---
Steve and Jerry,
> laptop:kargl[209] f95 -o z t.f90
> Error: t.f90, line 3: Element no. 13 of object A already initialised
> Errors in declarations, no further processing for $main$
> [f95 error termination]
>
The s
--- Comment #8 from jvdelisle at gcc dot gnu dot org 2006-10-29 23:51
---
Here is a case that makes it through gfortran and into middle-end or back-end.
real :: a(5,5)
DATA a /25*-5.0/ !(1,1), a(3,1), a(1,2), a(3,3) /2*1.0, 2*2.0/
DATA a(2,1) /2.5/
print '(5f5.2)', a
end
test2.f90: In
--- Comment #7 from sgk at troutmask dot apl dot washington dot edu
2006-10-29 20:02 ---
Subject: Re: ICE in gfc_assign_data_value_range
> Should we simply avoid the ice, perhaps accepting the invalid code or do we
> want to search for duplicates in the DATA statements and generate an
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2006-10-29 16:47
---
I have started looking into this one
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2006-10-29 05:16
---
Should we simply avoid the ice, perhaps accepting the invalid code or do we
want to search for duplicates in the DATA statements and generate an error?
Also,
Is this valid?:
real :: a(5,5)
DATA a(1,1), a(3,1),
--- Comment #4 from kargl at gcc dot gnu dot org 2006-06-05 17:40 ---
(In reply to comment #3)
> I marked it as ice-on-valid-code, but I'm not sure it's valid code. g95 emits
> an error, but Intel and Sun compilers don't. Uttam, do you know if that code
> is
> valid?
>
It is invalid-c
--- Comment #3 from fxcoudert at gcc dot gnu dot org 2006-06-04 10:01
---
I marked it as ice-on-valid-code, but I'm not sure it's valid code. g95 emits
an error, but Intel and Sun compilers don't. Uttam, do you know if that code is
valid?
--
fxcoudert at gcc dot gnu dot org changed:
--- Comment #2 from dje at gcc dot gnu dot org 2006-01-03 16:27 ---
Not powerpc-specific.
--
dje at gcc dot gnu dot org changed:
What|Removed |Added
GCC build triplet|po
--- Comment #1 from pinskia at gcc dot gnu dot org 2005-11-21 21:02 ---
Confirmed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCON
39 matches
Mail list logo
