--- Comment #17 from pault at gcc dot gnu dot org 2009-10-11 12:26 ---
(In reply to comment #16)
Sorry - that was fingers trouble on my part - wrong PR.
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40440
--- Comment #16 from pault at gcc dot gnu dot org 2009-10-11 12:20 ---
Subject: Bug 40440
Author: pault
Date: Sun Oct 11 12:20:09 2009
New Revision: 152640
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=152640
Log:
2009-10-11 Paul Thomas
PR fortran/40440
* de
--- Comment #15 from pault at gcc dot gnu dot org 2009-07-09 19:29 ---
Fixed on trunk and 4.4
Thanks for the patch
Paul
--
pault at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #14 from pault at gcc dot gnu dot org 2009-07-09 19:28 ---
Subject: Bug 40440
Author: pault
Date: Thu Jul 9 19:28:20 2009
New Revision: 149431
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=149431
Log:
2009-07-09 Paul Thomas
PR fortran/40440
* tr
--- Comment #13 from pault at gcc dot gnu dot org 2009-06-19 21:58 ---
Subject: Bug 40440
Author: pault
Date: Fri Jun 19 21:58:27 2009
New Revision: 148731
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148731
Log:
2009-06-19 Paul Thomas
PR fortran/40440
* tr
--- Comment #12 from pault at gcc dot gnu dot org 2009-06-19 00:20 ---
Adding at trans-expr.c:2740
&& !(e->symtree && e->symtree->n.sym->attr.pointer)
eliminates the problem in the reduced testcase and allows the original testcase
to run correctly. This has not been regtested
--- Comment #11 from burnus at gcc dot gnu dot org 2009-06-18 21:15 ---
(In reply to comment #10)
> Yes, I understood after a bit of dyslexia about it :-(
>
> Since the function result is a pointer, it is an ultimate component and, I
> think, the deallocation of the allocatable componen
--- Comment #10 from pault at gcc dot gnu dot org 2009-06-18 20:51 ---
(In reply to comment #8)
> > I am not sure that your testcase should be allowed at all! I am not sure
> > that
> > I understand what it means.
>
> I think it is valid and not different from:
Yes, I understood afte
--- Comment #9 from burnus at gcc dot gnu dot org 2009-06-18 15:17 ---
(In reply to comment #7)
> I'm still convinced that this is a problem of the compiler, since it works
> with the
> NAG and Intel compilers.
Well, compilers can have all bugs - and not all invalid programs can be
dia
--- Comment #8 from burnus at gcc dot gnu dot org 2009-06-18 14:45 ---
> I am not sure that your testcase should be allowed at all! I am not sure that
> I understand what it means.
I think it is valid and not different from:
integer, pointer :: ptr
allocate(ptr)
ptr = 5
call f
--- Comment #7 from juergen dot reuter at desy dot de 2009-06-18 13:33
---
(In reply to comment #6)
> (In reply to comment #5)
The crucial part is that the return value is a pointer! If I
>
> Ys there is a bug there somewhere. I shall have to think this through.
> I am not s
--- Comment #6 from pault at gcc dot gnu dot org 2009-06-18 09:44 ---
(In reply to comment #5)
> Juergen: Thanks for the report, but it is not a regression - it might not
> crash
> with 4.3 (or your 4.4) but I think that's just by chance.
>
> Paul, I think also this bug touches code fo
--- Comment #5 from burnus at gcc dot gnu dot org 2009-06-15 13:09 ---
Juergen: Thanks for the report, but it is not a regression - it might not crash
with 4.3 (or your 4.4) but I think that's just by chance.
Paul, I think also this bug touches code for which you have the expertise.
Th
13 matches
Mail list logo
