--- Comment #31 from burnus at gcc dot gnu dot org 2009-11-27 08:32 ---
Crossref: I have opened a follow up PR 42189 as in the review it was stated
that gfc_is_constant_expr has unacceptable side effects.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41807
--- Comment #27 from jvdelisle at gcc dot gnu dot org 2009-11-26 21:53
---
Subject: Bug 41807
Author: jvdelisle
Date: Thu Nov 26 21:52:52 2009
New Revision: 154690
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154690
Log:
2009-11-26 Jerry DeLisle jvdeli...@gcc.gnu.org
--- Comment #28 from jvdelisle at gcc dot gnu dot org 2009-11-26 21:57
---
Subject: Bug 41807
Author: jvdelisle
Date: Thu Nov 26 21:57:32 2009
New Revision: 154691
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154691
Log:
2009-11-26 Jerry DeLisle jvdeli...@gcc.gnu.org
--- Comment #29 from jvdelisle at gcc dot gnu dot org 2009-11-26 22:18
---
Subject: Bug 41807
Author: jvdelisle
Date: Thu Nov 26 22:18:36 2009
New Revision: 154692
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154692
Log:
2009-11-26 Jerry DeLisle jvdeli...@gcc.gnu.org
--- Comment #30 from jvdelisle at gcc dot gnu dot org 2009-11-26 22:21
---
Fixed on trunk and 4.4.
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #25 from jvdelisle at gcc dot gnu dot org 2009-11-26 01:08
---
Since we are dealing with invalid fortran code, we can use gfc_fatal_error and
avoid the downstream errors and trying to translate bogus code. This is the
cheap way out of it.
--
jvdelisle at gcc dot gnu
--- Comment #26 from jvdelisle at gcc dot gnu dot org 2009-11-26 02:12
---
This is better, set the expr to a valid constant 0 before converting to a tree.
Index: trans-const.c
===
--- trans-const.c (revision 154660)
--- Comment #22 from jvdelisle at gcc dot gnu dot org 2009-11-25 02:38
---
Subject: Bug 41807
Author: jvdelisle
Date: Wed Nov 25 02:37:57 2009
New Revision: 154529
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154529
Log:
2009-11-24 Jerry DeLisle jvdeli...@gcc.gnu.org
--- Comment #23 from jvdelisle at gcc dot gnu dot org 2009-11-25 02:44
---
Disregard comment #22 , wrong PR number.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41807
--- Comment #24 from jvdelisle at gcc dot gnu dot org 2009-11-25 03:34
---
When attempting to backport the patch to 4.4.3 from mainline data_value_1.f90
test failes with a segmentation fault.
$ gfc44 data_value_1.f90
data_value_1.f90:12.21:
DATA P / POINT(1.+X) / ! { dg-error
--- Comment #18 from jvdelisle at gcc dot gnu dot org 2009-11-21 22:15
---
Here is a tentative patch. I removed the offending code and ran the testsuite
to see what would happen. The only failure was the test case associated with
patch that caused the regression. This failure was an
--- Comment #19 from jvdelisle at gcc dot gnu dot org 2009-11-22 02:05
---
Subject: Bug 41807
Author: jvdelisle
Date: Sun Nov 22 02:05:12 2009
New Revision: 154419
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154419
Log:
2009-11-21 Jerry DeLisle jvdeli...@gcc.gnu.org
--- Comment #20 from jvdelisle at gcc dot gnu dot org 2009-11-22 02:06
---
Subject: Bug 41807
Author: jvdelisle
Date: Sun Nov 22 02:06:26 2009
New Revision: 154420
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=154420
Log:
2009-11-21 Jerry DeLisle jvdeli...@gcc.gnu.org
--- Comment #21 from jvdelisle at gcc dot gnu dot org 2009-11-22 02:10
---
Fixed on trunk. Note I inadvertently left off the PR number in the commit.
It was:
SendingChangeLog
Sendingresolve.c
Sendingtrans-const.c
Transmitting file data ...
Committed revision
--- Comment #14 from jvdelisle at gcc dot gnu dot org 2009-11-17 04:17
---
The offending patch is in 4.4 r148732, r148731 passes the test case.
--- branches/gcc-4_4-branch/gcc/fortran/resolve.c 2009/04/03 20:56:54
145519
+++ branches/gcc-4_4-branch/gcc/fortran/resolve.c
--- Comment #15 from jvdelisle at gcc dot gnu dot org 2009-11-17 04:29
---
I have confirmed on trunk that removing that snippet clears the regression.
Looking at gfc_is_constant_expr we see a call to array.c (gfc_constant_ac)
which does indeed modify the expr. So we have a bad side
--- Comment #16 from jvdelisle at gcc dot gnu dot org 2009-11-17 05:35
---
I propose fixing this at gfc_consant_ac which has the following comment:
/* Given an array constructor, determine if the constructor is
constant or not by expanding it and making sure that all elements
--- Comment #17 from sgk at troutmask dot apl dot washington dot edu
2009-11-17 06:03 ---
Subject: Re: [4.5/4.4 Regression] data statement with nested type
constructors
On Tue, Nov 17, 2009 at 05:35:33AM -, jvdelisle at gcc dot gnu dot org
wrote:
- Comment #16 from jvdelisle
--- Comment #11 from kargl at gcc dot gnu dot org 2009-11-15 18:38 ---
Jerry, I added
@@ -56,11 +55,11 @@ get_array_index (gfc_array_ref *ar, mpz_
for (i = 0; i ar-dimen; i++)
{
e = gfc_copy_expr (ar-start[i]);
- re = gfc_simplify_expr (e, 1);
+
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2009-11-15 19:04
---
When we simplify start[i], we turn that expression into a constant. Then I
believe the traverse_data_var can no longer increment the index since we made
it a constant. I don't think the start[i] expression
--- Comment #13 from sgk at troutmask dot apl dot washington dot edu
2009-11-15 19:26 ---
Subject: Re: [4.5/4.4 Regression] data statement with nested type
constructors
On Sun, Nov 15, 2009 at 07:04:42PM -, jvdelisle at gcc dot gnu dot org
wrote:
--- Comment #12 from
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2009-11-14 18:35
---
Does anyone recognize this in resolve.c
/* If we have more than one element left in the repeat count,
and we have more than one element left in the target variable,
then create a range
--- Comment #8 from kargl at gcc dot gnu dot org 2009-11-14 19:30 ---
(In reply to comment #7)
Does anyone recognize this in resolve.c
/* If we have more than one element left in the repeat count,
and we have more than one element left in the target variable,
--- Comment #9 from kargl at gcc dot gnu dot org 2009-11-14 19:32 ---
which traces to
REMOVE:kargl[207] svn log -r 86443 resolve.c |more
r86443 | rth | 2004-08-23 14:53:14 -0700 (Mon, 23 Aug 2004) | 11 lines
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2009-11-14 21:24
---
Interesting, the following patch allows the test case in comment #4 to compile.
Index: data.c
===
--- data.c (revision 154170)
+++ data.c
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2009-11-11 05:20
---
I have tracked through the matchers and as suspected, the iterator is being
initialised correctly. Start, End, and Step are all constants. This hints at
some corruption. As time allows I will follow the
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #2 from pault at gcc dot gnu dot org 2009-10-24 09:38 ---
A reduced testcase
module w
real, parameter :: zero = 0.0
type, public :: multpol
real :: coor(3)
end type multpol
integer, public, parameter :: n_nuc=2
type(multpol), public ::
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P4
Summary|[4.5, 4.4 Regression] data |[4.5/4.4
29 matches
Mail list logo
