Boost C++ Libraries: Ticket #10925: fialed to build math library with studo 12.4 c++ on Solaris 11.2

cc set

John Maddock — Sat, 10 Jan 2015 19:47:29 GMT

cc e_float@… added

Chris can you look at this?

I assume that since the only part of Boost.Math that has a lib build does not include this file.... that this is an issue with the tests building, and not the lib building?

e_float@… — Sat, 10 Jan 2015 22:53:09 GMT

Whatever the root cause, I just reviewed some of the compiler switches in all of cstdfloatX. Maybe this issue actually reveals a logic error in my pre-processor code.

I think we need to review what I wrote for the case when GCC's libquadmath is available *and* the compiler supports a native 128-bit floating-point type.

Maybe there is a cut-and-paste error still lurking in my code.

Chris

anonymous — Sun, 11 Jan 2015 09:32:25 GMT

I think we probably need to see the preprocessed source for the file that failing to figure this out, can the OP please provide that?

Thanks, John.

anonymous — Tue, 13 Jan 2015 01:39:48 GMT

studio 12.4 compilers don't support float128.

John Maddock — Sun, 18 Jan 2015 18:54:30 GMT

studio 12.4 compilers don't support float128.

OK but we would still need to see the preprocessed source to figure out what's gone wrong.

angela.xie@… — Tue, 20 Jan 2015 19:24:04 GMT

John,

I have sent the preprocessed source to boost-bugs@… it is too large to attach it to this ticket.

Please let me know if you don't receive it.

Thanks

Angela

Zok — Thu, 22 Jan 2015 13:50:09 GMT

I think the problem is that Sun compiler always returns false on std::numeric_limits<T>::is_iec559. Is it reasonable to check instead for?: std::numeric_limits<T>::has_infinity std::numeric_limits<T>::has_quiet_NaN std::numeric_limits<T>::has_signaling_NaN

John Maddock — Thu, 22 Jan 2015 18:21:59 GMT

I'll let Chris answer that, in the mean time can you send the preprocessed source to john@… as I didn't get the boost-bugs one (and that list has no archives apparently). You'll need to zip it up to make it small enough to send through email too. Thanks! John.

anonymous — Thu, 22 Jan 2015 19:58:08 GMT

I think the problem is that Sun compiler always returns false on std::numeric_limits<T>::is_iec559. Is it reasonable to check instead for?: std::numeric_limits<T>::has_infinity std::numeric_limits<T>::has_quiet_NaN std::numeric_limits<T>::has_signaling_NaN

Thanks for this information. See below.

I'll let Chris answer that, ...

The proposed change is reasonable, but unfortunately not allowed. The types in <boost/cstdfloat.hpp> such as boost::float32_t, etc. provide the reference implementation for N3626 proposed for C++17. This requires the undelying floating-point built-in types to adhere to IEEE-754 (which is analogous to std::numeric_limits<T>::is_iec559 testing true.

I am, therefore, reluctant to provide a workaround. If we provide one --- and I'm not sure we will --- we would probably limit the workaround to this compiler and platform only. Can anyone provide clear and unique preprocessor defines for detecting this compiler and this platform only?

Thanks for your help and best regards, Chris

Zok — Fri, 23 Jan 2015 14:26:02 GMT

Hey, is that what you asking? (Sorry, if I misunderstood)

#if defined(__sun) && defined(__SVR4)
	Check for std::numeric_limits<T>::has_infinity std::numeric_limits<T>::has_quiet_NaN std::numeric_limits<T>::has_signaling_NaN
#else
        Check for std::numeric_limits<T>::is_iec559
#endif

anonymous — Fri, 23 Jan 2015 19:06:20 GMT

Hey, is that what you asking?

Yes. Thank you.

#if defined(sun) && defined(SVR4)

use infinity and NaN

#else

use is_iec559

#endif

Also:

What does SVR4 mean?
Does the PP have a version represented numerically?

Thank you and best regards, Chris

Zok — Fri, 23 Jan 2015 20:56:36 GMT

Oh good :),

SVR4 means that it is System V Based (i.e Solaris, does not include obsolete BSD-based SunOS)

As for the preprocessor, since I am on Solaris 12.3 __SUNPRO_CC and __SUNPRO_C are 0x5120

For older versions:
10 : 0x570
11 : 0x580
12 : 0x590
12.1 : 0x5100
12.2 : 0x5100

Thanks!

angela.xie@… — Sat, 31 Jan 2015 01:48:51 GMT

this problem is only if compile with option -library=stlport4. there is no this problem if compile with -std=c++03 or -library=stdcxx4

Angela

anonymous — Thu, 05 Feb 2015 22:58:52 GMT

this problem is only if compile with option -library=stlport4.

OK. Well that's interesting. What does STLport4 report for std::numeric_limits<T>::is_iec559 for float, double and long double ?

there is no this problem if compile with -std=c++03

OK. Thanks.

or -library=stdcxx4

OK. Do you know what stdcxx4 means ? Is it support for C++14 ?

Cheers, Chris

angela.xie@… — Thu, 05 Feb 2015 23:04:31 GMT

-library=stdcxx4 is Apache C++ Standard Library.

anonymous — Fri, 06 Feb 2015 15:08:39 GMT

It is completely opposite for me.

-library=stlport4 is the only option that returns true on:

std::numeric_limits<double>::is_iec559 (i.e expected behavior) std::numeric_limits<float>::is_iec559 (i.e expected behavior)

except this one I got false even with stlport4:

std::numeric_limits<long double>::is_iec559

I got false for all three when specifying compat=5(-std=sun03) and compat=g(-std=c++03) options instead.

Compiler version:

Sun C++ 5.12 SunOS_sparc Patch 148506-18 2014/02/1

John Maddock — Sun, 22 Feb 2015 19:16:19 GMT

This should be fixed for Solaris on x86 in https://github.com/boostorg/math/commit/1ef4e9c1c28b8d322f045c204ad25474bfde2221

At least for me, the only combination that failed was when using STLPort, and then only the 80-bit long double case. I fixed by not making long double a "standard" type in that case.

Which appears to just leave the Sparc case where none of the types are IEEE-compatible, is that right?

Zok — Tue, 24 Feb 2015 19:54:31 GMT

So I guess, I would not be able to compile my code then :(

Why can`t we just fix it for double and float as well?

John Maddock — Wed, 25 Feb 2015 08:53:32 GMT

So I guess, I would not be able to compile my code then :( Why can`t we just fix it for double and float as well?

We need to figure out what the right thing to do is ;)

I assume you're on Sparc then?

I should have thought of this before - can you please compile and run libs/config/test/math_info.cpp and let us have the program output when run? If you can do that for each of the -library=stlport4, -library=apache4 and -std=c++11 options that would be great. It's a self contained program so from the command line in the Boost root directory it's just a:

CC -I. <option> libs/config/test/math_info.cpp && ./a.out

As a temporary workaround - you casn either comment out the offending static_assert's or else revert boost/math/tools/big_constant.hpp to this version: https://github.com/boostorg/math/blob/c08785d7dd8b5c2f5da53fece401099fd31f852f/include/boost/math/tools/big_constant.hpp

Either should get the Boost.Math C-interface libraries building again for you

rsd@… — Tue, 31 Mar 2015 19:29:50 GMT

Me Too

After getting an inquiry from a customer I've been looking at this for the past day or so. The Cray C compiler has the same problem as the Sun C compiler. The current school of thought here is that flushing denormals to 0 is a reasonable optimization that the standard should not preclude.

rsd@… — Thu, 02 Apr 2015 16:06:07 GMT

Ah, so I made a little test program, and figured out that g++ -ffast-math or icpc -O<anything but 0> DO set FTZ (and presumably DAZ) and flush to zero, but then they lie about it and set has_denorm to denorm_present anyway.

So do I completely not understand this? Is there some interpretation of the standard that says it's compliant to zero denormals and still set has_denorm to denorm_present?

John Maddock — Thu, 02 Apr 2015 17:10:33 GMT

I think the fundamental issue with flushing-to-zero is that this is potentially a runtime setting (certainly it is if you're using the x87 FPU, not so sure about the SSE instructions). So there's no way that the compile time constant numeric_limits::has_denorm can accurately reflect reality. IEC559 would give the definitive answer as to whether flush-to-zero is acceptible or not.

BTW the issue here is when flush-to-zero may occur, but isn't absolutely guarenteed to always occur. That does genuinely make it hard to reason about some floating-point logic, though I agree it's a reasonable optimization.