hardenedbsd/HardenedBSD
1
0
Fork 0
mirror of https://git.hardenedbsd.org/hardenedbsd/HardenedBSD.git synced 2024-11-10 20:31:27 +01:00
Code Issues Actions Packages Projects Releases Wiki Activity
c0da032159
HardenedBSD/include/tgmath.h

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

211 lines
8.8 KiB
C
Raw Normal View History

Implement C99's standard header <tgmath.h>. It provides type-generic macros for the <math.h> and <complex.h> functions that have float, double and long double implementations. Such type-generic macros expand to an actual function, depending on the types of the macro arguments, eg. if <tgmath.h> is included, the invocation cos(1.0f) calls the function cosf().
2004-08-08 22:05:47 +02:00
/*-
spdx: The BSD-2-Clause-FreeBSD identifier is obsolete, drop -FreeBSD The SPDX folks have obsoleted the BSD-2-Clause-FreeBSD identifier. Catch up to that fact and revert to their recommended match of BSD-2-Clause. Discussed with: pfg MFC After: 3 days Sponsored by: Netflix
2023-05-10 17:40:58 +02:00
* SPDX-License-Identifier: BSD-2-Clause
include: General further adoption of SPDX licensing ID tags. Mainly focus on files that use BSD 2-Clause license, however the tool I was using mis-identified many licenses so this was mostly a manual - error prone - task. The Software Package Data Exchange (SPDX) group provides a specification to make it easier for automated tools to detect and summarize well known opensource licenses. We are gradually adopting the specification, noting that the tags are considered only advisory and do not, in any way, superceed or replace the license texts.
2017-11-25 18:09:43 +01:00
*
Implement C99's standard header <tgmath.h>. It provides type-generic macros for the <math.h> and <complex.h> functions that have float, double and long double implementations. Such type-generic macros expand to an actual function, depending on the types of the macro arguments, eg. if <tgmath.h> is included, the invocation cos(1.0f) calls the function cosf().
2004-08-08 22:05:47 +02:00
* Copyright (c) 2004 Stefan Farfeleder.
* All rights reserved.
*
Reimplement <tgmath.h> on top of __generic(). The macro construction used now, is almost identical to the code provided in C11 proposal N1404. This new version doesn't seem to introduce any regressions according to the regression test in tools/, but still seems to malfunction with Clang on certain aspects. The new code does work successfully with GCC 4.2, 4.6 and 4.7. With 4.7, it also works when __generic() is implemented on top of _Generic(). Discussed with: stefanf
2012-01-05 11:46:22 +01:00
* Copyright (c) 2012 Ed Schouten <ed@FreeBSD.org>
* All rights reserved.
*
Implement C99's standard header <tgmath.h>. It provides type-generic macros for the <math.h> and <complex.h> functions that have float, double and long double implementations. Such type-generic macros expand to an actual function, depending on the types of the macro arguments, eg. if <tgmath.h> is included, the invocation cos(1.0f) calls the function cosf().
2004-08-08 22:05:47 +02:00
* Redistribution and use in source and binary forms, with or without
* modification, are permitted provided that the following conditions
* are met:
* 1. Redistributions of source code must retain the above copyright
* notice, this list of conditions and the following disclaimer.
* 2. Redistributions in binary form must reproduce the above copyright
* notice, this list of conditions and the following disclaimer in the
* documentation and/or other materials provided with the distribution.
*
* THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
* ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
* IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
* FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
* DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
* OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
* HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
* LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
* OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
* SUCH DAMAGE.
*/
#ifndef _TGMATH_H_
#define _TGMATH_H_
#include <complex.h>
#include <math.h>
/*
Reimplement <tgmath.h> on top of __generic(). The macro construction used now, is almost identical to the code provided in C11 proposal N1404. This new version doesn't seem to introduce any regressions according to the regression test in tools/, but still seems to malfunction with Clang on certain aspects. The new code does work successfully with GCC 4.2, 4.6 and 4.7. With 4.7, it also works when __generic() is implemented on top of _Generic(). Discussed with: stefanf
2012-01-05 11:46:22 +01:00
* This implementation of <tgmath.h> uses the two following macros,
* which are based on the macros described in C11 proposal N1404:
* __tg_impl_simple(x, y, z, fnl, fn, fnf, ...)
Implement C99's standard header <tgmath.h>. It provides type-generic macros for the <math.h> and <complex.h> functions that have float, double and long double implementations. Such type-generic macros expand to an actual function, depending on the types of the macro arguments, eg. if <tgmath.h> is included, the invocation cos(1.0f) calls the function cosf().
2004-08-08 22:05:47 +02:00
* Invokes fnl() if the corresponding real type of x, y or z is long
* double, fn() if it is double or any has an integer type, and fnf()
* otherwise.
Reimplement <tgmath.h> on top of __generic(). The macro construction used now, is almost identical to the code provided in C11 proposal N1404. This new version doesn't seem to introduce any regressions according to the regression test in tools/, but still seems to malfunction with Clang on certain aspects. The new code does work successfully with GCC 4.2, 4.6 and 4.7. With 4.7, it also works when __generic() is implemented on top of _Generic(). Discussed with: stefanf
2012-01-05 11:46:22 +01:00
* __tg_impl_full(x, y, cfnl, cfn, cfnf, fnl, fn, fnf, ...)
* Invokes [c]fnl() if the corresponding real type of x or y is long
Implement C99's standard header <tgmath.h>. It provides type-generic macros for the <math.h> and <complex.h> functions that have float, double and long double implementations. Such type-generic macros expand to an actual function, depending on the types of the macro arguments, eg. if <tgmath.h> is included, the invocation cos(1.0f) calls the function cosf().
2004-08-08 22:05:47 +02:00
* double, [c]fn() if it is double or any has an integer type, and
* [c]fnf() otherwise. The function with the 'c' prefix is called if
Reimplement <tgmath.h> on top of __generic(). The macro construction used now, is almost identical to the code provided in C11 proposal N1404. This new version doesn't seem to introduce any regressions according to the regression test in tools/, but still seems to malfunction with Clang on certain aspects. The new code does work successfully with GCC 4.2, 4.6 and 4.7. With 4.7, it also works when __generic() is implemented on top of _Generic(). Discussed with: stefanf
2012-01-05 11:46:22 +01:00
* any of x or y is a complex number.
Implement C99's standard header <tgmath.h>. It provides type-generic macros for the <math.h> and <complex.h> functions that have float, double and long double implementations. Such type-generic macros expand to an actual function, depending on the types of the macro arguments, eg. if <tgmath.h> is included, the invocation cos(1.0f) calls the function cosf().
2004-08-08 22:05:47 +02:00
* Both macros call the chosen function with all additional arguments passed
* to them, as given by __VA_ARGS__.
*
* Note that these macros cannot be implemented with C's ?: operator,
* because the return type of the whole expression would incorrectly be long
* double complex regardless of the argument types.
Last attempt at <tgmath.h>: do enable the new code for C11 compilers. I was thinking by myself, if the new code doesn't work with GCC 4.2, why not simply turn it into an efficient version for C11 compilers? By changing the code to use _Generic() directly in that case, I can build the tgmath regression test in a matter of milliseconds with Clang, instead of the 8 seconds it used to take. So by the time C11 becomes the default, it will pick up the new code automatically. And now I will refrain from making more changes to <tgmath.h>.
2012-01-06 20:04:59 +01:00
*
* The structure of the C11 implementation of these macros can in
* principle be reused for non-C11 compilers, but due to an integer
* promotion bug for complex types in GCC 4.2, simply let non-C11
* compilers use an inefficient yet reliable version.
Implement C99's standard header <tgmath.h>. It provides type-generic macros for the <math.h> and <complex.h> functions that have float, double and long double implementations. Such type-generic macros expand to an actual function, depending on the types of the macro arguments, eg. if <tgmath.h> is included, the invocation cos(1.0f) calls the function cosf().
2004-08-08 22:05:47 +02:00
*/
Enable improved <tgmath.h> for Clang even when not using C11. By using __has_extension(c_generic_selections), we can explicitly test whether we're dealing with a version of Clang that supports _Generic(). That way we can use the improved <tgmath.h> code, even when not using -std=c11. This massively reduces the compilation time when invoking these functions.
2013-04-27 23:18:34 +02:00
#if (defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112L) || \
Roll back r271012 even more aggressively. I've looked at the GCC sources and I now understand what's going wrong. THe C11 keywords are simply nonexistent when using C++ mode. They are marked as C-only in the parser. This is absolutely impractical for multiple reasons: - The C11 keywords do not conflict with C++ naming rules. They all start with _[A-Z]. There is no reason to make them C-only. - It makes it practically impossible for people to use these keywords in C header files and expect them to work from within C++ sources. As I said in my previous commit message: GCC is by far the weirdest compiler that I've ever used.
2014-09-05 07:36:32 +02:00
__has_extension(c_generic_selections)
Add an even faster implementation of <tgmath.h> for the future. Instead of using an exponential number of cases with respect to the number of arguments, this version only uses a linear number. Unfortunately, it works with Clang, GCC 4.6 and GCC 4.7, but not GCC 4.2. Therefore, leave it commented out.
2012-01-06 17:20:17 +01:00
#define __tg_generic(x, cfnl, cfn, cfnf, fnl, fn, fnf) \
Last attempt at <tgmath.h>: do enable the new code for C11 compilers. I was thinking by myself, if the new code doesn't work with GCC 4.2, why not simply turn it into an efficient version for C11 compilers? By changing the code to use _Generic() directly in that case, I can build the tgmath regression test in a matter of milliseconds with Clang, instead of the 8 seconds it used to take. So by the time C11 becomes the default, it will pick up the new code automatically. And now I will refrain from making more changes to <tgmath.h>.
2012-01-06 20:04:59 +01:00
_Generic(x, \
long double _Complex: cfnl, \
double _Complex: cfn, \
float _Complex: cfnf, \
long double: fnl, \
default: fn, \
float: fnf \
)
Add an even faster implementation of <tgmath.h> for the future. Instead of using an exponential number of cases with respect to the number of arguments, this version only uses a linear number. Unfortunately, it works with Clang, GCC 4.6 and GCC 4.7, but not GCC 4.2. Therefore, leave it commented out.
2012-01-06 17:20:17 +01:00
#define __tg_type(x) \
__tg_generic(x, (long double _Complex)0, (double _Complex)0, \
(float _Complex)0, (long double)0, (double)0, (float)0)
#define __tg_impl_simple(x, y, z, fnl, fn, fnf, ...) \
__tg_generic( \
__tg_type(x) + __tg_type(y) + __tg_type(z), \
fnl, fn, fnf, fnl, fn, fnf)(__VA_ARGS__)
#define __tg_impl_full(x, y, cfnl, cfn, cfnf, fnl, fn, fnf, ...) \
__tg_generic( \
__tg_type(x) + __tg_type(y), \
cfnl, cfn, cfnf, fnl, fn, fnf)(__VA_ARGS__)
Last attempt at <tgmath.h>: do enable the new code for C11 compilers. I was thinking by myself, if the new code doesn't work with GCC 4.2, why not simply turn it into an efficient version for C11 compilers? By changing the code to use _Generic() directly in that case, I can build the tgmath regression test in a matter of milliseconds with Clang, instead of the 8 seconds it used to take. So by the time C11 becomes the default, it will pick up the new code automatically. And now I will refrain from making more changes to <tgmath.h>.
2012-01-06 20:04:59 +01:00
#elif defined(__generic)
Reimplement <tgmath.h> on top of __generic(). The macro construction used now, is almost identical to the code provided in C11 proposal N1404. This new version doesn't seem to introduce any regressions according to the regression test in tools/, but still seems to malfunction with Clang on certain aspects. The new code does work successfully with GCC 4.2, 4.6 and 4.7. With 4.7, it also works when __generic() is implemented on top of _Generic(). Discussed with: stefanf
2012-01-05 11:46:22 +01:00
#define __tg_generic_simple(x, fnl, fn, fnf) \
__generic(x, long double _Complex, fnl, \
__generic(x, double _Complex, fn, \
__generic(x, float _Complex, fnf, \
Remove _Complex_I workaround from <tgmath.h>. This removes the use of __typeof() from this header, thus making it work with a plain C11 compiler.
2012-01-05 13:06:49 +01:00
__generic(x, long double, fnl, \
__generic(x, float, fnf, fn)))))
Reimplement <tgmath.h> on top of __generic(). The macro construction used now, is almost identical to the code provided in C11 proposal N1404. This new version doesn't seem to introduce any regressions according to the regression test in tools/, but still seems to malfunction with Clang on certain aspects. The new code does work successfully with GCC 4.2, 4.6 and 4.7. With 4.7, it also works when __generic() is implemented on top of _Generic(). Discussed with: stefanf
2012-01-05 11:46:22 +01:00
#define __tg_impl_simple(x, y, z, fnl, fn, fnf, ...) \
__tg_generic_simple(x, \
__tg_generic_simple(y, \
__tg_generic_simple(z, fnl, fnl, fnl), \
__tg_generic_simple(z, fnl, fnl, fnl), \
__tg_generic_simple(z, fnl, fnl, fnl)), \
__tg_generic_simple(y, \
__tg_generic_simple(z, fnl, fnl, fnl), \
__tg_generic_simple(z, fnl, fn , fn ), \
__tg_generic_simple(z, fnl, fn , fn )), \
__tg_generic_simple(y, \
__tg_generic_simple(z, fnl, fnl, fnl), \
__tg_generic_simple(z, fnl, fn , fn ), \
__tg_generic_simple(z, fnl, fn , fnf)))(__VA_ARGS__)
#define __tg_generic_full(x, cfnl, cfn, cfnf, fnl, fn, fnf) \
__generic(x, long double _Complex, cfnl, \
__generic(x, double _Complex, cfn, \
__generic(x, float _Complex, cfnf, \
Remove _Complex_I workaround from <tgmath.h>. This removes the use of __typeof() from this header, thus making it work with a plain C11 compiler.
2012-01-05 13:06:49 +01:00
__generic(x, long double, fnl, \
__generic(x, float, fnf, fn)))))
Reimplement <tgmath.h> on top of __generic(). The macro construction used now, is almost identical to the code provided in C11 proposal N1404. This new version doesn't seem to introduce any regressions according to the regression test in tools/, but still seems to malfunction with Clang on certain aspects. The new code does work successfully with GCC 4.2, 4.6 and 4.7. With 4.7, it also works when __generic() is implemented on top of _Generic(). Discussed with: stefanf
2012-01-05 11:46:22 +01:00
#define __tg_impl_full(x, y, cfnl, cfn, cfnf, fnl, fn, fnf, ...) \
__tg_generic_full(x, \
__tg_generic_full(y, cfnl, cfnl, cfnl, cfnl, cfnl, cfnl), \
__tg_generic_full(y, cfnl, cfn , cfn , cfnl, cfn , cfn ), \
__tg_generic_full(y, cfnl, cfn , cfnf, cfnl, cfn , cfnf), \
__tg_generic_full(y, cfnl, cfnl, cfnl, fnl , fnl , fnl ), \
__tg_generic_full(y, cfnl, cfn , cfn , fnl , fn , fn ), \
__tg_generic_full(y, cfnl, cfn , cfnf, fnl , fn , fnf )) \
(__VA_ARGS__)
Last attempt at <tgmath.h>: do enable the new code for C11 compilers. I was thinking by myself, if the new code doesn't work with GCC 4.2, why not simply turn it into an efficient version for C11 compilers? By changing the code to use _Generic() directly in that case, I can build the tgmath regression test in a matter of milliseconds with Clang, instead of the 8 seconds it used to take. So by the time C11 becomes the default, it will pick up the new code automatically. And now I will refrain from making more changes to <tgmath.h>.
2012-01-06 20:04:59 +01:00
#else
#error "<tgmath.h> not implemented for this compiler"
Add an even faster implementation of <tgmath.h> for the future. Instead of using an exponential number of cases with respect to the number of arguments, this version only uses a linear number. Unfortunately, it works with Clang, GCC 4.6 and GCC 4.7, but not GCC 4.2. Therefore, leave it commented out.
2012-01-06 17:20:17 +01:00
#endif
Implement C99's standard header <tgmath.h>. It provides type-generic macros for the <math.h> and <complex.h> functions that have float, double and long double implementations. Such type-generic macros expand to an actual function, depending on the types of the macro arguments, eg. if <tgmath.h> is included, the invocation cos(1.0f) calls the function cosf().
2004-08-08 22:05:47 +02:00
/* Macros to save lots of repetition below */
#define __tg_simple(x, fn) \
Reimplement <tgmath.h> on top of __generic(). The macro construction used now, is almost identical to the code provided in C11 proposal N1404. This new version doesn't seem to introduce any regressions according to the regression test in tools/, but still seems to malfunction with Clang on certain aspects. The new code does work successfully with GCC 4.2, 4.6 and 4.7. With 4.7, it also works when __generic() is implemented on top of _Generic(). Discussed with: stefanf
2012-01-05 11:46:22 +01:00
__tg_impl_simple(x, x, x, fn##l, fn, fn##f, x)
Implement C99's standard header <tgmath.h>. It provides type-generic macros for the <math.h> and <complex.h> functions that have float, double and long double implementations. Such type-generic macros expand to an actual function, depending on the types of the macro arguments, eg. if <tgmath.h> is included, the invocation cos(1.0f) calls the function cosf().
2004-08-08 22:05:47 +02:00
#define __tg_simple2(x, y, fn) \
Reimplement <tgmath.h> on top of __generic(). The macro construction used now, is almost identical to the code provided in C11 proposal N1404. This new version doesn't seem to introduce any regressions according to the regression test in tools/, but still seems to malfunction with Clang on certain aspects. The new code does work successfully with GCC 4.2, 4.6 and 4.7. With 4.7, it also works when __generic() is implemented on top of _Generic(). Discussed with: stefanf
2012-01-05 11:46:22 +01:00
__tg_impl_simple(x, x, y, fn##l, fn, fn##f, x, y)
#define __tg_simple3(x, y, z, fn) \
__tg_impl_simple(x, y, z, fn##l, fn, fn##f, x, y, z)
Implement C99's standard header <tgmath.h>. It provides type-generic macros for the <math.h> and <complex.h> functions that have float, double and long double implementations. Such type-generic macros expand to an actual function, depending on the types of the macro arguments, eg. if <tgmath.h> is included, the invocation cos(1.0f) calls the function cosf().
2004-08-08 22:05:47 +02:00
#define __tg_simplev(x, fn, ...) \
Reimplement <tgmath.h> on top of __generic(). The macro construction used now, is almost identical to the code provided in C11 proposal N1404. This new version doesn't seem to introduce any regressions according to the regression test in tools/, but still seems to malfunction with Clang on certain aspects. The new code does work successfully with GCC 4.2, 4.6 and 4.7. With 4.7, it also works when __generic() is implemented on top of _Generic(). Discussed with: stefanf
2012-01-05 11:46:22 +01:00
__tg_impl_simple(x, x, x, fn##l, fn, fn##f, __VA_ARGS__)
Implement C99's standard header <tgmath.h>. It provides type-generic macros for the <math.h> and <complex.h> functions that have float, double and long double implementations. Such type-generic macros expand to an actual function, depending on the types of the macro arguments, eg. if <tgmath.h> is included, the invocation cos(1.0f) calls the function cosf().
2004-08-08 22:05:47 +02:00
#define __tg_full(x, fn) \
Reimplement <tgmath.h> on top of __generic(). The macro construction used now, is almost identical to the code provided in C11 proposal N1404. This new version doesn't seem to introduce any regressions according to the regression test in tools/, but still seems to malfunction with Clang on certain aspects. The new code does work successfully with GCC 4.2, 4.6 and 4.7. With 4.7, it also works when __generic() is implemented on top of _Generic(). Discussed with: stefanf
2012-01-05 11:46:22 +01:00
__tg_impl_full(x, x, c##fn##l, c##fn, c##fn##f, fn##l, fn, fn##f, x)
#define __tg_full2(x, y, fn) \
__tg_impl_full(x, y, c##fn##l, c##fn, c##fn##f, fn##l, fn, fn##f, x, y)
Implement C99's standard header <tgmath.h>. It provides type-generic macros for the <math.h> and <complex.h> functions that have float, double and long double implementations. Such type-generic macros expand to an actual function, depending on the types of the macro arguments, eg. if <tgmath.h> is included, the invocation cos(1.0f) calls the function cosf().
2004-08-08 22:05:47 +02:00
/* 7.22#4 -- These macros expand to real or complex functions, depending on
* the type of their arguments. */
#define acos(x) __tg_full(x, acos)
#define asin(x) __tg_full(x, asin)
#define atan(x) __tg_full(x, atan)
#define acosh(x) __tg_full(x, acosh)
#define asinh(x) __tg_full(x, asinh)
#define atanh(x) __tg_full(x, atanh)
#define cos(x) __tg_full(x, cos)
#define sin(x) __tg_full(x, sin)
#define tan(x) __tg_full(x, tan)
#define cosh(x) __tg_full(x, cosh)
#define sinh(x) __tg_full(x, sinh)
#define tanh(x) __tg_full(x, tanh)
#define exp(x) __tg_full(x, exp)
#define log(x) __tg_full(x, log)
Reimplement <tgmath.h> on top of __generic(). The macro construction used now, is almost identical to the code provided in C11 proposal N1404. This new version doesn't seem to introduce any regressions according to the regression test in tools/, but still seems to malfunction with Clang on certain aspects. The new code does work successfully with GCC 4.2, 4.6 and 4.7. With 4.7, it also works when __generic() is implemented on top of _Generic(). Discussed with: stefanf
2012-01-05 11:46:22 +01:00
#define pow(x, y) __tg_full2(x, y, pow)
Implement C99's standard header <tgmath.h>. It provides type-generic macros for the <math.h> and <complex.h> functions that have float, double and long double implementations. Such type-generic macros expand to an actual function, depending on the types of the macro arguments, eg. if <tgmath.h> is included, the invocation cos(1.0f) calls the function cosf().
2004-08-08 22:05:47 +02:00
#define sqrt(x) __tg_full(x, sqrt)
/* "The corresponding type-generic macro for fabs and cabs is fabs." */
Reimplement <tgmath.h> on top of __generic(). The macro construction used now, is almost identical to the code provided in C11 proposal N1404. This new version doesn't seem to introduce any regressions according to the regression test in tools/, but still seems to malfunction with Clang on certain aspects. The new code does work successfully with GCC 4.2, 4.6 and 4.7. With 4.7, it also works when __generic() is implemented on top of _Generic(). Discussed with: stefanf
2012-01-05 11:46:22 +01:00
#define fabs(x) __tg_impl_full(x, x, cabsl, cabs, cabsf, \
fabsl, fabs, fabsf, x)
Implement C99's standard header <tgmath.h>. It provides type-generic macros for the <math.h> and <complex.h> functions that have float, double and long double implementations. Such type-generic macros expand to an actual function, depending on the types of the macro arguments, eg. if <tgmath.h> is included, the invocation cos(1.0f) calls the function cosf().
2004-08-08 22:05:47 +02:00
/* 7.22#5 -- These macros are only defined for arguments with real type. */
#define atan2(x, y) __tg_simple2(x, y, atan2)
#define cbrt(x) __tg_simple(x, cbrt)
#define ceil(x) __tg_simple(x, ceil)
#define copysign(x, y) __tg_simple2(x, y, copysign)
#define erf(x) __tg_simple(x, erf)
#define erfc(x) __tg_simple(x, erfc)
#define exp2(x) __tg_simple(x, exp2)
#define expm1(x) __tg_simple(x, expm1)
#define fdim(x, y) __tg_simple2(x, y, fdim)
#define floor(x) __tg_simple(x, floor)
Reimplement <tgmath.h> on top of __generic(). The macro construction used now, is almost identical to the code provided in C11 proposal N1404. This new version doesn't seem to introduce any regressions according to the regression test in tools/, but still seems to malfunction with Clang on certain aspects. The new code does work successfully with GCC 4.2, 4.6 and 4.7. With 4.7, it also works when __generic() is implemented on top of _Generic(). Discussed with: stefanf
2012-01-05 11:46:22 +01:00
#define fma(x, y, z) __tg_simple3(x, y, z, fma)
Implement C99's standard header <tgmath.h>. It provides type-generic macros for the <math.h> and <complex.h> functions that have float, double and long double implementations. Such type-generic macros expand to an actual function, depending on the types of the macro arguments, eg. if <tgmath.h> is included, the invocation cos(1.0f) calls the function cosf().
2004-08-08 22:05:47 +02:00
#define fmax(x, y) __tg_simple2(x, y, fmax)
#define fmin(x, y) __tg_simple2(x, y, fmin)
#define fmod(x, y) __tg_simple2(x, y, fmod)
#define frexp(x, y) __tg_simplev(x, frexp, x, y)
#define hypot(x, y) __tg_simple2(x, y, hypot)
#define ilogb(x) __tg_simple(x, ilogb)
#define ldexp(x, y) __tg_simplev(x, ldexp, x, y)
#define lgamma(x) __tg_simple(x, lgamma)
#define llrint(x) __tg_simple(x, llrint)
#define llround(x) __tg_simple(x, llround)
#define log10(x) __tg_simple(x, log10)
#define log1p(x) __tg_simple(x, log1p)
#define log2(x) __tg_simple(x, log2)
#define logb(x) __tg_simple(x, logb)
#define lrint(x) __tg_simple(x, lrint)
#define lround(x) __tg_simple(x, lround)
Embarrassing typo: s/nextbyint/nearbyint/
2004-09-04 01:26:55 +02:00
#define nearbyint(x) __tg_simple(x, nearbyint)
Implement C99's standard header <tgmath.h>. It provides type-generic macros for the <math.h> and <complex.h> functions that have float, double and long double implementations. Such type-generic macros expand to an actual function, depending on the types of the macro arguments, eg. if <tgmath.h> is included, the invocation cos(1.0f) calls the function cosf().
2004-08-08 22:05:47 +02:00
#define nextafter(x, y) __tg_simple2(x, y, nextafter)
#define nexttoward(x, y) __tg_simplev(x, nexttoward, x, y)
#define remainder(x, y) __tg_simple2(x, y, remainder)
Reimplement <tgmath.h> on top of __generic(). The macro construction used now, is almost identical to the code provided in C11 proposal N1404. This new version doesn't seem to introduce any regressions according to the regression test in tools/, but still seems to malfunction with Clang on certain aspects. The new code does work successfully with GCC 4.2, 4.6 and 4.7. With 4.7, it also works when __generic() is implemented on top of _Generic(). Discussed with: stefanf
2012-01-05 11:46:22 +01:00
#define remquo(x, y, z) __tg_impl_simple(x, x, y, remquol, remquo, \
remquof, x, y, z)
Implement C99's standard header <tgmath.h>. It provides type-generic macros for the <math.h> and <complex.h> functions that have float, double and long double implementations. Such type-generic macros expand to an actual function, depending on the types of the macro arguments, eg. if <tgmath.h> is included, the invocation cos(1.0f) calls the function cosf().
2004-08-08 22:05:47 +02:00
#define rint(x) __tg_simple(x, rint)
#define round(x) __tg_simple(x, round)
#define scalbn(x, y) __tg_simplev(x, scalbn, x, y)
#define scalbln(x, y) __tg_simplev(x, scalbln, x, y)
#define tgamma(x) __tg_simple(x, tgamma)
#define trunc(x) __tg_simple(x, trunc)
/* 7.22#6 -- These macros always expand to complex functions. */
#define carg(x) __tg_simple(x, carg)
#define cimag(x) __tg_simple(x, cimag)
#define conj(x) __tg_simple(x, conj)
#define cproj(x) __tg_simple(x, cproj)
#define creal(x) __tg_simple(x, creal)
#endif /* !_TGMATH_H_ */
Reference in New Issue Copy Permalink