http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48852
--- Comment #7 from Janne Blomqvist <jb at gcc dot gnu.org> 2011-05-05 12:44:42 UTC --- (In reply to comment #6) > On 05/05/2011 12:04 AM, thenlich at users dot sourceforge.net wrote: > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48852 > ---snip--- > > As much as I'd like to, I cannot agree: > > > > "The only embedded blanks permitted within a complex constant are between > > the > > separator and the end of a record and one blank at the beginning of the next > > record." > > I am a little concerned. The above says 'constant'. Does this mean a > complex > 'variable' is output differently? Right now, the runtime libarary has no way > to > know the difference. We do have a control bit we can set before and after the > transfer and we could have the frontend insert this for a complex constant. > It > just seems odd that one would treat a constant differently from a variable so > I > am seeking clarity here. I was a bit confused by this as well, but it seems it's just a strangely named term the standard uses for "the character representation of the IO list element in the unit the data transfer statement refers to", or something like that. So it doesn't have anything to do with what one would ordinarily consider a constant in a programming language (in Fortran, PARAMETER). > Also, See below. Does this give the expected output? > > print *, (1.0, 0.0) > end > > $ ./a.out > (1.00000000,.00000000) > > Index: write.c > =================================================================== > --- write.c (revision 173411) > +++ write.c (working copy) > @@ -1509,15 +1509,15 @@ > { > char semi_comma = > dtp->u.p.current_unit->decimal_status == DECIMAL_POINT ? ',' : ';'; > - > if (write_char (dtp, '(')) > return; > + dtp->u.p.g0_no_blanks = 1; > write_real (dtp, source, kind); > > if (write_char (dtp, semi_comma)) > return; > write_real (dtp, source + size / 2, kind); > - > + dtp->u.p.g0_no_blanks = 0; > write_char (dtp, ')'); > } This looks like a good start, I was thinking of something similar myself. As Thomas says, we might want to right-justify this in a field of (per type/kind) constant width in order to guarantee aligned columns, like we do for other types.
