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


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

Submitted by:  None
Submitted on:  Tue 21 Mar 2017 03:02:59 AM UTC  
Category:  Test Suite Severity:  3 - Normal
Priority:  3 - Low Item Group:  Incorrect Result
Status:  Invalid Assigned to:  None
Originator Name:  Carl Ponder Originator Email:  -email is unavailable-
Open/Closed:  Closed Release:  4.2.1
Operating System:  GNU/Linux

Add a New Comment(Rich Markup)

You are not logged in

Please log in, so followups can be emailed to you.


( 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>
Project Administrator
Wed 22 Mar 2017 07:27:58 PM UTC, comment #9:

This might be of some interest:


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


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>
Project Administrator
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>
Project Administrator
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)

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>
Project Member
Tue 21 Mar 2017 04:16:19 PM UTC, comment #4:

I tried adding -O0 to the Fortran compile:

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

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>
Project 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

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...)

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
The INSTALL.OCTAVE file said this
I didn't try editing the "lo-ieee.cc" file because you weren't specific on what changes I'm supposed to make.

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
I get this message
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.



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

Attach Files:

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)

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only project members can vote.




    Follow 5 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2017-10-08 mtmiller StatusNeed Info => Invalid
        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.3