On Wed, Sep 28, 2022 at 08:19:43PM +0200, Jakub Jelinek via Gcc-patches wrote:
> Another case are the following 3 snippets:
> # if !__GNUC_PREREQ (7, 0) || defined __cplusplus
> # error "_Float128X supported but no constant suffix"
> # else
> # define __f128x(x) x##f128x
> # endif
> ...
> # if !__GNUC_PREREQ (7, 0) || defined __cplusplus
> # error "_Float128X supported but no complex type"
> # else
> # define __CFLOAT128X _Complex _Float128x
> # endif
> ...
> # if !__GNUC_PREREQ (7, 0) || defined __cplusplus
> # error "_Float128x supported but no type"
> # endif
> but as no target has _Float128x right now and don't see it
> coming soon, it isn't a big deal (on the glibc side it is of
> course ok to adjust those).
This incremental patch deals handles the above 3 cases, so we
fixinclude what glibc itself changed too.
2022-10-07 Jakub Jelinek <jakub@redhat.com>
PR bootstrap/107059
* inclhack.def (glibc_cxx_floatn_5): New.
* fixincl.x: Regenerated.
* tests/base/bits/floatn.h: Regenerated.
On Wed, Sep 28, 2022 at 12:23:31AM +0000, Joseph Myers wrote:
> In general the changes match those made by fixincludes, though I think
> the ones in sysdeps/powerpc/bits/floatn.h, where the header tests
> __LDBL_MANT_DIG__ == 113 or uses #elif, wouldn't match the existing
> fixincludes patterns.
You're right, missed that.
The header has:
/* Defined to a complex binary128 type if __HAVE_FLOAT128 is 1. */
# if __HAVE_FLOAT128
# if __LDBL_MANT_DIG__ == 113 && defined __cplusplus
typedef long double _Float128;
# define __CFLOAT128 _Complex long double
# elif !__GNUC_PREREQ (7, 0) || defined __cplusplus
/* The type _Float128 exist for powerpc only since GCC 7.0. */
typedef __float128 _Float128;
/* Add a typedef for older GCC and C++ compilers which don't natively support
_Complex _Float128. */
typedef _Complex float __cfloat128 __attribute__ ((__mode__ (__KC__)));
# define __CFLOAT128 __cfloat128
# else
# define __CFLOAT128 _Complex _Float128
# endif
# endif
and my current rules don't do anything about that.
The following patch fixes that.
I've run additionally
MACRO_LIST=`pwd`/../gcc/macro_list TARGET_MACHINE=x86_64-pc-linux-gnu \
../fixincludes/fixinc.sh /tmp/include-fixed \
`echo /usr/src/libc | sed -e :a -e 's,[^/]*/\.\.\/,,' -e ta`
in the builddir/fixincludes directory where /usr/src/libc is latest glibc
trunk checkout and seems the remaining defined __cplusplus cases in the floatn.h
and floatn-common.h headers are ok or acceptable.
The remaining cases are:
#if __GNUC_PREREQ (7, 0) && !defined __cplusplus
# define __HAVE_FLOATN_NOT_TYPEDEF 1
#else
# define __HAVE_FLOATN_NOT_TYPEDEF 0
#endif
which is IMHO ok because this is only used in tgmath.h or tgmath-like math.h
stuff which is C only, as C++ doesn't have _Generic.
Another case are the following 3 snippets:
# if !__GNUC_PREREQ (7, 0) || defined __cplusplus
# error "_Float128X supported but no constant suffix"
# else
# define __f128x(x) x##f128x
# endif
...
# if !__GNUC_PREREQ (7, 0) || defined __cplusplus
# error "_Float128X supported but no complex type"
# else
# define __CFLOAT128X _Complex _Float128x
# endif
...
# if !__GNUC_PREREQ (7, 0) || defined __cplusplus
# error "_Float128x supported but no type"
# endif
but as no target has _Float128x right now and don't see it
coming soon, it isn't a big deal (on the glibc side it is of
course ok to adjust those).
OT, besides floatn.h and floatn-common.h headers, the only
one remaining in /tmp/include-fixed is sysdeps/arm/unwind.h, perhaps
-#if defined(linux) || defined(__NetBSD__)
+#if defined(__linux__) || defined(__NetBSD__)
should be done in that header (and libgcc/config/arm/unwind-arm.h
too).
2022-10-07 Jakub Jelinek <jakub@redhat.com>
PR bootstrap/107059
* inclhack.def (glibc_cxx_floatn_2): Handle #elif the same as #if.
(glibc_cxx_floatn_4): New.
* fixincl.x: Regenerated.
* tests/base/bits/floatn.h: Regenerated.
The following patch implements the compiler part of C++23
P1467R9 - Extended floating-point types and standard names compiler part
by introducing _Float{16,32,64,128} as keywords and builtin types
like they are implemented for C already since GCC 7, with DF{16,32,64,128}_
mangling.
It also introduces _Float{32,64,128}x for C++ with the
https://github.com/itanium-cxx-abi/cxx-abi/pull/147
proposed mangling of DF{32,64,128}x.
The patch doesn't add anything for bfloat16_t support, as right now
__bf16 type refuses all conversions and arithmetic operations.
The patch wants to keep backwards compatibility with how __float128 has
been handled in C++ before, both for mangling and behavior in binary
operations, overload resolution etc. So, there are some backend changes
where for C __float128 and _Float128 are the same type (float128_type_node
and float128t_type_node are the same pointer), but for C++ they are distinct
types which mangle differently and _Float128 is treated as extended
floating-point type while __float128 is treated as non-standard floating
point type. The various C++23 changes about how floating-point types
are changed are actually implemented as written in the spec only if at least
one of the types involved is _Float{16,32,64,128,32x,64x,128x} (_FloatNx are
also treated as extended floating-point types) and kept previous behavior
otherwise. For float/double/long double the rules are actually written that
they behave the same as before.
There is some backwards incompatibility at least on x86 regarding _Float16,
because that type was already used by that name and with the DF16_ mangling
(but only since GCC 12 and I think it isn't that widely used in the wild
yet). E.g. config/i386/avx512fp16intrin.h shows the issues, where
in C or in GCC 12 in C++ one could pass 0.0f to a builtin taking _Float16
argument, but with the changes that is not possible anymore, one needs
to either use 0.0f16 or (_Float16) 0.0f.
We have also a problem with glibc headers, where since glibc 2.27
math.h and complex.h aren't compilable with these changes. One gets
errors like:
In file included from /usr/include/math.h:43,
from abc.c:1:
/usr/include/bits/floatn.h:86:9: error: multiple types in one declaration
86 | typedef __float128 _Float128;
| ^~~~~~~~~~
/usr/include/bits/floatn.h:86:20: error: declaration does not declare anything [-fpermissive]
86 | typedef __float128 _Float128;
| ^~~~~~~~~
In file included from /usr/include/bits/floatn.h:119:
/usr/include/bits/floatn-common.h:214:9: error: multiple types in one declaration
214 | typedef float _Float32;
| ^~~~~
/usr/include/bits/floatn-common.h:214:15: error: declaration does not declare anything [-fpermissive]
214 | typedef float _Float32;
| ^~~~~~~~
/usr/include/bits/floatn-common.h:251:9: error: multiple types in one declaration
251 | typedef double _Float64;
| ^~~~~~
/usr/include/bits/floatn-common.h:251:16: error: declaration does not declare anything [-fpermissive]
251 | typedef double _Float64;
| ^~~~~~~~
This is from snippets like:
/* The remaining of this file provides support for older compilers. */
# if __HAVE_FLOAT128
/* The type _Float128 exists only since GCC 7.0. */
# if !__GNUC_PREREQ (7, 0) || defined __cplusplus
typedef __float128 _Float128;
# endif
where it hardcodes that C++ doesn't have _Float{16,32,64,128,32x,64x,128x} support nor
{f,F}{16,32,64,128}{,x} literal suffixes nor _Complex _Float{16,32,64,128,32x,64x,128x}.
The patch fixincludes this for now and hopefully if this is committed, then
glibc can change those. The patch changes those
# if !__GNUC_PREREQ (7, 0) || defined __cplusplus
conditions to
# if !__GNUC_PREREQ (7, 0) || (defined __cplusplus && !__GNUC_PREREQ (13, 0))
Another thing is mangling, as said above, Itanium C++ ABI specifies
DF <number> _ as _Float{16,32,64,128} mangling, but GCC was implementing
a mangling incompatible with that starting with DF for fixed point types.
Fixed point was never supported in C++ though, I believe the reason why
the mangling has been added was that due to a bug it would leak into the
C++ FE through decltype (0.0r) etc. But that has been shortly after the
mangling was added fixed (I think in the same GCC release cycle), so we
now reject 0.0r etc. in C++. If we ever need the fixed point mangling,
I think it can be readded but better with a different prefix so that it
doesn't conflict with the published standard manglings. So, this patch
also kills the fixed point mangling and implements the DF <number> _
demangling.
The patch predefines __STDCPP_FLOAT{16,32,64,128}_T__ macros when
those types are available, but only for C++23, while the underlying types
are available in C++98 and later including the {f,F}{16,32,64,128} literal
suffixes (but those with a pedwarn for C++20 and earlier). My understanding
is that it needs to be predefined by the compiler, on the other side
predefining even for older modes when <stdfloat> is a new C++23 header
would be weird. One can find out if _Float{16,32,64,128,32x,64x,128x} is
supported in C++ by
__GNUC__ >= 13 && defined(__FLT{16,32,64,128,32X,64X,128X}_MANT_DIG__)
(but that doesn't work well with older G++ 13 snapshots).
As for std::bfloat16_t, three targets (aarch64, arm and x86) apparently
"support" __bf16 type which has the bfloat16 format, but isn't really
usable, e.g. {aarch64,arm,ix86}_invalid_conversion disallow any conversions
from or to type with BFmode, {aarch64,arm,ix86}_invalid_unary_op disallows
any unary operations on those except for ADDR_EXPR and
{aarch64,arm,ix86}_invalid_binary_op disallows any binary operation on
those. So, I think we satisfy:
"If the implementation supports an extended floating-point type with the
properties, as specified by ISO/IEC/IEEE 60559, of radix (b) of 2, storage
width in bits (k) of 16, precision in bits (p) of 8, maximum exponent (emax)
of 127, and exponent field width in bits (w) of 8, then the typedef-name
std::bfloat16_t is defined in the header <stdfloat> and names such a type,
the macro __STDCPP_BFLOAT16_T__ is defined, and the floating-point literal
suffixes bf16 and BF16 are supported."
because we don't really support those right now.
2022-09-27 Jakub Jelinek <jakub@redhat.com>
PR c++/106652
PR c++/85518
gcc/
* tree-core.h (enum tree_index): Add TI_FLOAT128T_TYPE
enumerator.
* tree.h (float128t_type_node): Define.
* tree.cc (build_common_tree_nodes): Initialize float128t_type_node.
* builtins.def (DEF_FLOATN_BUILTIN): Adjust comment now that
_Float<N> is supported in C++ too.
* config/i386/i386.cc (ix86_mangle_type): Only mangle as "g"
float128t_type_node.
* config/i386/i386-builtins.cc (ix86_init_builtin_types): Use
float128t_type_node for __float128 instead of float128_type_node
and create it if NULL.
* config/i386/avx512fp16intrin.h (_mm_setzero_ph, _mm256_setzero_ph,
_mm512_setzero_ph, _mm_set_sh, _mm_load_sh): Use 0.0f16 instead of
0.0f.
* config/ia64/ia64.cc (ia64_init_builtins): Use
float128t_type_node for __float128 instead of float128_type_node
and create it if NULL.
* config/rs6000/rs6000-c.cc (is_float128_p): Also return true
for float128t_type_node if non-NULL.
* config/rs6000/rs6000.cc (rs6000_mangle_type): Don't mangle
float128_type_node as "u9__ieee128".
* config/rs6000/rs6000-builtin.cc (rs6000_init_builtins): Use
float128t_type_node for __float128 instead of float128_type_node
and create it if NULL.
gcc/c-family/
* c-common.cc (c_common_reswords): Change _Float{16,32,64,128} and
_Float{32,64,128}x flags from D_CONLY to 0.
(shorten_binary_op): Punt if common_type returns error_mark_node.
(shorten_compare): Likewise.
(c_common_nodes_and_builtins): For C++ record _Float{16,32,64,128}
and _Float{32,64,128}x builtin types if available. For C++
clear float128t_type_node.
* c-cppbuiltin.cc (c_cpp_builtins): Predefine
__STDCPP_FLOAT{16,32,64,128}_T__ for C++23 if supported.
* c-lex.cc (interpret_float): For q/Q suffixes prefer
float128t_type_node over float128_type_node. Allow
{f,F}{16,32,64,128} suffixes for C++ if supported with pedwarn
for C++20 and older. Allow {f,F}{32,64,128}x suffixes for C++
with pedwarn. Don't call excess_precision_type for C++.
gcc/cp/
* cp-tree.h (cp_compare_floating_point_conversion_ranks): Implement
P1467R9 - Extended floating-point types and standard names except
for std::bfloat16_t for now. Declare.
(extended_float_type_p): New inline function.
* mangle.cc (write_builtin_type): Mangle float{16,32,64,128}_type_node
as DF{16,32,64,128}_. Mangle float{32,64,128}x_type_node as
DF{32,64,128}x. Remove FIXED_POINT_TYPE mangling that conflicts
with that.
* typeck2.cc (check_narrowing): If one of ftype or type is extended
floating-point type, compare floating-point conversion ranks.
* parser.cc (cp_keyword_starts_decl_specifier_p): Handle
CASE_RID_FLOATN_NX.
(cp_parser_simple_type_specifier): Likewise and diagnose missing
_Float<N> or _Float<N>x support if not supported by target.
* typeck.cc (cp_compare_floating_point_conversion_ranks): New function.
(cp_common_type): If both types are REAL_TYPE and one or both are
extended floating-point types, select common type based on comparison
of floating-point conversion ranks and subranks.
(cp_build_binary_op): Diagnose operation with floating point arguments
with unordered conversion ranks.
* call.cc (standard_conversion): For floating-point conversion, if
either from or to are extended floating-point types, set conv->bad_p
for implicit conversion from larger to smaller conversion rank or
with unordered conversion ranks.
(convert_like_internal): Emit a pedwarn on such conversions.
(build_conditional_expr): Diagnose operation with floating point
arguments with unordered conversion ranks.
(convert_arg_to_ellipsis): Don't promote extended floating-point types
narrower than double to double.
(compare_ics): Implement P1467R9 [over.ics.rank]/4 changes.
gcc/testsuite/
* g++.dg/cpp23/ext-floating1.C: New test.
* g++.dg/cpp23/ext-floating2.C: New test.
* g++.dg/cpp23/ext-floating3.C: New test.
* g++.dg/cpp23/ext-floating4.C: New test.
* g++.dg/cpp23/ext-floating5.C: New test.
* g++.dg/cpp23/ext-floating6.C: New test.
* g++.dg/cpp23/ext-floating7.C: New test.
* g++.dg/cpp23/ext-floating8.C: New test.
* g++.dg/cpp23/ext-floating9.C: New test.
* g++.dg/cpp23/ext-floating10.C: New test.
* g++.dg/cpp23/ext-floating.h: New file.
* g++.target/i386/float16-1.C: Adjust expected diagnostics.
libcpp/
* expr.cc (interpret_float_suffix): Allow {f,F}{16,32,64,128} and
{f,F}{32,64,128}x suffixes for C++.
include/
* demangle.h (enum demangle_component_type): Add
DEMANGLE_COMPONENT_EXTENDED_BUILTIN_TYPE.
(struct demangle_component): Add u.s_extended_builtin member.
libiberty/
* cp-demangle.c (d_dump): Handle
DEMANGLE_COMPONENT_EXTENDED_BUILTIN_TYPE. Don't handle
DEMANGLE_COMPONENT_FIXED_TYPE.
(d_make_extended_builtin_type): New function.
(cplus_demangle_builtin_types): Add _Float entry.
(cplus_demangle_type): For DF demangle it as _Float<N> or
_Float<N>x rather than fixed point which conflicts with it.
(d_count_templates_scopes): Handle
DEMANGLE_COMPONENT_EXTENDED_BUILTIN_TYPE. Just break; for
DEMANGLE_COMPONENT_FIXED_TYPE.
(d_find_pack): Handle DEMANGLE_COMPONENT_EXTENDED_BUILTIN_TYPE.
Don't handle DEMANGLE_COMPONENT_FIXED_TYPE.
(d_print_comp_inner): Likewise.
* cp-demangle.h (D_BUILTIN_TYPE_COUNT): Bump.
* testsuite/demangle-expected: Replace _Z3xxxDFyuVb test
with _Z3xxxDF16_DF32_DF64_DF128_CDF16_Vb. Add
_Z3xxxDF32xDF64xDF128xCDF32xVb test.
fixincludes/
* inclhack.def (glibc_cxx_floatn_1, glibc_cxx_floatn_2,
glibc_cxx_floatn_3): New fixes.
* tests/base/bits/floatn.h: New file.
* fixincl.x: Regenerated.
The declarations of _DINFINITY, _SINFINITY and _SQNAN need to be constant
expressions.
2022-02-27 John David Anglin <danglin@gcc.gnu.org>
fixincludes/ChangeLog:
* inclhack.def (hpux_math_constexpr): New hack.
* fixincl.x: Regenerate.
* tests/base/math.h: Update.
When system headers expose a strict "open" prototype with
3 args, arrange to expose a C++ overload with only two.
2021-01-10 Olivier Hainque <hainque@adacore.com>
* inclhack.def (vxworks_math_h_fp_c99): New hack.
* tests/base/fcntl.h: Update.
* fixincl.x: Regenerate.
Make sure there is a visible prototype of sysClkRateGet() when
CLOCKS_PER_SEC is #defined to that in time.h for VxWorks. This
would typically be provided by sysLib.h.
2021-01-10 Olivier Hainque <hainque@adacore.com>
* inclhack.def (vxworks_time_h_syslib): New hack.
* tests/base/time.h: Update.
* fixincl.x: Regenerate.
Arrange to provide missing defs for C99 FP classification functions
and constants queried by libstdc++ configure checks (C99 support for C++98)
2021-01-10 Olivier Hainque <hainque@adacore.com>
* inclhack.def (vxworks_math_h_fp_c99): New hack.
* tests/base/math.h: Update.
* fixincl.x: Regenerate.
yvals.h on VxWorks expects the toolchain to provide its own
version of the header, which we don't do. Arrange to fallback
on the common system definitions instead.
2021-12-16 Olivier Hainque <hainque@adacore.com>
fixincludes/
* inclhack.def (vxworks_next_yvals): New hack.
* tests/base/yvals.h: New expected test result.
* fixincl.x: Regenerate.
For VxWorks, replace an attempt at providing a posix API for
mkdir via macro by a varargs prototype, which works better for
C++ references like std::mkdir(arg1, arg2).
2021-12-16 Olivier Hainque <hainque@adacore.com>
fixincludes/
* inclhack.def (vxworks_posix_mkdir): Refine to expose a
varargs interface.
* tests/base/sys/stat.h: Update expected results.
* fixincl.x: Regenerate.
The darwin system headers error out on __FLT_EVAL_METHOD__ == 16, which
occurs when the compiler is called with -mavx512fp16 on i386. Allow this
value to proceed past the check (nothing else depends on it in the
system headers).
fixincludes/ChangeLog:
* inclhack.def: Add new fix on darwin.
* fixincl.x: Regenerate.
* tests/base/math.h: Regenerate.
Add include hack to define PRIdPTR, PRIiPTR, PRIoPTR, PRIuPTR, PRIxPTR
and PRIXPTR in inttypes.h.
2021-08-30 John David Anglin <danglin@gcc.gnu.org>
fixincludes/ChangeLog:
* inclhack.def (hpux_c99_inttypes5): New hack to define PRIdPTR, etc.
* fixincl.x: Regenerate.
* tests/base/inttypes.h: Update.
Add more context to aix_externcpp1 selection to ensure
that the fix is correctly applied even in future AIX versions.
fixincludes/Changelog:
2021-07-01 Clément Chigot <clement.chigot@atos.net>
* inclhack.def (aix_externcpp1): Improve select regexp.
* fixincl.x: Regenerate.
* tests/base/sys/socket.h: Update.
After 92648faa1c ("aix: Fixinclude") make check-fixincludes began to
fail (at least on gcc121 machine). Fix by updating fixincludes/tests
and rerunning genfixes.
Co-developed-by: Nathan Sidwell <nathan@acm.org>
fixincludes/ChangeLog:
2020-12-11 Ilya Leoshkevich <iii@linux.ibm.com>
* fixincl.x: Rerun genfixes.
* inclhack.def(aix_physadr_t): Change test_text to something
that needs to be replaced.
* tests/base/sys/types.h(aix_physadr_t): Add expectation.
In recent Technology Levels of AIX 7.2, new "#ifdef __cplusplus" have been
added. Thus, the aix_malloc fix was applied in wrong locations. This patch
increases the context to avoid this.
fixincludes/ChangeLog:
2020-10-03 Clément Chigot <clement.chigot@atos.net>
* inclhack.def (aix_malloc): Add more context to select.
* fixincl.x: Regenerate.
* tests/base/malloc.h: Update expected results.
AIX protects the STDC Format Macros in a manner that can prevent the
definition of the macros depending on the order of header inclusion.
The protection of the macros was referenced in C99, removed in C11, and
never specified in any C++ standard. Also, the macros are in the namespace
reserved to the implementation (compiler) so the compiler is permitted to
choose to inject those names.
fixincludes/ChangeLog:
2020-09-17 David Edelsohn <dje.gcc@gmail.com>
PR target/97044
* inclhack.def (aix_inttypes): New fix.
* fixincl.x: Regenerate.
* tests/base/sys/inttypes.h: New file.
Recent Technology Levels of AIX 7.2 have made sys/socket.h more C++-aware,
which causes the fix to be applied in too many locations. This patch adds
more context for the selection to apply the fix more narrowly.
fixincludes/ChangeLog:
2020-09-17 David Edelsohn <dje.gcc@gmail.com>
* inclhack.def (aix_externcpp1): Add more context to select.
(aix_externcpp2): Same.
* fixincl.x: Regenerate.
* tests/base/sys/socket.h: Update expected results.
There is no reasonable chance that the SDKs in question will be re-
issued, so the only viable solution is a fixincludes.
2019-08-18 C.G. Dogan <gcc+cgdogan.00@gmail.com>
Iain Sandoe <iain@sandoe.co.uk>
PR target/83531
* inclhack.def (darwin_api_availability): New, strip leading
underscores from API_XXXX defines.
* fixincl.x: Regenerate.
* tests/base/os/availability.h: New file.
Co-Authored-By: Iain Sandoe <iain@sandoe.co.uk>
From-SVN: r274624
Darwin has had long long functions for some considerable time and these are
exposed in Darwin8 and Darwin11+ headers. However, for some reason it was
elected to hide them behind __STRICT_ANSI__ and __STDC_VERSION__ on Darwin9
and Darwin10. This is a problem for G++/libstdc++ that expects the functions
to be available for strict ansi (-std=c++14, for example) and without
defining __STDC_VERSION__. The fix here follows the pattern used in
Darwin11+ headers where the functions may be explicitly hidden by defining
__DARWIN_NO_LONG_LONG.
This fixes the tr1 testsuite fails seen on Darwin9 and 10.
2019-06-21 Iain Sandoe <iain@sandoe.co.uk>
* inclhack.def: Replace the complex test using __STRICT_ANSI__ and
__STDC_VERSION__ with a test using __DARWIN_NO_LONG_LONG.
Ensure that the top level math.h uses <> to wrap included headers
rather than "".
* fixincl.x: Regenerated.
* tests/base/architecture/ppc/math.h: Update test to include the
__DARWIN_NO_LONG_LONG case.
From-SVN: r272563
There are two issues with the Darwin14 (SDK) headers in which unguarded
advanced syntax elements causes any code including these headers to fail.
2019-06-21 Iain Sandoe <iain@sandoe.co.uk>
* inclhack.def: Guard __has_attribute and __has_extension in
os/base.h.
Guard Apple blocks syntax in dispatch/object.h.
* fixincl.x: Regenerate.
* tests/base/dispatch/object.h: New file.
* tests/base/os/base.h: New file.
From-SVN: r272561
When adding the vxworks_iolib_include_unistd hack I failed to add the
appropriate hunk to the tests/base/ioLib.h file, causing "make
check-fixincludes" to fail.
From-SVN: r262177
* inclhack.def (aix_stdlib_malloc): New fix.
(aix_stdlib_realloc): New fix.
(aix_stdlib_calloc): New fix.
(aix_stdlib_valloc): New fix.
* fixincl.x: Regenerate.
* test/base/stdlib.h [AIX_STDLIB_MALLOC]: New test.
[AIX_STDLIB_REALLOC]: New test.
[AIX_STDLIB_CALLOC]: New test.
[AIX_STDLIB_VALLOC]: New test.
From-SVN: r237394
plus fix the ordering of the patches:
* inclhack.def: many of the headers found under "bits/" are
often stashed under architecture directories. Apply fixes
to those, too. Also, re-ordered misordered fixes.
* tests/base/linux/vt.h: 80 columns in .def file limitation
* tests/base/iso/math_c99.h: adjust ordering
* tests/base/rtldef/string.h: likewise
* tests/base/bits/fenv.h: likewise
* tests/base/pthread.h: likewise
From-SVN: r205793
2013-12-06 Richard Biener <rguenther@suse.de>
* inclhack.def (suse_linux_vt_cxx): New fix for linux/vt.h
being not compatible with C++.
* tests/base/linux/vt.h: New test.
From-SVN: r205729
