[Bug fortran/50407] compiler confused by .operator.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50407 --- Comment #15 from Uros Bizjak 2011-10-20 18:53:12 UTC --- (In reply to comment #14) > Fixed on trunk at revision 180261. Forgot to include PR number > in ChangeLog, so commit message won't show up in audit trail. This can be solved by copying commit message from gcc-cvs@ ML by hand. Like ... this: Author: kargl Date: Thu Oct 20 17:04:53 2011 New Revision: 180261 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=180261 Log: 2011-10-16 Steven G. Kargl * io.c (match_dt_format): Match a user-defined operator or a kind type prefixed string. 2011-10-16 Steven G. Kargl * gfortran.dg/format_string.f: New test. Added: trunk/gcc/testsuite/gfortran.dg/format_string.f Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/io.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/50407] compiler confused by .operator.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50407 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #14 from kargl at gcc dot gnu.org 2011-10-20 17:10:00 UTC --- Fixed on trunk at revision 180261. Forgot to include PR number in ChangeLog, so commit message won't show up in audit trail.
[Bug fortran/50407] compiler confused by .operator.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50407
--- Comment #13 from Steve Kargl
2011-09-16 14:42:31 UTC ---
On Fri, Sep 16, 2011 at 12:44:37PM +, sgk at troutmask dot
apl.washington.edu wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50407
>
> --- Comment #12 from Steve Kargl
> 2011-09-16 12:44:37 UTC ---
> On Fri, Sep 16, 2011 at 07:22:09AM +, zeccav at gmail dot com wrote:
> >
> > To me, it looks like the parser does not handle correctly the format
> > specification as a default-char-expression defined in fortran 95 R913
> >
>
> I posted a patch yesterday.
>
Updated patch to deal with
i = 42
print 1_'(i0)', i
end
Index: io.c
===
--- io.c(revision 178782)
+++ io.c(working copy)
@@ -2548,17 +2554,31 @@ match_dt_format (gfc_dt *dt)
if ((m = gfc_match_st_label (&label)) == MATCH_YES)
{
- if (dt->format_expr != NULL || dt->format_label != NULL)
+ char c;
+
+ /* Need to check if the format label is actually either an operand
+ to a user-defined operator or is a kind type parameter. That is,
+ print 2.ip.8 ! .ip. is a user-defined operator return CHARACTER.
+ print 1_'(I0)', i ! 1_'(I0)' is a default character string. */
+
+ gfc_gobble_whitespace ();
+ c = gfc_peek_ascii_char ();
+ if (c == '.' || c == '_')
+gfc_current_locus = where;
+ else
{
- gfc_free_st_label (label);
- goto conflict;
-}
+ if (dt->format_expr != NULL || dt->format_label != NULL)
+{
+ gfc_free_st_label (label);
+ goto conflict;
+}
- if (gfc_reference_st_label (label, ST_LABEL_FORMAT) == FAILURE)
-return MATCH_ERROR;
+ if (gfc_reference_st_label (label, ST_LABEL_FORMAT) == FAILURE)
+return MATCH_ERROR;
- dt->format_label = label;
- return MATCH_YES;
+ dt->format_label = label;
+ return MATCH_YES;
+}
}
else if (m == MATCH_ERROR)
/* The label was zero or too large. Emit the correct diagnosis. */
[Bug fortran/50407] compiler confused by .operator.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50407 --- Comment #12 from Steve Kargl 2011-09-16 12:44:37 UTC --- On Fri, Sep 16, 2011 at 07:22:09AM +, zeccav at gmail dot com wrote: > > To me, it looks like the parser does not handle correctly the format > specification as a default-char-expression defined in fortran 95 R913 > I posted a patch yesterday.
[Bug fortran/50407] compiler confused by .operator.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50407 --- Comment #11 from Vittorio Zecca 2011-09-16 07:22:09 UTC --- If you add character(9) s s=2.ip.8 gfortran, and g95, compile successfully. On the contrary gfortran fails to parse write(6,fmt=2.ip.8) To me, it looks like the parser does not handle correctly the format specification as a default-char-expression defined in fortran 95 R913 By the way, the following fails as well, should I open a new bug? write(6,fmt=1_'()') Again, in my opinion, recursive I/O, allowed or not, has nothing to do with parsing format specifications.
[Bug fortran/50407] compiler confused by .operator.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50407
--- Comment #10 from Steve Kargl
2011-09-15 23:05:25 UTC ---
On Thu, Sep 15, 2011 at 10:53:17PM +, sgk at troutmask dot
apl.washington.edu wrote:
>
> putting a fairly ugly hack into match_dt_format to
> skip statement lable matching, I can get gfortran
> to give
>
> troutmask:sgk[266] gfc4x -o z b.f && ./z
> ok 16
> ok 6
> ok 12
>
It's not pretty, but it appears to work.
Index: io.c
===
--- io.c(revision 178782)
+++ io.c(working copy)
@@ -2548,17 +2554,24 @@ match_dt_format (gfc_dt *dt)
if ((m = gfc_match_st_label (&label)) == MATCH_YES)
{
- if (dt->format_expr != NULL || dt->format_label != NULL)
+ gfc_gobble_whitespace ();
+ if (gfc_peek_ascii_char () != '.')
{
- gfc_free_st_label (label);
- goto conflict;
-}
- if (gfc_reference_st_label (label, ST_LABEL_FORMAT) == FAILURE)
-return MATCH_ERROR;
+ if (dt->format_expr != NULL || dt->format_label != NULL)
+{
+ gfc_free_st_label (label);
+ goto conflict;
+}
- dt->format_label = label;
- return MATCH_YES;
+ if (gfc_reference_st_label (label, ST_LABEL_FORMAT) == FAILURE)
+return MATCH_ERROR;
+
+ dt->format_label = label;
+ return MATCH_YES;
+}
+ else
+gfc_current_locus = where;
}
else if (m == MATCH_ERROR)
/* The label was zero or too large. Emit the correct diagnosis. */
[Bug fortran/50407] compiler confused by .operator.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50407 --- Comment #9 from Steve Kargl 2011-09-15 22:53:17 UTC --- On Thu, Sep 15, 2011 at 09:32:41PM +, sgk at troutmask dot apl.washington.edu wrote: > On Thu, Sep 15, 2011 at 09:21:42PM +, anlauf at gmx dot de wrote: > > > > When you put parentheses around the expressions, > > like (2.ip.8), then the code compiles. > > > > This is also what the Intel Compiler seems to require for the > > other variants. Otherwise you get a lot of messages... > > I can confirm that gfortran is mathcing the 2 as if it is > a statement label. It seems one may need to alter > match_dt_format in fortran/io.c to check if 2 is an > operand of a user defined operator. > putting a fairly ugly hack into match_dt_format to skip statement lable matching, I can get gfortran to give troutmask:sgk[266] gfc4x -o z b.f && ./z ok 16 ok 6 ok 12
[Bug fortran/50407] compiler confused by .operator.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50407 --- Comment #8 from Dominique d'Humieres 2011-09-15 22:06:50 UTC --- > So as Steve, I think the code is invalid. My mistake: I did not parse the code well enough to realize that the result of the operator was a valid format. Concerning the actual recursive I/O, I think it is allowed since 'mul' is an internal file.
[Bug fortran/50407] compiler confused by .operator.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50407 --- Comment #7 from Steve Kargl 2011-09-15 21:32:41 UTC --- On Thu, Sep 15, 2011 at 09:21:42PM +, anlauf at gmx dot de wrote: > > When you put parentheses around the expressions, > like (2.ip.8), then the code compiles. > > This is also what the Intel Compiler seems to require for the > other variants. Otherwise you get a lot of messages... I can confirm that gfortran is mathcing the 2 as if it is a statement label. It seems one may need to alter match_dt_format in fortran/io.c to check if 2 is an operand of a user defined operator.
[Bug fortran/50407] compiler confused by .operator.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50407 --- Comment #6 from Harald Anlauf 2011-09-15 21:21:42 UTC --- (In reply to comment #5) > On Thu, Sep 15, 2011 at 08:21:04PM +, zeccav at gmail dot com wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50407 > > > > --- Comment #2 from Vittorio Zecca 2011-09-15 > > 20:21:04 UTC --- > > I believe the code is valid, and it has nothing to do with recursive I/O. > > If you comment out the write in the mul function gfortran still fails, so it > > does not depend on recursive I/O. > > If I comment out the write statement and the 2.ip.8 statement, > you again have invalid code because the return value of the > function is never defined. > > But, as I stated, I need to check the requirements of the > standard on recursive IO. When you put parentheses around the expressions, like (2.ip.8), then the code compiles. This is also what the Intel Compiler seems to require for the other variants. Otherwise you get a lot of messages...
[Bug fortran/50407] compiler confused by .operator.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50407 --- Comment #5 from Steve Kargl 2011-09-15 21:13:16 UTC --- On Thu, Sep 15, 2011 at 08:21:04PM +, zeccav at gmail dot com wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50407 > > --- Comment #2 from Vittorio Zecca 2011-09-15 > 20:21:04 UTC --- > I believe the code is valid, and it has nothing to do with recursive I/O. > If you comment out the write in the mul function gfortran still fails, so it > does not depend on recursive I/O. If I comment out the write statement and the 2.ip.8 statement, you again have invalid code because the return value of the function is never defined. But, as I stated, I need to check the requirements of the standard on recursive IO.
[Bug fortran/50407] compiler confused by .operator.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50407 --- Comment #4 from Vittorio Zecca 2011-09-15 20:36:54 UTC --- I disagree, the Fortran 95 standard at R911 allows PRINT format and R913 says that format may be a default-char-expr Now, 2.ip.8 is a default character expression, or not? Again, the .ip. operator appears in a format, not in an output-item-list. g95 is wrong.
[Bug fortran/50407] compiler confused by .operator.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50407
--- Comment #3 from Dominique d'Humieres 2011-09-15
20:28:15 UTC ---
g95 fails with
In file pr50407.f90:10
print 2.ip.8 ! gfortran gets confused, expects a comma
1
Error: Syntax error in PRINT statement at (1)
print *, 2.ip.8 ! gfortran gets confused, expects a comma
print *, i.ip.2 ! compiles fine
print *, i.ip.j ! compiles fine
compiles and gives
('ok 16')
('ok 6')
('ok 12')
So as Steve, I think the code is invalid.
[Bug fortran/50407] compiler confused by .operator.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50407 --- Comment #2 from Vittorio Zecca 2011-09-15 20:21:04 UTC --- I believe the code is valid, and it has nothing to do with recursive I/O. If you comment out the write in the mul function gfortran still fails, so it does not depend on recursive I/O. gfortran only fails on 2.ip.8 while it correctly recognizes i.ip.2 and i.ip.j, if you run the code commenting out print 2.ip.8 you get ok 6 ok 12 Oracle Solaris compiler sunf95 correctly compiles and run displaying ok 16 ok 6 ok 12 Remember 2.ip.8 must be a format string in this context.
[Bug fortran/50407] compiler confused by .operator.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50407 kargl at gcc dot gnu.org changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #1 from kargl at gcc dot gnu.org 2011-09-15 16:55:12 UTC --- I believe the code is invalid due to the recursive IO. Don't have time now to verify this. gfortran is looking for a comma because it sees 2 in 2.ip.8 as a statement label. I think gfortran may be correct in its behavior.
