[Octave-bug-tracker] [bug #48531] LTO warnings in liboctave

[Robert Jenssen]

URL:
  <http://savannah.gnu.org/bugs/?48531>

                 Summary: LTO warnings in liboctave
                 Project: GNU Octave
            Submitted by: morgawr
            Submitted on: Sat 16 Jul 2016 11:26:44 AM GMT
                Category: Libraries
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Other
                  Status: None
             Assigned to: None
         Originator Name: Robert Jenssen
        Originator Email: 
             Open/Closed: Open
         Discussion Lock: Any
                 Release: dev
        Operating System: GNU/Linux

    _______________________________________________________

Details:

Compiling and linking with gcc, g++ and gfortran flags including -flto gives
warnings like:

../octave/liboctave/numeric/schur.cc:88:3: warning: type of 'zrsf2csf_' does
not match original declaration [-Wlto-type-mismatch]
   F77_FUNC (zrsf2csf, ZRSF2CSF) (const octave_idx_type&, Complex *,
   ^
../octave/liboctave/cruft/lapack-xtra/zrsf2csf.f:22:2: note: return value type
mismatch
        subroutine zrsf2csf(n,t,u,c,s)
  ^
../octave/liboctave/cruft/lapack-xtra/zrsf2csf.f:22:2: note: type 'void'
should match type 'int'
../octave/liboctave/cruft/lapack-xtra/zrsf2csf.f:22:2: note: 'zrsf2csf' was
previously declared here
../octave/liboctave/cruft/lapack-xtra/zrsf2csf.f:22:2: note: code may be
misoptimized unless -fno-strict-aliasing is used

A possibly incomplete list of the Fortran subroutines affected is crsf2csf,
zrsf2csf, zdconv2i, zdconv2o, csconv2i, csconv2o, cconv2i, cconv2o, cbiry,
cairy, cbesy, cbesk, cbesj, cbesi, cbesh, xcdotu, xcdotc, xilaenv, xzdotu,
xzdotc.

The following patch silences the warnings for crsf2csf:

diff -r ad1790bb8f71 liboctave/cruft/lapack-xtra/crsf2csf.f
--- a/liboctave/cruft/lapack-xtra/crsf2csf.f    Fri Jul 15 16:32:13 2016 -0700
+++ b/liboctave/cruft/lapack-xtra/crsf2csf.f    Sat Jul 16 19:12:14 2016 +1000
@@ -19,10 +19,13 @@
 c <http://www.gnu.org/licenses/>.
 c
 
-       subroutine crsf2csf(n,t,u,c,s)
-       integer n
-       complex t(n,n),u(n,n)
-       real c(n-1),s(n-1)
+       subroutine crsf2csf(n,t,u,c,s) bind(c, name="crsf2csf_")
+       use iso_c_binding, only: c_int, c_float, c_float_complex
+       integer(c_int), value :: n
+       complex(c_float_complex) :: t(n,n)
+       complex(c_float_complex) :: u(n,n)
+       real(c_float) :: c(n-1)
+       real(c_float) :: s(n-1)
        real x,y,z
        integer j
        do j = 1,n-1
diff -r ad1790bb8f71 liboctave/numeric/schur.cc
--- a/liboctave/numeric/schur.cc        Fri Jul 15 16:32:13 2016 -0700
+++ b/liboctave/numeric/schur.cc        Sat Jul 16 19:12:14 2016 +1000
@@ -102,9 +102,9 @@
                              F77_CHAR_ARG_LEN_DECL
                              F77_CHAR_ARG_LEN_DECL);
 
-  F77_RET_T
-  F77_FUNC (crsf2csf, CRSF2CSF) (const octave_idx_type&, FloatComplex *,
-                                 FloatComplex *, float *, float *);
+  void
+  F77_FUNC (crsf2csf, CRSF2CSF) (octave_idx_type, __complex__ float *,
+                                 __complex__ float *, float *, float *);
 }
 
 // For real types.
@@ -519,8 +519,11 @@
       OCTAVE_LOCAL_BUFFER (float, c, n-1);
       OCTAVE_LOCAL_BUFFER (float, sx, n-1);
 
-      F77_XFCN (crsf2csf, CRSF2CSF, (n, s.fortran_vec (),
-                                     u.fortran_vec (), c, sx));
+      F77_XFCN (crsf2csf, CRSF2CSF,
+                (n,
+                 reinterpret_cast< __complex__ float * >(s.fortran_vec()),
+                 reinterpret_cast< __complex__ float * >(u.fortran_vec()),
+                 c, sx));
     }
 
   return schur<FloatComplexMatrix> (s, u);


My understanding is that C++11 arranges that "__complex__ float" and
"std::complex<float>" are made interchangeable by reinterpret_cast<>.
See:[http://en.cppreference.com/w/cpp/numeric/complex]

For example:

// test_complex.cc

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

int main(void)
{
    std::complex<float> jf(0.0F, 1.0F);
    float __complex__ jcf={jf.real(),jf.imag()};
    jcf={0,1};
    jf=std::complex<float>(jcf);
    jcf=*(reinterpret_cast<__complex__ float*>(&jf));
    jcf=jf;
    return 0;
}

gives:

$ g++ -std=c++11 -Wall -o test_complex test_complex.cc
test_complex.cc: In function ‘int main()’:
test_complex.cc:13:9: error: cannot convert ‘std::complex<float>’ to
‘__complex__ float’ in assignment
     jcf=jf;
         ^~


I'm not sure what happens on the Fortran side when octave is configured with
--enable-64.

The above patch does nothing for LTO warnings about naming differences inside
Fortran COMMON blocks in the odepack code. For example:

octave/liboctave/cruft/odepack/slsode.f:1234:1: warning: type of 'sls001' does
not match original declaration [-Wlto-type-mismatch]
       COMMON /SLS001/ ROWNS(209),
 ^
octave/liboctave/cruft/odepack/sstode.f:109:1: warning: type of 'sls001' does
not match original declaration [-Wlto-type-mismatch]
       COMMON /SLS001/ CONIT, CRATE, EL(13), ELCO(13,12),
 ^
octave/liboctave/cruft/odepack/sintdy.f:51:1: note: 'sls001' was previously
declared here
       COMMON /SLS001/ ROWNS(209),
 ^
octave/liboctave/cruft/odepack/sintdy.f:51:1: note: code may be misoptimized
unless -fno-strict-aliasing is used





    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?48531>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/