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 Mar 21 03:02:59 2017  
 
Category: Test SuiteSeverity: 3 - Normal
Priority: 3 - LowItem Group: Incorrect Result
Status: Need InfoAssigned to: None
Originator Name: Carl PonderOriginator Email: -unavailable-
Open/Closed: OpenRelease: 4.2.1
Operating System: GNU/Linux

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

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

 

(Jump to the original submission Jump to the original submission)

Wed Mar 22 19:27:58 2017, 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 Mar 22 19:19:46 2017, 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 Mar 22 19:03:39 2017, 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 Mar 22 18:35:25 2017, 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 Mar 21 17:22:31 2017, 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 Mar 21 16:16:19 2017, 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?

Anonymous
Tue Mar 21 13:01:17 2017, 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 Mar 21 03:12:05 2017, 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...)

Anonymous
Tue Mar 21 03:08:37 2017, 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.

Anonymous
Tue Mar 21 03:02:59 2017, 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.

Anonymous

 

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

Attach File(s):
   
   
Comment:
   

Attached Files
file #40066:  02.Install added by None (5kB - 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
  • -unavailable- added by dasergatskov (Posted a comment)
  • -unavailable- added by mtmiller (Updated the item)
  • -unavailable- added by None (Submitted the item)
  •  

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

    Only project members can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Wed Mar 22 18:35:25 2017NoneAttached File-=>Added 02.Install, #40066
    Wed Mar 22 18:08:48 2017mtmillerPriority5 - Normal=>3 - Low
      StatusNone=>Need Info

    Back to the top


    Powered by Savane 3.1-cleanup1