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

[Bug libfortran/48852] New: 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

           Summary: Invalid spaces in list-directed output of complex
                    constants
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libfortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: thenlich@users.sourceforge.net


There are invalid spaces in complex constants in list-directed output:

print *, (1.0, 0.0) ! " (  1.00000000    ,  0.00000000    )" expected "
(1.00000000,0.00000000)"

Fortran 2003/2008:
"Real constants are produced with the effect of either an F edit descriptor or
an E edit descriptor, depending on the magnitude x of the value and a range
10^d1 <= x < 10^d2, where d1 and d2 are processor-dependent integers. If the
magnitude x  is within this range or is zero, the constant is produced using
0PFw.d; otherwise, 1PEw.d Ee is used.

Complex constants are enclosed in parentheses with a separator between the real
and imaginary parts, each produced as defined above for real constants. The
separator is a comma if the decimal edit mode is POINT; it is a semicolon if
the decimal edit mode is COMMA. The end of a record may occur between the
separator and the imaginary part only if the entire constant is as long as, or
longer than, an entire record. 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."

Part of the problem is caused by GFortran using Gw.dEe editing instead of the
Fw.d editing required by the standard (i.e. appending the n blanks at the end).
This is a waste of space for real constants and an outright bug for complex
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

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

as we do now, 

 (      1.00000000,      0.00000000)

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

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

[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.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.

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

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

[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

[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.00000000    ,  0.00000000    ) ( -1.00000002E-25,  0.00000000    )
 ( -1.00000002E-25,  0.00000000    ) (  1.00000000    ,  0.00000000    )
 ( -3.49999992E-24, -3.49999992E-24) ( -4.19999998E-24, -1.27000003E-23)
 (  1.00000000    ,  0.00000000    ) ( -1.00000002E-25,  0.00000000    )
 ---------------------------------

I have my experimental doing this: case A
 ---------------------------------
 (1.00000000,0.00000000)             (-0.10000000E-24,0.00000000)       
 (-0.10000000E-24,0.00000000)        (1.00000000,0.00000000)            
 (-0.34999999E-23,-0.34999999E-23)   (-0.42000000E-23,-0.12700000E-22)  
 (1.00000000,0.00000000)             (-0.10000000E-24,0.00000000)       
 ---------------------------------

I could also do this: case B
 ---------------------------------
 (1.00000000,0.00000000          ) (-0.10000000E-24,0.00000000     )       
 (-0.10000000E-24,0.00000000     ) (1.00000000,0.00000000          )            
 (-0.34999999E-23,-0.34999999E-23) (-0.42000000E-23,-0.12700000E-22)  
 (1.00000000,0.00000000          ) (-0.10000000E-24,0.00000000     )       
 ---------------------------------

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.000000,0.0000000E+00) (-1.0000000E-25,0.0000000E+00)
 (-1.0000000E-25,0.0000000E+00) (1.000000,0.0000000E+00)
 (-3.4999999E-24,-3.4999999E-24) (-4.2000000E-24,-1.2700000E-23)
 (1.000000,0.0000000E+00) (-1.0000000E-25,0.0000000E+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

[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.00000000    ,  0.00000000    ) ( -1.00000002E-25,  0.00000000    )
>  ( -1.00000002E-25,  0.00000000    ) (  1.00000000    ,  0.00000000    )
>  ( -3.49999992E-24, -3.49999992E-24) ( -4.19999998E-24, -1.27000003E-23)
>  (  1.00000000    ,  0.00000000    ) ( -1.00000002E-25,  0.00000000    )
>  ---------------------------------
> 
> I have my experimental doing this: case A
>  ---------------------------------
>  (1.00000000,0.00000000)             (-0.10000000E-24,0.00000000)       
>  (-0.10000000E-24,0.00000000)        (1.00000000,0.00000000)            
>  (-0.34999999E-23,-0.34999999E-23)   (-0.42000000E-23,-0.12700000E-22)  
>  (1.00000000,0.00000000)             (-0.10000000E-24,0.00000000)       
>  ---------------------------------
> 
> I could also do this: case B
>  ---------------------------------
>  (1.00000000,0.00000000          ) (-0.10000000E-24,0.00000000     )       
>  (-0.10000000E-24,0.00000000     ) (1.00000000,0.00000000          )        
> 
>  (-0.34999999E-23,-0.34999999E-23) (-0.42000000E-23,-0.12700000E-22)  
>  (1.00000000,0.00000000          ) (-0.10000000E-24,0.00000000     )       
>  ---------------------------------
> 
> 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.00000000,0.00000000)      (-0.10000000E-24,0.00000000)
      (-0.10000000E-24,0.00000000)           (1.00000000,0.00000000)            
 (-0.34999999E-23,-0.34999999E-23) (-0.42000000E-23,-0.12700000E-22)  
           (1.00000000,0.00000000)      (-0.10000000E-24,0.00000000)       
 ---------------------------------

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."
>From gcc-bugs-return-484607-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Apr 25 08:40:27 2015
Return-Path: <gcc-bugs-return-484607-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 87863 invoked by alias); 25 Apr 2015 08:40:26 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 87796 invoked by uid 48); 25 Apr 2015 08:40:23 -0000
From: "pault at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/65841] Seg fault on intrinsic assignment to allocatable derived type with allocatable component
Date: Sat, 25 Apr 2015 08:40:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: pault at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65841-4-feGuPpimkw@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65841-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65841-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-04/txt/msg02159.txt.bz2
Content-length: 736

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide841

--- Comment #4 from Paul Thomas <pault at gcc dot gnu.org> ---
(In reply to Dominique d'Humieres from comment #3)
> This PR is fixed by Andre's patch for pr59678 (all tests).
>
> > Note that the last test in comment 1 segfault with only the [fist patch]
> > for pr65792 + the one for pr59678.
>
> So this is another conflict between the two patches.

I haven't had time to keep track of the gfortran list. However, whilst
travelling I have worked on this bug and came to the same analysis as Andre and
nearly the same patch :-)  I am therefore reviewing Andre's patch for PR59678.
I just applied it to trunk and am regtesting. Watch this space in the next few
hours!

Cheers

Paul

[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.