[Bug libfortran/48852] Invalid spaces in list-directed output of complex constants

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48852
Bug 48852 depends on bug 48925, which changed state.

Bug 48925 Summary: Code cleanup in write_float.def
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48925

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

[Bug libfortran/48852] Invalid spaces in list-directed output of complex constants

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48852

Jerry DeLisle  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #18 from Jerry DeLisle  ---
fixed, closing

[Bug libfortran/48852] Invalid spaces in list-directed output of complex constants

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48852

--- Comment #17 from Jerry DeLisle  ---
Author: jvdelisle
Date: Thu Jun 23 15:58:05 2016
New Revision: 237735

URL: https://gcc.gnu.org/viewcvs?rev=237735=gcc=rev
Log:
2016-06-23  Jerry DeLisle  

PR libgfortran/48852
* io/write.c: Cleaned up whitespace.
(write_d, write_e, write_f, write_es, write_en): Use new helper
function
write_float_0. (write_float_0): New helper function.
(get_precision, select_buffer, select_string, write_float_string): New
helper functions used in remaining float writing functions. Helper
function
write_float_string now contains code for writing to kind=4 character
internal units.
(write_real): Modified to establish working buffers at this level and
to
use new helper functions.
(write_real_g0): Likewise modified.
(write_complex): Likewise modified. Gets both float strings before
output so that final lengths can be determined which allows right
justifying the complex number with no intervening spaces.
* io/write_float.def (build_float_string): Renamed from previosly
output_float, modified to use buffers passed in from higher functions,
builds a null terminated string of the floating point value. Character
kind=4 code eliminated.
(write_infnan): Likewise modified to use incoming buffers and eliminate
kind=4 related code.
(OUTPUT_FLOAT_FMT_G): Deleted, functionality moved into FORMAT_FLOAT.
(FORMAT_FLOAT): Renamed macro from WRITE_FLOAT. Use build_float_string.
(get_float_string): Renamed from write_float, uses FORMAT_FLOAT macro.
Buffer allocation removed, now at higher level.

PR libgfortran/48852
* gfortran.dg/char4_iunit_1.f03: Update test.
* gfortran.dg/f2003_io_5.f03: Update test.
* gfortran.dg/real_const_3.f90: Update test.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/char4_iunit_1.f03
trunk/gcc/testsuite/gfortran.dg/f2003_io_5.f03
trunk/gcc/testsuite/gfortran.dg/real_const_3.f90
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/write.c
trunk/libgfortran/io/write_float.def

[Bug libfortran/48852] Invalid spaces in list-directed output of complex constants

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48852

--- Comment #16 from Jerry DeLisle  ---
Patch posted here:

https://gcc.gnu.org/ml/fortran/2016-06/msg00047.html

[Bug libfortran/48852] Invalid spaces in list-directed output of complex constants

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48852

Jerry DeLisle  changed:

   What|Removed |Added

 Depends on||48925

--- Comment #15 from Jerry DeLisle  ---
This will be fixed with 48925.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48925
[Bug 48925] Code cleanup in write_float.def

[Bug libfortran/48852] Invalid spaces in list-directed output of complex constants

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48852

--- Comment #14 from Jerry DeLisle jvdelisle at gcc dot gnu.org ---
I have decided that to do this right I need to revamp how write_float.def and
associated functions are organized.  We have discussed doing this quite a while
ago, so now is the time. 

I see it like this:

- Create a working buffer (currently buried down under, need it brought up)
- Get the digits based on the KIND etc (DTOA FTOA etc)
- Format the digits (right now mostly in output_float)
- Send the formatted digits out (split this out of output float)

[Bug libfortran/48852] Invalid spaces in list-directed output of complex constants

[thenlich at users dot sourceforge.net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48852

--- Comment #12 from Thomas Henlich thenlich at users dot sourceforge.net ---
(In reply to Jerry DeLisle from comment #10)
 gfortran currently does this with default formatting, list directed outout:
  -
  (  1.,  0.) ( -1.0002E-25,  0.)
  ( -1.0002E-25,  0.) (  1.,  0.)
  ( -3.4992E-24, -3.4992E-24) ( -4.1998E-24, -1.2703E-23)
  (  1.,  0.) ( -1.0002E-25,  0.)
  -
 
 I have my experimental doing this: case A
  -
  (1.,0.) (-0.1000E-24,0.)   
  (-0.1000E-24,0.)(1.,0.)
  (-0.3499E-23,-0.3499E-23)   (-0.4200E-23,-0.1270E-22)  
  (1.,0.) (-0.1000E-24,0.)   
  -
 
 I could also do this: case B
  -
  (1.,0.  ) (-0.1000E-24,0. )   
  (-0.1000E-24,0. ) (1.,0.  )
 
  (-0.3499E-23,-0.3499E-23) (-0.4200E-23,-0.1270E-22)  
  (1.,0.  ) (-0.1000E-24,0. )   
  -
 
 or is there some other arrangement?

I think your case B is invalid, because no spaces are allowed in constants,
i.e. between the parentheses (see above).

There is also case C (right-flush in 2*w+3):
 -
   (1.,0.)  (-0.1000E-24,0.)
  (-0.1000E-24,0.)   (1.,0.)
 (-0.3499E-23,-0.3499E-23) (-0.4200E-23,-0.1270E-22)  
   (1.,0.)  (-0.1000E-24,0.)   
 -

The standard says:

Numeric editing, General rules: ... On output, the representation is right
justified in the field. If the number of characters produced by the editing is
smaller than the field width, leading blanks are inserted in the field.

[Bug libfortran/48852] Invalid spaces in list-directed output of complex constants

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48852

--- Comment #13 from Jerry DeLisle jvdelisle at gcc dot gnu.org ---
(In reply to Thomas Henlich from comment #12)
--- snip ---

 There is also case C (right-flush in 2*w+3):

--- snip ---

Oh yes, Thanks Thomas. I now see you mentioned this in your previous comment.

It will require a different approach than what I have now.  I will see what I
can come up with.

[Bug libfortran/48852] Invalid spaces in list-directed output of complex constants

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48852

--- Comment #10 from Jerry DeLisle jvdelisle at gcc dot gnu.org ---
gfortran currently does this with default formatting, list directed outout:
 -
 (  1.,  0.) ( -1.0002E-25,  0.)
 ( -1.0002E-25,  0.) (  1.,  0.)
 ( -3.4992E-24, -3.4992E-24) ( -4.1998E-24, -1.2703E-23)
 (  1.,  0.) ( -1.0002E-25,  0.)
 -

I have my experimental doing this: case A
 -
 (1.,0.) (-0.1000E-24,0.)   
 (-0.1000E-24,0.)(1.,0.)
 (-0.3499E-23,-0.3499E-23)   (-0.4200E-23,-0.1270E-22)  
 (1.,0.) (-0.1000E-24,0.)   
 -

I could also do this: case B
 -
 (1.,0.  ) (-0.1000E-24,0. )   
 (-0.1000E-24,0. ) (1.,0.  )
 (-0.3499E-23,-0.3499E-23) (-0.4200E-23,-0.1270E-22)  
 (1.,0.  ) (-0.1000E-24,0. )   
 -

or is there some other arrangement?

[Bug libfortran/48852] Invalid spaces in list-directed output of complex constants

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48852

--- Comment #11 from Jerry DeLisle jvdelisle at gcc dot gnu.org ---
IFORT does this:

 -
 (1.00,0.000E+00) (-1.000E-25,0.000E+00)
 (-1.000E-25,0.000E+00) (1.00,0.000E+00)
 (-3.499E-24,-3.499E-24) (-4.200E-24,-1.270E-23)
 (1.00,0.000E+00) (-1.000E-25,0.000E+00)
 -

The program I am using is this:

print *, -
print *, (1.0,0.0),(-1.0e-25,0.0)
print *, (-1.0e-25,0.0),(1.0,0.0)
print *, (-35.0e-25,-35.0e-25),(-42.0e-25,-127.0e-25)
print *, (1.0,0.0),(-1.0e-25,0.0)
print *, -
end

I think Case A in Comment 10 looks best.

[Bug libfortran/48852] Invalid spaces in list-directed output of complex constants

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48852

Jerry DeLisle jvdelisle at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jvdelisle at gcc dot 
gnu.org

--- Comment #9 from Jerry DeLisle jvdelisle at gcc dot gnu.org ---
Putting this on my active list.

[Bug libfortran/48852] Invalid spaces in list-directed output of complex constants

[thenlich at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48852

--- Comment #4 from Thomas Henlich thenlich at users dot sourceforge.net 
2011-05-05 06:50:13 UTC ---
(In reply to comment #3)
 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?

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.

An embedded blank within a complex constant is any blank which neither leads
the complex constant nor trails it; in other words, any space between the left
and the right parenthesis. It is not permitted, except around record breaks.

If it is important, we can still ensure the tabular alignment of complex fields
by right-flushing them in a field of width 2*w+3, where w is the width for a
real constant.

[Bug libfortran/48852] Invalid spaces in list-directed output of complex constants

[jb at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48852

--- Comment #5 from Janne Blomqvist jb at gcc dot gnu.org 2011-05-05 12:11:02 
UTC ---
(In reply to comment #4)
 (In reply to comment #3)
  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?
 
 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.
 
 An embedded blank within a complex constant is any blank which neither leads
 the complex constant nor trails it; in other words, any space between the left
 and the right parenthesis. It is not permitted, except around record breaks.

Thinking about this some more, I think you're right. If not, the processor
could after all choose w such that any amount of leading blanks are present,
thus rendering more or less the entire rule forbidding embedded blanks (except
at those 2 specified locations if the constant straddles a record boundary)
meaningless.

I asked c.l.f, lets see if someone knowledgeable disagrees..

 If it is important, we can still ensure the tabular alignment of complex 
 fields
 by right-flushing them in a field of width 2*w+3, where w is the width for a
 real constant.

Yes, I suppose this is what must be done.

[Bug libfortran/48852] Invalid spaces in list-directed output of complex constants

[jvdelisle at frontier dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48852

--- Comment #6 from jvdelisle at frontier dot com 2011-05-05 12:28:01 UTC ---
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.

Also, See below.  Does this give the expected output?

print *, (1.0, 0.0)
end

$ ./a.out
  (1.,.)

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, ')');
  }

[Bug libfortran/48852] Invalid spaces in list-directed output of complex constants

[jb at gcc dot gnu.org]

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.,.)
 
 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.

[Bug libfortran/48852] Invalid spaces in list-directed output of complex constants

[thenlich at users dot sourceforge.net]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48852

--- Comment #8 from Thomas Henlich thenlich at users dot sourceforge.net 
2011-05-05 13:31:47 UTC ---
(In reply to comment #6)
 Also, See below.  Does this give the expected output?
 
 print *, (1.0, 0.0)
 end
 
 $ ./a.out
   (1.,.)

I personally prefer the optional zero before the decimal separator to be
printed, because we have done so and still do for real numbers:
(1.,0.)

[Bug libfortran/48852] Invalid spaces in list-directed output of complex constants

[jb at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48852

Janne Blomqvist jb at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2011.05.04 20:38:38
 CC||jb at gcc dot gnu.org
 Ever Confirmed|0   |1

--- Comment #1 from Janne Blomqvist jb at gcc dot gnu.org 2011-05-04 20:38:38 
UTC ---
Confirmed.

Wrt the space wastage, gfortran uses fixed width fields for each type for list
directed output. This has the benefit of aligning columns when printing tables,
at the cost of wasting space. The other choice, which some other compilers do,
is to get rid of extra blanks similar to the various w=0 edit descriptors.
Personally I would prefer this, but alas, history might force us to retain the
present behavior.

[Bug libfortran/48852] Invalid spaces in list-directed output of complex constants

[jvdelisle at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48852

Jerry DeLisle jvdelisle at gcc dot gnu.org changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot
   ||gnu.org

--- Comment #2 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2011-05-05 
01:06:01 UTC ---
We have another PR in place that is related to this, pr31190

One thought was to hide this behind an option so that one could stick with the
default or go for a thin format.

[Bug libfortran/48852] Invalid spaces in list-directed output of complex constants

[jb at gcc dot gnu.org]

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.,  0.)

as we do now, 

 (  1.,  0.)

is allowed and retains the fixed width fields we have now.