http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43062
--- Comment #29 from Diego Novillo 2011-02-02
17:52:20 UTC ---
Author: dnovillo
Date: Wed Feb 2 17:52:14 2011
New Revision: 169614
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169614
Log:
2011-01-26 Tobias Burnus
PR fortran
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43062
--- Comment #28 from Xavier 2011-01-29 21:47:19 UTC
---
I tried again to build gcc 4.6 (from svn) and i succeeded. The patch works
fine.
Thanks.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43062
--- Comment #27 from Tobias Burnus 2011-01-28
09:45:58 UTC ---
(In reply to comment #26)
> Question : I tried to build my own version, but i did not succeed.
> (1) gcc-4.5.2 : ok
> (2) gcc-4.5.2 + modified/added files from trunk (4.6) : compila
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43062
--- Comment #26 from Xavier 2011-01-28 09:11:27 UTC
---
Thanks for your work.
Question : I tried to build my own version, but i did not succeed.
(1) gcc-4.5.2 : ok
(2) gcc-4.5.2 + modified/added files from trunk (4.6) : compilation error on
fi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43062
Tobias Burnus changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43062
--- Comment #23 from Tobias Burnus 2011-01-22
21:58:02 UTC ---
(In reply to comment #21)
> It is not resolved because we are waiting for an interpretation from the
> Fortran standards committee on whether the test case is valid or invalid
> Fortr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43062
--- Comment #22 from Tobias Burnus 2011-01-22
21:50:54 UTC ---
(In reply to comment #20)
> so, I am bit lost, "bug" is resolved or not ?
> Correction available with next version of gcc ?
No the bug (or problem report, PR) is not yet resolved. Bu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43062
--- Comment #21 from Jerry DeLisle 2011-01-18
13:27:48 UTC ---
It is not resolved because we are waiting for an interpretation from the
Fortran standards committee on whether the test case is valid or invalid
Fortran. If invalid, then we need to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43062
--- Comment #20 from Xavier 2011-01-18 13:14:38 UTC
---
Hi,
so, I am bit lost, "bug" is resolved or not ?
Correction available with next version of gcc ?
Thanks,
Xavier
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43062
--- Comment #19 from Tobias Burnus 2011-01-18
12:57:11 UTC ---
Related: PR 47339
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43062
--- Comment #18 from Tobias Burnus 2010-10-02
06:44:41 UTC ---
(In reply to comment #16)
> Interpretation request for the June J3 meeting:
> http://j3-fortran.org/doc/meeting/192/10-146.txt
> Proposed edit is to allow ALLOCATABLEs.
(In reply t
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43062
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot
|
--- Comment #16 from burnus at gcc dot gnu dot org 2010-04-06 18:42 ---
Interpretation request for the June J3 meeting:
http://j3-fortran.org/doc/meeting/192/10-146.txt
Proposed edit is to allow ALLOCATABLEs.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43062
--- Comment #15 from burnus at gcc dot gnu dot org 2010-03-01 08:45 ---
See also: http://j3-fortran.org/pipermail/j3/2010-February/003401.html
where Van and Malcolm agreed that changes should be done.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43062
--- Comment #14 from burnus at gcc dot gnu dot org 2010-02-17 21:25 ---
Created an attachment (id=19899)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19899&action=view)
Draft patch - misses modifications to nml_get_addr_expr
The current standard is weird: allocatables/pointers/au
--- Comment #13 from kargl at gcc dot gnu dot org 2010-02-17 16:02 ---
(In reply to comment #11)
> Replying to myself (comment #10):
> > I think one should really send a interpretation request.
>
> I have now created one and sent it to Van.
>
Did you include the language from F2008 th
--- Comment #12 from kargl at gcc dot gnu dot org 2010-02-17 15:57 ---
(In reply to comment #10)
> (NAG f95 v5.1 and g95 reject it unconditionally; ifort allows it by default
> but
> rejects it with -stand f95 or -stand f03.)
>
> I think one should really send a interpretation request.
--- Comment #11 from burnus at gcc dot gnu dot org 2010-02-17 08:22 ---
Replying to myself (comment #10):
> I think one should really send a interpretation request.
I have now created one and sent it to Van.
> What about POINTERs?
Pointers seem to be treated similarly to allocatables.
--- Comment #10 from burnus at gcc dot gnu dot org 2010-02-17 07:32 ---
(NAG f95 v5.1 and g95 reject it unconditionally; ifort allows it by default but
rejects it with -stand f95 or -stand f03.)
I think one should really send a interpretation request.
A patch would be the following. Wh
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2010-02-17 02:06
---
After reading the thread on clf, its still not very clear. The wording is less
then perfect, but thinking out of the box I suppose it would be reasonable to
allow it in the namelist as long as the array gets allo
--- Comment #8 from kargl at gcc dot gnu dot org 2010-02-15 21:50 ---
(In reply to comment #6)
>
> Also, assuming it is something else, would it be invalid to use the namelist
> anywhere if TAB has not been allocated before it is used?
>
I forgot to reply to this part. See comment #2
--- Comment #7 from kargl at gcc dot gnu dot org 2010-02-15 21:47 ---
(In reply to comment #6)
> What is this?
>
> REAL, DIMENSION(:), ALLOCATABLE :: TAB
>
> If not assumed size?
>
> Also, assuming it is something else, would it be invalid to use the namelist
> anywhere if TAB has not
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2010-02-15 20:33
---
What is this?
REAL, DIMENSION(:), ALLOCATABLE :: TAB
If not assumed size?
Also, assuming it is something else, would it be invalid to use the namelist
anywhere if TAB has not been allocated before it is used?
--- Comment #5 from kargl at gcc dot gnu dot org 2010-02-15 17:04 ---
(In reply to comment #4)
> (In reply to comment #3)
> > I've posted a question to c.l.f about this code. I
> > believe the language of the standard is contradictory
> > and as such the code can be interpreted as ille
--- Comment #4 from zazzou at gmail dot com 2010-02-15 08:17 ---
(In reply to comment #3)
> I've posted a question to c.l.f about this code. I
> believe the language of the standard is contradictory
> and as such the code can be interpreted as illegal or
> legal.
>
> http://groups.goo
--- Comment #3 from kargl at gcc dot gnu dot org 2010-02-15 01:29 ---
I've posted a question to c.l.f about this code. I
believe the language of the standard is contradictory
and as such the code can be interpreted as illegal or
legal.
http://groups.google.com/group/comp.lang.fortran/
--- Comment #2 from kargl at gcc dot gnu dot org 2010-02-14 17:27 ---
> NAMELIST/TOTO/TAB
> 1
> Error: NAMELIST attribute conflicts with ALLOCATABLE attribute in 'tab' at (1)
>
>
> Test file :
>
> PROGRAM MAIN
> REAL, DIMENSION(:), ALLOCATABLE :: TAB
--- Comment #1 from pault at gcc dot gnu dot org 2010-02-14 17:21 ---
Yes indeed! Section 5.4 of F2003 removes most of the restrictions for
namelist-group-objects. Ifort 11.1 does the right thing with your testcase.
Thanks for the report.
Paul
--
pault at gcc dot gnu dot org chan
28 matches
Mail list logo
