--- Comment #19 from mikael at gcc dot gnu dot org 2010-07-25 17:01 ---
Subject: Bug 44660
Author: mikael
Date: Sun Jul 25 17:01:15 2010
New Revision: 162516
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=162516
Log:
2010-07-25 Mikael Morin
PR fortran/44660
*
--- Comment #18 from mikael at gcc dot gnu dot org 2010-07-24 19:52 ---
(In reply to comment #16)
> Mikael, what's the status of this patch?
>
Forgotten :-/
(In reply to comment #17)
> With 4.5 about to pop a release it would be good to get this fixed for it,
> with
> release manager
--- Comment #17 from jvdelisle at gcc dot gnu dot org 2010-07-23 03:05
---
With 4.5 about to pop a release it would be good to get this fixed for it, with
release manager approval
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44660
--- Comment #16 from burnus at gcc dot gnu dot org 2010-07-22 09:43 ---
(In reply to comment #13)
> Created an attachment (id=21003)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21003&action=view) [edit]
> patch against my (diry) tree
> patch restoring the old equivalence list on
--- Comment #15 from jakub at gcc dot gnu dot org 2010-06-25 18:11 ---
Well, the compiler shouldn't ICE on invalid input.
And, delta is just a simple text tool, it depends on the user how he writes the
test script. Ideally when reducing a testcase to find an ICE the delta test
script s
--- Comment #14 from kargl at gcc dot gnu dot org 2010-06-25 17:14 ---
(In reply to comment #11)
>
> Well, it is invalid code - based on a valid Fortran code. If you use Delta to
> reduce a test case (cf.
> http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction),
> it simply removes li
--- Comment #13 from mikael at gcc dot gnu dot org 2010-06-25 10:33 ---
Created an attachment (id=21003)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21003&action=view)
patch against my (diry) tree
patch restoring the old equivalence list on reject_statement ()
--
http://gcc
--- Comment #12 from mikael at gcc dot gnu dot org 2010-06-25 10:32 ---
(In reply to comment #11)
> Thus, seemingly, reject_statement leaves the symtree in a half-existing state.
> It calls: gfc_undo_symbols () and undo_new_statement (). I think the former
> one only does a partial clea
--- Comment #11 from burnus at gcc dot gnu dot org 2010-06-25 09:17 ---
(In reply to comment #10)
> What language is GAMESS written in?
Fortran, of course. See: http://www.spec.org/cpu2006/Docs/416.gamess.html
and http://www.msg.ameslab.gov/GAMESS/GAMESS.html
> The above simply is not
--- Comment #10 from kargl at gcc dot gnu dot org 2010-06-25 06:29 ---
(In reply to comment #6)
> Subject: Re: [regression 4.4/4.5/4.6] ICE in
> resolve_equivalence()
>
> These previous patches don't seem to solve the problem:
> here is another reduced case that still fails in
--- Comment #9 from sebpop at gmail dot com 2010-06-25 06:24 ---
Subject: Re: [regression 4.4/4.5/4.6] ICE in
resolve_equivalence()
On Fri, Jun 25, 2010 at 01:14, kargl at gcc dot gnu dot org
wrote:
> ... there is a 200 line difference in the location of your
> diff and my cl
--- Comment #8 from burnus at gcc dot gnu dot org 2010-06-25 06:20 ---
Comment 6 prints correctly the error that EQUIVALENCE is unexpected, but then
segfaults. Valgrind shows:
==11477== Invalid read of size 8
==11477==at 0x52B7BB: resolve_types (resolve.c:12544)
==11477==by 0x52
--- Comment #7 from kargl at gcc dot gnu dot org 2010-06-25 06:14 ---
(In reply to comment #5)
> Subject: Re: [regression 4.4/4.5/4.6] ICE in
> resolve_equivalence()
>
> On Thu, Jun 24, 2010 at 23:02, kargl at gcc dot gnu dot org
> wrote:
> >
> >
> > Comment #1 from kargl at
--- Comment #6 from sebpop at gmail dot com 2010-06-25 06:07 ---
Subject: Re: [regression 4.4/4.5/4.6] ICE in
resolve_equivalence()
These previous patches don't seem to solve the problem:
here is another reduced case that still fails in resolve_equivalence
at a different place
These previous patches don't seem to solve the problem:
here is another reduced case that still fails in resolve_equivalence
at a different place than before.
$ cat bug.f
CALL TRFWTM(JKT,XX,NX,Y,NIX,NORB2,1,TOL)
IF(DBUG.AND.NX.GT.0) THEN
EQUIVALENCE (DBUGME, DBUGME_STR)
--- Comment #5 from sebpop at gmail dot com 2010-06-25 05:49 ---
Subject: Re: [regression 4.4/4.5/4.6] ICE in
resolve_equivalence()
On Thu, Jun 24, 2010 at 23:02, kargl at gcc dot gnu dot org
wrote:
>
>
> --- Comment #1 from kargl at gcc dot gnu dot org 2010-06-25 04:02
--- Comment #4 from sebpop at gmail dot com 2010-06-25 05:32 ---
Subject: Re: [regression 4.4/4.5/4.6] ICE in
resolve_equivalence()
On Thu, Jun 24, 2010 at 23:42, kargl at gcc dot gnu dot org
wrote:
> The mangled Fortran code caught my eye. I'm actually wondering
> where Seb
--- Comment #3 from kargl at gcc dot gnu dot org 2010-06-25 04:42 ---
(In reply to comment #2)
> Confirmed. I came up with the exact same patch and it does pass regression
> testing, of course. Collided when I tried to post this. :)
>
:)
The mangled Fortran code caught my eye. I'm ac
--- Comment #2 from jvdelisle at gcc dot gnu dot org 2010-06-25 04:35
---
Confirmed. I came up with the exact same patch and it does pass regression
testing, of course. Collided when I tried to post this. :)
--
jvdelisle at gcc dot gnu dot org changed:
What|Removed
--- Comment #1 from kargl at gcc dot gnu dot org 2010-06-25 04:02 ---
Index: resolve.c
===
--- resolve.c (revision 161047)
+++ resolve.c (working copy)
@@ -12506,6 +12506,9 @@ resolve_equivalence (gfc_equiv *eq)
int o
20 matches
Mail list logo
