Re: buildbot test failures

[Dmitri A. Sergatskov]

On Wed, Apr 12, 2017 at 1:35 AM, Dmitri A. Sergatskov <address@hidden> wrote:

On Wed, Mar 15, 2017 at 4:06 PM, John W. Eaton <address@hidden> wrote:

​<...>​

The gcc-6-lto-debian build fails because of a mysterious problem saving and loading signed 32-bit integers to HDF5 files.

<...>

​
John,
​

I think the way buldbot slaves are configured to run lto optimization is not quite right.

One needs to set AR, NM, and RANLIB to gcc-ar, gcc-nm, and gcc-ranlib correspondingly.

The reason it is kind of works now is the lfat-lto-object preserves non-lto symbols which

nm/ar/ranlib would use. Perhaps this lead to some obscure problem like failing HDF5 test.

In any case I just build octave with

../configure CFLAGS="-flto=4" CXXFLAGS="-flto=4" FFLAGS="-flto=4" LDFLAGS="-flto=4" NM="gcc-nm" AR="gcc-ar" RANLIB="gcc-ranlib"

and it works fine and passes all the tests. (I am not sure if LDFLAGS is really needed).

So you may want to adjust flags accordingly.

​I guess I spoke too soon here. I still get the HDF5 fail if I set the flags

to "-O2 -flot=4".

I also noticed in lto compile the following warning (which I do not see in gcc default compile):

​

​

link: g++ -fPIC -pthread -fopenmp -Wall -W -Wshadow -Wold-style-cast -Wformat -Wpointer-arith -Wwrite-strings -Wcast-align -Wcast-qual -O2 -flto=4 -ffat-lto-objects -o src/octave-config src/src_octave_config-octave-config.o  libinterp/corefcn/.libs/libcorefcn.a libgnu/.libs/libgnu.a -lutil -lm -fopenmp -pthread
../src/liboctave/system/mach-info.cc:34:10: warning: type of 'd1mach_' does not match original declaration [-Wlto-type-mismatch]
   double F77_FUNC (d1mach, D1MACH) (const octave_idx_type&);
          ^
../src/liboctave/cruft/misc/d1mach.f:1:14: note: 'd1mach' was previously declared here
       double precision function d1mach (i)
              ^
../src/liboctave/cruft/misc/d1mach.f:1:14: note: code may be misoptimized unless -fno-strict-aliasing is used
libtool: link: (cd "liboctave/.libs" && rm -f "liboctave.so.4" && ln -s "liboctave.so.4.0.0" "liboctave.so.4")

​

​Not sure how important this is, and if test failure has anything to do with that.​

Also -- clang's bug not linking graphicsmagick is gone (at least on Fedora), so the

--without-magick in clang configure could be dropped as well.

jwe

​Sincerely,

Dmitri.
--
​