diff mbox

RFC patch: Add libquadmath - and use it in gfortran (round THREE)

Message ID 4CD9DA70.5040602@net-b.de
State New
Headers show

Commit Message

Tobias Burnus Nov. 9, 2010, 11:34 p.m. UTC 
Tobias Burnus wrote:
> this patch is an updated version of the one posted at 
> http://gcc.gnu.org/ml/gcc-patches/2010-11/msg00790.html
>
> As libquadmath remained unchanged, I did not include the 180K file but 
> I just refer to 
> http://gcc.gnu.org/ml/gcc-patches/2010-11/msg00790/libquadmath.tar.bz2

The other patches can be found at 
http://gcc.gnu.org/ml/fortran/2010-11/msg00173.html

> TODO: Fix using gfortran in libgomp. Currently, no .mod files are 
> generated. It works if one manually runs "make omp_lib.mod" but it 
> won't happen automatically.

The solution it trivial - even though it took me quite some time to find 
out. Please apply the following patch after the other ones.

 From my side, everything should work now. Though, I have not yet 
bootstrapped and regtested (check-gfortran + libgomp check).

Remains to do:
- Get report from other platforms whether it works
- Find out why for Angelo on Cygwin there is no quadmath .DLL and no 
functions from libgfortran/transfer128.c
- Fix review comments (hint!)




Tobias

Comments

Jack Howarth Nov. 10, 2010, 1:23 a.m. UTC | #1 
On Wed, Nov 10, 2010 at 12:34:08AM +0100, Tobias Burnus wrote:
> Tobias Burnus wrote:
>> this patch is an updated version of the one posted at  
>> http://gcc.gnu.org/ml/gcc-patches/2010-11/msg00790.html
>>
>> As libquadmath remained unchanged, I did not include the 180K file but  
>> I just refer to  
>> http://gcc.gnu.org/ml/gcc-patches/2010-11/msg00790/libquadmath.tar.bz2
>
> The other patches can be found at  
> http://gcc.gnu.org/ml/fortran/2010-11/msg00173.html
>
>> TODO: Fix using gfortran in libgomp. Currently, no .mod files are  
>> generated. It works if one manually runs "make omp_lib.mod" but it  
>> won't happen automatically.
>
> The solution it trivial - even though it took me quite some time to find  
> out. Please apply the following patch after the other ones.
>
> From my side, everything should work now. Though, I have not yet  
> bootstrapped and regtested (check-gfortran + libgomp check).
>
> Remains to do:
> - Get report from other platforms whether it works
> - Find out why for Angelo on Cygwin there is no quadmath .DLL and no  
> functions from libgfortran/transfer128.c
> - Fix review comments (hint!)
>
>
> diff --git a/libgomp/configure.ac b/libgomp/configure.ac
> index 85945c7..45723a5 100644
> --- a/libgomp/configure.ac
> +++ b/libgomp/configure.ac
> @@ -140,6 +140,10 @@ AC_SUBST(enable_static)
>
>  AM_MAINTAINER_MODE
>
> +# Create a spec file, so that compile/link tests don't fail
> +test -f libgfortran.spec || touch libgfortran.spec
> +FCFLAGS="$FCFLAGS -L."
> +
>  # We need gfortran to compile parts of the library
>  # We can't use AC_PROG_FC because it expects a fully working gfortran.
>  #AC_PROG_FC(gfortran)
>
> diff --git a/libgomp/configure b/libgomp/configure
> index 9dd8323..423690f 100755
> --- a/libgomp/configure
> +++ b/libgomp/configure
> @@ -11459,6 +11459,10 @@ fi
>
>
>
> +# Create a spec file, so that compile/link tests don't fail
> +test -f libgfortran.spec || touch libgfortran.spec
> +FCFLAGS="$FCFLAGS -L."
> +
>  # We need gfortran to compile parts of the library
>  # We can't use AC_PROG_FC because it expects a fully working gfortran.
>  #AC_PROG_FC(gfortran)
>
>
> Tobias

Tobias,
   These patches aren't working properly on x86_64-apple-darwin10. The resulting
transfer128.o contains no symbols according to nm and the test_qp.f90 testcase
fails to compile with...

gfortran test_qp.f90
Undefined symbols:
  "__gfortran_transfer_real128_write", referenced from:
      _MAIN__ in ccUAfKvc.o
      _MAIN__ in ccUAfKvc.o
      _MAIN__ in ccUAfKvc.o
      _MAIN__ in ccUAfKvc.o
      _MAIN__ in ccUAfKvc.o
      _MAIN__ in ccUAfKvc.o
      _MAIN__ in ccUAfKvc.o
      _MAIN__ in ccUAfKvc.o
ld: symbol(s) not found
collect2: ld returned 1 exit status

I believe the problem is that the current patches are no longer including
kinds-override.h in mk-kinds-h.sh as was the case in the previous patches.

# After this, we include a header that can override some of the 
# autodetected settings.
echo '#include "kinds-override.h"'

       Jack
Tobias Burnus Nov. 10, 2010, 7:32 a.m. UTC | #2 
Attached a new version of the patch.

Changes compared to http://gcc.gnu.org/ml/gcc-patches/2010-11/msg00932.html
- Fixed libgomp's configure{,.ac}  (cf. last email)
- Included (again!) missing kinds-override.h

The libquadmath itself is in: 
http://gcc.gnu.org/ml/gcc-patches/2010-11/msg00790/libquadmath.tar.bz2

The patch was bootstrapped and libgomp-regtested on x86-64-linux and is 
currently check-gfortran regtesting.

TODO:
- Ensure that on Cygwin a .DLL is build - allegedly that's still not the 
case.


Jack Howarth wrote:
> These patches aren't working properly on x86_64-apple-darwin10. The 
> resulting transfer128.o contains no symbols according to nm and the 
> test_qp.f90 testcase fails to compile with...
>    "__gfortran_transfer_real128_write", referenced from:
> I believe the problem is that the current patches are no longer including
> kinds-override.h in mk-kinds-h.sh as was the case in the previous patches.

That sounds very reasonable - and indeed I had forgotten to add that 
file to the patch for the non-generated files; there are simply too many 
files :-(

Thanks for spotting this!


Jerry DeLisle wrote:
> I did see that there are some mixups in declarations in transfer.c. I 
> tried fixing those and no luck,  Things like:
>
> transfer_real128_write vs transfer_real_write128, the former I believe 
> is correct.

I tried to find *write128 - but I could not. Neither in my local tree 
nor in the patch.

> libtool: install: warning: relinking `libgfortran.la'
> ldconfig: /home/jerry/gcc/usr/lib/../lib/libstdc++.so.6.0.15-gdb.py is 
> not an ELF file - it has the wrong magic bytes at the start.

I think that's kind of OK. That file is a helper file for GDB which 
offers some macros. As it is written in Python, it cannot be relinked.

Tobias
Jack Howarth Nov. 10, 2010, 1:22 p.m. UTC | #3 
On Wed, Nov 10, 2010 at 08:32:40AM +0100, Tobias Burnus wrote:
> Attached a new version of the patch.
>
> Changes compared to http://gcc.gnu.org/ml/gcc-patches/2010-11/msg00932.html
> - Fixed libgomp's configure{,.ac}  (cf. last email)
> - Included (again!) missing kinds-override.h
>
> The libquadmath itself is in:  
> http://gcc.gnu.org/ml/gcc-patches/2010-11/msg00790/libquadmath.tar.bz2
>
> The patch was bootstrapped and libgomp-regtested on x86-64-linux and is  
> currently check-gfortran regtesting.
>
> TODO:
> - Ensure that on Cygwin a .DLL is build - allegedly that's still not the  
> case.
>
>
> Jack Howarth wrote:
>> These patches aren't working properly on x86_64-apple-darwin10. The  
>> resulting transfer128.o contains no symbols according to nm and the  
>> test_qp.f90 testcase fails to compile with...
>>    "__gfortran_transfer_real128_write", referenced from:
>> I believe the problem is that the current patches are no longer including
>> kinds-override.h in mk-kinds-h.sh as was the case in the previous patches.
>
> That sounds very reasonable - and indeed I had forgotten to add that  
> file to the patch for the non-generated files; there are simply too many  
> files :-(
>
> Thanks for spotting this!
>
>
> Jerry DeLisle wrote:
>> I did see that there are some mixups in declarations in transfer.c. I  
>> tried fixing those and no luck,  Things like:
>>
>> transfer_real128_write vs transfer_real_write128, the former I believe  
>> is correct.
>
> I tried to find *write128 - but I could not. Neither in my local tree  
> nor in the patch.

Tobias,
   Are you testing the resulting gfortran compiler from these patches against
the simple testcase...

program test_qp
  implicit none
  integer, parameter :: QP = 16
  real(QP), parameter :: Z1 = 1,HALF_PI = asin(Z1),PI = HALF_PI+HALF_PI
  real(QP) :: x = 0.124_QP
  print *, x
  print *, PI
  print *, 16*atan(0.2_QP)-4*atan(Z1/239)
  print *, sin(PI)
  print *, cos(HALF_PI)
  print *, asinh(PI)
  print *, erfc(Z1)
  print *, epsilon(x)
  print *, precision(x)
  print *, digits(x)
end program test_qp

before posting?
            Jack
>
>> libtool: install: warning: relinking `libgfortran.la'
>> ldconfig: /home/jerry/gcc/usr/lib/../lib/libstdc++.so.6.0.15-gdb.py is  
>> not an ELF file - it has the wrong magic bytes at the start.
>
> I think that's kind of OK. That file is a helper file for GDB which  
> offers some macros. As it is written in Python, it cannot be relinked.
>
> Tobias
Tobias Burnus Nov. 10, 2010, 2:19 p.m. UTC | #4 
On 11/10/2010 02:22 PM, Jack Howarth wrote:
> Tobias,
>     Are you testing the resulting gfortran compiler from these patches against
> the simple testcase...
>
> program test_qp
>    implicit none
>    integer, parameter :: QP = 16
>    real(QP), parameter :: Z1 = 1,HALF_PI = asin(Z1),PI = HALF_PI+HALF_PI
>    real(QP) :: x = 0.124_QP
>    print *, x
>    print *, PI
>    print *, 16*atan(0.2_QP)-4*atan(Z1/239)
>    print *, sin(PI)
>    print *, cos(HALF_PI)
>    print *, asinh(PI)
>    print *, erfc(Z1)
>    print *, epsilon(x)
>    print *, precision(x)
>    print *, digits(x)
> end program test_qp

Kind of. I test against my tree. I do not re-test the posted patches, 
which means that I might miss files. I try very hard not to do so, but 
it might happen. I probably should apply the patches to a clean tree and 
bootstrap - but that costs me at least two three due to my slow 
computer. Your test case looks like:

$ gfortran hgjff.f90
$ ./a.out
   0.12399999999999999999999999999999999
    3.1415926535897932384626433832795028
    3.1415926535897932384626433832795032
   8.67181013012378102479704402604335225E-0035
   4.33590506506189051239852201302167613E-0035
    1.8622957433108482198883613251826206
   0.15729920705028513065877936491739074
   1.92592994438723585305597794258492732E-0034
           33
          113

I assume you get the same as you do not post an error message ;-)

Tobias
Jack Howarth Nov. 10, 2010, 4:54 p.m. UTC | #5 
On Wed, Nov 10, 2010 at 03:19:25PM +0100, Tobias Burnus wrote:
> On 11/10/2010 02:22 PM, Jack Howarth wrote:
>> Tobias,
>>     Are you testing the resulting gfortran compiler from these patches against
>> the simple testcase...
>>
>> program test_qp
>>    implicit none
>>    integer, parameter :: QP = 16
>>    real(QP), parameter :: Z1 = 1,HALF_PI = asin(Z1),PI = HALF_PI+HALF_PI
>>    real(QP) :: x = 0.124_QP
>>    print *, x
>>    print *, PI
>>    print *, 16*atan(0.2_QP)-4*atan(Z1/239)
>>    print *, sin(PI)
>>    print *, cos(HALF_PI)
>>    print *, asinh(PI)
>>    print *, erfc(Z1)
>>    print *, epsilon(x)
>>    print *, precision(x)
>>    print *, digits(x)
>> end program test_qp
>
> Kind of. I test against my tree. I do not re-test the posted patches,  
> which means that I might miss files. I try very hard not to do so, but  
> it might happen. I probably should apply the patches to a clean tree and  
> bootstrap - but that costs me at least two three due to my slow  
> computer. Your test case looks like:
>
> $ gfortran hgjff.f90
> $ ./a.out
>   0.12399999999999999999999999999999999
>    3.1415926535897932384626433832795028
>    3.1415926535897932384626433832795032
>   8.67181013012378102479704402604335225E-0035
>   4.33590506506189051239852201302167613E-0035
>    1.8622957433108482198883613251826206
>   0.15729920705028513065877936491739074
>   1.92592994438723585305597794258492732E-0034
>           33
>          113
>
> I assume you get the same as you do not post an error message ;-)

Tobias,
   I downloaded the two patches again and restarted from a fresh tree. Now
the problem seems to have disappeared and the test_qp.f90 testcase can
find all of the required symbols in libgfortran. Also I can now compile
with...

gfortran -static-libgfortran test_qp.f90

on x86_64-apple-darwin10 with libgfortran.a being properly linked in.
              Jack
ps Do you plan to implement -static-libquad as a gfortran option so
that the user can execute...

gfortran -static-libgfortran -static-libquad test_qp.f90

as well?

>
> Tobias
diff mbox

Patch

diff --git a/libgomp/configure.ac b/libgomp/configure.ac
index 85945c7..45723a5 100644
--- a/libgomp/configure.ac
+++ b/libgomp/configure.ac
@@ -140,6 +140,10 @@  AC_SUBST(enable_static)

  AM_MAINTAINER_MODE

+# Create a spec file, so that compile/link tests don't fail
+test -f libgfortran.spec || touch libgfortran.spec
+FCFLAGS="$FCFLAGS -L."
+
  # We need gfortran to compile parts of the library
  # We can't use AC_PROG_FC because it expects a fully working gfortran.
  #AC_PROG_FC(gfortran)

diff --git a/libgomp/configure b/libgomp/configure
index 9dd8323..423690f 100755
--- a/libgomp/configure
+++ b/libgomp/configure
@@ -11459,6 +11459,10 @@  fi



+# Create a spec file, so that compile/link tests don't fail
+test -f libgfortran.spec || touch libgfortran.spec
+FCFLAGS="$FCFLAGS -L."
+
  # We need gfortran to compile parts of the library
  # We can't use AC_PROG_FC because it expects a fully working gfortran.
  #AC_PROG_FC(gfortran)