stdcxx-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Martin Sebor (JIRA)" <>
Subject [jira] Commented: (STDCXX-722) [gcc] use math __builtins
Date Tue, 19 Feb 2008 22:12:43 GMT


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:
>             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>|] with
gcc's built-in  equivalents.
> Quoting from section [5.46 Other built-in functions provided by GCC|]
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.

View raw message