[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Octave-bug-tracker] [bug #48531] LTO warnings in liboctave
From: |
Robert Jenssen |
Subject: |
[Octave-bug-tracker] [bug #48531] LTO warnings in liboctave |
Date: |
Sat, 16 Jul 2016 11:26:46 +0000 (UTC) |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.106 Safari/537.36 |
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/
- [Octave-bug-tracker] [bug #48531] LTO warnings in liboctave,
Robert Jenssen <=
- [Octave-bug-tracker] [bug #48531] LTO warnings in liboctave, Mike Miller, 2016/07/16
- Message not available
- [Octave-bug-tracker] [bug #48531] LTO warnings in liboctave, Mike Miller, 2016/07/16
- Message not available
- [Octave-bug-tracker] [bug #48531] LTO warnings in liboctave, John W. Eaton, 2016/07/17
- [Octave-bug-tracker] [bug #48531] LTO warnings in liboctave, John W. Eaton, 2016/07/18
- [Octave-bug-tracker] [bug #48531] LTO warnings in liboctave, John W. Eaton, 2016/07/18
- [Octave-bug-tracker] [bug #48531] LTO warnings in liboctave, Robert Jenssen, 2016/07/18
- [Octave-bug-tracker] [bug #48531] LTO warnings in liboctave, John W. Eaton, 2016/07/18
- [Octave-bug-tracker] [bug #48531] LTO warnings in liboctave, Mike Miller, 2016/07/18
- [Octave-bug-tracker] [bug #48531] LTO warnings in liboctave, John W. Eaton, 2016/07/18