[Bug fortran/54463] New: -fdefault-real-8 does not promote the BLAS call when using -fexternal-blas

[Bug fortran/54463] New: -fdefault-real-8 does not promote the BLAS call when using -fexternal-blas

[dominiq at lps dot ens.fr]

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

             Bug #: 54463
           Summary: -fdefault-real-8 does not promote the BLAS call when
                    using -fexternal-blas
    Classification: Unclassified
           Product: gcc
           Version: 4.7.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: dominiq@lps.ens.fr


From http://gcc.gnu.org/ml/fortran/2012-09/msg00004.html :

> I just tried to compile the simple program

program test
implicit none
real, dimension(3,3) :: A
A = matmul(A,A)
end program test

> with
> $ gfortran-4.7 -fexternal-blas -fdefault-real-8 test.f95
> /tmp/cc3ij1CL.o: In function `MAIN__':
> test.f95:(.text+0x14e): undefined reference to `sgemm_'
> collect2: Fehler: ld gab 1 als Ende-Status zurück
>
> looks like matmul is replaced with sgemm and not with dgemm

[Bug fortran/54463] -fdefault-real-8 does not promote the BLAS call when using -fexternal-blas

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org
           Severity|normal                      |enhancement

--- Comment #1 from kargl at gcc dot gnu.org 2012-09-02 23:46:30 UTC ---
This bug report should be closed.  Combining
-fexternal-blas and -fdefault-real-8 would 
add needless complexity to the compiler.
The correct solution is to write proper Fortran
code.  To be even more specific, don't use 
-fdefault-real-8.  It was a really, really,
bad idea and was only supplied to give
backwards compatibility with g77.

[Bug fortran/54463] -fdefault-real-8 does not promote the BLAS call when using -fexternal-blas

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org
           Severity|enhancement                 |normal

--- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-09-03 06:14:22 UTC ---
The following should work. I am not too kind to have magic numbers, maybe that
part could be improved.

--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -2364,4 +2364,3 @@ gfc_conv_intrinsic_funcall (gfc_se * se, gfc_expr * expr)
          && (sym->ts.type == BT_REAL || sym->ts.type == BT_COMPLEX)
-         && (sym->ts.kind == gfc_default_real_kind
-             || sym->ts.kind == gfc_default_double_kind))
+         && (sym->ts.kind == 4 || sym->ts.kind == 8))
        {
@@ -2371,3 +2370,3 @@ gfc_conv_intrinsic_funcall (gfc_se * se, gfc_expr * expr)
            {
-             if (sym->ts.kind == gfc_default_real_kind)
+             if (sym->ts.kind == 4)
                gemm_fndecl = gfor_fndecl_sgemm;
@@ -2378,3 +2377,3 @@ gfc_conv_intrinsic_funcall (gfc_se * se, gfc_expr * expr)
            {
-             if (sym->ts.kind == gfc_default_real_kind)
+             if (sym->ts.kind == 4)
                gemm_fndecl = gfor_fndecl_cgemm;

[Bug fortran/54463] -fdefault-real-8 does not promote the BLAS call when using -fexternal-blas

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #3 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2012-09-03 13:38:36 UTC ---
On Mon, Sep 03, 2012 at 06:14:22AM +0000, burnus at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54463
> 
> Tobias Burnus <burnus at gcc dot gnu.org> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |burnus at gcc dot gnu.org
>            Severity|enhancement                 |normal
> 
> --- Comment #2 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-09-03 06:14:22 UTC ---
> The following should work. I am not too kind to have magic numbers, maybe that
> part could be improved.
> 
> --- a/gcc/fortran/trans-intrinsic.c
> +++ b/gcc/fortran/trans-intrinsic.c
> @@ -2364,4 +2364,3 @@ gfc_conv_intrinsic_funcall (gfc_se * se, gfc_expr * expr)
>           && (sym->ts.type == BT_REAL || sym->ts.type == BT_COMPLEX)
> -         && (sym->ts.kind == gfc_default_real_kind
> -             || sym->ts.kind == gfc_default_double_kind))
> +         && (sym->ts.kind == 4 || sym->ts.kind == 8))

What about -freal-4-real-10 -freal-4-real-16 -freal-4-real-8
-freal-8-real-10 -freal-8-real-16 and -freal-8-real-4?  See
my initial response.  The correct solution it write proper
Fortran.

[Bug fortran/54463] -fdefault-real-8 does not promote the BLAS call when using -fexternal-blas

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-09-03
     Ever Confirmed|0                           |1

--- Comment #4 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2012-09-03 15:01:31 UTC ---
> What about -freal-4-real-10 -freal-4-real-16 -freal-4-real-8
> -freal-8-real-10 -freal-8-real-16 and -freal-8-real-4?  See
> my initial response. ...

I have made the following change to the original test

program test
implicit none
integer, parameter :: n = 100
real(8), dimension(n,n) :: A
A = 1.1_8
A = matmul(A,A)
print *, A(1,1), A(n,n)
end program test

(n is chosen larger than the blas-matmul-limit, 30 IIRC). So I got

[macbook] f90/bug% gfc -fexternal-blas pr54463_db.f90
Undefined symbols:
  "_dgemm_", referenced from:
      _MAIN__ in ccj9WebD.o
ld: symbol(s) not found
collect2: error: ld returned 1 exit status
[macbook] f90/bug% gfc -fexternal-blas -freal-8-real-4 pr54463_db.f90
Undefined symbols:
  "_sgemm_", referenced from:
      _MAIN__ in ccvXhCex.o
ld: symbol(s) not found
collect2: error: ld returned 1 exit status
[macbook] f90/bug% gfc -fexternal-blas pr54463_db.f90 -L/sw64/lib -lptlapack
-lptcblas -lptf77blas -latlas
[macbook] f90/bug% a.out
   121.00000000000006        120.99999999999974     
[macbook] f90/bug% gfc -fexternal-blas -freal-8-real-4 pr54463_db.f90
-L/sw64/lib -lptlapack -lptcblas -lptf77blas -latlas
[macbook] f90/bug% a.out
   121.000000       120.999924    

i.e., -freal-8-real-4 seems to work as expected.

Then I changed pr54463_db.f90 to pr54463_db_1.f90 by replacing real(8) with
real, and I got

macbook] f90/bug% gfc -fexternal-blas pr54463_db_1.f90
Undefined symbols:
  "_sgemm_", referenced from:
      _MAIN__ in ccznZgF3.o
ld: symbol(s) not found
collect2: error: ld returned 1 exit status
[macbook] f90/bug% gfc -fexternal-blas -freal-4-real-8 pr54463_db_1.f90
Undefined symbols:
  "_sgemm_", referenced from:
      _MAIN__ in ccN7UdCe.o
ld: symbol(s) not found
collect2: error: ld returned 1 exit status
[macbook] f90/bug% gfc -fexternal-blas -freal-4-real-8 pr54463_db_1.f90
-L/sw64/lib -lptlapack -lptcblas -lptf77blas -latlas
[macbook] f90/bug% a.out
   0.0000000000000000        0.0000000000000000     
[macbook] f90/bug% gfc -fexternal-blas pr54463_db_1.f90 -L/sw64/lib -lptlapack
-lptcblas -lptf77blas -latlas
[macbook] f90/bug% a.out
   121.000000       120.999924    

i.e., -freal-4-real-8, as well as -fdefault-real-8, -freal-4-real-10,
-freal-4-real-16, and -freal-8-real-16, are not working as I'ld expect.

IMO there are four ways to handle this PR:

(1) the Steve's way: closing it as WONTFIX, but I ready to bet a meal in a good
restaurant in Paris next time that sooner or later another PR will be filled;

(2) add to the manual for -fexternal-blas something along the line: "Presently
the -fexternal-blas option is incompatible with the -f*-real-* ones"; this
could be effective if the knowledge of -fexternal-blas propagates through RTFM,
but not if it propagates through mailing lists;

(3) gives an error if -fexternal-blas is used with one of the -f*-real-*
options; IIRC some conbinations of options already give such errors, so either
there is a general way to do it or some code could be borrowed;

(4) since the combination '-fexternal-blas -freal-8-real-4' seems to work, 
some day, someone can try to figure out why and why the other ones are not and
provide a proper fix.

(2) is very easy, but I think (4) would be better (with a low priority).

[Bug fortran/54463] -fdefault-real-8 does not promote the BLAS call when using -fexternal-blas

[burnus at gcc dot gnu.org]

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

--- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-09-05 10:21:53 UTC ---
(In reply to comment #1)
> This bug report should be closed.  Combining
> -fexternal-blas and -fdefault-real-8 would 
> add needless complexity to the compiler.

I think a patch like mine in comment 2 should be sufficient and it not that
complex.


> The correct solution is to write proper Fortran
> code.  To be even more specific, don't use 
> -fdefault-real-8.  It was a really, really,
> bad idea and was only supplied to give
> backwards compatibility with g77.

Well, many compilers have such a flag and there are several programs which rely
on the presence of such a flag. It might not be the most sensible to write
programs that way, but it is common enough that a compiler should support it.


[Comment to my patch:]
(In reply to comment #3)
> What about -freal-4-real-10 -freal-4-real-16 -freal-4-real-8
> -freal-8-real-10 -freal-8-real-16 and -freal-8-real-4?

Ugh, those flags are ugly! (Actually, I think you approved that patch, which I
regard as worse than -fdefault-real-8.) the -freal-*-real-* flags completely
messes up everything. However, since everything is handled in primary.c/decl.c,
the internal kind numbers should be fine. (There are bits in trans-types.c, but
they only error out when a given kind doesn't exist.)

Of course, I assume that one doesn't mess around with -fdefault-real-8 or
-freal-4-real-10 when compiling BLAS. If one does this, one gets what one
deserves.

[Bug fortran/54463] -fdefault-real-8 does not promote the BLAS call when using -fexternal-blas

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #6 from Steve Kargl <sgk at troutmask dot apl.washington.edu> 2012-09-05 14:56:36 UTC ---
On Wed, Sep 05, 2012 at 10:21:53AM +0000, burnus at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54463
> 
> --- Comment #5 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-09-05 10:21:53 UTC ---
> 
> [Comment to my patch:]
> (In reply to comment #3)
> > What about -freal-4-real-10 -freal-4-real-16 -freal-4-real-8
> > -freal-8-real-10 -freal-8-real-16 and -freal-8-real-4?
> 
> Ugh, those flags are ugly! (Actually, I think you approved that
> patch, which I regard as worse than -fdefault-real-8.)

Yes, I did approve the patch.  Oddly, I regard the -freal-4-real-8
option as a better version of -fdefault-real-8 because it is a complete
promotion of real(4) to real(8).  With -fdefault-real-8, there are
a few "gotcha"s; one in particular gotcha is doing IO because of an
alignment issue with a structure used within libgfortran.  (Now,
that I think about it, I do not recall testing whether the
-freal-*-real-* have a similar IO issue.)

> The -freal-*-real-* flags completely messes up everything.

All of these options (ie, the -fdefault*, -freal-*, and -finteger-*)
mess up everything.

The correct solution is to fix the Fortran code so that these options
are not needed.  One way to encourage the user to fix the code is too
unconditionally issue a warning that discourages the use of these
options.  By "unconditionally" I mean that the warning cannot be
suppressed (without redirecting stderr to /dev/null).

> Of course, I assume that one doesn't mess around with -fdefault-real-8 or
> -freal-4-real-10 when compiling BLAS. If one does this, one gets what one
> deserves.

We've both been around long enough that the inventiveness of 
the gfortran user base should no longer cause surprise. :-)

I personally prefer Dominique's suggestion that we add a a warning
in the manual that -fexternal-blas and the -fdefault-* and -freal-*
option have a conflict.  That being said, you've provided a patch
and I won't oppose you committing it.

[Bug fortran/54463] -fdefault-real-8 does not promote the BLAS call when using -fexternal-blas

[burnus at gcc dot gnu.org]

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

--- Comment #7 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-09-06 07:03:49 UTC ---
Author: burnus
Date: Thu Sep  6 07:03:42 2012
New Revision: 191012

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191012
Log:
2012-09-06  Tobias Burnus

        PR fortran/54463
        * trans-intrinsic.c (gfc_conv_intrinsic_funcall): Fix matmul
        call to BLAS if the default-kind has been promoted.

2012-09-06  Tobias Burnus

        PR fortran/54463
        * gfortran.dg/promotion_2.f90: New.


Added:
    trunk/gcc/testsuite/gfortran.dg/promotion_2.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-intrinsic.c
    trunk/gcc/testsuite/ChangeLog

[Bug fortran/54463] -fdefault-real-8 does not promote the BLAS call when using -fexternal-blas

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #8 from Tobias Burnus <burnus at gcc dot gnu.org> 2012-09-06 07:12:15 UTC ---
FIXED on the 4.8 trunk.

Thanks for the report Simon!