gfortran quad precision bug

[e p chandler]

The following program

integer,parameter :: qp=selected_real_kind(20)
real(qp) :: q

q=1
print *,q
print '(f4.2)',q

end

gives this output on Win32, MinGW32


gcc version 4.6.2 from equation solution

1.0000000000000000000000000000000000
1.00

gcc version 4.7.0 20111029 from equation solution

0.00000000000000000000000000000000000
0.00

gcc version 4.7.0 20111011 from humboldt.edu

0.00000000000000000000000000000000000
0.00

Is this bug specific to gcc 4.7 on Win32?

[Terence]

See what happens when you change
q=1
to
q=1.d0

[Richard Maine]

If it does make any difference, it would still be a bug. Both statements
are perfectly standard conforming and should have the same result.

--
Richard Maine | Good judgment comes from experience;
email: last name at domain . net | experience comes from bad judgment.
domain: summertriangle | -- Mark Twain

[Steven G. Kargl]

On Fri, 04 Nov 2011 21:54:04 -0400, e p chandler wrote:

>>
> gcc version 4.7.0 20111011 from humboldt.edu
>
> 0.00000000000000000000000000000000000
> 0.00
>
> Is this bug specific to gcc 4.7 on Win32?

Maybe.

What does -fdump-tree-original produce?

On FreeBSD with 4.7.0, I see

laptop:kargl[208] gfc4x -o z -O foo.f90 -fdump-tree-original && ./z
1.00000000000000000000000000000000000
1.00

laptop:kargl[211] more foo.f90.003t.original
MAIN__ ()
{
real(kind=16) q;

q = 1.0e+0;
{
struct __st_parameter_dt dt_parm.0;

dt_parm.0.common.filename = &"foo.f90"[1]{lb: 1 sz: 1};
dt_parm.0.common.line = 4;
dt_parm.0.common.flags = 128;
dt_parm.0.common.unit = 6;
_gfortran_st_write (&dt_parm.0);
_gfortran_transfer_real128_write (&dt_parm.0, &q, 16);
_gfortran_st_write_done (&dt_parm.0);
}
{
struct __st_parameter_dt dt_parm.1;

dt_parm.1.common.filename = &"foo.f90"[1]{lb: 1 sz: 1};
dt_parm.1.common.line = 5;
dt_parm.1.format = &"(f4.2)"[1]{lb: 1 sz: 1};
dt_parm.1.format_len = 6;
dt_parm.1.common.flags = 4096;
dt_parm.1.common.unit = 6;
_gfortran_st_write (&dt_parm.1);
_gfortran_transfer_real128_write (&dt_parm.1, &q, 16);
_gfortran_st_write_done (&dt_parm.1);
}
}

--
steve

[e p chandler]

"Steven G. Kargl" wrote in message news:j92j64$9lp$1...@dont-email.me...

On Fri, 04 Nov 2011 21:54:04 -0400, e p chandler wrote:

>>
> gcc version 4.7.0 20111011 from humboldt.edu
>
> 0.00000000000000000000000000000000000
> 0.00
>
> Is this bug specific to gcc 4.7 on Win32?

Maybe.

What does -fdump-tree-original produce?

On FreeBSD with 4.7.0, I see

laptop:kargl[208] gfc4x -o z -O foo.f90 -fdump-tree-original && ./z
1.00000000000000000000000000000000000
1.00

laptop:kargl[211] more foo.f90.003t.original
MAIN__ ()
{
real(kind=16) q;

q = 1.0e+0;
{
struct __st_parameter_dt dt_parm.0;

dt_parm.0.common.filename = &"foo.f90"[1]{lb: 1 sz: 1};
dt_parm.0.common.line = 4;

4 -> 5

dt_parm.0.common.flags = 128;
dt_parm.0.common.unit = 6;
_gfortran_st_write (&dt_parm.0);
_gfortran_transfer_real128_write (&dt_parm.0, &q, 16);
_gfortran_st_write_done (&dt_parm.0);
}
{
struct __st_parameter_dt dt_parm.1;

dt_parm.1.common.filename = &"foo.f90"[1]{lb: 1 sz: 1};
dt_parm.1.common.line = 5;

5 -> 6

dt_parm.1.format = &"(f4.2)"[1]{lb: 1 sz: 1};
dt_parm.1.format_len = 6;
dt_parm.1.common.flags = 4096;
dt_parm.1.common.unit = 6;
_gfortran_st_write (&dt_parm.1);
_gfortran_transfer_real128_write (&dt_parm.1, &q, 16);
_gfortran_st_write_done (&dt_parm.1);
}
}

added ->

main (integer(kind=4) argc, character(kind=1) * * argv)
{
static integer(kind=4) options.2[8] = {68, 1023, 0, 0, 1, 1, 0, 1};

_gfortran_set_args (argc, argv);
_gfortran_set_options (8, &options.2[0]);
MAIN__ ();
return 0;
}

--- e

[Daniel Carrera]

On 11/05/2011 08:02 AM, e p chandler wrote:
> Maybe.
>
> What does -fdump-tree-original produce?

It prints out the parse tree produced the Fortran front-end, before any
optimizations.

GFortran works by parsing your Fortran code and converting it into a
very simple (thus verbose) language/parse-tree called GIMPLE, which is
given to the middle end of GCC. The middle end performs optimizations
and gives it to the back-end. The back-end converts it into machine
language and applies architecture-specific low level optimizations.

You can see in the output how each print statement was turned into a
block of code.

Hmm... the output looks reasonable, except that I don't know what "4 ->
5" and "5 -> 6" do, and the dump tree from Steven doesn't have those lines.

Daniel.

[Tobias Burnus]

Daniel Carrera wrote:
> On 11/05/2011 08:02 AM, e p chandler wrote:
>> What does -fdump-tree-original produce?
>
> It prints out the parse tree produced the Fortran front-end, before any
> optimizations.
>
> GFortran works by parsing your Fortran code and converting it into a
> very simple (thus verbose) language/parse-tree called GIMPLE, which is
> given to the middle end of GCC.

I want to point out that this dump, which resembles C does not contain
the full details. For instance, whether a pair of parentheses ("()") may
be optimized away (as it is typically done in C) or not (as in Fortran)
is not visible from the dump.

There are also other dumps available such as -fdump-tree-optimized or
one can have also the line-number information to check whether the
generated debuggining information is correct
(-fdump-tree-original-lineno). Consult the GCC manual for all available
trees and options.

> Hmm... the output looks reasonable, except that I don't know what "4 ->
> 5" and "5 -> 6" do, and the dump tree from Steven doesn't have those lines.

I think that's a manual diff: Those are the changes compared with
Steve's dump. (Namely: Line-number changes.)

I think the compiler itself it OK and the problem must be in the
library. Thus, either in libgfortran or in libquadmath or possibly in
some library which is called by the latter.

Unfortunately, there is no libquadmath test suite and only a rather
simple test for it in gfortran itself*. Thus, I would not rule out a
regression - even though I could not find anything in the changelog of
libgfortran/libquadmath after the 4.6.0 release which could cause such
problems.


e.p. chandler: Can you provide more information about *your* GCC
versions? Namely, which version exactly? Which MinGW32 version? And
where did you get the compiler (TDM, mingwg.org, equation.com, compiled
yourself, ...)?

Tobias

[Steven G. Kargl]

On Sat, 05 Nov 2011 11:59:24 +0100, Daniel Carrera wrote:

> On 11/05/2011 08:02 AM, e p chandler wrote:
>> Maybe.
>>
>> What does -fdump-tree-original produce?
>
> It prints out the parse tree produced the Fortran front-end, before any
> optimizations.
>
> GFortran works by parsing your Fortran code and converting it into a
> very simple (thus verbose) language/parse-tree called GIMPLE, which is
> given to the middle end of GCC. The middle end performs optimizations
> and gives it to the back-end. The back-end converts it into machine
> language and applies architecture-specific low level optimizations.
>
> You can see in the output how each print statement was turned into a
> block of code.

Daniel, it is unclear to me whether you're explaining what this
option does for e p or for me? In any event,

laptop:kargl[212] pwd
/usr/home/kargl/gcc/gcc4x
laptop:kargl[213] grep -i kargl MAINTAINERS
Fortran Steven G. Kargl sgk at troutmask apl washington edu

> Hmm... the output looks reasonable, except that I don't know what "4 ->
> 5" and "5 -> 6" do, and the dump tree from Steven doesn't have those
> lines.

These changes are simply line number difference in our files.
I wanted to see if e p's 4.7.0 was producing the same dump
as his 4.6.2. The answer appears to be 'yes'. This suggests
that the problem is not in Fortran frontend.

I suspect the issue lies in libquadmath's IO routines and MingW.
A long time ago, libgfortran's IO routine had some bugs due to
MingW and how it interfaced with Windows. I do not remember the
details, because I do not do windows.

>> added ->
>>
>> main (integer(kind=4) argc, character(kind=1) * * argv) {
>> static integer(kind=4) options.2[8] = {68, 1023, 0, 0, 1, 1, 0, 1};
>>
>> _gfortran_set_args (argc, argv);
>> _gfortran_set_options (8, &options.2[0]); MAIN__ ();
>> return 0;
>> }

And, yes, I left this part out because it isn't what I wanted
to see.

--
steve

[Daniel Carrera]

On 11/05/2011 05:25 PM, Steven G. Kargl wrote:
>
> Daniel, it is unclear to me whether you're explaining what this
> option does for e p or for me? In any event,

For e p. He asked. I know that you know.

Cheers,
Daniel.

[William Clodius]

Tobias Burnus <bur...@net-b.de> wrote:

> Daniel Carrera wrote:
> > On 11/05/2011 08:02 AM, e p chandler wrote:
> >> What does -fdump-tree-original produce?
> >
> > It prints out the parse tree produced the Fortran front-end, before any
> > optimizations.
> >
> > GFortran works by parsing your Fortran code and converting it into a
> > very simple (thus verbose) language/parse-tree called GIMPLE, which is
> > given to the middle end of GCC.
>
> I want to point out that this dump, which resembles C does not contain
> the full details. For instance, whether a pair of parentheses ("()") may
> be optimized away (as it is typically done in C) or not (as in Fortran)
> is not visible from the dump.

Minor correction, while K&R C had more flexiblity with respect to
parentheses than Fortran, I bellieve ANSI C has very similar
restrictions.

>
> There are also other dumps available such as -fdump-tree-optimized or
> one can have also the line-number information to check whether the
> generated debuggining information is correct
> (-fdump-tree-original-lineno). Consult the GCC manual for all available
> trees and options.
>
> > Hmm... the output looks reasonable, except that I don't know what "4 ->
> > 5" and "5 -> 6" do, and the dump tree from Steven doesn't have those lines.
>
> I think that's a manual diff: Those are the changes compared with
> Steve's dump. (Namely: Line-number changes.)
>
> I think the compiler itself it OK and the problem must be in the
> library. Thus, either in libgfortran or in libquadmath or possibly in
> some library which is called by the latter.
>
> Unfortunately, there is no libquadmath test suite and only a rather
> simple test for it in gfortran itself*. Thus, I would not rule out a
> regression - even though I could not find anything in the changelog of
> libgfortran/libquadmath after the 4.6.0 release which could cause such
> problems.
>
>
> e.p. chandler: Can you provide more information about *your* GCC
> versions? Namely, which version exactly? Which MinGW32 version? And
> where did you get the compiler (TDM, mingwg.org, equation.com, compiled
> yourself, ...)?
>
> Tobias

--
Bill Clodius
los the lost and net the pet to email

[e p chandler]

"Daniel Carrera" wrote in message news:4EB5170C...@gmail.com...

On 11/05/2011 08:02 AM, e p chandler wrote:
> Maybe.
>
> What does -fdump-tree-original produce?

It prints out the parse tree produced the Fortran front-end, before any
optimizations.

GFortran works by parsing your Fortran code and converting it into a
very simple (thus verbose) language/parse-tree called GIMPLE, which is
given to the middle end of GCC. The middle end performs optimizations
and gives it to the back-end. The back-end converts it into machine
language and applies architecture-specific low level optimizations.

You can see in the output how each print statement was turned into a
block of code.

Hmm... the output looks reasonable, except that I don't know what "4 ->
5" and "5 -> 6" do, and the dump tree from Steven doesn't have those lines.

Daniel.

---> These represent the differences in text between his output and my
output. Probably these are harmless differences in numbering of source
lines.

--- e

[e p chandler]

"Tobias Burnus" wrote in message news:4EB52163...@net-b.de...

Daniel Carrera wrote:
> On 11/05/2011 08:02 AM, e p chandler wrote:
>> What does -fdump-tree-original produce?
>
> It prints out the parse tree produced the Fortran front-end, before any
> optimizations.
>
> GFortran works by parsing your Fortran code and converting it into a
> very simple (thus verbose) language/parse-tree called GIMPLE, which is
> given to the middle end of GCC.

I want to point out that this dump, which resembles C does not contain
the full details. For instance, whether a pair of parentheses ("()") may
be optimized away (as it is typically done in C) or not (as in Fortran)
is not visible from the dump.

There are also other dumps available such as -fdump-tree-optimized or
one can have also the line-number information to check whether the
generated debuggining information is correct
(-fdump-tree-original-lineno). Consult the GCC manual for all available
trees and options.

> Hmm... the output looks reasonable, except that I don't know what "4 ->
> 5" and "5 -> 6" do, and the dump tree from Steven doesn't have those
> lines.

I think that's a manual diff: Those are the changes compared with
Steve's dump. (Namely: Line-number changes.)

---> Yes, it's a "manual" diff.

I think the compiler itself it OK and the problem must be in the
library. Thus, either in libgfortran or in libquadmath or possibly in
some library which is called by the latter.

Unfortunately, there is no libquadmath test suite and only a rather
simple test for it in gfortran itself*. Thus, I would not rule out a
regression - even though I could not find anything in the changelog of
libgfortran/libquadmath after the 4.6.0 release which could cause such
problems.


e.p. chandler: Can you provide more information about *your* GCC
versions? Namely, which version exactly? Which MinGW32 version? And
where did you get the compiler (TDM, mingwg.org, equation.com, compiled
yourself, ...)?

Tobias

---> The 4.6.2 (ok) was the latest release from equation.com.
The 4.7.0 were compiled by equation.com and finneyb at humboldt.edu (the
"native" MinGW referenced on the Gfortran Wiki page. Dates of the last are
10/29 and 10/11.

If you need to, I can re-install each of these 3 versions and use a v
switch.

---- e

[e p chandler]

"Daniel Carrera" wrote in message news:4EB564DD...@gmail.com...

--> Thanks for the explanation, however it was addressed. :).

[Terence]

Well I made my first suggestion, intended to discover if the problem was an
integer-to-real conversion problem of the compiler, with this precision
level.

Another is to try different values of n in

integer,parameter :: qp=selected_real_kind(n)

to see if the problem is related to a range of values for n, where the
software routines fail for that precision level.

The more data you have on the failure circumstances, the easier it will be
to get it fixed (or avoided).

[Tobias Burnus]

e p chandler wrote:
> ---> The 4.6.2 (ok) was the latest release from equation.com.
> The 4.7.0 were compiled by equation.com and finneyb at humboldt.edu (the
> "native" MinGW referenced on the Gfortran Wiki page. Dates of the last
> are 10/29 and 10/11.

The bug could be reproduced on MinGW64 with the current GCC/MinGW64
version as of a few hours ago.

It's still unclear where exactly it fails and why it is (seemingly) a
regression. Since it fails on both MinGW(32) and MinGW64 rules out
certain kind of bugs.

Tobias

[e p chandler]

"Terence" wrote in message
news:Yvitq.5365$7r4....@viwinnwfe02.internal.bigpond.com...

---> I already looked at this in a preliminary program that printed out the
kind numbers for various values of n.
qp was set to 16 (not portable!) where I expected it to change.

--- e

[baf]

It seems like it must be a bug in the output library for quad type

integer,parameter :: qp=selected_real_kind(20)
real::r
real(qp) :: q
q=1
r=q
print *,r,q
print '(f4.2)',r,q

end

gives output

1.00000000 0.00000000000000000000000000000000000
1.00
0.00

using

Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=c:/program
files/gfortran/bin/../libexec/gcc/i586-pc-mingw32/4.7.0/lto-wrapper.exe
Target: i586-pc-mingw32
Configured with: ../gcc-trunk/configure --prefix=/mingw
--enable-languages=c,fortran --with-gmp=/home/brad/gfortran/dependencies
--disable-werror --enable-threads --disable-nls --build=i586-pc-mingw32
--enable-libgomp --enable-shared --disable-win32-registry --with-dwarf2
--disable-sjlj-exceptions --enable-lto
Thread model: win32
gcc version 4.7.0 20111011 (experimental) [trunk revision 179806] (GCC)

[FX]

> It's still unclear where exactly it fails and why it is (seemingly) a
> regression. Since it fails on both MinGW(32) and MinGW64 rules out
> certain kind of bugs.

It fails also with current trunk on a cross-compiler to mingw32 running
on Mac OS 10.7 under Wine. So, it's a pretty persistent bug.

--
FX

[FX]

> It fails also with current trunk on a cross-compiler to mingw32 running
> on Mac OS 10.7 under Wine. So, it's a pretty persistent bug.

I filed it on the GCC bugzilla at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51007

It's not Fortran-specific, but a bug in the quadmath library of GCC.

--
FX

[FX]

> Is this bug specific to gcc 4.7 on Win32?

Yes, it was. A fix was found, and the next version of the binaries should
be okay.

--
FX

[e p chandler]

"FX" <cou...@alussinan.org> wrote in message
news:j98jmn$jn6$1...@dont-email.me...

-- Thanks for your hard work as described on gcc bugzilla.