http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48852
--- Comment #3 from Janne Blomqvist <jb at gcc dot gnu.org> 2011-05-05 03:33:30 UTC --- (In reply to comment #2) > We have another PR in place that is related to this, pr31190 Thanks for the reminder. > One thought was to hide this behind an option so that one could stick with the > default or go for a thin format. I don't think an option is worth it; few people care to use such things, and it just means more code to write, test and document. As the consensus in that PR seems to be to retain the current behavior as default, IMHO this suggestion of mine can be ignored. And as you mention, with (1X,G0) one can easily get minimum-width fields. That being said, this bug is still valid as it seems the standard is quite clear that trailing blanks in the constituent real fields are not allowed (as neither 0PFw.d nor 1PEw.dEe allow it). However, AFAICS leading blanks are still allowed as they are part of the real parts, the prohibition against embedded blanks in the complex output refer only to blanks other than the ones present in the real fields, no? So while print *, (1.0, 0.0) may not output ( 1.00000000 , 0.00000000 ) as we do now, ( 1.00000000, 0.00000000) is allowed and retains the fixed width fields we have now.
