[Bug fortran/33268] read ('(f3.3)'), a rejected due to the extra (...)
--- Comment #11 from jvdelisle at gcc dot gnu dot org 2008-05-03 15:12 --- Subject: Bug 33268 Author: jvdelisle Date: Sat May 3 15:11:33 2008 New Revision: 134900 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134900 Log: 2008-05-03 Jerry DeLisle [EMAIL PROTECTED] PR fortran/33268 * gfortran.h: Add extra_comma pointer to gfc_dt structure. Add iokind to gfc_expr value union. Add io_kind enum to here from io.c. * io.c (gfc_free_dt): Free extra_comma. (gfc_resolve_dt): If an extra comma was encountered and io_unit is type BT_CHARACTER, resolve to format_expr and set default unit. Error if io_kind is M_WRITE. (match_io): Match the extra comma and set new pointer, extra_comma. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/io.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33268
[Bug fortran/33268] read ('(f3.3)'), a rejected due to the extra (...)
--- Comment #12 from jvdelisle at gcc dot gnu dot org 2008-05-03 15:15 --- Subject: Bug 33268 Author: jvdelisle Date: Sat May 3 15:14:55 2008 New Revision: 134901 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=134901 Log: 2008-05-03 Jerry DeLisle [EMAIL PROTECTED] PR fortran/33268 * gfortran.dg/io_constraints_4.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/io_constraints_4.f90 Modified: trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33268
[Bug fortran/33268] read ('(f3.3)'), a rejected due to the extra (...)
--- Comment #13 from jvdelisle at gcc dot gnu dot org 2008-05-03 15:16 --- Closing. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33268
[Bug fortran/33268] read ('(f3.3)'), a rejected due to the extra (...)
--- Comment #10 from jvdelisle at gcc dot gnu dot org 2008-02-17 04:44 --- I want to get this on my radar. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jvdelisle at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2007-09-02 16:33:54 |2008-02-17 04:44:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33268
[Bug fortran/33268] read ('(f3.3)'), a rejected due to the extra (...)
--- Comment #8 from burnus at gcc dot gnu dot org 2007-10-08 20:28 ---
I am going to vote that this bug is invalid. IFORT and Sun F95 also reject
this.
Remark: The compilers, which accept the ('(a)') all reject
READ(*,*), a
because of the comma after *) (g95, NAG f95); the compiler accepting this
extension (ifort, sunf95, gfortran) all do not accept the valid
READ ('(a)'), a
Thus viewed from the Fortran standard it is easy: If there is a comma after the
(...) it must be a format/default-character-expression, otherwise a
io-control-spec-list. Unfortunately, with gfortran we don't have this luxury as
we do support the vendor extension with the comma after the
(io-control-spec-list).
Well from comment on comp.lang.fortran, I lost my argument. :)
http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/05465f765b682279/
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33268
[Bug fortran/33268] read ('(f3.3)'), a rejected due to the extra (...)
--- Comment #9 from jvdelisle at gcc dot gnu dot org 2007-10-09 01:37 --- Also, right now we warn on that comma so instead of warning we return MATCH_NO for the statement and go back and try again with a different matcher and we should be there. I agree the comma is the key. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33268
[Bug fortran/33268] read ('(f3.3)'), a rejected due to the extra (...)
--- Comment #6 from jvdelisle at gcc dot gnu dot org 2007-10-06 20:22 --- Reply to comment #2: After studying this some more. Note that the first form of the READ has a non optional left paren. This means that as soon as one sees a left paren right after READ that we must be in io-control-spec-list form. The PRINT statement is valid because the first entity after the PRINT, must always be a format expression, parens do not matter in the same way. I am going to vote that this bug is invalid. IFORT and Sun F95 also reject this. I will post to comp.lang.fortran for an interpretation. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33268
[Bug fortran/33268] read ('(f3.3)'), a rejected due to the extra (...)
--- Comment #7 from jvdelisle at gcc dot gnu dot org 2007-10-06 21:40 --- Well from comment on comp.lang.fortran, I lost my argument. :) We move on to fixing this. I am not going to assign myself yet. I need to study the how to do it a bit more. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33268
[Bug fortran/33268] read ('(f3.3)'), a rejected due to the extra (...)
--- Comment #5 from tobi at gcc dot gnu dot org 2007-09-27 21:41 --- I'm unassigning myself for the time being, as I couldn't think of a fix that does the right thing and doesn't involve overhauling parts of the compiler. -- tobi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|tobi at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33268
[Bug fortran/33268] read ('(f3.3)'), a rejected due to the extra (...)
--- Comment #4 from tobi at gcc dot gnu dot org 2007-09-20 13:03 --- Created an attachment (id=14231) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14231action=view) Failed attempt at a patch This is a first attempt at a patch. Unfortunately, when I wrote the e-mail for submission to the list, I realised that it would make us erroneously accept something like READ (UNIT=((f5.3))) x I have no non-intrusive idea for fixing this problem, but will look into it further when I return from vacation. The patch also contains a bunch of cleanups which I will split out and submit separately. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33268
[Bug fortran/33268] read ('(f3.3)'), a rejected due to the extra (...)
-- tobi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |tobi at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-09-02 16:33:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33268
[Bug fortran/33268] read ('(f3.3)'), a rejected due to the extra (...)
--- Comment #2 from burnus at gcc dot gnu dot org 2007-08-31 20:16 ---
The print case is rejected at run time.
My bad. I wanted to write:
print('(a)'), 'Hello'
which is valid code and accepted. (Cf. PR33269 for detecting this.)
read ('(f3.3)'), a ! Invalid, rejected at compile time, requires unit number.
I disagree - and also NAG f95 agrees with me; READ has two form:
R910 read-stmt is READ ( io-control-spec-list ) [ input-item-list ]
or READ format [ , input-item-list ]
And I would argue that read '(f3.3)', a and read ('(f3.3)'), a are both of
the second type. As both are default-character-expressions, this should be
valid. As is my - fixed - PRINT case.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33268
[Bug fortran/33268] read ('(f3.3)'), a rejected due to the extra (...)
--- Comment #1 from jvdelisle at gcc dot gnu dot org 2007-08-31 20:05
---
The print case is rejected at run time. See PR28397. IMHO
print('a'), 'Hello' ! Invalid, caught at run time, no leading paren
! in char expr.
write(*,('(a)')) 'Hello' ! Valid, ('(a)') simplifies to '(a)', a char expr.
read (*,('(f3.3)')) a ! Valid, ('(f3.3)') simplifies to '(f3.3)', a char expr.
read '(f3'//'.3)', a ! Valid, a char expr
read ('(f3.3)'), a ! Invalid, rejected at compile time, requires unit number.
end
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33268
[Bug fortran/33268] read ('(f3.3)'), a rejected due to the extra (...)
--- Comment #3 from jvdelisle at gcc dot gnu dot org 2007-08-31 20:48 --- Point well taken. Tobias, I will work this one unless you wish to do so. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33268
