bugGNU Octave - Bugs: bug #50600, floating point format is not IEEE!...

 
 

bug #50600: floating point format is not IEEE! (using PGI compiler)

Submitter:  None
Submitted:  Tue 21 Mar 2017 03:02:59 AM UTC
   
 
Category:  Test Suite Severity:  3 - Normal
Priority:  3 - Low Item Group:  Incorrect Result
Status:  Invalid / Not an Octave Bug Assigned to:  None
Originator Name:  Carl Ponder Originator Email:  -email is unavailable-
Open/Closed:  * Closed Release:  * 4.2.1
Operating System:  * GNU/Linux Fixed Release:  None
Planned Release:  None
* Mandatory Fields

Add a New Comment Rich Markup
   

Jump to the original submission

Sun 08 Oct 2017 04:34:07 PM UTC, comment #10: 

Closing as invalid after several months of no activity.

If this issue is still present and you are still debugging it, feel free to reply to this bug again.

Mike Miller <mtmiller>
Group Member
Wed 22 Mar 2017 07:27:58 PM UTC, comment #9: 

This might be of some interest:

https://bugzilla.redhat.com/show_bug.cgi?id=520518

The issue was related to 32-bit intel. Though perhaps it is
due to x87 f.p. which some fancy compilers might use even in x64
mode.

Dmitri.

Dmitri A. Sergatskov <dasergatskov>
Wed 22 Mar 2017 07:19:46 PM UTC, comment #8: 

And the "no optimization" is likely applied to building LAPACK or OpenBLAS. For instance, when building netlib LAPACK, the -O0 option is applied to both dlamch.f and slamch.f. Hopefully that is the case for building OpenBLAS as well.

Mike Miller <mtmiller>
Group Member
Wed 22 Mar 2017 07:03:39 PM UTC, comment #7: 

I think the previous issue that Philip is recalling was with an older release of Octave and an older release of GCC. There is no guarantee that the issue you are seeing with the PGI compiler is the same or related.

I think Philip is referring to the liboctave library, make sure that you don't have multiple copies of Octave in your environment or leftover build products of a different configuration.

If you want to debug this, you will probably want to look at the octave::get_float_format routine in liboctave/system/mach-info.cc. This function looks at the values of certain floating point constants returned by the Fortran function DLAMCH (which is part of LAPACK, or OpenBLAS in your case) and compares them to what they should be if the system supports IEEE floating point, either big-endian or little-endian. You should be able to look at the results in a debugger (or printf debugging) to see what values are not matching up.

Mike Miller <mtmiller>
Group Member
Wed 22 Mar 2017 06:35:25 PM UTC, comment #6: 

What updated library do you mean? I put the Octave library directory on the $LD_LIBRARY_PATH and $LD_RUN_PATH. Or is there something I need to do when I build OpenBLAS & FFTW?

I'm uploading my install-script & build-log in case you're interested.
There are a number of capabilities that I haven't figured out how to enable yet.

(file #40066)

Anonymous
Tue 21 Mar 2017 05:22:31 PM UTC, comment #5: 

I'd have to dig deep in the mail archives. Currently I got no time / priority for that, sorry.
There's even no guarantee that what I mentioned is the actual problem. But I remember that at that time it was a recurring peoblem.

BTW are you sure that your build accesses the updated library?

Philip Nienhuis <philipnienhuis>
Group Member
Tue 21 Mar 2017 04:16:19 PM UTC, comment #4: 

I tried adding -O0 to the Fortran compile:


libtool: compile:  /cm/extra/apps/PGI/17.3/linux86-64/17.3/bin/pgfortran -Kieee -fPIC -O0 -c liboctave/cruft/lapack-xtra/xdlamch.f  -fpic -o liboctave/cruft/lapack-xtra/.libs/liboctave_cruft_libcruft_la-xdlamch.o

libtool: compile:  /cm/extra/apps/PGI/17.3/linux86-64/17.3/bin/pgfortran -Kieee -fPIC -O0 -c liboctave/cruft/lapack-xtra/xslamch.f  -fpic -o liboctave/cruft/lapack-xtra/.libs/liboctave_cruft_libcruft_la-xslamch.o


but it didn't help anything. The DLAMCH message, is it referring to the xdlamch.f file, or a different one?

Anonymous
Tue 21 Mar 2017 01:01:17 PM UTC, comment #3: 

2006 - a long time back.

IIRC I hit a related or the same issue, relating to miscompiled modules in the (IIRC) lapack(?) library, miscompiled because of too agressive compiler optimization.
What I did was recompile the DLAMCH and an other similar module (SLAMCH?) without optimization, and replace them (only those two) in the .so lib. The details are hazy as it is a long time ago, sorry for that.

Philip Nienhuis <philipnienhuis>
Group Member
Tue 21 Mar 2017 03:12:05 AM UTC, comment #2: 

I'm willing o put some work into this if you can give me some suggestions. I also saw  this item

http://git.net/ml/gnu.octave.bugs/2006-09/msg00074.html


but still can't tell what edits I'm supposed to try making.
(Also, is there a way for me to edit the discussion entries I've made? The formatting looks terrible...)

Anonymous
Tue 21 Mar 2017 03:08:37 AM UTC, comment #1: 

I tried adding the -Kieee flag to the build but it didn't help

export   FFLAGS=" -Kieee -fPIC"
export   CFLAGS=" -Kieee -fPIC"
export CXXFLAGS=" -Kieee -fPIC ..."

The INSTALL.OCTAVE file said this

  * If Octave crashes immediately with a floating point exception, it
     is likely that it is failing to initialize the IEEE floating point
     values for infinity and NaN.

     If your system actually does support IEEE arithmetic, you should be
     able to fix this problem by modifying the function
     'octave_ieee_init' in the file 'lo-ieee.cc' to correctly initialize
     Octave's internal infinity and NaN variables.

     If your system does not support IEEE arithmetic but Octave's
     configure script incorrectly determined that it does, you can work
     around the problem by editing the file 'config.h' to not define
     'HAVE_ISINF', 'HAVE_FINITE', and 'HAVE_ISNAN'.

     In any case, please report this as a bug since it might be possible
     to modify Octave's configuration script to automatically determine
     the proper thing to do.

I didn't try editing the "lo-ieee.cc" file because you weren't specific on what changes I'm supposed to make.

Anonymous
Tue 21 Mar 2017 03:02:59 AM UTC, original submission:  

I'm building Octave 4.2.0 & 4.2.1 using the PGI 17.1 & 17.3 compilers, respectively. When I run the

make -i -k check

I get this message

cd test && /bin/sh ../run-octave  --norc --silent --no-history /cm/extra/apps/Octave/4.2.1/PGI-17.3_HDF5-1.10.0-patch2_openBLAS-0.2.19_FFTW-3.3.6-pl1/distro/test/fntests.m /cm/extra/apps/Octave/4.2.1/PGI-17.3_HDF5-1.10.0-patch2_openBLAS-0.2.19_FFTW-3.3.6-pl1/distro/test
fatal: lo_ieee_init: floating point format is not IEEE!  Maybe DLAMCH is miscompiled, or you are using some strange system without IEEE floating point math?
make[3]: [check-local] Error 1 (ignored)

This did not happen with the Intel 17.0 or GCC 4.9.3 compilers, so it's clearly an issue with the PGI compiler/runtime rather than the system hardware.

Anonymous

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach Files:
   
   
Comment:
   

Attached Files
file #40066:  02.Install added by None (5KiB - application/octet-stream - Build-script and build-log with PGI compiler)

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by dasergatskov (Posted a comment)
  • -email is unavailable- added by mtmiller (Updated the item)
  • -email is unavailable- added by None (Submitted the item)
  •  

    There are 0 votes so far. Votes easily highlight which items people would like to see resolved in priority, independently of the priority of the item set by tracker managers.

    Only group members can vote.

     

    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-10-08 mtmiller StatusNeed Info Invalid / Not an Octave Bug
        Open/ClosedOpen Closed
    2017-03-22 None Attached File- Added 02.Install, #40066
    2017-03-22 mtmiller Priority5 - Normal 3 - Low
        StatusNone Need Info

    Back to the top

    Powered by Savane 3.13-d3ae.
    Corresponding source code