[
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.
