Opened 8 years ago
Last modified 8 years ago
#10925 new Bugs
fialed to build math library with studo 12.4 c++ on Solaris 11.2
Reported by: | Owned by: | John Maddock | |
---|---|---|---|
Milestone: | To Be Determined | Component: | math |
Version: | Boost 1.56.0 | Severity: | Showstopper |
Keywords: | Cc: | e_float@… |
Description
Problem:fails to build math library with studio 12.4 on Solaris 11.2
with "../../../boost/math/cstdfloat/cstdfloat_types.hpp", line 393: Error: The type "boost::STATIC_ASSERTION_FAILURE<0>" is incomplete.
1 Error(s) detected.
Change History (22)
comment:1 by , 8 years ago
Cc: | added |
---|
comment:2 by , 8 years ago
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
comment:3 by , 8 years ago
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.
comment:5 by , 8 years ago
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.
comment:6 by , 8 years ago
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
comment:7 by , 8 years ago
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
comment:8 by , 8 years ago
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.
comment:9 by , 8 years ago
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
comment:10 by , 8 years ago
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
comment:11 by , 8 years ago
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
comment:12 by , 8 years ago
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!
comment:13 by , 8 years ago
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
comment:14 by , 8 years ago
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
comment:16 by , 8 years ago
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
comment:17 by , 8 years ago
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?
comment:18 by , 8 years ago
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?
comment:19 by , 8 years ago
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
comment:20 by , 8 years ago
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.
comment:21 by , 8 years ago
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?
comment:22 by , 8 years ago
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.
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?