Bug 98201 - CSQRT function gives bad resuts at runtime
Summary: CSQRT function gives bad resuts at runtime
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 9.2.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-12-08 14:44 UTC by Dave
Modified: 2021-03-28 13:16 UTC (History)
2 users (show)

See Also:
Host:
Target: mingw
Build:
Known to work:
Known to fail:
Last reconfirmed: 2020-12-08 00:00:00

Attachments
cmdout.txt (5.70 KB, text/plain)
2020-12-09 13:24 UTC, dpozar 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Dave 2020-12-08 14:44:08 UTC 
I am running mingw gfortran 9.2.0 on Windows 7, and have a problem with results from the CSQRT function during runtime. Sample code below, with results. Starting with a complex argument having increasingly large real part, and a relatively small imaginary part, csqrt initially gives a correct result (as tested by squaring the result from CSQRT). But the second row shows some significant error, and later rows show 'Infinity' for the imaginary part. (using sq = z**.5 gives correct results)


F95 CODE;

! test CSQRT
    complex z, sq
    write(6,*) "         Argument                SquareRoot               SR squared"
    do n=1,9
        z=-10.**n+(0.,.1)
        sq=csqrt(z)
        write(*,1) z, sq, sq*sq
    end do
1   format(3("(",e10.4,2x,e10.4,")",3x))
pause

RESULTS:
          Argument                  SquareRoot               SR squared
(-.1000E+02  0.1000E+00)   (0.1581E-01  0.3163E+01)   (-.1001E+02  0.1000E+00)
(-.1000E+03  0.1000E+00)   (0.5167E-02  0.9676E+01)   (-.9362E+02  0.1000E+00)
(-.1000E+04  0.1000E+00)   (0.0000E+00    Infinity)   ( -Infinity         NaN)
(-.1000E+05  0.1000E+00)   (0.0000E+00    Infinity)   ( -Infinity         NaN)
(-.1000E+06  0.1000E+00)   (0.0000E+00    Infinity)   ( -Infinity         NaN)
(-.1000E+07  0.1000E+00)   (0.0000E+00    Infinity)   ( -Infinity         NaN)
(-.1000E+08  0.1000E+00)   (0.0000E+00    Infinity)   ( -Infinity         NaN)
(-.1000E+09  0.1000E+00)   (0.0000E+00    Infinity)   ( -Infinity         NaN)
(-.1000E+10  0.1000E+00)   (0.0000E+00    Infinity)   ( -Infinity         NaN)
PAUSE
Comment 1 Thomas Koenig 2020-12-08 15:34:11 UTC 
Here is a slight extension of your program, which also
checks the compile-time simplification. Can you tell me
what it does?

program main
  implicit none
  integer :: i,n
  complex z, sq
  complex, parameter, dimension(9) :: zp = [(-10.**i+(0.,1.),i=1,9)]
  complex, parameter, dimension(9) :: sqp = sqrt(zp)
  write (*,*) "Runtime"
  write (*,*) "         Argument                SquareRoot               SR squared"
  do n=1,9
     z=-10.**n+(0.,.1)
     sq=csqrt(z)
     write(*,1) z, sq, sq*sq
  end do
  write (*,*) "Compile-time"
  do n=1,9
    write (*,1) zp(n), sqp(n), sqp(n)**2
  end do
1 format(3("(",e10.4,2x,e10.4,")",3x))
end

On my Linux box, it prints

 Runtime
          Argument                SquareRoot               SR squared
(-.1000E+02  0.1000E+00)   (0.1581E-01  0.3162E+01)   (-.1000E+02  0.1000E+00)
(-.1000E+03  0.1000E+00)   (0.5000E-02  0.1000E+02)   (-.1000E+03  0.1000E+00)
(-.1000E+04  0.1000E+00)   (0.1581E-02  0.3162E+02)   (-.1000E+04  0.1000E+00)
(-.1000E+05  0.1000E+00)   (0.5000E-03  0.1000E+03)   (-.1000E+05  0.1000E+00)
(-.1000E+06  0.1000E+00)   (0.1581E-03  0.3162E+03)   (-.1000E+06  0.1000E+00)
(-.1000E+07  0.1000E+00)   (0.5000E-04  0.1000E+04)   (-.1000E+07  0.1000E+00)
(-.1000E+08  0.1000E+00)   (0.1581E-04  0.3162E+04)   (-.1000E+08  0.1000E+00)
(-.1000E+09  0.1000E+00)   (0.5000E-05  0.1000E+05)   (-.1000E+09  0.1000E+00)
(-.1000E+10  0.1000E+00)   (0.1581E-05  0.3162E+05)   (-.1000E+10  0.1000E+00)
 Compile-time
(-.1000E+02  0.1000E+01)   (0.1579E+00  0.3166E+01)   (-.1000E+02  0.1000E+01)
(-.1000E+03  0.1000E+01)   (0.5000E-01  0.1000E+02)   (-.1000E+03  0.1000E+01)
(-.1000E+04  0.1000E+01)   (0.1581E-01  0.3162E+02)   (-.1000E+04  0.1000E+01)
(-.1000E+05  0.1000E+01)   (0.5000E-02  0.1000E+03)   (-.1000E+05  0.1000E+01)
(-.1000E+06  0.1000E+01)   (0.1581E-02  0.3162E+03)   (-.1000E+06  0.1000E+01)
(-.1000E+07  0.1000E+01)   (0.5000E-03  0.1000E+04)   (-.1000E+07  0.1000E+01)
(-.1000E+08  0.1000E+01)   (0.1581E-03  0.3162E+04)   (-.1000E+08  0.1000E+01)
(-.1000E+09  0.1000E+01)   (0.5000E-04  0.1000E+05)   (-.1000E+09  0.1000E+01)
(-.1000E+10  0.1000E+01)   (0.1581E-04  0.3162E+05)   (-.1000E+10  0.1000E+01)

so there is a slight difference in one value, but nothing as
completely wrong as what you show.

What is the output of that program on your system?

And what is the output of "gfortran -v" ?
Comment 2 Dominique d'Humieres 2020-12-08 15:35:31 UTC 
WORKSFORME on Darwin.
Comment 3 dpozar 2020-12-08 15:47:14 UTC 
Thomas,

compile time works fine; runtime not so good.
dave

Output below:
 Runtime
          Argument                         SquareRoot                              SR squared
(-.1000E+02  0.1000E+00)   (0.1581E-01  0.3163E+01)   (-.1001E+02  0.1000E+00)
(-.1000E+03  0.1000E+00)   (0.5167E-02  0.9676E+01)   (-.9362E+02  0.1000E+00)
(-.1000E+04  0.1000E+00)   (0.0000E+00    Infinity)   ( -Infinity         NaN)
(-.1000E+05  0.1000E+00)   (0.0000E+00    Infinity)   ( -Infinity         NaN)
(-.1000E+06  0.1000E+00)   (0.0000E+00    Infinity)   ( -Infinity         NaN)
(-.1000E+07  0.1000E+00)   (0.0000E+00    Infinity)   ( -Infinity         NaN)
(-.1000E+08  0.1000E+00)   (0.0000E+00    Infinity)   ( -Infinity         NaN)
(-.1000E+09  0.1000E+00)   (0.0000E+00    Infinity)   ( -Infinity         NaN)
(-.1000E+10  0.1000E+00)   (0.0000E+00    Infinity)   ( -Infinity         NaN)
 Compile-time
(-.1000E+02  0.1000E+01)   (0.1579E+00  0.3166E+01)   (-.1000E+02  0.1000E+01)
(-.1000E+03  0.1000E+01)   (0.5000E-01  0.1000E+02)   (-.1000E+03  0.1000E+01)
(-.1000E+04  0.1000E+01)   (0.1581E-01  0.3162E+02)   (-.1000E+04  0.1000E+01)
(-.1000E+05  0.1000E+01)   (0.5000E-02  0.1000E+03)   (-.1000E+05  0.1000E+01)
(-.1000E+06  0.1000E+01)   (0.1581E-02  0.3162E+03)   (-.1000E+06  0.1000E+01)
(-.1000E+07  0.1000E+01)   (0.5000E-03  0.1000E+04)   (-.1000E+07  0.1000E+01)
(-.1000E+08  0.1000E+01)   (0.1581E-03  0.3162E+04)   (-.1000E+08  0.1000E+01)
(-.1000E+09  0.1000E+01)   (0.5000E-04  0.1000E+05)   (-.1000E+09  0.1000E+01)
(-.1000E+10  0.1000E+01)   (0.1581E-04  0.3162E+05)   (-.1000E+10  0.1000E+01)

Process returned 0 (0x0)   execution time : 0.060 s
Press any key to continue.


________________________________
From: tkoenig at gcc dot gnu.org <gcc-bugzilla@gcc.gnu.org>
Sent: Tuesday, December 8, 2020 10:34 AM
To: David Pozar <dpozar@ecs.umass.edu>
Subject: [Bug fortran/98201] CSQRT function gives bad resuts at runtime

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

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |mingw
                 CC|                            |tkoenig at gcc dot gnu.org

--- Comment #1 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
Here is a slight extension of your program, which also
checks the compile-time simplification. Can you tell me
what it does?

program main
  implicit none
  integer :: i,n
  complex z, sq
  complex, parameter, dimension(9) :: zp = [(-10.**i+(0.,1.),i=1,9)]
  complex, parameter, dimension(9) :: sqp = sqrt(zp)
  write (*,*) "Runtime"
  write (*,*) "         Argument                SquareRoot               SR
squared"
  do n=1,9
     z=-10.**n+(0.,.1)
     sq=csqrt(z)
     write(*,1) z, sq, sq*sq
  end do
  write (*,*) "Compile-time"
  do n=1,9
    write (*,1) zp(n), sqp(n), sqp(n)**2
  end do
1 format(3("(",e10.4,2x,e10.4,")",3x))
end

On my Linux box, it prints

 Runtime
          Argument                SquareRoot               SR squared
(-.1000E+02  0.1000E+00)   (0.1581E-01  0.3162E+01)   (-.1000E+02  0.1000E+00)
(-.1000E+03  0.1000E+00)   (0.5000E-02  0.1000E+02)   (-.1000E+03  0.1000E+00)
(-.1000E+04  0.1000E+00)   (0.1581E-02  0.3162E+02)   (-.1000E+04  0.1000E+00)
(-.1000E+05  0.1000E+00)   (0.5000E-03  0.1000E+03)   (-.1000E+05  0.1000E+00)
(-.1000E+06  0.1000E+00)   (0.1581E-03  0.3162E+03)   (-.1000E+06  0.1000E+00)
(-.1000E+07  0.1000E+00)   (0.5000E-04  0.1000E+04)   (-.1000E+07  0.1000E+00)
(-.1000E+08  0.1000E+00)   (0.1581E-04  0.3162E+04)   (-.1000E+08  0.1000E+00)
(-.1000E+09  0.1000E+00)   (0.5000E-05  0.1000E+05)   (-.1000E+09  0.1000E+00)
(-.1000E+10  0.1000E+00)   (0.1581E-05  0.3162E+05)   (-.1000E+10  0.1000E+00)
 Compile-time
(-.1000E+02  0.1000E+01)   (0.1579E+00  0.3166E+01)   (-.1000E+02  0.1000E+01)
(-.1000E+03  0.1000E+01)   (0.5000E-01  0.1000E+02)   (-.1000E+03  0.1000E+01)
(-.1000E+04  0.1000E+01)   (0.1581E-01  0.3162E+02)   (-.1000E+04  0.1000E+01)
(-.1000E+05  0.1000E+01)   (0.5000E-02  0.1000E+03)   (-.1000E+05  0.1000E+01)
(-.1000E+06  0.1000E+01)   (0.1581E-02  0.3162E+03)   (-.1000E+06  0.1000E+01)
(-.1000E+07  0.1000E+01)   (0.5000E-03  0.1000E+04)   (-.1000E+07  0.1000E+01)
(-.1000E+08  0.1000E+01)   (0.1581E-03  0.3162E+04)   (-.1000E+08  0.1000E+01)
(-.1000E+09  0.1000E+01)   (0.5000E-04  0.1000E+05)   (-.1000E+09  0.1000E+01)
(-.1000E+10  0.1000E+01)   (0.1581E-04  0.3162E+05)   (-.1000E+10  0.1000E+01)

so there is a slight difference in one value, but nothing as
completely wrong as what you show.

What is the output of that program on your system?

And what is the output of "gfortran -v" ?

--
You are receiving this mail because:
You reported the bug.
Comment 4 dpozar 2020-12-08 15:54:29 UTC 
Thomas,

the output for gfortran -v is:

c:\MinGW>gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/9.2.0/lto-wrapper.exe
Target: mingw32
Configured with: ../src/gcc-9.2.0/configure --build=x86_64-pc-linux-gnu --host=m
ingw32 --target=mingw32 --disable-win32-registry --with-arch=i586 --with-tune=ge
neric --enable-static --enable-shared --enable-threads --enable-languages=c,c++,
objc,obj-c++,fortran,ada --with-dwarf2 --disable-sjlj-exceptions --enable-versio
n-specific-runtime-libs --enable-libgomp --disable-libvtv --with-libiconv-prefix
=/mingw --with-libintl-prefix=/mingw --enable-libstdcxx-debug --disable-build-fo
rmat-warnings --prefix=/mingw --with-gmp=/mingw --with-mpfr=/mingw --with-mpc=/m
ingw --with-isl=/mingw --enable-nls --with-pkgversion='MinGW.org GCC Build-2'
Thread model: win32
gcc version 9.2.0 (MinGW.org GCC Build-2)

c:\MinGW>
________________________________
From: tkoenig at gcc dot gnu.org <gcc-bugzilla@gcc.gnu.org>
Sent: Tuesday, December 8, 2020 10:34 AM
To: David Pozar <dpozar@ecs.umass.edu>
Subject: [Bug fortran/98201] CSQRT function gives bad resuts at runtime

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

Thomas Koenig <tkoenig at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |mingw
                 CC|                            |tkoenig at gcc dot gnu.org

--- Comment #1 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
Here is a slight extension of your program, which also
checks the compile-time simplification. Can you tell me
what it does?

program main
  implicit none
  integer :: i,n
  complex z, sq
  complex, parameter, dimension(9) :: zp = [(-10.**i+(0.,1.),i=1,9)]
  complex, parameter, dimension(9) :: sqp = sqrt(zp)
  write (*,*) "Runtime"
  write (*,*) "         Argument                SquareRoot               SR
squared"
  do n=1,9
     z=-10.**n+(0.,.1)
     sq=csqrt(z)
     write(*,1) z, sq, sq*sq
  end do
  write (*,*) "Compile-time"
  do n=1,9
    write (*,1) zp(n), sqp(n), sqp(n)**2
  end do
1 format(3("(",e10.4,2x,e10.4,")",3x))
end

On my Linux box, it prints

 Runtime
          Argument                SquareRoot               SR squared
(-.1000E+02  0.1000E+00)   (0.1581E-01  0.3162E+01)   (-.1000E+02  0.1000E+00)
(-.1000E+03  0.1000E+00)   (0.5000E-02  0.1000E+02)   (-.1000E+03  0.1000E+00)
(-.1000E+04  0.1000E+00)   (0.1581E-02  0.3162E+02)   (-.1000E+04  0.1000E+00)
(-.1000E+05  0.1000E+00)   (0.5000E-03  0.1000E+03)   (-.1000E+05  0.1000E+00)
(-.1000E+06  0.1000E+00)   (0.1581E-03  0.3162E+03)   (-.1000E+06  0.1000E+00)
(-.1000E+07  0.1000E+00)   (0.5000E-04  0.1000E+04)   (-.1000E+07  0.1000E+00)
(-.1000E+08  0.1000E+00)   (0.1581E-04  0.3162E+04)   (-.1000E+08  0.1000E+00)
(-.1000E+09  0.1000E+00)   (0.5000E-05  0.1000E+05)   (-.1000E+09  0.1000E+00)
(-.1000E+10  0.1000E+00)   (0.1581E-05  0.3162E+05)   (-.1000E+10  0.1000E+00)
 Compile-time
(-.1000E+02  0.1000E+01)   (0.1579E+00  0.3166E+01)   (-.1000E+02  0.1000E+01)
(-.1000E+03  0.1000E+01)   (0.5000E-01  0.1000E+02)   (-.1000E+03  0.1000E+01)
(-.1000E+04  0.1000E+01)   (0.1581E-01  0.3162E+02)   (-.1000E+04  0.1000E+01)
(-.1000E+05  0.1000E+01)   (0.5000E-02  0.1000E+03)   (-.1000E+05  0.1000E+01)
(-.1000E+06  0.1000E+01)   (0.1581E-02  0.3162E+03)   (-.1000E+06  0.1000E+01)
(-.1000E+07  0.1000E+01)   (0.5000E-03  0.1000E+04)   (-.1000E+07  0.1000E+01)
(-.1000E+08  0.1000E+01)   (0.1581E-03  0.3162E+04)   (-.1000E+08  0.1000E+01)
(-.1000E+09  0.1000E+01)   (0.5000E-04  0.1000E+05)   (-.1000E+09  0.1000E+01)
(-.1000E+10  0.1000E+01)   (0.1581E-04  0.3162E+05)   (-.1000E+10  0.1000E+01)

so there is a slight difference in one value, but nothing as
completely wrong as what you show.

What is the output of that program on your system?

And what is the output of "gfortran -v" ?

--
You are receiving this mail because:
You reported the bug.
Comment 5 Thomas Koenig 2020-12-08 15:55:59 UTC 
What is the output of

#include <complex.h>
#include <stdio.h>

int main()
{
  _Complex float z, sq, sq2;
  int n;
  float a;
  a = -1.;
  for (n = 1; n < 10; n++)
    {
      a = a * 10;
      z = a + _Complex_I * 1.0;
      sq = csqrtf (z);
      sq2 = sq * sq;
      printf ("(%e,%e) (%e,%e) (%e,%e)\n", creal(z), cimag(z),
              creal(sq), cimag(sq), creal(sq2), cimag(sq2));
    }
  return 0;
}

?

On my Linux box, it is

(-1.000000e+01,1.000000e+00) (1.579171e-01,3.166218e+00) (-1.000000e+01,1.000000e+00)
(-1.000000e+02,1.000000e+00) (4.999937e-02,1.000012e+01) (-1.000000e+02,1.000000e+00)
(-1.000000e+03,1.000000e+00) (1.581139e-02,3.162278e+01) (-9.999999e+02,1.000000e+00)
(-1.000000e+04,1.000000e+00) (5.000000e-03,1.000000e+02) (-1.000000e+04,1.000000e+00)
(-1.000000e+05,1.000000e+00) (1.581139e-03,3.162278e+02) (-9.999999e+04,1.000000e+00)
(-1.000000e+06,1.000000e+00) (5.000000e-04,1.000000e+03) (-1.000000e+06,1.000000e+00)
(-1.000000e+07,1.000000e+00) (1.581139e-04,3.162278e+03) (-1.000000e+07,1.000000e+00)
(-1.000000e+08,1.000000e+00) (5.000000e-05,1.000000e+04) (-1.000000e+08,1.000000e+00)
(-1.000000e+09,1.000000e+00) (1.581139e-05,3.162278e+04) (-1.000000e+09,9.999999e-01)
Comment 6 dpozar 2020-12-08 16:27:24 UTC 
Thomas,
I am running that code in code blocks with MS visual C++ 2010, but I can't find the output - no console screen, and no output file that I can find.

dave
________________________________
From: tkoenig at gcc dot gnu.org <gcc-bugzilla@gcc.gnu.org>
Sent: Tuesday, December 8, 2020 10:55 AM
To: David Pozar <dpozar@ecs.umass.edu>
Subject: [Bug fortran/98201] CSQRT function gives bad resuts at runtime

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

--- Comment #5 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
What is the output of

#include <complex.h>
#include <stdio.h>

int main()
{
  _Complex float z, sq, sq2;
  int n;
  float a;
  a = -1.;
  for (n = 1; n < 10; n++)
    {
      a = a * 10;
      z = a + _Complex_I * 1.0;
      sq = csqrtf (z);
      sq2 = sq * sq;
      printf ("(%e,%e) (%e,%e) (%e,%e)\n", creal(z), cimag(z),
              creal(sq), cimag(sq), creal(sq2), cimag(sq2));
    }
  return 0;
}

?

On my Linux box, it is

(-1.000000e+01,1.000000e+00) (1.579171e-01,3.166218e+00)
(-1.000000e+01,1.000000e+00)
(-1.000000e+02,1.000000e+00) (4.999937e-02,1.000012e+01)
(-1.000000e+02,1.000000e+00)
(-1.000000e+03,1.000000e+00) (1.581139e-02,3.162278e+01)
(-9.999999e+02,1.000000e+00)
(-1.000000e+04,1.000000e+00) (5.000000e-03,1.000000e+02)
(-1.000000e+04,1.000000e+00)
(-1.000000e+05,1.000000e+00) (1.581139e-03,3.162278e+02)
(-9.999999e+04,1.000000e+00)
(-1.000000e+06,1.000000e+00) (5.000000e-04,1.000000e+03)
(-1.000000e+06,1.000000e+00)
(-1.000000e+07,1.000000e+00) (1.581139e-04,3.162278e+03)
(-1.000000e+07,1.000000e+00)
(-1.000000e+08,1.000000e+00) (5.000000e-05,1.000000e+04)
(-1.000000e+08,1.000000e+00)
(-1.000000e+09,1.000000e+00) (1.581139e-05,3.162278e+04)
(-1.000000e+09,9.999999e-01)

--
You are receiving this mail because:
You reported the bug.
Comment 7 kargls 2020-12-08 17:36:39 UTC 
(In reply to dpozar from comment #3)
> Thomas,
> 
> compile time works fine; runtime not so good.
> dave
> 

So, maybe not a gfortran problem.

% gfcx -o z -fdump-tree-original a.f90
% grep csqrt a.f90.004t.original 
        sq = __builtin_csqrtf (z);
% nm z | grep sqrt
         U csqrtf@@FBSD_1.1

'sq = csqrt(z)' is compiled to 'sq = __builtin_csqrtf (z);' and __builtin_csqrtf() is mapped to your math library's csqrtf()
function.  If your math library does not have csqrtf(), then 
there is a fall back function in libgfortran.  Looking at the
fallback function shows a design flaw.  Don't know if that you're
problem.
Comment 8 Thomas Koenig 2020-12-08 18:19:25 UTC 
(In reply to dpozar from comment #6)
> Thomas,
> I am running that code in code blocks with MS visual C++ 2010, but I can't
> find the output - no console screen, and no output file that I can find.

What if you use gcc to compile this code, same as with gfortran?

And am I right in assuming (from the output of gfortran -v) that
you are using 32-bit gfortran?  (And why?)
Comment 9 dpozar 2020-12-08 19:13:06 UTC 
Thomas,

when I run your code with gcc from command line, I still do not see any output (no errors, but no output). Tried with both c and c++. I am not an expert at C, and actually I don't think I have used MinGW with C before.

as far as Mingw32 - that was the only option I saw at sourceforge when I downloaded it. But I would think that either version should work.

thanks,
dave
________________________________
From: tkoenig at gcc dot gnu.org <gcc-bugzilla@gcc.gnu.org>
Sent: Tuesday, December 8, 2020 1:19 PM
To: David Pozar <dpozar@ecs.umass.edu>
Subject: [Bug fortran/98201] CSQRT function gives bad resuts at runtime

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

--- Comment #8 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
(In reply to dpozar from comment #6)
> Thomas,
> I am running that code in code blocks with MS visual C++ 2010, but I can't
> find the output - no console screen, and no output file that I can find.

What if you use gcc to compile this code, same as with gfortran?

And am I right in assuming (from the output of gfortran -v) that
you are using 32-bit gfortran?  (And why?)

--
You are receiving this mail because:
You reported the bug.
Comment 10 Thomas Koenig 2020-12-08 19:27:17 UTC 
I don't have a working mingw system myself, but I dusted off my cygwin
system for this, using their cross-compiler to mingw.

With

$ x86_64-w64-mingw32-gfortran.exe -static -static-libgfortran csqrt.f90

this gave

          Argument                SquareRoot               SR squared
(-.1000E+02  0.1000E+00)   (0.1581E-01  0.3162E+01)   (-.1000E+02  0.1000E+00)
(-.1000E+03  0.1000E+00)   (0.5000E-02  0.1000E+02)   (-.1000E+03  0.1000E+00)
(-.1000E+04  0.1000E+00)   (0.1581E-02  0.3162E+02)   (-.1000E+04  0.1000E+00)
(-.1000E+05  0.1000E+00)   (0.5000E-03  0.1000E+03)   (-.1000E+05  0.1000E+00)
(-.1000E+06  0.1000E+00)   (0.1581E-03  0.3162E+03)   (-.1000E+06  0.1000E+00)
(-.1000E+07  0.1000E+00)   (0.5000E-04  0.1000E+04)   (-.1000E+07  0.1000E+00)
(-.1000E+08  0.1000E+00)   (0.1581E-04  0.3162E+04)   (-.1000E+08  0.1000E+00)
(-.1000E+09  0.1000E+00)   (0.5000E-05  0.1000E+05)   (-.1000E+09  0.1000E+00)
(-.1000E+10  0.1000E+00)   (0.1581E-05  0.3162E+05)   (-.1000E+10  0.1000E+00)

which is OK (I tried the program both from the cygwin command line and
the cmd prompt).
Comment 11 dpozar 2020-12-08 20:46:56 UTC 
Thomas,

that looks good. But I am not sure how to proceed ...

dave
________________________________
From: tkoenig at gcc dot gnu.org <gcc-bugzilla@gcc.gnu.org>
Sent: Tuesday, December 8, 2020 2:27 PM
To: David Pozar <dpozar@ecs.umass.edu>
Subject: [Bug fortran/98201] CSQRT function gives bad resuts at runtime

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

--- Comment #10 from Thomas Koenig <tkoenig at gcc dot gnu.org> ---
I don't have a working mingw system myself, but I dusted off my cygwin
system for this, using their cross-compiler to mingw.

With

$ x86_64-w64-mingw32-gfortran.exe -static -static-libgfortran csqrt.f90

this gave

          Argument                SquareRoot               SR squared
(-.1000E+02  0.1000E+00)   (0.1581E-01  0.3162E+01)   (-.1000E+02  0.1000E+00)
(-.1000E+03  0.1000E+00)   (0.5000E-02  0.1000E+02)   (-.1000E+03  0.1000E+00)
(-.1000E+04  0.1000E+00)   (0.1581E-02  0.3162E+02)   (-.1000E+04  0.1000E+00)
(-.1000E+05  0.1000E+00)   (0.5000E-03  0.1000E+03)   (-.1000E+05  0.1000E+00)
(-.1000E+06  0.1000E+00)   (0.1581E-03  0.3162E+03)   (-.1000E+06  0.1000E+00)
(-.1000E+07  0.1000E+00)   (0.5000E-04  0.1000E+04)   (-.1000E+07  0.1000E+00)
(-.1000E+08  0.1000E+00)   (0.1581E-04  0.3162E+04)   (-.1000E+08  0.1000E+00)
(-.1000E+09  0.1000E+00)   (0.5000E-05  0.1000E+05)   (-.1000E+09  0.1000E+00)
(-.1000E+10  0.1000E+00)   (0.1581E-05  0.3162E+05)   (-.1000E+10  0.1000E+00)

which is OK (I tried the program both from the cygwin command line and
the cmd prompt).

--
You are receiving this mail because:
You reported the bug.
Comment 12 kargls 2020-12-08 22:06:15 UTC 
(In reply to dpozar from comment #11)
> Thomas,
> 
> that looks good. But I am not sure how to proceed ...
> 
> dave

Well, the first thing to do is to use either nm or objdump on the
executable created from the code in comment #1 to determine where
csqrtf() lives.

If csqrtf() is from a Microsoft library, then we're done here and
you need to contact Microsoft.

If csqrtf() is from MingW's libm.a (or libm.so), then we're done
here and you need to contact MingW.

If csqrtf() is from libgfortran.a (or libgfortran.so), then you'll
need to look at gcc/libgfortran/intrinsics/c99_functions.c.
Comment 13 dpozar 2020-12-09 00:28:49 UTC 
Ok, I have objdump, and the .exe file. What switch options do I need to use in objdump?

thanks
________________________________
From: kargl at gcc dot gnu.org <gcc-bugzilla@gcc.gnu.org>
Sent: Tuesday, December 8, 2020 5:06 PM
To: David Pozar <dpozar@ecs.umass.edu>
Subject: [Bug fortran/98201] CSQRT function gives bad resuts at runtime

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

--- Comment #12 from kargl at gcc dot gnu.org ---
(In reply to dpozar from comment #11)
> Thomas,
>
> that looks good. But I am not sure how to proceed ...
>
> dave

Well, the first thing to do is to use either nm or objdump on the
executable created from the code in comment #1 to determine where
csqrtf() lives.

If csqrtf() is from a Microsoft library, then we're done here and
you need to contact Microsoft.

If csqrtf() is from MingW's libm.a (or libm.so), then we're done
here and you need to contact MingW.

If csqrtf() is from libgfortran.a (or libgfortran.so), then you'll
need to look at gcc/libgfortran/intrinsics/c99_functions.c.

--
You are receiving this mail because:
You reported the bug.
Comment 14 Steve Kargl 2020-12-09 04:38:51 UTC 
On Wed, Dec 09, 2020 at 12:28:49AM +0000, dpozar at ecs dot umass.edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98201
> 
> --- Comment #13 from dpozar at ecs dot umass.edu ---
> Ok, I have objdump, and the .exe file. What switch options do I need to use in
> objdump?
> 

Don't use windows, so only guessing.

cmd> objdump -t name_of_file.exe
Comment 15 dpozar 2020-12-09 13:24:20 UTC 
Created attachment 49717 [details]
cmdout.txt

attached is the output file from

c:\MinGW>objdump -t c:\mingw\programs\testcsqrt.exe >cmdout.txt

don't see any reference to libraries, though.

thanks,
dave
________________________________
From: sgk at troutmask dot apl.washington.edu <gcc-bugzilla@gcc.gnu.org>
Sent: Tuesday, December 8, 2020 11:38 PM
To: David Pozar <dpozar@ecs.umass.edu>
Subject: [Bug fortran/98201] CSQRT function gives bad resuts at runtime

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

--- Comment #14 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Wed, Dec 09, 2020 at 12:28:49AM +0000, dpozar at ecs dot umass.edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98201
>
> --- Comment #13 from dpozar at ecs dot umass.edu ---
> Ok, I have objdump, and the .exe file. What switch options do I need to use in
> objdump?
>

Don't use windows, so only guessing.

cmd> objdump -t name_of_file.exe

--
You are receiving this mail because:
You reported the bug.
Comment 16 Steve Kargl 2020-12-09 15:37:54 UTC 
On Wed, Dec 09, 2020 at 01:24:20PM +0000, dpozar at ecs dot umass.edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98201
> 
> --- Comment #15 from dpozar at ecs dot umass.edu ---
> attached is the output file from
> 
> c:\MinGW>objdump -t c:\mingw\programs\testcsqrt.exe >cmdout.txt
> 
> don't see any reference to libraries, though.
> 

Is testcsqrt.exe compiled with the -static option?  cmdout.txt
shows

[152](sec  1)(fl 0x00)(ty  20)(scl   2) (nx 1) 0x00001210 _csqrtf
AUX tagndx 0 ttlsiz 0x0 lnnos 0 next 0

On my FreeBSD system and a static binary, I see 

% gfcx -o z -static a.f90
% objdump -t z | grep csqrt
00000000 l    df *ABS*  00000000 s_csqrtf.c
08078a90 g     F .text  0000021d csqrtf

On my FreeBSD system and a dynamic binary, I see

% gfcx -o z a.f90
% objdump -t z | grep csqrt
00000000       F *UND*  00000000              csqrtf@@FBSD_1.1

This info is sufficient to tell me that csqrtf lives in FreeBSD's libm.

objdump has several options that may help determine where
csqrtf() resides.   I don't know MingW (or windows 10) to
be of any additional help.
Comment 17 dpozar 2020-12-09 16:04:24 UTC 
No, I don't think it is compiled with static option. I am using code blocks, which does not seem to even allow a static option.
________________________________
From: sgk at troutmask dot apl.washington.edu <gcc-bugzilla@gcc.gnu.org>
Sent: Wednesday, December 9, 2020 10:37 AM
To: David Pozar <dpozar@ecs.umass.edu>
Subject: [Bug fortran/98201] CSQRT function gives bad resuts at runtime

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

--- Comment #16 from Steve Kargl <sgk at troutmask dot apl.washington.edu> ---
On Wed, Dec 09, 2020 at 01:24:20PM +0000, dpozar at ecs dot umass.edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98201
>
> --- Comment #15 from dpozar at ecs dot umass.edu ---
> attached is the output file from
>
> c:\MinGW>objdump -t c:\mingw\programs\testcsqrt.exe >cmdout.txt
>
> don't see any reference to libraries, though.
>

Is testcsqrt.exe compiled with the -static option?  cmdout.txt
shows

[152](sec  1)(fl 0x00)(ty  20)(scl   2) (nx 1) 0x00001210 _csqrtf
AUX tagndx 0 ttlsiz 0x0 lnnos 0 next 0

On my FreeBSD system and a static binary, I see

% gfcx -o z -static a.f90
% objdump -t z | grep csqrt
00000000 l    df *ABS*  00000000 s_csqrtf.c
08078a90 g     F .text  0000021d csqrtf

On my FreeBSD system and a dynamic binary, I see

% gfcx -o z a.f90
% objdump -t z | grep csqrt
00000000       F *UND*  00000000              csqrtf@@FBSD_1.1

This info is sufficient to tell me that csqrtf lives in FreeBSD's libm.

objdump has several options that may help determine where
csqrtf() resides.   I don't know MingW (or windows 10) to
be of any additional help.

--
You are receiving this mail because:
You reported the bug.
Comment 18 Dominique d'Humieres 2021-03-28 12:38:00 UTC 
Could this PR be closed or moved to target component?
Comment 19 dpozar 2021-03-28 13:05:26 UTC 
I think it can be closed. never found out why this occurred, but I reloaded gfortran from another source and it worked after that.

thanks,
dave
________________________________
From: dominiq at lps dot ens.fr <gcc-bugzilla@gcc.gnu.org>
Sent: Sunday, March 28, 2021 8:38 AM
To: David Pozar <dpozar@ecs.umass.edu>
Subject: [Bug fortran/98201] CSQRT function gives bad resuts at runtime

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

--- Comment #18 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Could this PR be closed or moved to target component?

--
You are receiving this mail because:
You reported the bug.
Comment 20 Dominique d'Humieres 2021-03-28 13:16:24 UTC 
> I think it can be closed.

Thus closing.