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 copyin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50407
kargl at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|
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
> 20
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-expr
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
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
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 par
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 actua
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 wha
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 V
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:
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
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 *
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
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
--- Co
15 matches
Mail list logo
