[v3] Use Solaris prototypes if possible (PR libstdc++-v3/1773)

Paolo Carlini paolo.carlini@oracle.com
Thu Aug 18 12:31:00 GMT 2011


Hi,
> On Tue, 9 Aug 2011, Rainer Orth wrote:
>
>> This patch is the last but one in the series to finally fix
>>
>> PR libstdc++-v3/1773    __cplusplus defined to 1, should be 199711L
>
> Only piece left before the switch :-)
>
>>     * include/c_global/cmath (double abs(double)): Wrap in
>>     !__CORRECT_ISO_CPP_MATH_H_PROTO1 &&
>>     !__CORRECT_ISO_CPP_MATH_H_PROTO2.
>>     (float abs(float), long double abs(long double): Wrap in
>>     !__CORRECT_ISO_CPP_MATH_H_PROTO1.
>>     (float acos(float), long double acos(long double)): Likewise.
> [...]
>
> I guess it would also be possible to reorder the declarations so as to 
> have a single #ifdef (well, two), but then the various overloads of 
> each function wouldn't be adjacent anymore.
Indeed. I would say let's not re-order for now, I'll have a further look 
later on.
>>     * include/tr1/cmath (float fabs(float), long double fabs(long
>>     double)): Wrap in !__CORRECT_ISO_CPP_MATH_H_PROTO1.
>
> There is a comment:
>   // Note: we deal with fabs in a special way, because an using std::fabs
>   // would bring in also the overloads for complex types, which in C++0x
>   // mode have a different return type.
>
> and then it proceeds to using ::fabs and declare the float and long 
> double overloads. Now on solaris, using ::fabs is going to be 
> equivalent to using std::fabs. I don't know if that creates problems 
> for the complex types, and in that case what can be done about it 
> (declare fabs(double) instead of importing the global one?).
We have a testcase for that issue, see Rev 170083,  
testsuite/tr1/headers/c++200x/complex.cc. I think defining fabs(double) 
in namespace tr1 is not an option, because an actual definition vs an 
using leads to errors when the user does an using std::tr1 in the global 
namespace (a recurring issue, this one, we must be very careful). I 
think for now we have to live with a possible regression of the above 
testcase on Solaris, seems a relatively minor issue to me, nobody 
noticed the problem for *years*.

Paolo.



More information about the Gcc-patches mailing list