Re: Bugs blocking the 6.1 release

[Markus Mützel]

Am 22. Mai 2020 um 16:15 Uhr schrieb "Markus Mützel":
> Am 16. Mai 2020 um 16:38 Uhr schrieb "John W. Eaton":
> > On 5/16/20 4:58 AM, "Markus Mützel" wrote:
> > > Thanks for the quick fix. I could successfully create the tarball with 
> > > that change (hg id 178d101fd37d).
> > > 
> > > Cross-building the stable-octave target with MXE Octave fails with the 
> > > following error:
> > > 
> > > /home/osboxes/Documents/Repositories/Octave/mxe-octave-stable/tmp-stable-octave/octave-6.0.1/libinterp/octave-value/ov-fcn-handle.cc:
> > >  In constructor 'octave::simple_fcn_handle::simple_fcn_handle(const 
> > > octave_value&, const string&)':
> > > /home/osboxes/Documents/Repositories/Octave/mxe-octave-stable/tmp-stable-octave/octave-6.0.1/libinterp/octave-value/ov-fcn-handle.cc:181:28:
> > >  warning: declaration of 'octave_function* fcn' shadows a parameter 
> > > [-Wshadow]
> > >    181 |           octave_function *fcn = m_fcn.function_value ();
> > >        |                            ^~~
> > 
> > [...]
> > 
> > I'll check out the warnings.  What version of GCC are you using that 
> > produces these warnings?  I don't recall seeing them with GCC 8.
> > 
> > > /home/osboxes/Documents/Repositories/Octave/mxe-octave-stable/tmp-stable-octave/octave-6.0.1/libinterp/octave-value/ov-fcn-handle.cc:
> > >  In member function 'virtual bool 
> > > octave_fcn_handle::load_hdf5(octave_hdf5_id, const char*)':
> > > /home/osboxes/Documents/Repositories/Octave/mxe-octave-stable/tmp-stable-octave/octave-6.0.1/libinterp/octave-value/ov-fcn-handle.cc:2640:27:
> > >  error: cannot bind non-const lvalue reference of type 'octave_hdf5_id&' 
> > > {aka 'long long int&'} to an rvalue of type 'octave_hdf5_id' {aka 'long 
> > > long int'}
> > >   2640 |       if (afh->load_hdf5 (group_hid, space_hid, type_hid))
> > >        |                           ^~~~~~~~~
> > > /home/osboxes/Documents/Repositories/Octave/mxe-octave-stable/tmp-stable-octave/octave-6.0.1/libinterp/octave-value/ov-fcn-handle.cc:2022:57:
> > >  note:   initializing argument 1 of 'bool 
> > > octave::anonymous_fcn_handle::load_hdf5(octave_hdf5_id&, octave_hdf5_id&, 
> > > octave_hdf5_id&)'
> > >   2022 |   bool anonymous_fcn_handle::load_hdf5 (octave_hdf5_id& 
> > > group_hid,
> > >        |                                         ~~~~~~~~~~~~~~~~^~~~~~~~~
> > > make[5]: *** [Makefile:20696: 
> > > libinterp/octave-value/liboctave_value_la-ov-fcn-handle.lo] Error 1
> > > 
> > > 
> > > Some of those are warnings that I also see for native builds on Ubuntu 
> > > Linux. But the error about the non-const lvalue seems to be Windows 
> > > specific. I'm not sure why gcc doesn't mind on Linux though (maybe some 
> > > standard extension?).
> > 
> > Yeah, strange.  I'll try a Windows build and see if I can understand why 
> > that's failing.
> 
> I think I finally understand why this is failing:
> For native compilations on my Linux box, hid_t is typedef'ed as int64_t. In 
> the version of the HDF5 headers that is included in MXE Octave, hid_t is 
> typedef'ed as int. Like shown in the error message, octave_hdf5_id is likely 
> typedef'ed as int64_t.
> Thus, the types match for native builds on Linux. For Windows MXE builds, the 
> compiler tries to create a temporary rvalue of matching type to call 
> load_hdf5 and fails on binding the non-const lvalue reference to the 
> temporary rvalue.
> To be honest, the error message would have been a lot more helpful if it 
> mentioned the type of hid_t...
> 
> I used the attached changes to fix that error and to also avoid the shadowed 
> variable warnings.
> 
> I'll report back when the cross-compilation has finished and I could test the 
> performance on Windows.

Compilation finished successfully. The test suite results in a bunch of failed 
tests and a pair of regressions (mostly indexing related where a function is 
mistaken for an array, see the attached log file).
On Linux, I only see 2 failing tests and 2 regressions.

However, the performance difference is more than noticeable.
I attached "Very Sleepy" for about 2 minutes to what I think was the 
interpreter thread. "file_stat" still accounts for approx. 10% of the execution 
time (on a HDD). But that is very low compared to the about 80% from before the 
changes.

HTH,
Markus

fntests-jwe.log
Description: Binary data