You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@stdcxx.apache.org by "Martin Sebor (JIRA)" <ji...@apache.org> on 2008/02/11 22:46:08 UTC
[jira] Created: (STDCXX-722) [gcc] use math __builtins
[gcc] use math __builtins
-------------------------
Key: STDCXX-722
URL: https://issues.apache.org/jira/browse/STDCXX-722
Project: C++ Standard Library
Issue Type: Sub-task
Reporter: Martin Sebor
Assignee: Martin Sebor
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-722) [gcc] use math __builtins
Posted by "Martin Sebor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/STDCXX-722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Sebor updated STDCXX-722:
--------------------------------
Attachment: stdcxx-722.diff
Attached patch with the full solution.
> [gcc] use math __builtins
> -------------------------
>
> Key: STDCXX-722
> URL: https://issues.apache.org/jira/browse/STDCXX-722
> Project: C++ Standard Library
> Issue Type: Sub-task
> Components: 26. Numerics
> Affects Versions: 4.2.0
> Environment: gcc 4
> Reporter: Martin Sebor
> Assignee: Martin Sebor
> Priority: Minor
> Fix For: 4.2.1
>
> Attachments: stdcxx-722.diff
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> For better efficiency and to reduce namespace pollution we can replace all the math functions used in [<complex>|http://svn.apache.org/repos/asf/stdcxx/trunk/include/complex] with gcc's built-in equivalents.
> Quoting from section [5.46 Other built-in functions provided by GCC|http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Other-Builtins.html#Other-Builtins] of the gcc online manual:
> {quote}
> The ISO C99 functions {{_Exit}}, {{acoshf}}, {{acoshl}}, {{acosh}}, {{asinhf}}, {{asinhl}}, {{asinh}}, {{atanhf}}, {{atanhl}}, {{atanh}}, {{cabsf}}, {{cabsl}}, {{cabs}}, {{cacosf}}, {{cacoshf}}, {{cacoshl}}, {{cacosh}}, {{cacosl}}, {{cacos}}, {{cargf}}, {{cargl}}, {{carg}}, {{casinf}}, {{casinhf}}, {{casinhl}}, {{casinh}}, {{casinl}}, {{casin}}, {{catanf}}, {{catanhf}}, {{catanhl}}, {{catanh}}, {{catanl}}, {{catan}}, {{cbrtf}}, {{cbrtl}}, {{cbrt}}, {{ccosf}}, {{ccoshf}}, {{ccoshl}}, {{ccosh}}, {{ccosl}}, {{ccos}}, {{cexpf}}, {{cexpl}}, {{cexp}}, {{cimagf}}, {{cimagl}}, {{cimag}}, {{clogf}}, {{clogl}}, {{clog}}, {{conjf}}, {{conjl}}, {{conj}}, {{copysignf}}, {{copysignl}}, {{copysign}}, {{cpowf}}, {{cpowl}}, {{cpow}}, {{cprojf}}, {{cprojl}}, {{cproj}}, {{crealf}}, {{creall}}, {{creal}}, {{csinf}}, {{csinhf}}, {{csinhl}}, {{csinh}}, {{csinl}}, {{csin}}, {{csqrtf}}, {{csqrtl}}, {{csqrt}}, {{ctanf}}, {{ctanhf}}, {{ctanhl}}, {{ctanh}}, {{ctanl}}, {{ctan}}, {{erfcf}}, {{erfcl}}, {{erfc}}, {{erff}}, {{erfl}}, {{erf}}, {{exp2f}}, {{exp2l}}, {{exp2}}, {{expm1f}}, {{expm1l}}, {{expm1}}, {{fdimf}}, {{fdiml}}, {{fdim}}, {{fmaf}}, {{fmal}}, {{fmaxf}}, {{fmaxl}}, {{fmax}}, {{fma}}, {{fminf}}, {{fminl}}, {{fmin}}, {{hypotf}}, {{hypotl}}, {{hypot}}, {{ilogbf}}, {{ilogbl}}, {{ilogb}}, {{imaxabs}}, {{isblank}}, {{iswblank}}, {{lgammaf}}, {{lgammal}}, {{lgamma}}, {{llabs}}, {{llrintf}}, {{llrintl}}, {{llrint}}, {{llroundf}}, {{llroundl}}, {{llround}}, {{log1pf}}, {{log1pl}}, {{log1p}}, {{log2f}}, {{log2l}}, {{log2}}, {{logbf}}, {{logbl}}, {{logb}}, {{lrintf}}, {{lrintl}}, {{lrint}}, {{lroundf}}, {{lroundl}}, {{lround}}, {{nearbyintf}}, {{nearbyintl}}, {{nearbyint}}, {{nextafterf}}, {{nextafterl}}, {{nextafter}}, {{nexttowardf}}, {{nexttowardl}}, {{nexttoward}}, {{remainderf}}, {{remainderl}}, {{remainder}}, {{remquof}}, {{remquol}}, {{remquo}}, {{rintf}}, {{rintl}}, {{rint}}, {{roundf}}, {{roundl}}, {{round}}, {{scalblnf}}, {{scalblnl}}, {{scalbln}}, {{scalbnf}}, {{scalbnl}}, {{scalbn}}, {{snprintf}}, {{tgammaf}}, {{tgammal}}, {{tgamma}}, {{truncf}}, {{truncl}}, {{trunc}}, {{vfscanf}}, {{vscanf}}, {{vsnprintf}} and {{vsscanf}} are handled as built-in functions except in strict ISO C90 mode ({{-ansi}} or {{-std=c89}}).
> There are also built-in versions of the ISO C99 functions {{acosf}}, {{acosl}}, {{asinf}}, {{asinl}}, {{atan2f}}, {{atan2l}}, {{atanf}}, {{atanl}}, {{ceilf}}, {{ceill}}, {{cosf}}, {{coshf}}, {{coshl}}, {{cosl}}, {{expf}}, {{expl}}, {{fabsf}}, {{fabsl}}, {{floorf}}, {{floorl}}, {{fmodf}}, {{fmodl}}, {{frexpf}}, {{frexpl}}, {{ldexpf}}, {{ldexpl}}, {{log10f}}, {{log10l}}, {{logf}}, {{logl}}, {{modfl}}, {{modf}}, {{powf}}, {{powl}}, {{sinf}}, {{sinhf}}, {{sinhl}}, {{sinl}}, {{sqrtf}}, {{sqrtl}}, {{tanf}}, {{tanhf}}, {{tanhl}} and {{tanl}} that are recognized in any mode since ISO C90 reserves these names for the purpose to which ISO C99 puts them. All these functions have corresponding versions prefixed with {{__builtin_}}.
> {quote}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-722) [gcc] use math __builtins
Posted by "Travis Vitek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/STDCXX-722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568684#action_12568684 ]
Travis Vitek commented on STDCXX-722:
-------------------------------------
Martin, a few comments on your patch.
{noformat}
+#if 4 <= __GNUG__
+
+// define helpers to call gcc 4.x math builtins
+
+_RWSTD_NAMESPACE (__rw) {
+
+inline float __rw_atan2 (float __x, float __y)
+{
+ return __builtin_atan2f (__x, __y);
+}
+
+inline float __rw_cos (float __x)
+{
+ return __builtin_cosf (__x);
+}
+// use gcc 4 builtins for efficiency and namespace cleanliness
+# define _RWSTD_ATAN2 _RW::__rw_atan2
+# define _RWSTD_COS _RW::__rw_cos
+# define _RWSTD_COSH _RW::__rw_cosh
+# define _RWSTD_EXP _RW::__rw_exp
+# define _RWSTD_LOG _RW::__rw_log
+# define _RWSTD_POW _RW::__rw_pow
+# define _RWSTD_SIN _RW::__rw_sin
+# define _RWSTD_SINH _RW::__rw_sinh
+# define _RWSTD_SQRT _RW::__rw_sqrt
+
+#else // gcc < 4.0
+# include _RWSTD_CMATH
+
+# define _RWSTD_ATAN2 _RWSTD_C::atan2
+# define _RWSTD_COS _RWSTD_C::cos
+# define _RWSTD_COSH _RWSTD_C::cosh
+# define _RWSTD_EXP _RWSTD_C::exp
+# define _RWSTD_LOG _RWSTD_C::log
+# define _RWSTD_POW _RWSTD_C::pow
+# define _RWSTD_SIN _RWSTD_C::sin
+# define _RWSTD_SINH _RWSTD_C::sinh
+# define _RWSTD_SQRT _RWSTD_C::sqrt
+
+#endif // gcc 4.0
{noformat}
It would be nice if these definitions and macros could go into a common header. That way the valarray transcendentals could take advantage of them.
{noformat}
+#if 4 <= __GNUG__
+
+ // use gcc 4.x builtins
+ complex (const float __complex__ &__rhs)
+ : _C_re (__builtin_crealf (__rhs)),
+ _C_im (__builtin_cimagf (__rhs)) { }
+
+#endif // gcc >= 4.0
{noformat}
Should these new constructors be guarded by a _RWSTD_NO_EXT_* macro? They are extensions, so it seems that we should provide a way to disable them in strict mode.
C99 adds _Complex and functions for manipulating them. Should we add an enhancement to support these since you've opened the door here?
{noformat}
+#if 4 <= __GNUG__
+
+// use gcc 4.x C99 complex builtins
+
+# define _RWSTD_COMPLEX_CAST(T, arg) \
+ _RWSTD_REINTERPRET_CAST (const T __complex__&, arg)
+
+
+_RWSTD_SPECIALIZED_FUNCTION inline float
+abs (const complex<float> &__x)
+{
+ return __builtin_cabsf (_RWSTD_COMPLEX_CAST (float, __x));
+}
+
{noformat}
I think _RWSTD_COMPLEX_CAST() is dangerous at best. I don't know for sure how a __complex__ is laid out in memory. If I were to guess, I'd expect a `float __complex__' to be two contiguous floats like `float _C_complex [2]', which may be completely different from `float _C_real, _C_imag' if any padding is inserted. Fortunately the [documentation|http://gcc.gnu.org/onlinedocs/gcc-4.2.3/gcc/Complex.html#Complex] says some interesting things about the layout of a __complex__.
It also appears that the IBM compiler supports a similar set of [functions|http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.xlcpp8a.doc/compiler/ref/bif_fp.htm]. It might be nice to add support for them while we're in there.
> [gcc] use math __builtins
> -------------------------
>
> Key: STDCXX-722
> URL: https://issues.apache.org/jira/browse/STDCXX-722
> Project: C++ Standard Library
> Issue Type: Sub-task
> Components: 26. Numerics
> Affects Versions: 4.2.0
> Environment: gcc 4
> Reporter: Martin Sebor
> Assignee: Martin Sebor
> Priority: Minor
> Fix For: 4.2.1
>
> Attachments: stdcxx-722.diff, stdcxx-722.log
>
> Original Estimate: 2h
> Time Spent: 4h
> Remaining Estimate: 0h
>
> For better efficiency and to reduce namespace pollution we can replace all the math functions used in [<complex>|http://svn.apache.org/repos/asf/stdcxx/trunk/include/complex] with gcc's built-in equivalents.
> Quoting from section [5.46 Other built-in functions provided by GCC|http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Other-Builtins.html#Other-Builtins] of the gcc online manual:
> {quote}
> The ISO C99 functions {{_Exit}}, {{acoshf}}, {{acoshl}}, {{acosh}}, {{asinhf}}, {{asinhl}}, {{asinh}}, {{atanhf}}, {{atanhl}}, {{atanh}}, {{cabsf}}, {{cabsl}}, {{cabs}}, {{cacosf}}, {{cacoshf}}, {{cacoshl}}, {{cacosh}}, {{cacosl}}, {{cacos}}, {{cargf}}, {{cargl}}, {{carg}}, {{casinf}}, {{casinhf}}, {{casinhl}}, {{casinh}}, {{casinl}}, {{casin}}, {{catanf}}, {{catanhf}}, {{catanhl}}, {{catanh}}, {{catanl}}, {{catan}}, {{cbrtf}}, {{cbrtl}}, {{cbrt}}, {{ccosf}}, {{ccoshf}}, {{ccoshl}}, {{ccosh}}, {{ccosl}}, {{ccos}}, {{cexpf}}, {{cexpl}}, {{cexp}}, {{cimagf}}, {{cimagl}}, {{cimag}}, {{clogf}}, {{clogl}}, {{clog}}, {{conjf}}, {{conjl}}, {{conj}}, {{copysignf}}, {{copysignl}}, {{copysign}}, {{cpowf}}, {{cpowl}}, {{cpow}}, {{cprojf}}, {{cprojl}}, {{cproj}}, {{crealf}}, {{creall}}, {{creal}}, {{csinf}}, {{csinhf}}, {{csinhl}}, {{csinh}}, {{csinl}}, {{csin}}, {{csqrtf}}, {{csqrtl}}, {{csqrt}}, {{ctanf}}, {{ctanhf}}, {{ctanhl}}, {{ctanh}}, {{ctanl}}, {{ctan}}, {{erfcf}}, {{erfcl}}, {{erfc}}, {{erff}}, {{erfl}}, {{erf}}, {{exp2f}}, {{exp2l}}, {{exp2}}, {{expm1f}}, {{expm1l}}, {{expm1}}, {{fdimf}}, {{fdiml}}, {{fdim}}, {{fmaf}}, {{fmal}}, {{fmaxf}}, {{fmaxl}}, {{fmax}}, {{fma}}, {{fminf}}, {{fminl}}, {{fmin}}, {{hypotf}}, {{hypotl}}, {{hypot}}, {{ilogbf}}, {{ilogbl}}, {{ilogb}}, {{imaxabs}}, {{isblank}}, {{iswblank}}, {{lgammaf}}, {{lgammal}}, {{lgamma}}, {{llabs}}, {{llrintf}}, {{llrintl}}, {{llrint}}, {{llroundf}}, {{llroundl}}, {{llround}}, {{log1pf}}, {{log1pl}}, {{log1p}}, {{log2f}}, {{log2l}}, {{log2}}, {{logbf}}, {{logbl}}, {{logb}}, {{lrintf}}, {{lrintl}}, {{lrint}}, {{lroundf}}, {{lroundl}}, {{lround}}, {{nearbyintf}}, {{nearbyintl}}, {{nearbyint}}, {{nextafterf}}, {{nextafterl}}, {{nextafter}}, {{nexttowardf}}, {{nexttowardl}}, {{nexttoward}}, {{remainderf}}, {{remainderl}}, {{remainder}}, {{remquof}}, {{remquol}}, {{remquo}}, {{rintf}}, {{rintl}}, {{rint}}, {{roundf}}, {{roundl}}, {{round}}, {{scalblnf}}, {{scalblnl}}, {{scalbln}}, {{scalbnf}}, {{scalbnl}}, {{scalbn}}, {{snprintf}}, {{tgammaf}}, {{tgammal}}, {{tgamma}}, {{truncf}}, {{truncl}}, {{trunc}}, {{vfscanf}}, {{vscanf}}, {{vsnprintf}} and {{vsscanf}} are handled as built-in functions except in strict ISO C90 mode ({{-ansi}} or {{-std=c89}}).
> There are also built-in versions of the ISO C99 functions {{acosf}}, {{acosl}}, {{asinf}}, {{asinl}}, {{atan2f}}, {{atan2l}}, {{atanf}}, {{atanl}}, {{ceilf}}, {{ceill}}, {{cosf}}, {{coshf}}, {{coshl}}, {{cosl}}, {{expf}}, {{expl}}, {{fabsf}}, {{fabsl}}, {{floorf}}, {{floorl}}, {{fmodf}}, {{fmodl}}, {{frexpf}}, {{frexpl}}, {{ldexpf}}, {{ldexpl}}, {{log10f}}, {{log10l}}, {{logf}}, {{logl}}, {{modfl}}, {{modf}}, {{powf}}, {{powl}}, {{sinf}}, {{sinhf}}, {{sinhl}}, {{sinl}}, {{sqrtf}}, {{sqrtl}}, {{tanf}}, {{tanhf}}, {{tanhl}} and {{tanl}} that are recognized in any mode since ISO C90 reserves these names for the purpose to which ISO C99 puts them. All these functions have corresponding versions prefixed with {{__builtin_}}.
> {quote}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (STDCXX-722) [gcc] use math __builtins
Posted by "Travis Vitek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/STDCXX-722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568684#action_12568684 ]
vitek edited comment on STDCXX-722 at 2/13/08 11:18 AM:
---------------------------------------------------------------
Martin, a few comments on your patch.
{noformat}
+#if 4 <= __GNUG__
+
+// define helpers to call gcc 4.x math builtins
+
+_RWSTD_NAMESPACE (__rw) {
+
+inline float __rw_atan2 (float __x, float __y)
+{
+ return __builtin_atan2f (__x, __y);
+}
+
+inline float __rw_cos (float __x)
+{
+ return __builtin_cosf (__x);
+}
+// use gcc 4 builtins for efficiency and namespace cleanliness
+# define _RWSTD_ATAN2 _RW::__rw_atan2
+# define _RWSTD_COS _RW::__rw_cos
+# define _RWSTD_COSH _RW::__rw_cosh
+# define _RWSTD_EXP _RW::__rw_exp
+# define _RWSTD_LOG _RW::__rw_log
+# define _RWSTD_POW _RW::__rw_pow
+# define _RWSTD_SIN _RW::__rw_sin
+# define _RWSTD_SINH _RW::__rw_sinh
+# define _RWSTD_SQRT _RW::__rw_sqrt
+
+#else // gcc < 4.0
+# include _RWSTD_CMATH
+
+# define _RWSTD_ATAN2 _RWSTD_C::atan2
+# define _RWSTD_COS _RWSTD_C::cos
+# define _RWSTD_COSH _RWSTD_C::cosh
+# define _RWSTD_EXP _RWSTD_C::exp
+# define _RWSTD_LOG _RWSTD_C::log
+# define _RWSTD_POW _RWSTD_C::pow
+# define _RWSTD_SIN _RWSTD_C::sin
+# define _RWSTD_SINH _RWSTD_C::sinh
+# define _RWSTD_SQRT _RWSTD_C::sqrt
+
+#endif // gcc 4.0
{noformat}
It would be nice if these definitions and macros could go into a common header. That way the valarray transcendentals could take advantage of them.
{noformat}
+#if 4 <= __GNUG__
+
+ // use gcc 4.x builtins
+ complex (const float __complex__ &__rhs)
+ : _C_re (__builtin_crealf (__rhs)),
+ _C_im (__builtin_cimagf (__rhs)) { }
+
+#endif // gcc >= 4.0
{noformat}
Should these new constructors be guarded by a _RWSTD_NO_EXT_* macro? They are extensions, so it seems that we should provide a way to disable them in strict mode. Also, C99 adds _Complex and functions for manipulating them. Should we add an enhancement to support these since you've opened the door here?
{noformat}
+#if 4 <= __GNUG__
+
+// use gcc 4.x C99 complex builtins
+
+# define _RWSTD_COMPLEX_CAST(T, arg) \
+ _RWSTD_REINTERPRET_CAST (const T __complex__&, arg)
+
+
+_RWSTD_SPECIALIZED_FUNCTION inline float
+abs (const complex<float> &__x)
+{
+ return __builtin_cabsf (_RWSTD_COMPLEX_CAST (float, __x));
+}
+
{noformat}
I think _RWSTD_COMPLEX_CAST() is dangerous at best. I don't know for sure how a __complex__ is laid out in memory. If I were to guess, I'd expect a 'float __complex__' to be two contiguous floats like 'float _C_complex [2]', which may be completely different from 'float _C_real, _C_imag' if any padding is inserted. Fortunately the [documentation|http://gcc.gnu.org/onlinedocs/gcc-4.2.3/gcc/Complex.html#Complex] says some interesting things about the layout of a __complex__.
It also appears that the IBM compiler supports a similar set of [functions|http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.xlcpp8a.doc/compiler/ref/bif_fp.htm]. It might be nice to add support for them while we're in there.
was (Author: vitek):
Martin, a few comments on your patch.
{noformat}
+#if 4 <= __GNUG__
+
+// define helpers to call gcc 4.x math builtins
+
+_RWSTD_NAMESPACE (__rw) {
+
+inline float __rw_atan2 (float __x, float __y)
+{
+ return __builtin_atan2f (__x, __y);
+}
+
+inline float __rw_cos (float __x)
+{
+ return __builtin_cosf (__x);
+}
+// use gcc 4 builtins for efficiency and namespace cleanliness
+# define _RWSTD_ATAN2 _RW::__rw_atan2
+# define _RWSTD_COS _RW::__rw_cos
+# define _RWSTD_COSH _RW::__rw_cosh
+# define _RWSTD_EXP _RW::__rw_exp
+# define _RWSTD_LOG _RW::__rw_log
+# define _RWSTD_POW _RW::__rw_pow
+# define _RWSTD_SIN _RW::__rw_sin
+# define _RWSTD_SINH _RW::__rw_sinh
+# define _RWSTD_SQRT _RW::__rw_sqrt
+
+#else // gcc < 4.0
+# include _RWSTD_CMATH
+
+# define _RWSTD_ATAN2 _RWSTD_C::atan2
+# define _RWSTD_COS _RWSTD_C::cos
+# define _RWSTD_COSH _RWSTD_C::cosh
+# define _RWSTD_EXP _RWSTD_C::exp
+# define _RWSTD_LOG _RWSTD_C::log
+# define _RWSTD_POW _RWSTD_C::pow
+# define _RWSTD_SIN _RWSTD_C::sin
+# define _RWSTD_SINH _RWSTD_C::sinh
+# define _RWSTD_SQRT _RWSTD_C::sqrt
+
+#endif // gcc 4.0
{noformat}
It would be nice if these definitions and macros could go into a common header. That way the valarray transcendentals could take advantage of them.
{noformat}
+#if 4 <= __GNUG__
+
+ // use gcc 4.x builtins
+ complex (const float __complex__ &__rhs)
+ : _C_re (__builtin_crealf (__rhs)),
+ _C_im (__builtin_cimagf (__rhs)) { }
+
+#endif // gcc >= 4.0
{noformat}
Should these new constructors be guarded by a _RWSTD_NO_EXT_* macro? They are extensions, so it seems that we should provide a way to disable them in strict mode.
C99 adds _Complex and functions for manipulating them. Should we add an enhancement to support these since you've opened the door here?
{noformat}
+#if 4 <= __GNUG__
+
+// use gcc 4.x C99 complex builtins
+
+# define _RWSTD_COMPLEX_CAST(T, arg) \
+ _RWSTD_REINTERPRET_CAST (const T __complex__&, arg)
+
+
+_RWSTD_SPECIALIZED_FUNCTION inline float
+abs (const complex<float> &__x)
+{
+ return __builtin_cabsf (_RWSTD_COMPLEX_CAST (float, __x));
+}
+
{noformat}
I think _RWSTD_COMPLEX_CAST() is dangerous at best. I don't know for sure how a __complex__ is laid out in memory. If I were to guess, I'd expect a `float __complex__' to be two contiguous floats like `float _C_complex [2]', which may be completely different from `float _C_real, _C_imag' if any padding is inserted. Fortunately the [documentation|http://gcc.gnu.org/onlinedocs/gcc-4.2.3/gcc/Complex.html#Complex] says some interesting things about the layout of a __complex__.
It also appears that the IBM compiler supports a similar set of [functions|http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.xlcpp8a.doc/compiler/ref/bif_fp.htm]. It might be nice to add support for them while we're in there.
> [gcc] use math __builtins
> -------------------------
>
> Key: STDCXX-722
> URL: https://issues.apache.org/jira/browse/STDCXX-722
> Project: C++ Standard Library
> Issue Type: Sub-task
> Components: 26. Numerics
> Affects Versions: 4.2.0
> Environment: gcc 4
> Reporter: Martin Sebor
> Assignee: Martin Sebor
> Priority: Minor
> Fix For: 4.2.1
>
> Attachments: stdcxx-722.diff, stdcxx-722.log
>
> Original Estimate: 2h
> Time Spent: 4h
> Remaining Estimate: 0h
>
> For better efficiency and to reduce namespace pollution we can replace all the math functions used in [<complex>|http://svn.apache.org/repos/asf/stdcxx/trunk/include/complex] with gcc's built-in equivalents.
> Quoting from section [5.46 Other built-in functions provided by GCC|http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Other-Builtins.html#Other-Builtins] of the gcc online manual:
> {quote}
> The ISO C99 functions {{_Exit}}, {{acoshf}}, {{acoshl}}, {{acosh}}, {{asinhf}}, {{asinhl}}, {{asinh}}, {{atanhf}}, {{atanhl}}, {{atanh}}, {{cabsf}}, {{cabsl}}, {{cabs}}, {{cacosf}}, {{cacoshf}}, {{cacoshl}}, {{cacosh}}, {{cacosl}}, {{cacos}}, {{cargf}}, {{cargl}}, {{carg}}, {{casinf}}, {{casinhf}}, {{casinhl}}, {{casinh}}, {{casinl}}, {{casin}}, {{catanf}}, {{catanhf}}, {{catanhl}}, {{catanh}}, {{catanl}}, {{catan}}, {{cbrtf}}, {{cbrtl}}, {{cbrt}}, {{ccosf}}, {{ccoshf}}, {{ccoshl}}, {{ccosh}}, {{ccosl}}, {{ccos}}, {{cexpf}}, {{cexpl}}, {{cexp}}, {{cimagf}}, {{cimagl}}, {{cimag}}, {{clogf}}, {{clogl}}, {{clog}}, {{conjf}}, {{conjl}}, {{conj}}, {{copysignf}}, {{copysignl}}, {{copysign}}, {{cpowf}}, {{cpowl}}, {{cpow}}, {{cprojf}}, {{cprojl}}, {{cproj}}, {{crealf}}, {{creall}}, {{creal}}, {{csinf}}, {{csinhf}}, {{csinhl}}, {{csinh}}, {{csinl}}, {{csin}}, {{csqrtf}}, {{csqrtl}}, {{csqrt}}, {{ctanf}}, {{ctanhf}}, {{ctanhl}}, {{ctanh}}, {{ctanl}}, {{ctan}}, {{erfcf}}, {{erfcl}}, {{erfc}}, {{erff}}, {{erfl}}, {{erf}}, {{exp2f}}, {{exp2l}}, {{exp2}}, {{expm1f}}, {{expm1l}}, {{expm1}}, {{fdimf}}, {{fdiml}}, {{fdim}}, {{fmaf}}, {{fmal}}, {{fmaxf}}, {{fmaxl}}, {{fmax}}, {{fma}}, {{fminf}}, {{fminl}}, {{fmin}}, {{hypotf}}, {{hypotl}}, {{hypot}}, {{ilogbf}}, {{ilogbl}}, {{ilogb}}, {{imaxabs}}, {{isblank}}, {{iswblank}}, {{lgammaf}}, {{lgammal}}, {{lgamma}}, {{llabs}}, {{llrintf}}, {{llrintl}}, {{llrint}}, {{llroundf}}, {{llroundl}}, {{llround}}, {{log1pf}}, {{log1pl}}, {{log1p}}, {{log2f}}, {{log2l}}, {{log2}}, {{logbf}}, {{logbl}}, {{logb}}, {{lrintf}}, {{lrintl}}, {{lrint}}, {{lroundf}}, {{lroundl}}, {{lround}}, {{nearbyintf}}, {{nearbyintl}}, {{nearbyint}}, {{nextafterf}}, {{nextafterl}}, {{nextafter}}, {{nexttowardf}}, {{nexttowardl}}, {{nexttoward}}, {{remainderf}}, {{remainderl}}, {{remainder}}, {{remquof}}, {{remquol}}, {{remquo}}, {{rintf}}, {{rintl}}, {{rint}}, {{roundf}}, {{roundl}}, {{round}}, {{scalblnf}}, {{scalblnl}}, {{scalbln}}, {{scalbnf}}, {{scalbnl}}, {{scalbn}}, {{snprintf}}, {{tgammaf}}, {{tgammal}}, {{tgamma}}, {{truncf}}, {{truncl}}, {{trunc}}, {{vfscanf}}, {{vscanf}}, {{vsnprintf}} and {{vsscanf}} are handled as built-in functions except in strict ISO C90 mode ({{-ansi}} or {{-std=c89}}).
> There are also built-in versions of the ISO C99 functions {{acosf}}, {{acosl}}, {{asinf}}, {{asinl}}, {{atan2f}}, {{atan2l}}, {{atanf}}, {{atanl}}, {{ceilf}}, {{ceill}}, {{cosf}}, {{coshf}}, {{coshl}}, {{cosl}}, {{expf}}, {{expl}}, {{fabsf}}, {{fabsl}}, {{floorf}}, {{floorl}}, {{fmodf}}, {{fmodl}}, {{frexpf}}, {{frexpl}}, {{ldexpf}}, {{ldexpl}}, {{log10f}}, {{log10l}}, {{logf}}, {{logl}}, {{modfl}}, {{modf}}, {{powf}}, {{powl}}, {{sinf}}, {{sinhf}}, {{sinhl}}, {{sinl}}, {{sqrtf}}, {{sqrtl}}, {{tanf}}, {{tanhf}}, {{tanhl}} and {{tanl}} that are recognized in any mode since ISO C90 reserves these names for the purpose to which ISO C99 puts them. All these functions have corresponding versions prefixed with {{__builtin_}}.
> {quote}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (STDCXX-722) [gcc] use math __builtins
Posted by "Travis Vitek (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/STDCXX-722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12568684#action_12568684 ]
vitek edited comment on STDCXX-722 at 2/13/08 11:25 AM:
---------------------------------------------------------------
Martin, a few comments on your patch.
{noformat}
+#if 4 <= __GNUG__
+
+// define helpers to call gcc 4.x math builtins
+
+_RWSTD_NAMESPACE (__rw) {
+
+inline float __rw_atan2 (float __x, float __y)
+{
+ return __builtin_atan2f (__x, __y);
+}
+
+inline float __rw_cos (float __x)
+{
+ return __builtin_cosf (__x);
+}
+// use gcc 4 builtins for efficiency and namespace cleanliness
+# define _RWSTD_ATAN2 _RW::__rw_atan2
+# define _RWSTD_COS _RW::__rw_cos
+# define _RWSTD_COSH _RW::__rw_cosh
+# define _RWSTD_EXP _RW::__rw_exp
+# define _RWSTD_LOG _RW::__rw_log
+# define _RWSTD_POW _RW::__rw_pow
+# define _RWSTD_SIN _RW::__rw_sin
+# define _RWSTD_SINH _RW::__rw_sinh
+# define _RWSTD_SQRT _RW::__rw_sqrt
+
+#else // gcc < 4.0
+# include _RWSTD_CMATH
+
+# define _RWSTD_ATAN2 _RWSTD_C::atan2
+# define _RWSTD_COS _RWSTD_C::cos
+# define _RWSTD_COSH _RWSTD_C::cosh
+# define _RWSTD_EXP _RWSTD_C::exp
+# define _RWSTD_LOG _RWSTD_C::log
+# define _RWSTD_POW _RWSTD_C::pow
+# define _RWSTD_SIN _RWSTD_C::sin
+# define _RWSTD_SINH _RWSTD_C::sinh
+# define _RWSTD_SQRT _RWSTD_C::sqrt
+
+#endif // gcc 4.0
{noformat}
It would be nice if these definitions and macros could go into a common header. That way the valarray transcendentals could take advantage of them.
{noformat}
+#if 4 <= __GNUG__
+
+ // use gcc 4.x builtins
+ complex (const float __complex__ &__rhs)
+ : _C_re (__builtin_crealf (__rhs)),
+ _C_im (__builtin_cimagf (__rhs)) { }
+
+#endif // gcc >= 4.0
{noformat}
Should these new constructors be guarded by a \_RWSTD_NO_EXT_* macro? They are extensions, so it seems that we should provide a way to disable them in strict mode. Also, C99 adds _Complex and functions for manipulating them. Should we add an enhancement to support these since you've opened the door here?
{noformat}
+#if 4 <= __GNUG__
+
+// use gcc 4.x C99 complex builtins
+
+# define _RWSTD_COMPLEX_CAST(T, arg) \
+ _RWSTD_REINTERPRET_CAST (const T __complex__&, arg)
+
+
+_RWSTD_SPECIALIZED_FUNCTION inline float
+abs (const complex<float> &__x)
+{
+ return __builtin_cabsf (_RWSTD_COMPLEX_CAST (float, __x));
+}
+
{noformat}
I think \_RWSTD_COMPLEX_CAST is dangerous at best. I don't know for sure how a GCC \_\_complex__ is laid out in memory. If I were to guess, I'd expect a `float \_\_complex\_\_' to be two contiguous floats like `float \_C_complex [2]', which may be completely different from `float \_C_real, \_C_imag' if any padding is inserted. Fortunately the [documentation|http://gcc.gnu.org/onlinedocs/gcc-4.2.3/gcc/Complex.html#Complex] says some interesting things about the layout of a \_\_complex__.
It also appears that the IBM compiler supports a similar set of [functions|http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.xlcpp8a.doc/compiler/ref/bif_fp.htm]. It might be nice to add support for them while we're in there.
was (Author: vitek):
Martin, a few comments on your patch.
{noformat}
+#if 4 <= __GNUG__
+
+// define helpers to call gcc 4.x math builtins
+
+_RWSTD_NAMESPACE (__rw) {
+
+inline float __rw_atan2 (float __x, float __y)
+{
+ return __builtin_atan2f (__x, __y);
+}
+
+inline float __rw_cos (float __x)
+{
+ return __builtin_cosf (__x);
+}
+// use gcc 4 builtins for efficiency and namespace cleanliness
+# define _RWSTD_ATAN2 _RW::__rw_atan2
+# define _RWSTD_COS _RW::__rw_cos
+# define _RWSTD_COSH _RW::__rw_cosh
+# define _RWSTD_EXP _RW::__rw_exp
+# define _RWSTD_LOG _RW::__rw_log
+# define _RWSTD_POW _RW::__rw_pow
+# define _RWSTD_SIN _RW::__rw_sin
+# define _RWSTD_SINH _RW::__rw_sinh
+# define _RWSTD_SQRT _RW::__rw_sqrt
+
+#else // gcc < 4.0
+# include _RWSTD_CMATH
+
+# define _RWSTD_ATAN2 _RWSTD_C::atan2
+# define _RWSTD_COS _RWSTD_C::cos
+# define _RWSTD_COSH _RWSTD_C::cosh
+# define _RWSTD_EXP _RWSTD_C::exp
+# define _RWSTD_LOG _RWSTD_C::log
+# define _RWSTD_POW _RWSTD_C::pow
+# define _RWSTD_SIN _RWSTD_C::sin
+# define _RWSTD_SINH _RWSTD_C::sinh
+# define _RWSTD_SQRT _RWSTD_C::sqrt
+
+#endif // gcc 4.0
{noformat}
It would be nice if these definitions and macros could go into a common header. That way the valarray transcendentals could take advantage of them.
{noformat}
+#if 4 <= __GNUG__
+
+ // use gcc 4.x builtins
+ complex (const float __complex__ &__rhs)
+ : _C_re (__builtin_crealf (__rhs)),
+ _C_im (__builtin_cimagf (__rhs)) { }
+
+#endif // gcc >= 4.0
{noformat}
Should these new constructors be guarded by a _RWSTD_NO_EXT_* macro? They are extensions, so it seems that we should provide a way to disable them in strict mode. Also, C99 adds _Complex and functions for manipulating them. Should we add an enhancement to support these since you've opened the door here?
{noformat}
+#if 4 <= __GNUG__
+
+// use gcc 4.x C99 complex builtins
+
+# define _RWSTD_COMPLEX_CAST(T, arg) \
+ _RWSTD_REINTERPRET_CAST (const T __complex__&, arg)
+
+
+_RWSTD_SPECIALIZED_FUNCTION inline float
+abs (const complex<float> &__x)
+{
+ return __builtin_cabsf (_RWSTD_COMPLEX_CAST (float, __x));
+}
+
{noformat}
I think _RWSTD_COMPLEX_CAST() is dangerous at best. I don't know for sure how a __complex__ is laid out in memory. If I were to guess, I'd expect a 'float __complex__' to be two contiguous floats like 'float _C_complex [2]', which may be completely different from 'float _C_real, _C_imag' if any padding is inserted. Fortunately the [documentation|http://gcc.gnu.org/onlinedocs/gcc-4.2.3/gcc/Complex.html#Complex] says some interesting things about the layout of a __complex__.
It also appears that the IBM compiler supports a similar set of [functions|http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.xlcpp8a.doc/compiler/ref/bif_fp.htm]. It might be nice to add support for them while we're in there.
> [gcc] use math __builtins
> -------------------------
>
> Key: STDCXX-722
> URL: https://issues.apache.org/jira/browse/STDCXX-722
> Project: C++ Standard Library
> Issue Type: Sub-task
> Components: 26. Numerics
> Affects Versions: 4.2.0
> Environment: gcc 4
> Reporter: Martin Sebor
> Assignee: Martin Sebor
> Priority: Minor
> Fix For: 4.2.1
>
> Attachments: stdcxx-722.diff, stdcxx-722.log
>
> Original Estimate: 2h
> Time Spent: 4h
> Remaining Estimate: 0h
>
> For better efficiency and to reduce namespace pollution we can replace all the math functions used in [<complex>|http://svn.apache.org/repos/asf/stdcxx/trunk/include/complex] with gcc's built-in equivalents.
> Quoting from section [5.46 Other built-in functions provided by GCC|http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Other-Builtins.html#Other-Builtins] of the gcc online manual:
> {quote}
> The ISO C99 functions {{_Exit}}, {{acoshf}}, {{acoshl}}, {{acosh}}, {{asinhf}}, {{asinhl}}, {{asinh}}, {{atanhf}}, {{atanhl}}, {{atanh}}, {{cabsf}}, {{cabsl}}, {{cabs}}, {{cacosf}}, {{cacoshf}}, {{cacoshl}}, {{cacosh}}, {{cacosl}}, {{cacos}}, {{cargf}}, {{cargl}}, {{carg}}, {{casinf}}, {{casinhf}}, {{casinhl}}, {{casinh}}, {{casinl}}, {{casin}}, {{catanf}}, {{catanhf}}, {{catanhl}}, {{catanh}}, {{catanl}}, {{catan}}, {{cbrtf}}, {{cbrtl}}, {{cbrt}}, {{ccosf}}, {{ccoshf}}, {{ccoshl}}, {{ccosh}}, {{ccosl}}, {{ccos}}, {{cexpf}}, {{cexpl}}, {{cexp}}, {{cimagf}}, {{cimagl}}, {{cimag}}, {{clogf}}, {{clogl}}, {{clog}}, {{conjf}}, {{conjl}}, {{conj}}, {{copysignf}}, {{copysignl}}, {{copysign}}, {{cpowf}}, {{cpowl}}, {{cpow}}, {{cprojf}}, {{cprojl}}, {{cproj}}, {{crealf}}, {{creall}}, {{creal}}, {{csinf}}, {{csinhf}}, {{csinhl}}, {{csinh}}, {{csinl}}, {{csin}}, {{csqrtf}}, {{csqrtl}}, {{csqrt}}, {{ctanf}}, {{ctanhf}}, {{ctanhl}}, {{ctanh}}, {{ctanl}}, {{ctan}}, {{erfcf}}, {{erfcl}}, {{erfc}}, {{erff}}, {{erfl}}, {{erf}}, {{exp2f}}, {{exp2l}}, {{exp2}}, {{expm1f}}, {{expm1l}}, {{expm1}}, {{fdimf}}, {{fdiml}}, {{fdim}}, {{fmaf}}, {{fmal}}, {{fmaxf}}, {{fmaxl}}, {{fmax}}, {{fma}}, {{fminf}}, {{fminl}}, {{fmin}}, {{hypotf}}, {{hypotl}}, {{hypot}}, {{ilogbf}}, {{ilogbl}}, {{ilogb}}, {{imaxabs}}, {{isblank}}, {{iswblank}}, {{lgammaf}}, {{lgammal}}, {{lgamma}}, {{llabs}}, {{llrintf}}, {{llrintl}}, {{llrint}}, {{llroundf}}, {{llroundl}}, {{llround}}, {{log1pf}}, {{log1pl}}, {{log1p}}, {{log2f}}, {{log2l}}, {{log2}}, {{logbf}}, {{logbl}}, {{logb}}, {{lrintf}}, {{lrintl}}, {{lrint}}, {{lroundf}}, {{lroundl}}, {{lround}}, {{nearbyintf}}, {{nearbyintl}}, {{nearbyint}}, {{nextafterf}}, {{nextafterl}}, {{nextafter}}, {{nexttowardf}}, {{nexttowardl}}, {{nexttoward}}, {{remainderf}}, {{remainderl}}, {{remainder}}, {{remquof}}, {{remquol}}, {{remquo}}, {{rintf}}, {{rintl}}, {{rint}}, {{roundf}}, {{roundl}}, {{round}}, {{scalblnf}}, {{scalblnl}}, {{scalbln}}, {{scalbnf}}, {{scalbnl}}, {{scalbn}}, {{snprintf}}, {{tgammaf}}, {{tgammal}}, {{tgamma}}, {{truncf}}, {{truncl}}, {{trunc}}, {{vfscanf}}, {{vscanf}}, {{vsnprintf}} and {{vsscanf}} are handled as built-in functions except in strict ISO C90 mode ({{-ansi}} or {{-std=c89}}).
> There are also built-in versions of the ISO C99 functions {{acosf}}, {{acosl}}, {{asinf}}, {{asinl}}, {{atan2f}}, {{atan2l}}, {{atanf}}, {{atanl}}, {{ceilf}}, {{ceill}}, {{cosf}}, {{coshf}}, {{coshl}}, {{cosl}}, {{expf}}, {{expl}}, {{fabsf}}, {{fabsl}}, {{floorf}}, {{floorl}}, {{fmodf}}, {{fmodl}}, {{frexpf}}, {{frexpl}}, {{ldexpf}}, {{ldexpl}}, {{log10f}}, {{log10l}}, {{logf}}, {{logl}}, {{modfl}}, {{modf}}, {{powf}}, {{powl}}, {{sinf}}, {{sinhf}}, {{sinhl}}, {{sinl}}, {{sqrtf}}, {{sqrtl}}, {{tanf}}, {{tanhf}}, {{tanhl}} and {{tanl}} that are recognized in any mode since ISO C90 reserves these names for the purpose to which ISO C99 puts them. All these functions have corresponding versions prefixed with {{__builtin_}}.
> {quote}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-722) [gcc] use math __builtins
Posted by "Martin Sebor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/STDCXX-722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Sebor updated STDCXX-722:
--------------------------------
Patch Info: [Patch Available]
> [gcc] use math __builtins
> -------------------------
>
> Key: STDCXX-722
> URL: https://issues.apache.org/jira/browse/STDCXX-722
> Project: C++ Standard Library
> Issue Type: Sub-task
> Components: 26. Numerics
> Affects Versions: 4.2.0
> Environment: gcc 4
> Reporter: Martin Sebor
> Assignee: Martin Sebor
> Priority: Minor
> Fix For: 4.2.1
>
> Attachments: stdcxx-722.diff, stdcxx-722.log
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> For better efficiency and to reduce namespace pollution we can replace all the math functions used in [<complex>|http://svn.apache.org/repos/asf/stdcxx/trunk/include/complex] with gcc's built-in equivalents.
> Quoting from section [5.46 Other built-in functions provided by GCC|http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Other-Builtins.html#Other-Builtins] of the gcc online manual:
> {quote}
> The ISO C99 functions {{_Exit}}, {{acoshf}}, {{acoshl}}, {{acosh}}, {{asinhf}}, {{asinhl}}, {{asinh}}, {{atanhf}}, {{atanhl}}, {{atanh}}, {{cabsf}}, {{cabsl}}, {{cabs}}, {{cacosf}}, {{cacoshf}}, {{cacoshl}}, {{cacosh}}, {{cacosl}}, {{cacos}}, {{cargf}}, {{cargl}}, {{carg}}, {{casinf}}, {{casinhf}}, {{casinhl}}, {{casinh}}, {{casinl}}, {{casin}}, {{catanf}}, {{catanhf}}, {{catanhl}}, {{catanh}}, {{catanl}}, {{catan}}, {{cbrtf}}, {{cbrtl}}, {{cbrt}}, {{ccosf}}, {{ccoshf}}, {{ccoshl}}, {{ccosh}}, {{ccosl}}, {{ccos}}, {{cexpf}}, {{cexpl}}, {{cexp}}, {{cimagf}}, {{cimagl}}, {{cimag}}, {{clogf}}, {{clogl}}, {{clog}}, {{conjf}}, {{conjl}}, {{conj}}, {{copysignf}}, {{copysignl}}, {{copysign}}, {{cpowf}}, {{cpowl}}, {{cpow}}, {{cprojf}}, {{cprojl}}, {{cproj}}, {{crealf}}, {{creall}}, {{creal}}, {{csinf}}, {{csinhf}}, {{csinhl}}, {{csinh}}, {{csinl}}, {{csin}}, {{csqrtf}}, {{csqrtl}}, {{csqrt}}, {{ctanf}}, {{ctanhf}}, {{ctanhl}}, {{ctanh}}, {{ctanl}}, {{ctan}}, {{erfcf}}, {{erfcl}}, {{erfc}}, {{erff}}, {{erfl}}, {{erf}}, {{exp2f}}, {{exp2l}}, {{exp2}}, {{expm1f}}, {{expm1l}}, {{expm1}}, {{fdimf}}, {{fdiml}}, {{fdim}}, {{fmaf}}, {{fmal}}, {{fmaxf}}, {{fmaxl}}, {{fmax}}, {{fma}}, {{fminf}}, {{fminl}}, {{fmin}}, {{hypotf}}, {{hypotl}}, {{hypot}}, {{ilogbf}}, {{ilogbl}}, {{ilogb}}, {{imaxabs}}, {{isblank}}, {{iswblank}}, {{lgammaf}}, {{lgammal}}, {{lgamma}}, {{llabs}}, {{llrintf}}, {{llrintl}}, {{llrint}}, {{llroundf}}, {{llroundl}}, {{llround}}, {{log1pf}}, {{log1pl}}, {{log1p}}, {{log2f}}, {{log2l}}, {{log2}}, {{logbf}}, {{logbl}}, {{logb}}, {{lrintf}}, {{lrintl}}, {{lrint}}, {{lroundf}}, {{lroundl}}, {{lround}}, {{nearbyintf}}, {{nearbyintl}}, {{nearbyint}}, {{nextafterf}}, {{nextafterl}}, {{nextafter}}, {{nexttowardf}}, {{nexttowardl}}, {{nexttoward}}, {{remainderf}}, {{remainderl}}, {{remainder}}, {{remquof}}, {{remquol}}, {{remquo}}, {{rintf}}, {{rintl}}, {{rint}}, {{roundf}}, {{roundl}}, {{round}}, {{scalblnf}}, {{scalblnl}}, {{scalbln}}, {{scalbnf}}, {{scalbnl}}, {{scalbn}}, {{snprintf}}, {{tgammaf}}, {{tgammal}}, {{tgamma}}, {{truncf}}, {{truncl}}, {{trunc}}, {{vfscanf}}, {{vscanf}}, {{vsnprintf}} and {{vsscanf}} are handled as built-in functions except in strict ISO C90 mode ({{-ansi}} or {{-std=c89}}).
> There are also built-in versions of the ISO C99 functions {{acosf}}, {{acosl}}, {{asinf}}, {{asinl}}, {{atan2f}}, {{atan2l}}, {{atanf}}, {{atanl}}, {{ceilf}}, {{ceill}}, {{cosf}}, {{coshf}}, {{coshl}}, {{cosl}}, {{expf}}, {{expl}}, {{fabsf}}, {{fabsl}}, {{floorf}}, {{floorl}}, {{fmodf}}, {{fmodl}}, {{frexpf}}, {{frexpl}}, {{ldexpf}}, {{ldexpl}}, {{log10f}}, {{log10l}}, {{logf}}, {{logl}}, {{modfl}}, {{modf}}, {{powf}}, {{powl}}, {{sinf}}, {{sinhf}}, {{sinhl}}, {{sinl}}, {{sqrtf}}, {{sqrtl}}, {{tanf}}, {{tanhf}}, {{tanhl}} and {{tanl}} that are recognized in any mode since ISO C90 reserves these names for the purpose to which ISO C99 puts them. All these functions have corresponding versions prefixed with {{__builtin_}}.
> {quote}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-722) [gcc] use math __builtins
Posted by "Martin Sebor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/STDCXX-722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567853#action_12567853 ]
Martin Sebor commented on STDCXX-722:
-------------------------------------
The naive solution here is to simply replace calls to the libc math functions (such as {{atan2}}) with those to the corresponding builtin. The script below shows the names of these functions currently used.
A (likely) more efficient but more involved solution is to make use of gcc's built-ins for the C99 complex functions such as {{ccoshf}}, {{ccosh}}, and {{ccoshl}} etc.
{noformat}
$ svn cat http://svn.apache.org/repos/asf/stdcxx/trunk/include/complex \
http://svn.apache.org/repos/asf/stdcxx/trunk/include/complex.cc \
| sed -n "s/.*_RWSTD_C::\([a-z][a-z0-9]*\).*/\1/gp" | sort | uniq
atan2
cos
cosh
exp
log
pow
sin
sinh
sqrt
{noformat}
> [gcc] use math __builtins
> -------------------------
>
> Key: STDCXX-722
> URL: https://issues.apache.org/jira/browse/STDCXX-722
> Project: C++ Standard Library
> Issue Type: Sub-task
> Components: 26. Numerics
> Affects Versions: 4.2.0
> Environment: gcc 4
> Reporter: Martin Sebor
> Assignee: Martin Sebor
> Priority: Minor
> Fix For: 4.2.1
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> For better efficiency and to reduce namespace pollution we can replace all the math functions used in [<complex>|http://svn.apache.org/repos/asf/stdcxx/trunk/include/complex] with gcc's built-in equivalents.
> Quoting from section [5.46 Other built-in functions provided by GCC|http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Other-Builtins.html#Other-Builtins] of the gcc online manual:
> {quote}
> The ISO C99 functions {{_Exit}}, {{acoshf}}, {{acoshl}}, {{acosh}}, {{asinhf}}, {{asinhl}}, {{asinh}}, {{atanhf}}, {{atanhl}}, {{atanh}}, {{cabsf}}, {{cabsl}}, {{cabs}}, {{cacosf}}, {{cacoshf}}, {{cacoshl}}, {{cacosh}}, {{cacosl}}, {{cacos}}, {{cargf}}, {{cargl}}, {{carg}}, {{casinf}}, {{casinhf}}, {{casinhl}}, {{casinh}}, {{casinl}}, {{casin}}, {{catanf}}, {{catanhf}}, {{catanhl}}, {{catanh}}, {{catanl}}, {{catan}}, {{cbrtf}}, {{cbrtl}}, {{cbrt}}, {{ccosf}}, {{ccoshf}}, {{ccoshl}}, {{ccosh}}, {{ccosl}}, {{ccos}}, {{cexpf}}, {{cexpl}}, {{cexp}}, {{cimagf}}, {{cimagl}}, {{cimag}}, {{clogf}}, {{clogl}}, {{clog}}, {{conjf}}, {{conjl}}, {{conj}}, {{copysignf}}, {{copysignl}}, {{copysign}}, {{cpowf}}, {{cpowl}}, {{cpow}}, {{cprojf}}, {{cprojl}}, {{cproj}}, {{crealf}}, {{creall}}, {{creal}}, {{csinf}}, {{csinhf}}, {{csinhl}}, {{csinh}}, {{csinl}}, {{csin}}, {{csqrtf}}, {{csqrtl}}, {{csqrt}}, {{ctanf}}, {{ctanhf}}, {{ctanhl}}, {{ctanh}}, {{ctanl}}, {{ctan}}, {{erfcf}}, {{erfcl}}, {{erfc}}, {{erff}}, {{erfl}}, {{erf}}, {{exp2f}}, {{exp2l}}, {{exp2}}, {{expm1f}}, {{expm1l}}, {{expm1}}, {{fdimf}}, {{fdiml}}, {{fdim}}, {{fmaf}}, {{fmal}}, {{fmaxf}}, {{fmaxl}}, {{fmax}}, {{fma}}, {{fminf}}, {{fminl}}, {{fmin}}, {{hypotf}}, {{hypotl}}, {{hypot}}, {{ilogbf}}, {{ilogbl}}, {{ilogb}}, {{imaxabs}}, {{isblank}}, {{iswblank}}, {{lgammaf}}, {{lgammal}}, {{lgamma}}, {{llabs}}, {{llrintf}}, {{llrintl}}, {{llrint}}, {{llroundf}}, {{llroundl}}, {{llround}}, {{log1pf}}, {{log1pl}}, {{log1p}}, {{log2f}}, {{log2l}}, {{log2}}, {{logbf}}, {{logbl}}, {{logb}}, {{lrintf}}, {{lrintl}}, {{lrint}}, {{lroundf}}, {{lroundl}}, {{lround}}, {{nearbyintf}}, {{nearbyintl}}, {{nearbyint}}, {{nextafterf}}, {{nextafterl}}, {{nextafter}}, {{nexttowardf}}, {{nexttowardl}}, {{nexttoward}}, {{remainderf}}, {{remainderl}}, {{remainder}}, {{remquof}}, {{remquol}}, {{remquo}}, {{rintf}}, {{rintl}}, {{rint}}, {{roundf}}, {{roundl}}, {{round}}, {{scalblnf}}, {{scalblnl}}, {{scalbln}}, {{scalbnf}}, {{scalbnl}}, {{scalbn}}, {{snprintf}}, {{tgammaf}}, {{tgammal}}, {{tgamma}}, {{truncf}}, {{truncl}}, {{trunc}}, {{vfscanf}}, {{vscanf}}, {{vsnprintf}} and {{vsscanf}} are handled as built-in functions except in strict ISO C90 mode ({{-ansi}} or {{-std=c89}}).
> There are also built-in versions of the ISO C99 functions {{acosf}}, {{acosl}}, {{asinf}}, {{asinl}}, {{atan2f}}, {{atan2l}}, {{atanf}}, {{atanl}}, {{ceilf}}, {{ceill}}, {{cosf}}, {{coshf}}, {{coshl}}, {{cosl}}, {{expf}}, {{expl}}, {{fabsf}}, {{fabsl}}, {{floorf}}, {{floorl}}, {{fmodf}}, {{fmodl}}, {{frexpf}}, {{frexpl}}, {{ldexpf}}, {{ldexpl}}, {{log10f}}, {{log10l}}, {{logf}}, {{logl}}, {{modfl}}, {{modf}}, {{powf}}, {{powl}}, {{sinf}}, {{sinhf}}, {{sinhl}}, {{sinl}}, {{sqrtf}}, {{sqrtl}}, {{tanf}}, {{tanhf}}, {{tanhl}} and {{tanl}} that are recognized in any mode since ISO C90 reserves these names for the purpose to which ISO C99 puts them. All these functions have corresponding versions prefixed with {{__builtin_}}.
> {quote}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-722) [gcc] use math __builtins
Posted by "Martin Sebor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/STDCXX-722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Sebor updated STDCXX-722:
--------------------------------
Fix Version/s: (was: 4.2.1)
4.3
The patch is quite extensive and there's some uncertainty about the binary compatibility of the patch.
Deferring until 4.3.
> [gcc] use math __builtins
> -------------------------
>
> Key: STDCXX-722
> URL: https://issues.apache.org/jira/browse/STDCXX-722
> Project: C++ Standard Library
> Issue Type: Sub-task
> Components: 26. Numerics
> Affects Versions: 4.2.0
> Environment: gcc 4
> Reporter: Martin Sebor
> Assignee: Martin Sebor
> Priority: Minor
> Fix For: 4.3
>
> Attachments: stdcxx-722.diff, stdcxx-722.log
>
> Original Estimate: 2h
> Time Spent: 4h
> Remaining Estimate: 2h
>
> For better efficiency and to reduce namespace pollution we can replace all the math functions used in [<complex>|http://svn.apache.org/repos/asf/stdcxx/trunk/include/complex] with gcc's built-in equivalents.
> Quoting from section [5.46 Other built-in functions provided by GCC|http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Other-Builtins.html#Other-Builtins] of the gcc online manual:
> {quote}
> The ISO C99 functions {{_Exit}}, {{acoshf}}, {{acoshl}}, {{acosh}}, {{asinhf}}, {{asinhl}}, {{asinh}}, {{atanhf}}, {{atanhl}}, {{atanh}}, {{cabsf}}, {{cabsl}}, {{cabs}}, {{cacosf}}, {{cacoshf}}, {{cacoshl}}, {{cacosh}}, {{cacosl}}, {{cacos}}, {{cargf}}, {{cargl}}, {{carg}}, {{casinf}}, {{casinhf}}, {{casinhl}}, {{casinh}}, {{casinl}}, {{casin}}, {{catanf}}, {{catanhf}}, {{catanhl}}, {{catanh}}, {{catanl}}, {{catan}}, {{cbrtf}}, {{cbrtl}}, {{cbrt}}, {{ccosf}}, {{ccoshf}}, {{ccoshl}}, {{ccosh}}, {{ccosl}}, {{ccos}}, {{cexpf}}, {{cexpl}}, {{cexp}}, {{cimagf}}, {{cimagl}}, {{cimag}}, {{clogf}}, {{clogl}}, {{clog}}, {{conjf}}, {{conjl}}, {{conj}}, {{copysignf}}, {{copysignl}}, {{copysign}}, {{cpowf}}, {{cpowl}}, {{cpow}}, {{cprojf}}, {{cprojl}}, {{cproj}}, {{crealf}}, {{creall}}, {{creal}}, {{csinf}}, {{csinhf}}, {{csinhl}}, {{csinh}}, {{csinl}}, {{csin}}, {{csqrtf}}, {{csqrtl}}, {{csqrt}}, {{ctanf}}, {{ctanhf}}, {{ctanhl}}, {{ctanh}}, {{ctanl}}, {{ctan}}, {{erfcf}}, {{erfcl}}, {{erfc}}, {{erff}}, {{erfl}}, {{erf}}, {{exp2f}}, {{exp2l}}, {{exp2}}, {{expm1f}}, {{expm1l}}, {{expm1}}, {{fdimf}}, {{fdiml}}, {{fdim}}, {{fmaf}}, {{fmal}}, {{fmaxf}}, {{fmaxl}}, {{fmax}}, {{fma}}, {{fminf}}, {{fminl}}, {{fmin}}, {{hypotf}}, {{hypotl}}, {{hypot}}, {{ilogbf}}, {{ilogbl}}, {{ilogb}}, {{imaxabs}}, {{isblank}}, {{iswblank}}, {{lgammaf}}, {{lgammal}}, {{lgamma}}, {{llabs}}, {{llrintf}}, {{llrintl}}, {{llrint}}, {{llroundf}}, {{llroundl}}, {{llround}}, {{log1pf}}, {{log1pl}}, {{log1p}}, {{log2f}}, {{log2l}}, {{log2}}, {{logbf}}, {{logbl}}, {{logb}}, {{lrintf}}, {{lrintl}}, {{lrint}}, {{lroundf}}, {{lroundl}}, {{lround}}, {{nearbyintf}}, {{nearbyintl}}, {{nearbyint}}, {{nextafterf}}, {{nextafterl}}, {{nextafter}}, {{nexttowardf}}, {{nexttowardl}}, {{nexttoward}}, {{remainderf}}, {{remainderl}}, {{remainder}}, {{remquof}}, {{remquol}}, {{remquo}}, {{rintf}}, {{rintl}}, {{rint}}, {{roundf}}, {{roundl}}, {{round}}, {{scalblnf}}, {{scalblnl}}, {{scalbln}}, {{scalbnf}}, {{scalbnl}}, {{scalbn}}, {{snprintf}}, {{tgammaf}}, {{tgammal}}, {{tgamma}}, {{truncf}}, {{truncl}}, {{trunc}}, {{vfscanf}}, {{vscanf}}, {{vsnprintf}} and {{vsscanf}} are handled as built-in functions except in strict ISO C90 mode ({{-ansi}} or {{-std=c89}}).
> There are also built-in versions of the ISO C99 functions {{acosf}}, {{acosl}}, {{asinf}}, {{asinl}}, {{atan2f}}, {{atan2l}}, {{atanf}}, {{atanl}}, {{ceilf}}, {{ceill}}, {{cosf}}, {{coshf}}, {{coshl}}, {{cosl}}, {{expf}}, {{expl}}, {{fabsf}}, {{fabsl}}, {{floorf}}, {{floorl}}, {{fmodf}}, {{fmodl}}, {{frexpf}}, {{frexpl}}, {{ldexpf}}, {{ldexpl}}, {{log10f}}, {{log10l}}, {{logf}}, {{logl}}, {{modfl}}, {{modf}}, {{powf}}, {{powl}}, {{sinf}}, {{sinhf}}, {{sinhl}}, {{sinl}}, {{sqrtf}}, {{sqrtl}}, {{tanf}}, {{tanhf}}, {{tanhl}} and {{tanl}} that are recognized in any mode since ISO C90 reserves these names for the purpose to which ISO C99 puts them. All these functions have corresponding versions prefixed with {{__builtin_}}.
> {quote}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-722) [gcc] use math __builtins
Posted by "Martin Sebor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/STDCXX-722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12570476#action_12570476 ]
Martin Sebor commented on STDCXX-722:
-------------------------------------
Thanks for the comments!
Yes, moving the new macros to a common header is probably a good idea. Although I'm not sure we should make the corresponding changes to {{valarray}} before I commit the (binary incompatible) rewrite to it that's been sitting on my hard drive for months and months now.
I'm not sure the {{complex}} ctors I added are a good thing since they might introduce undesirable matches into the overload set in user code, but if we keep them they can't be guarded with an {{_RWSTD_NO_EXT_}} macro because all the new specializations of the {{complex}} non-member functions depend on them and wouldn't compile without them.
I think that at least in theory a compiler is allowed to insert padding after each of the members of {{struct { float a, b; };}} so you're right, there is no guarantee that such a struct would be laid out the same way as an array of 2 floats. I don't believe any of our compilers inserts such padding but we should check to be 100% sure. If none does, we might want to consider changing {{complex}} to declare an array of data members rather than individual data subobjects to prevent future compilers from doing so.
Lastly, thanks for the pointer to the IBM docs! I agree that we should take advantage of these features wherever they are available. Rather than doing so in the same patch I think I will go ahead and implement this in stages, one for each compiler. That way I will minimize the scope of the adverse fallout from any mistakes I might make.
> [gcc] use math __builtins
> -------------------------
>
> Key: STDCXX-722
> URL: https://issues.apache.org/jira/browse/STDCXX-722
> Project: C++ Standard Library
> Issue Type: Sub-task
> Components: 26. Numerics
> Affects Versions: 4.2.0
> Environment: gcc 4
> Reporter: Martin Sebor
> Assignee: Martin Sebor
> Priority: Minor
> Fix For: 4.2.1
>
> Attachments: stdcxx-722.diff, stdcxx-722.log
>
> Original Estimate: 2h
> Time Spent: 4h
> Remaining Estimate: 0h
>
> For better efficiency and to reduce namespace pollution we can replace all the math functions used in [<complex>|http://svn.apache.org/repos/asf/stdcxx/trunk/include/complex] with gcc's built-in equivalents.
> Quoting from section [5.46 Other built-in functions provided by GCC|http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Other-Builtins.html#Other-Builtins] of the gcc online manual:
> {quote}
> The ISO C99 functions {{_Exit}}, {{acoshf}}, {{acoshl}}, {{acosh}}, {{asinhf}}, {{asinhl}}, {{asinh}}, {{atanhf}}, {{atanhl}}, {{atanh}}, {{cabsf}}, {{cabsl}}, {{cabs}}, {{cacosf}}, {{cacoshf}}, {{cacoshl}}, {{cacosh}}, {{cacosl}}, {{cacos}}, {{cargf}}, {{cargl}}, {{carg}}, {{casinf}}, {{casinhf}}, {{casinhl}}, {{casinh}}, {{casinl}}, {{casin}}, {{catanf}}, {{catanhf}}, {{catanhl}}, {{catanh}}, {{catanl}}, {{catan}}, {{cbrtf}}, {{cbrtl}}, {{cbrt}}, {{ccosf}}, {{ccoshf}}, {{ccoshl}}, {{ccosh}}, {{ccosl}}, {{ccos}}, {{cexpf}}, {{cexpl}}, {{cexp}}, {{cimagf}}, {{cimagl}}, {{cimag}}, {{clogf}}, {{clogl}}, {{clog}}, {{conjf}}, {{conjl}}, {{conj}}, {{copysignf}}, {{copysignl}}, {{copysign}}, {{cpowf}}, {{cpowl}}, {{cpow}}, {{cprojf}}, {{cprojl}}, {{cproj}}, {{crealf}}, {{creall}}, {{creal}}, {{csinf}}, {{csinhf}}, {{csinhl}}, {{csinh}}, {{csinl}}, {{csin}}, {{csqrtf}}, {{csqrtl}}, {{csqrt}}, {{ctanf}}, {{ctanhf}}, {{ctanhl}}, {{ctanh}}, {{ctanl}}, {{ctan}}, {{erfcf}}, {{erfcl}}, {{erfc}}, {{erff}}, {{erfl}}, {{erf}}, {{exp2f}}, {{exp2l}}, {{exp2}}, {{expm1f}}, {{expm1l}}, {{expm1}}, {{fdimf}}, {{fdiml}}, {{fdim}}, {{fmaf}}, {{fmal}}, {{fmaxf}}, {{fmaxl}}, {{fmax}}, {{fma}}, {{fminf}}, {{fminl}}, {{fmin}}, {{hypotf}}, {{hypotl}}, {{hypot}}, {{ilogbf}}, {{ilogbl}}, {{ilogb}}, {{imaxabs}}, {{isblank}}, {{iswblank}}, {{lgammaf}}, {{lgammal}}, {{lgamma}}, {{llabs}}, {{llrintf}}, {{llrintl}}, {{llrint}}, {{llroundf}}, {{llroundl}}, {{llround}}, {{log1pf}}, {{log1pl}}, {{log1p}}, {{log2f}}, {{log2l}}, {{log2}}, {{logbf}}, {{logbl}}, {{logb}}, {{lrintf}}, {{lrintl}}, {{lrint}}, {{lroundf}}, {{lroundl}}, {{lround}}, {{nearbyintf}}, {{nearbyintl}}, {{nearbyint}}, {{nextafterf}}, {{nextafterl}}, {{nextafter}}, {{nexttowardf}}, {{nexttowardl}}, {{nexttoward}}, {{remainderf}}, {{remainderl}}, {{remainder}}, {{remquof}}, {{remquol}}, {{remquo}}, {{rintf}}, {{rintl}}, {{rint}}, {{roundf}}, {{roundl}}, {{round}}, {{scalblnf}}, {{scalblnl}}, {{scalbln}}, {{scalbnf}}, {{scalbnl}}, {{scalbn}}, {{snprintf}}, {{tgammaf}}, {{tgammal}}, {{tgamma}}, {{truncf}}, {{truncl}}, {{trunc}}, {{vfscanf}}, {{vscanf}}, {{vsnprintf}} and {{vsscanf}} are handled as built-in functions except in strict ISO C90 mode ({{-ansi}} or {{-std=c89}}).
> There are also built-in versions of the ISO C99 functions {{acosf}}, {{acosl}}, {{asinf}}, {{asinl}}, {{atan2f}}, {{atan2l}}, {{atanf}}, {{atanl}}, {{ceilf}}, {{ceill}}, {{cosf}}, {{coshf}}, {{coshl}}, {{cosl}}, {{expf}}, {{expl}}, {{fabsf}}, {{fabsl}}, {{floorf}}, {{floorl}}, {{fmodf}}, {{fmodl}}, {{frexpf}}, {{frexpl}}, {{ldexpf}}, {{ldexpl}}, {{log10f}}, {{log10l}}, {{logf}}, {{logl}}, {{modfl}}, {{modf}}, {{powf}}, {{powl}}, {{sinf}}, {{sinhf}}, {{sinhl}}, {{sinl}}, {{sqrtf}}, {{sqrtl}}, {{tanf}}, {{tanhf}}, {{tanhl}} and {{tanl}} that are recognized in any mode since ISO C90 reserves these names for the purpose to which ISO C99 puts them. All these functions have corresponding versions prefixed with {{__builtin_}}.
> {quote}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-722) [gcc] use math __builtins
Posted by "Martin Sebor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/STDCXX-722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Sebor updated STDCXX-722:
--------------------------------
Remaining Estimate: 2h (was: 0h)
Still about 2 hours worth of work left on this.
> [gcc] use math __builtins
> -------------------------
>
> Key: STDCXX-722
> URL: https://issues.apache.org/jira/browse/STDCXX-722
> Project: C++ Standard Library
> Issue Type: Sub-task
> Components: 26. Numerics
> Affects Versions: 4.2.0
> Environment: gcc 4
> Reporter: Martin Sebor
> Assignee: Martin Sebor
> Priority: Minor
> Fix For: 4.2.1
>
> Attachments: stdcxx-722.diff, stdcxx-722.log
>
> Original Estimate: 2h
> Time Spent: 4h
> Remaining Estimate: 2h
>
> For better efficiency and to reduce namespace pollution we can replace all the math functions used in [<complex>|http://svn.apache.org/repos/asf/stdcxx/trunk/include/complex] with gcc's built-in equivalents.
> Quoting from section [5.46 Other built-in functions provided by GCC|http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Other-Builtins.html#Other-Builtins] of the gcc online manual:
> {quote}
> The ISO C99 functions {{_Exit}}, {{acoshf}}, {{acoshl}}, {{acosh}}, {{asinhf}}, {{asinhl}}, {{asinh}}, {{atanhf}}, {{atanhl}}, {{atanh}}, {{cabsf}}, {{cabsl}}, {{cabs}}, {{cacosf}}, {{cacoshf}}, {{cacoshl}}, {{cacosh}}, {{cacosl}}, {{cacos}}, {{cargf}}, {{cargl}}, {{carg}}, {{casinf}}, {{casinhf}}, {{casinhl}}, {{casinh}}, {{casinl}}, {{casin}}, {{catanf}}, {{catanhf}}, {{catanhl}}, {{catanh}}, {{catanl}}, {{catan}}, {{cbrtf}}, {{cbrtl}}, {{cbrt}}, {{ccosf}}, {{ccoshf}}, {{ccoshl}}, {{ccosh}}, {{ccosl}}, {{ccos}}, {{cexpf}}, {{cexpl}}, {{cexp}}, {{cimagf}}, {{cimagl}}, {{cimag}}, {{clogf}}, {{clogl}}, {{clog}}, {{conjf}}, {{conjl}}, {{conj}}, {{copysignf}}, {{copysignl}}, {{copysign}}, {{cpowf}}, {{cpowl}}, {{cpow}}, {{cprojf}}, {{cprojl}}, {{cproj}}, {{crealf}}, {{creall}}, {{creal}}, {{csinf}}, {{csinhf}}, {{csinhl}}, {{csinh}}, {{csinl}}, {{csin}}, {{csqrtf}}, {{csqrtl}}, {{csqrt}}, {{ctanf}}, {{ctanhf}}, {{ctanhl}}, {{ctanh}}, {{ctanl}}, {{ctan}}, {{erfcf}}, {{erfcl}}, {{erfc}}, {{erff}}, {{erfl}}, {{erf}}, {{exp2f}}, {{exp2l}}, {{exp2}}, {{expm1f}}, {{expm1l}}, {{expm1}}, {{fdimf}}, {{fdiml}}, {{fdim}}, {{fmaf}}, {{fmal}}, {{fmaxf}}, {{fmaxl}}, {{fmax}}, {{fma}}, {{fminf}}, {{fminl}}, {{fmin}}, {{hypotf}}, {{hypotl}}, {{hypot}}, {{ilogbf}}, {{ilogbl}}, {{ilogb}}, {{imaxabs}}, {{isblank}}, {{iswblank}}, {{lgammaf}}, {{lgammal}}, {{lgamma}}, {{llabs}}, {{llrintf}}, {{llrintl}}, {{llrint}}, {{llroundf}}, {{llroundl}}, {{llround}}, {{log1pf}}, {{log1pl}}, {{log1p}}, {{log2f}}, {{log2l}}, {{log2}}, {{logbf}}, {{logbl}}, {{logb}}, {{lrintf}}, {{lrintl}}, {{lrint}}, {{lroundf}}, {{lroundl}}, {{lround}}, {{nearbyintf}}, {{nearbyintl}}, {{nearbyint}}, {{nextafterf}}, {{nextafterl}}, {{nextafter}}, {{nexttowardf}}, {{nexttowardl}}, {{nexttoward}}, {{remainderf}}, {{remainderl}}, {{remainder}}, {{remquof}}, {{remquol}}, {{remquo}}, {{rintf}}, {{rintl}}, {{rint}}, {{roundf}}, {{roundl}}, {{round}}, {{scalblnf}}, {{scalblnl}}, {{scalbln}}, {{scalbnf}}, {{scalbnl}}, {{scalbn}}, {{snprintf}}, {{tgammaf}}, {{tgammal}}, {{tgamma}}, {{truncf}}, {{truncl}}, {{trunc}}, {{vfscanf}}, {{vscanf}}, {{vsnprintf}} and {{vsscanf}} are handled as built-in functions except in strict ISO C90 mode ({{-ansi}} or {{-std=c89}}).
> There are also built-in versions of the ISO C99 functions {{acosf}}, {{acosl}}, {{asinf}}, {{asinl}}, {{atan2f}}, {{atan2l}}, {{atanf}}, {{atanl}}, {{ceilf}}, {{ceill}}, {{cosf}}, {{coshf}}, {{coshl}}, {{cosl}}, {{expf}}, {{expl}}, {{fabsf}}, {{fabsl}}, {{floorf}}, {{floorl}}, {{fmodf}}, {{fmodl}}, {{frexpf}}, {{frexpl}}, {{ldexpf}}, {{ldexpl}}, {{log10f}}, {{log10l}}, {{logf}}, {{logl}}, {{modfl}}, {{modf}}, {{powf}}, {{powl}}, {{sinf}}, {{sinhf}}, {{sinhl}}, {{sinl}}, {{sqrtf}}, {{sqrtl}}, {{tanf}}, {{tanhf}}, {{tanhl}} and {{tanl}} that are recognized in any mode since ISO C90 reserves these names for the purpose to which ISO C99 puts them. All these functions have corresponding versions prefixed with {{__builtin_}}.
> {quote}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-722) [gcc] use math __builtins
Posted by "Martin Sebor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/STDCXX-722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Sebor updated STDCXX-722:
--------------------------------
Attachment: stdcxx-722.log
Attached ChangeLog.
> [gcc] use math __builtins
> -------------------------
>
> Key: STDCXX-722
> URL: https://issues.apache.org/jira/browse/STDCXX-722
> Project: C++ Standard Library
> Issue Type: Sub-task
> Components: 26. Numerics
> Affects Versions: 4.2.0
> Environment: gcc 4
> Reporter: Martin Sebor
> Assignee: Martin Sebor
> Priority: Minor
> Fix For: 4.2.1
>
> Attachments: stdcxx-722.diff, stdcxx-722.log
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> For better efficiency and to reduce namespace pollution we can replace all the math functions used in [<complex>|http://svn.apache.org/repos/asf/stdcxx/trunk/include/complex] with gcc's built-in equivalents.
> Quoting from section [5.46 Other built-in functions provided by GCC|http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Other-Builtins.html#Other-Builtins] of the gcc online manual:
> {quote}
> The ISO C99 functions {{_Exit}}, {{acoshf}}, {{acoshl}}, {{acosh}}, {{asinhf}}, {{asinhl}}, {{asinh}}, {{atanhf}}, {{atanhl}}, {{atanh}}, {{cabsf}}, {{cabsl}}, {{cabs}}, {{cacosf}}, {{cacoshf}}, {{cacoshl}}, {{cacosh}}, {{cacosl}}, {{cacos}}, {{cargf}}, {{cargl}}, {{carg}}, {{casinf}}, {{casinhf}}, {{casinhl}}, {{casinh}}, {{casinl}}, {{casin}}, {{catanf}}, {{catanhf}}, {{catanhl}}, {{catanh}}, {{catanl}}, {{catan}}, {{cbrtf}}, {{cbrtl}}, {{cbrt}}, {{ccosf}}, {{ccoshf}}, {{ccoshl}}, {{ccosh}}, {{ccosl}}, {{ccos}}, {{cexpf}}, {{cexpl}}, {{cexp}}, {{cimagf}}, {{cimagl}}, {{cimag}}, {{clogf}}, {{clogl}}, {{clog}}, {{conjf}}, {{conjl}}, {{conj}}, {{copysignf}}, {{copysignl}}, {{copysign}}, {{cpowf}}, {{cpowl}}, {{cpow}}, {{cprojf}}, {{cprojl}}, {{cproj}}, {{crealf}}, {{creall}}, {{creal}}, {{csinf}}, {{csinhf}}, {{csinhl}}, {{csinh}}, {{csinl}}, {{csin}}, {{csqrtf}}, {{csqrtl}}, {{csqrt}}, {{ctanf}}, {{ctanhf}}, {{ctanhl}}, {{ctanh}}, {{ctanl}}, {{ctan}}, {{erfcf}}, {{erfcl}}, {{erfc}}, {{erff}}, {{erfl}}, {{erf}}, {{exp2f}}, {{exp2l}}, {{exp2}}, {{expm1f}}, {{expm1l}}, {{expm1}}, {{fdimf}}, {{fdiml}}, {{fdim}}, {{fmaf}}, {{fmal}}, {{fmaxf}}, {{fmaxl}}, {{fmax}}, {{fma}}, {{fminf}}, {{fminl}}, {{fmin}}, {{hypotf}}, {{hypotl}}, {{hypot}}, {{ilogbf}}, {{ilogbl}}, {{ilogb}}, {{imaxabs}}, {{isblank}}, {{iswblank}}, {{lgammaf}}, {{lgammal}}, {{lgamma}}, {{llabs}}, {{llrintf}}, {{llrintl}}, {{llrint}}, {{llroundf}}, {{llroundl}}, {{llround}}, {{log1pf}}, {{log1pl}}, {{log1p}}, {{log2f}}, {{log2l}}, {{log2}}, {{logbf}}, {{logbl}}, {{logb}}, {{lrintf}}, {{lrintl}}, {{lrint}}, {{lroundf}}, {{lroundl}}, {{lround}}, {{nearbyintf}}, {{nearbyintl}}, {{nearbyint}}, {{nextafterf}}, {{nextafterl}}, {{nextafter}}, {{nexttowardf}}, {{nexttowardl}}, {{nexttoward}}, {{remainderf}}, {{remainderl}}, {{remainder}}, {{remquof}}, {{remquol}}, {{remquo}}, {{rintf}}, {{rintl}}, {{rint}}, {{roundf}}, {{roundl}}, {{round}}, {{scalblnf}}, {{scalblnl}}, {{scalbln}}, {{scalbnf}}, {{scalbnl}}, {{scalbn}}, {{snprintf}}, {{tgammaf}}, {{tgammal}}, {{tgamma}}, {{truncf}}, {{truncl}}, {{trunc}}, {{vfscanf}}, {{vscanf}}, {{vsnprintf}} and {{vsscanf}} are handled as built-in functions except in strict ISO C90 mode ({{-ansi}} or {{-std=c89}}).
> There are also built-in versions of the ISO C99 functions {{acosf}}, {{acosl}}, {{asinf}}, {{asinl}}, {{atan2f}}, {{atan2l}}, {{atanf}}, {{atanl}}, {{ceilf}}, {{ceill}}, {{cosf}}, {{coshf}}, {{coshl}}, {{cosl}}, {{expf}}, {{expl}}, {{fabsf}}, {{fabsl}}, {{floorf}}, {{floorl}}, {{fmodf}}, {{fmodl}}, {{frexpf}}, {{frexpl}}, {{ldexpf}}, {{ldexpl}}, {{log10f}}, {{log10l}}, {{logf}}, {{logl}}, {{modfl}}, {{modf}}, {{powf}}, {{powl}}, {{sinf}}, {{sinhf}}, {{sinhl}}, {{sinl}}, {{sqrtf}}, {{sqrtl}}, {{tanf}}, {{tanhf}}, {{tanhl}} and {{tanl}} that are recognized in any mode since ISO C90 reserves these names for the purpose to which ISO C99 puts them. All these functions have corresponding versions prefixed with {{__builtin_}}.
> {quote}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (STDCXX-722) [gcc] use math __builtins
Posted by "Martin Sebor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/STDCXX-722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Martin Sebor updated STDCXX-722:
--------------------------------
Component/s: 26. Numerics
Description:
For better efficiency and to reduce namespace pollution we can replace all the math functions used in [<complex>|http://svn.apache.org/repos/asf/stdcxx/trunk/include/complex] with gcc's built-in equivalents.
Quoting from section [5.46 Other built-in functions provided by GCC|http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Other-Builtins.html#Other-Builtins] of the gcc online manual:
{quote}
The ISO C99 functions {{_Exit}}, {{acoshf}}, {{acoshl}}, {{acosh}}, {{asinhf}}, {{asinhl}}, {{asinh}}, {{atanhf}}, {{atanhl}}, {{atanh}}, {{cabsf}}, {{cabsl}}, {{cabs}}, {{cacosf}}, {{cacoshf}}, {{cacoshl}}, {{cacosh}}, {{cacosl}}, {{cacos}}, {{cargf}}, {{cargl}}, {{carg}}, {{casinf}}, {{casinhf}}, {{casinhl}}, {{casinh}}, {{casinl}}, {{casin}}, {{catanf}}, {{catanhf}}, {{catanhl}}, {{catanh}}, {{catanl}}, {{catan}}, {{cbrtf}}, {{cbrtl}}, {{cbrt}}, {{ccosf}}, {{ccoshf}}, {{ccoshl}}, {{ccosh}}, {{ccosl}}, {{ccos}}, {{cexpf}}, {{cexpl}}, {{cexp}}, {{cimagf}}, {{cimagl}}, {{cimag}}, {{clogf}}, {{clogl}}, {{clog}}, {{conjf}}, {{conjl}}, {{conj}}, {{copysignf}}, {{copysignl}}, {{copysign}}, {{cpowf}}, {{cpowl}}, {{cpow}}, {{cprojf}}, {{cprojl}}, {{cproj}}, {{crealf}}, {{creall}}, {{creal}}, {{csinf}}, {{csinhf}}, {{csinhl}}, {{csinh}}, {{csinl}}, {{csin}}, {{csqrtf}}, {{csqrtl}}, {{csqrt}}, {{ctanf}}, {{ctanhf}}, {{ctanhl}}, {{ctanh}}, {{ctanl}}, {{ctan}}, {{erfcf}}, {{erfcl}}, {{erfc}}, {{erff}}, {{erfl}}, {{erf}}, {{exp2f}}, {{exp2l}}, {{exp2}}, {{expm1f}}, {{expm1l}}, {{expm1}}, {{fdimf}}, {{fdiml}}, {{fdim}}, {{fmaf}}, {{fmal}}, {{fmaxf}}, {{fmaxl}}, {{fmax}}, {{fma}}, {{fminf}}, {{fminl}}, {{fmin}}, {{hypotf}}, {{hypotl}}, {{hypot}}, {{ilogbf}}, {{ilogbl}}, {{ilogb}}, {{imaxabs}}, {{isblank}}, {{iswblank}}, {{lgammaf}}, {{lgammal}}, {{lgamma}}, {{llabs}}, {{llrintf}}, {{llrintl}}, {{llrint}}, {{llroundf}}, {{llroundl}}, {{llround}}, {{log1pf}}, {{log1pl}}, {{log1p}}, {{log2f}}, {{log2l}}, {{log2}}, {{logbf}}, {{logbl}}, {{logb}}, {{lrintf}}, {{lrintl}}, {{lrint}}, {{lroundf}}, {{lroundl}}, {{lround}}, {{nearbyintf}}, {{nearbyintl}}, {{nearbyint}}, {{nextafterf}}, {{nextafterl}}, {{nextafter}}, {{nexttowardf}}, {{nexttowardl}}, {{nexttoward}}, {{remainderf}}, {{remainderl}}, {{remainder}}, {{remquof}}, {{remquol}}, {{remquo}}, {{rintf}}, {{rintl}}, {{rint}}, {{roundf}}, {{roundl}}, {{round}}, {{scalblnf}}, {{scalblnl}}, {{scalbln}}, {{scalbnf}}, {{scalbnl}}, {{scalbn}}, {{snprintf}}, {{tgammaf}}, {{tgammal}}, {{tgamma}}, {{truncf}}, {{truncl}}, {{trunc}}, {{vfscanf}}, {{vscanf}}, {{vsnprintf}} and {{vsscanf}} are handled as built-in functions except in strict ISO C90 mode ({{-ansi}} or {{-std=c89}}).
There are also built-in versions of the ISO C99 functions {{acosf}}, {{acosl}}, {{asinf}}, {{asinl}}, {{atan2f}}, {{atan2l}}, {{atanf}}, {{atanl}}, {{ceilf}}, {{ceill}}, {{cosf}}, {{coshf}}, {{coshl}}, {{cosl}}, {{expf}}, {{expl}}, {{fabsf}}, {{fabsl}}, {{floorf}}, {{floorl}}, {{fmodf}}, {{fmodl}}, {{frexpf}}, {{frexpl}}, {{ldexpf}}, {{ldexpl}}, {{log10f}}, {{log10l}}, {{logf}}, {{logl}}, {{modfl}}, {{modf}}, {{powf}}, {{powl}}, {{sinf}}, {{sinhf}}, {{sinhl}}, {{sinl}}, {{sqrtf}}, {{sqrtl}}, {{tanf}}, {{tanhf}}, {{tanhl}} and {{tanl}} that are recognized in any mode since ISO C90 reserves these names for the purpose to which ISO C99 puts them. All these functions have corresponding versions prefixed with {{__builtin_}}.
{quote}
Priority: Minor (was: Major)
Environment: gcc 4
Affects Version/s: 4.2.0
Fix Version/s: 4.2.1
Remaining Estimate: 2h
Original Estimate: 2h
> [gcc] use math __builtins
> -------------------------
>
> Key: STDCXX-722
> URL: https://issues.apache.org/jira/browse/STDCXX-722
> Project: C++ Standard Library
> Issue Type: Sub-task
> Components: 26. Numerics
> Affects Versions: 4.2.0
> Environment: gcc 4
> Reporter: Martin Sebor
> Assignee: Martin Sebor
> Priority: Minor
> Fix For: 4.2.1
>
> Original Estimate: 2h
> Remaining Estimate: 2h
>
> For better efficiency and to reduce namespace pollution we can replace all the math functions used in [<complex>|http://svn.apache.org/repos/asf/stdcxx/trunk/include/complex] with gcc's built-in equivalents.
> Quoting from section [5.46 Other built-in functions provided by GCC|http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Other-Builtins.html#Other-Builtins] of the gcc online manual:
> {quote}
> The ISO C99 functions {{_Exit}}, {{acoshf}}, {{acoshl}}, {{acosh}}, {{asinhf}}, {{asinhl}}, {{asinh}}, {{atanhf}}, {{atanhl}}, {{atanh}}, {{cabsf}}, {{cabsl}}, {{cabs}}, {{cacosf}}, {{cacoshf}}, {{cacoshl}}, {{cacosh}}, {{cacosl}}, {{cacos}}, {{cargf}}, {{cargl}}, {{carg}}, {{casinf}}, {{casinhf}}, {{casinhl}}, {{casinh}}, {{casinl}}, {{casin}}, {{catanf}}, {{catanhf}}, {{catanhl}}, {{catanh}}, {{catanl}}, {{catan}}, {{cbrtf}}, {{cbrtl}}, {{cbrt}}, {{ccosf}}, {{ccoshf}}, {{ccoshl}}, {{ccosh}}, {{ccosl}}, {{ccos}}, {{cexpf}}, {{cexpl}}, {{cexp}}, {{cimagf}}, {{cimagl}}, {{cimag}}, {{clogf}}, {{clogl}}, {{clog}}, {{conjf}}, {{conjl}}, {{conj}}, {{copysignf}}, {{copysignl}}, {{copysign}}, {{cpowf}}, {{cpowl}}, {{cpow}}, {{cprojf}}, {{cprojl}}, {{cproj}}, {{crealf}}, {{creall}}, {{creal}}, {{csinf}}, {{csinhf}}, {{csinhl}}, {{csinh}}, {{csinl}}, {{csin}}, {{csqrtf}}, {{csqrtl}}, {{csqrt}}, {{ctanf}}, {{ctanhf}}, {{ctanhl}}, {{ctanh}}, {{ctanl}}, {{ctan}}, {{erfcf}}, {{erfcl}}, {{erfc}}, {{erff}}, {{erfl}}, {{erf}}, {{exp2f}}, {{exp2l}}, {{exp2}}, {{expm1f}}, {{expm1l}}, {{expm1}}, {{fdimf}}, {{fdiml}}, {{fdim}}, {{fmaf}}, {{fmal}}, {{fmaxf}}, {{fmaxl}}, {{fmax}}, {{fma}}, {{fminf}}, {{fminl}}, {{fmin}}, {{hypotf}}, {{hypotl}}, {{hypot}}, {{ilogbf}}, {{ilogbl}}, {{ilogb}}, {{imaxabs}}, {{isblank}}, {{iswblank}}, {{lgammaf}}, {{lgammal}}, {{lgamma}}, {{llabs}}, {{llrintf}}, {{llrintl}}, {{llrint}}, {{llroundf}}, {{llroundl}}, {{llround}}, {{log1pf}}, {{log1pl}}, {{log1p}}, {{log2f}}, {{log2l}}, {{log2}}, {{logbf}}, {{logbl}}, {{logb}}, {{lrintf}}, {{lrintl}}, {{lrint}}, {{lroundf}}, {{lroundl}}, {{lround}}, {{nearbyintf}}, {{nearbyintl}}, {{nearbyint}}, {{nextafterf}}, {{nextafterl}}, {{nextafter}}, {{nexttowardf}}, {{nexttowardl}}, {{nexttoward}}, {{remainderf}}, {{remainderl}}, {{remainder}}, {{remquof}}, {{remquol}}, {{remquo}}, {{rintf}}, {{rintl}}, {{rint}}, {{roundf}}, {{roundl}}, {{round}}, {{scalblnf}}, {{scalblnl}}, {{scalbln}}, {{scalbnf}}, {{scalbnl}}, {{scalbn}}, {{snprintf}}, {{tgammaf}}, {{tgammal}}, {{tgamma}}, {{truncf}}, {{truncl}}, {{trunc}}, {{vfscanf}}, {{vscanf}}, {{vsnprintf}} and {{vsscanf}} are handled as built-in functions except in strict ISO C90 mode ({{-ansi}} or {{-std=c89}}).
> There are also built-in versions of the ISO C99 functions {{acosf}}, {{acosl}}, {{asinf}}, {{asinl}}, {{atan2f}}, {{atan2l}}, {{atanf}}, {{atanl}}, {{ceilf}}, {{ceill}}, {{cosf}}, {{coshf}}, {{coshl}}, {{cosl}}, {{expf}}, {{expl}}, {{fabsf}}, {{fabsl}}, {{floorf}}, {{floorl}}, {{fmodf}}, {{fmodl}}, {{frexpf}}, {{frexpl}}, {{ldexpf}}, {{ldexpl}}, {{log10f}}, {{log10l}}, {{logf}}, {{logl}}, {{modfl}}, {{modf}}, {{powf}}, {{powl}}, {{sinf}}, {{sinhf}}, {{sinhl}}, {{sinl}}, {{sqrtf}}, {{sqrtl}}, {{tanf}}, {{tanhf}}, {{tanhl}} and {{tanl}} that are recognized in any mode since ISO C90 reserves these names for the purpose to which ISO C99 puts them. All these functions have corresponding versions prefixed with {{__builtin_}}.
> {quote}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (STDCXX-722) [gcc] use math __builtins
Posted by "Martin Sebor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/STDCXX-722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12570476#action_12570476 ]
sebor edited comment on STDCXX-722 at 3/28/08 7:59 AM:
--------------------------------------------------------------
Thanks for the comments!
Yes, moving the new macros to a common header is probably a good idea. Although I'm not sure we should make the corresponding changes to {{valarray}} before I commit the (binary incompatible) rewrite to it that's been sitting on my hard drive for months and months now.
I'm not sure the {{complex}} ctors I added are a good thing since they might introduce undesirable matches into the overload set in user code, but if we keep them they can't be guarded with an {{\_RWSTD_NO_EXT_}} macro because all the new specializations of the {{complex}} non-member functions depend on them and wouldn't compile without them.
I think that at least in theory a compiler is allowed to insert padding after each of the members of {{struct { float a, b; };}} so you're right, there is no guarantee that such a struct would be laid out the same way as an array of 2 floats. I don't believe any of our compilers inserts such padding but we should check to be 100% sure. If none does, we might want to consider changing {{complex}} to declare an array of data members rather than individual data subobjects to prevent future compilers from doing so.
Lastly, thanks for the pointer to the IBM docs! I agree that we should take advantage of these features wherever they are available. Rather than doing so in the same patch I think I will go ahead and implement this in stages, one for each compiler. That way I will minimize the scope of the adverse fallout from any mistakes I might make.
was (Author: sebor):
Thanks for the comments!
Yes, moving the new macros to a common header is probably a good idea. Although I'm not sure we should make the corresponding changes to {{valarray}} before I commit the (binary incompatible) rewrite to it that's been sitting on my hard drive for months and months now.
I'm not sure the {{complex}} ctors I added are a good thing since they might introduce undesirable matches into the overload set in user code, but if we keep them they can't be guarded with an {{_RWSTD_NO_EXT_}} macro because all the new specializations of the {{complex}} non-member functions depend on them and wouldn't compile without them.
I think that at least in theory a compiler is allowed to insert padding after each of the members of {{struct { float a, b; };}} so you're right, there is no guarantee that such a struct would be laid out the same way as an array of 2 floats. I don't believe any of our compilers inserts such padding but we should check to be 100% sure. If none does, we might want to consider changing {{complex}} to declare an array of data members rather than individual data subobjects to prevent future compilers from doing so.
Lastly, thanks for the pointer to the IBM docs! I agree that we should take advantage of these features wherever they are available. Rather than doing so in the same patch I think I will go ahead and implement this in stages, one for each compiler. That way I will minimize the scope of the adverse fallout from any mistakes I might make.
> [gcc] use math __builtins
> -------------------------
>
> Key: STDCXX-722
> URL: https://issues.apache.org/jira/browse/STDCXX-722
> Project: C++ Standard Library
> Issue Type: Sub-task
> Components: 26. Numerics
> Affects Versions: 4.2.0
> Environment: gcc 4
> Reporter: Martin Sebor
> Assignee: Martin Sebor
> Priority: Minor
> Fix For: 4.2.1
>
> Attachments: stdcxx-722.diff, stdcxx-722.log
>
> Original Estimate: 2h
> Time Spent: 4h
> Remaining Estimate: 2h
>
> For better efficiency and to reduce namespace pollution we can replace all the math functions used in [<complex>|http://svn.apache.org/repos/asf/stdcxx/trunk/include/complex] with gcc's built-in equivalents.
> Quoting from section [5.46 Other built-in functions provided by GCC|http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Other-Builtins.html#Other-Builtins] of the gcc online manual:
> {quote}
> The ISO C99 functions {{_Exit}}, {{acoshf}}, {{acoshl}}, {{acosh}}, {{asinhf}}, {{asinhl}}, {{asinh}}, {{atanhf}}, {{atanhl}}, {{atanh}}, {{cabsf}}, {{cabsl}}, {{cabs}}, {{cacosf}}, {{cacoshf}}, {{cacoshl}}, {{cacosh}}, {{cacosl}}, {{cacos}}, {{cargf}}, {{cargl}}, {{carg}}, {{casinf}}, {{casinhf}}, {{casinhl}}, {{casinh}}, {{casinl}}, {{casin}}, {{catanf}}, {{catanhf}}, {{catanhl}}, {{catanh}}, {{catanl}}, {{catan}}, {{cbrtf}}, {{cbrtl}}, {{cbrt}}, {{ccosf}}, {{ccoshf}}, {{ccoshl}}, {{ccosh}}, {{ccosl}}, {{ccos}}, {{cexpf}}, {{cexpl}}, {{cexp}}, {{cimagf}}, {{cimagl}}, {{cimag}}, {{clogf}}, {{clogl}}, {{clog}}, {{conjf}}, {{conjl}}, {{conj}}, {{copysignf}}, {{copysignl}}, {{copysign}}, {{cpowf}}, {{cpowl}}, {{cpow}}, {{cprojf}}, {{cprojl}}, {{cproj}}, {{crealf}}, {{creall}}, {{creal}}, {{csinf}}, {{csinhf}}, {{csinhl}}, {{csinh}}, {{csinl}}, {{csin}}, {{csqrtf}}, {{csqrtl}}, {{csqrt}}, {{ctanf}}, {{ctanhf}}, {{ctanhl}}, {{ctanh}}, {{ctanl}}, {{ctan}}, {{erfcf}}, {{erfcl}}, {{erfc}}, {{erff}}, {{erfl}}, {{erf}}, {{exp2f}}, {{exp2l}}, {{exp2}}, {{expm1f}}, {{expm1l}}, {{expm1}}, {{fdimf}}, {{fdiml}}, {{fdim}}, {{fmaf}}, {{fmal}}, {{fmaxf}}, {{fmaxl}}, {{fmax}}, {{fma}}, {{fminf}}, {{fminl}}, {{fmin}}, {{hypotf}}, {{hypotl}}, {{hypot}}, {{ilogbf}}, {{ilogbl}}, {{ilogb}}, {{imaxabs}}, {{isblank}}, {{iswblank}}, {{lgammaf}}, {{lgammal}}, {{lgamma}}, {{llabs}}, {{llrintf}}, {{llrintl}}, {{llrint}}, {{llroundf}}, {{llroundl}}, {{llround}}, {{log1pf}}, {{log1pl}}, {{log1p}}, {{log2f}}, {{log2l}}, {{log2}}, {{logbf}}, {{logbl}}, {{logb}}, {{lrintf}}, {{lrintl}}, {{lrint}}, {{lroundf}}, {{lroundl}}, {{lround}}, {{nearbyintf}}, {{nearbyintl}}, {{nearbyint}}, {{nextafterf}}, {{nextafterl}}, {{nextafter}}, {{nexttowardf}}, {{nexttowardl}}, {{nexttoward}}, {{remainderf}}, {{remainderl}}, {{remainder}}, {{remquof}}, {{remquol}}, {{remquo}}, {{rintf}}, {{rintl}}, {{rint}}, {{roundf}}, {{roundl}}, {{round}}, {{scalblnf}}, {{scalblnl}}, {{scalbln}}, {{scalbnf}}, {{scalbnl}}, {{scalbn}}, {{snprintf}}, {{tgammaf}}, {{tgammal}}, {{tgamma}}, {{truncf}}, {{truncl}}, {{trunc}}, {{vfscanf}}, {{vscanf}}, {{vsnprintf}} and {{vsscanf}} are handled as built-in functions except in strict ISO C90 mode ({{-ansi}} or {{-std=c89}}).
> There are also built-in versions of the ISO C99 functions {{acosf}}, {{acosl}}, {{asinf}}, {{asinl}}, {{atan2f}}, {{atan2l}}, {{atanf}}, {{atanl}}, {{ceilf}}, {{ceill}}, {{cosf}}, {{coshf}}, {{coshl}}, {{cosl}}, {{expf}}, {{expl}}, {{fabsf}}, {{fabsl}}, {{floorf}}, {{floorl}}, {{fmodf}}, {{fmodl}}, {{frexpf}}, {{frexpl}}, {{ldexpf}}, {{ldexpl}}, {{log10f}}, {{log10l}}, {{logf}}, {{logl}}, {{modfl}}, {{modf}}, {{powf}}, {{powl}}, {{sinf}}, {{sinhf}}, {{sinhl}}, {{sinl}}, {{sqrtf}}, {{sqrtl}}, {{tanf}}, {{tanhf}}, {{tanhl}} and {{tanl}} that are recognized in any mode since ISO C90 reserves these names for the purpose to which ISO C99 puts them. All these functions have corresponding versions prefixed with {{__builtin_}}.
> {quote}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (STDCXX-722) [gcc] use math __builtins
Posted by "Martin Sebor (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/STDCXX-722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12567913#action_12567913 ]
Martin Sebor commented on STDCXX-722:
-------------------------------------
The attached patch implements the full solution, i.e., it provides explicit specializations for most of the C++ 1998 primary functions template that call the corresponding gcc built-ins. A test that exercises both the primary templates and the specializations (when they exist) still needs to be added.
> [gcc] use math __builtins
> -------------------------
>
> Key: STDCXX-722
> URL: https://issues.apache.org/jira/browse/STDCXX-722
> Project: C++ Standard Library
> Issue Type: Sub-task
> Components: 26. Numerics
> Affects Versions: 4.2.0
> Environment: gcc 4
> Reporter: Martin Sebor
> Assignee: Martin Sebor
> Priority: Minor
> Fix For: 4.2.1
>
> Attachments: stdcxx-722.diff, stdcxx-722.log
>
> Original Estimate: 2h
> Time Spent: 4h
> Remaining Estimate: 0h
>
> For better efficiency and to reduce namespace pollution we can replace all the math functions used in [<complex>|http://svn.apache.org/repos/asf/stdcxx/trunk/include/complex] with gcc's built-in equivalents.
> Quoting from section [5.46 Other built-in functions provided by GCC|http://gcc.gnu.org/onlinedocs/gcc-4.1.2/gcc/Other-Builtins.html#Other-Builtins] of the gcc online manual:
> {quote}
> The ISO C99 functions {{_Exit}}, {{acoshf}}, {{acoshl}}, {{acosh}}, {{asinhf}}, {{asinhl}}, {{asinh}}, {{atanhf}}, {{atanhl}}, {{atanh}}, {{cabsf}}, {{cabsl}}, {{cabs}}, {{cacosf}}, {{cacoshf}}, {{cacoshl}}, {{cacosh}}, {{cacosl}}, {{cacos}}, {{cargf}}, {{cargl}}, {{carg}}, {{casinf}}, {{casinhf}}, {{casinhl}}, {{casinh}}, {{casinl}}, {{casin}}, {{catanf}}, {{catanhf}}, {{catanhl}}, {{catanh}}, {{catanl}}, {{catan}}, {{cbrtf}}, {{cbrtl}}, {{cbrt}}, {{ccosf}}, {{ccoshf}}, {{ccoshl}}, {{ccosh}}, {{ccosl}}, {{ccos}}, {{cexpf}}, {{cexpl}}, {{cexp}}, {{cimagf}}, {{cimagl}}, {{cimag}}, {{clogf}}, {{clogl}}, {{clog}}, {{conjf}}, {{conjl}}, {{conj}}, {{copysignf}}, {{copysignl}}, {{copysign}}, {{cpowf}}, {{cpowl}}, {{cpow}}, {{cprojf}}, {{cprojl}}, {{cproj}}, {{crealf}}, {{creall}}, {{creal}}, {{csinf}}, {{csinhf}}, {{csinhl}}, {{csinh}}, {{csinl}}, {{csin}}, {{csqrtf}}, {{csqrtl}}, {{csqrt}}, {{ctanf}}, {{ctanhf}}, {{ctanhl}}, {{ctanh}}, {{ctanl}}, {{ctan}}, {{erfcf}}, {{erfcl}}, {{erfc}}, {{erff}}, {{erfl}}, {{erf}}, {{exp2f}}, {{exp2l}}, {{exp2}}, {{expm1f}}, {{expm1l}}, {{expm1}}, {{fdimf}}, {{fdiml}}, {{fdim}}, {{fmaf}}, {{fmal}}, {{fmaxf}}, {{fmaxl}}, {{fmax}}, {{fma}}, {{fminf}}, {{fminl}}, {{fmin}}, {{hypotf}}, {{hypotl}}, {{hypot}}, {{ilogbf}}, {{ilogbl}}, {{ilogb}}, {{imaxabs}}, {{isblank}}, {{iswblank}}, {{lgammaf}}, {{lgammal}}, {{lgamma}}, {{llabs}}, {{llrintf}}, {{llrintl}}, {{llrint}}, {{llroundf}}, {{llroundl}}, {{llround}}, {{log1pf}}, {{log1pl}}, {{log1p}}, {{log2f}}, {{log2l}}, {{log2}}, {{logbf}}, {{logbl}}, {{logb}}, {{lrintf}}, {{lrintl}}, {{lrint}}, {{lroundf}}, {{lroundl}}, {{lround}}, {{nearbyintf}}, {{nearbyintl}}, {{nearbyint}}, {{nextafterf}}, {{nextafterl}}, {{nextafter}}, {{nexttowardf}}, {{nexttowardl}}, {{nexttoward}}, {{remainderf}}, {{remainderl}}, {{remainder}}, {{remquof}}, {{remquol}}, {{remquo}}, {{rintf}}, {{rintl}}, {{rint}}, {{roundf}}, {{roundl}}, {{round}}, {{scalblnf}}, {{scalblnl}}, {{scalbln}}, {{scalbnf}}, {{scalbnl}}, {{scalbn}}, {{snprintf}}, {{tgammaf}}, {{tgammal}}, {{tgamma}}, {{truncf}}, {{truncl}}, {{trunc}}, {{vfscanf}}, {{vscanf}}, {{vsnprintf}} and {{vsscanf}} are handled as built-in functions except in strict ISO C90 mode ({{-ansi}} or {{-std=c89}}).
> There are also built-in versions of the ISO C99 functions {{acosf}}, {{acosl}}, {{asinf}}, {{asinl}}, {{atan2f}}, {{atan2l}}, {{atanf}}, {{atanl}}, {{ceilf}}, {{ceill}}, {{cosf}}, {{coshf}}, {{coshl}}, {{cosl}}, {{expf}}, {{expl}}, {{fabsf}}, {{fabsl}}, {{floorf}}, {{floorl}}, {{fmodf}}, {{fmodl}}, {{frexpf}}, {{frexpl}}, {{ldexpf}}, {{ldexpl}}, {{log10f}}, {{log10l}}, {{logf}}, {{logl}}, {{modfl}}, {{modf}}, {{powf}}, {{powl}}, {{sinf}}, {{sinhf}}, {{sinhl}}, {{sinl}}, {{sqrtf}}, {{sqrtl}}, {{tanf}}, {{tanhf}}, {{tanhl}} and {{tanl}} that are recognized in any mode since ISO C90 reserves these names for the purpose to which ISO C99 puts them. All these functions have corresponding versions prefixed with {{__builtin_}}.
> {quote}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.