The multiplication (4 * _M_t * __1p) can wraparound to zero if _M_t is
unsigned and 4 * _M_t wraps to zero. The third operand has type double,
so do the second multiplication first, so that we aren't multiplying
integers.
libstdc++-v3/ChangeLog:
PR libstdc++/114359
* include/bits/random.tcc (binomial_distribution::param_type):
Ensure arithmetic is done as type double.
* testsuite/26_numerics/random/binomial_distribution/114359.cc: New test.
The call to __valarray_copy constructs an _Array object to refer to
this->_M_data but that means that accesses to this->_M_data are through
a restrict-qualified pointer. This leads to undefined behaviour when
copying from an _Expr object that actually aliases this->_M_data.
Replace the call to __valarray_copy with a plain loop. I think this
removes the only use of that overload of __valarray_copy, so it could
probably be removed. I haven't done that here.
libstdc++-v3/ChangeLog:
PR libstdc++/99117
* include/std/valarray (valarray::operator=(const _Expr&)):
Use loop to copy instead of __valarray_copy with _Array.
* testsuite/26_numerics/valarray/99117.cc: New test.
For 32-bit targets without __int128 we need to implement the LCG
transition function by hand using 64-bit types.
We can also slightly simplify the __mod function by using if-constexpr
unconditionally, disabling -Wc++17-extensions warnings with diagnostic
pragmas.
libstdc++-v3/ChangeLog:
PR libstdc++/87744
* include/bits/random.h [!__SIZEOF_INT128__] (_Select_uint_least_t):
Define specialization for 64-bit generators with
non-power-of-two modulus and large constants.
(__mod): Use if constexpr unconditionally.
* testsuite/26_numerics/random/pr60037-neg.cc: Adjust dg-error
line number.
* testsuite/26_numerics/random/linear_congruential_engine/87744.cc:
New test.
I implemented the resolution of LWG 3809 in r13-4364-ga64775a0edd469 but
it was recently noted in the MSVC STL github repo that the change causes
possible truncation for 64-bit seeds. Whether the truncation occurs (and
to what value) depends on the width of uint_least32_t which is not
portable, so the output of the PRNG for 64-bit seed values is no longer
the same as in C++20, and no longer portable across platforms.
That new issue was filed as LWG 4014. I proposed a new change which
reduces the seed by the LCG's modulus before the conversion to
uint_least32_t. This ensures that 64-bit seed values are consistently
reduced by the modulus before any truncation. This removes the
platform-dependent behaviour and restores the old behaviour for
std::subtract_with_carry_engine specializations using a 64-bit result
type (such as std::ranlux48_base).
libstdc++-v3/ChangeLog:
PR libstdc++/107466
* include/bits/random.tcc (subtract_with_carry_engine::seed):
Implement proposed resolution of LWG 4014.
* testsuite/26_numerics/random/pr60037-neg.cc: Adjust dg-error
line number.
* testsuite/26_numerics/random/subtract_with_carry_engine/cons/lwg3809.cc:
Check for expected result of 64-bit engine with seed that
doesn't fit in 32-bits.
The changes in r14-5979 to support unknown references in constant
expressions caused some test regressions. The way that __glibcxx_assert
is defined for constant evaluation no longer works when
_GLIBCXX_ASSERTIONS is defined.
This change simplifies __glibcxx_assert so that there is only one check,
rather than a constexpr one and a conditionally-enabled runtime one. The
constexpr one does not need to use __builtin_unreachable to cause a
compilation failure, because __glibcxx_assert_fail is not usable in
constant expressions, so that will cause a failure too.
As well as fixing the regressions, this makes the code for the
assertions shorter and simpler, so should be quicker to compile, and
might inline better too.
libstdc++-v3/ChangeLog:
* include/bits/c++config (__glibcxx_assert_fail): Declare even
when assertions are not enabled.
(__glibcxx_constexpr_assert): Remove macro.
(__glibcxx_assert_impl): Remove macro.
(_GLIBCXX_ASSERT_FAIL): New macro.
(_GLIBCXX_DO_ASSERT): New macro.
(__glibcxx_assert): Simplify to a single definition that works
at runtime and during constant evaluation.
* testsuite/21_strings/basic_string_view/element_access/char/back_constexpr_neg.cc:
Adjust expected errors.
* testsuite/21_strings/basic_string_view/element_access/char/constexpr_neg.cc:
Likewise.
* testsuite/21_strings/basic_string_view/element_access/char/front_constexpr_neg.cc:
Likewise.
* testsuite/21_strings/basic_string_view/element_access/wchar_t/back_constexpr_neg.cc:
Likewise.
* testsuite/21_strings/basic_string_view/element_access/wchar_t/constexpr_neg.cc:
Likewise.
* testsuite/21_strings/basic_string_view/element_access/wchar_t/front_constexpr_neg.cc:
Likewise.
* testsuite/21_strings/basic_string_view/modifiers/remove_prefix/debug.cc:
Likewise.
* testsuite/21_strings/basic_string_view/modifiers/remove_suffix/debug.cc:
Likewise.
* testsuite/23_containers/span/back_neg.cc: Likewise.
* testsuite/23_containers/span/front_neg.cc: Likewise.
* testsuite/23_containers/span/index_op_neg.cc: Likewise.
* testsuite/26_numerics/lcm/105844.cc: Likewise.
This was approved for C++26 last week at the WG21 meeting in Kona.
libstdc++-v3/ChangeLog:
* include/Makefile.am: Add new header.
* include/Makefile.in: Regenerate.
* include/bits/version.def (saturation_arithmetic): Define.
* include/bits/version.h: Regenerate.
* include/std/numeric: Include new header.
* include/bits/sat_arith.h: New file.
* testsuite/26_numerics/saturation/add.cc: New test.
* testsuite/26_numerics/saturation/cast.cc: New test.
* testsuite/26_numerics/saturation/div.cc: New test.
* testsuite/26_numerics/saturation/mul.cc: New test.
* testsuite/26_numerics/saturation/sub.cc: New test.
* testsuite/26_numerics/saturation/version.cc: New test.
When I added these tests I gave them .h file extensions, so they've
never been run.
They need to use the no_pch option, so that they only test the
<complex.h> header and don't get <complex> via <bits/stdc++.h>.
libstdc++-v3/ChangeLog:
* testsuite/26_numerics/headers/complex.h/std_c++11.h: Moved to...
* testsuite/26_numerics/headers/complex.h/std_c++11.cc: ...here.
* testsuite/26_numerics/headers/complex.h/std_c++98.h: Moved to...
* testsuite/26_numerics/headers/complex.h/std_c++98.cc: ...here.
Check macro first and then #undef.
* testsuite/26_numerics/headers/complex.h/std_gnu++11.h: Moved to...
* testsuite/26_numerics/headers/complex.h/std_gnu++11.cc: ...here.
This patch makes us recognize and check non-dependent simple assigments
ahead of time, like we already do for compound assignments. This means
the templated representation of such assignments will now usually have
an implicit INDIRECT_REF (due to the reference return type), which the
-Wparentheses code needs to handle. As a drive-by improvement, this
patch also makes maybe_convert_cond issue -Wparentheses warnings ahead
of time, and removes a seemingly unnecessary suppress_warning call in
build_x_modify_expr.
On the libstdc++ side, some tests were attempting to modify a data
member from a uninstantiated const member function, which this patch
minimally fixes by making the data member mutable.
PR c++/63198
PR c++/18474
gcc/cp/ChangeLog:
* semantics.cc (maybe_convert_cond): Look through implicit
INDIRECT_REF when deciding whether to issue a -Wparentheses
warning, and consider templated assignment expressions as well.
(finish_parenthesized_expr): Look through implicit INDIRECT_REF
when suppressing -Wparentheses warning.
* typeck.cc (build_x_modify_expr): Check simple assignments
ahead time too, not just compound assignments. Give the second
operand of MODOP_EXPR a non-null type so that it's not considered
always instantiation-dependent. Don't call suppress_warning.
gcc/testsuite/ChangeLog:
* g++.dg/cpp0x/static_assert15.C: Expect diagnostic for
non-constant static_assert condition.
* g++.dg/expr/unary2.C: Remove xfails.
* g++.dg/template/init7.C: Make initializer type-dependent to
preserve intent of test.
* g++.dg/template/recurse3.C: Likewise for the erroneous
statement.
* g++.dg/template/non-dependent26.C: New test.
* g++.dg/warn/Wparentheses-32.C: New test.
libstdc++-v3/ChangeLog:
* testsuite/26_numerics/random/discard_block_engine/cons/seed_seq2.cc:
Make data member seed_seq::called mutable.
* testsuite/26_numerics/random/independent_bits_engine/cons/seed_seq2.cc:
Likewise.
* testsuite/26_numerics/random/linear_congruential_engine/cons/seed_seq2.cc:
Likewise.
* testsuite/26_numerics/random/mersenne_twister_engine/cons/seed_seq2.cc:
Likewise.
* testsuite/26_numerics/random/shuffle_order_engine/cons/seed_seq2.cc:
Likewise.
* testsuite/26_numerics/random/subtract_with_carry_engine/cons/seed_seq2.cc:
Likewise.
* testsuite/ext/random/simd_fast_mersenne_twister_engine/cons/seed_seq2.cc:
Likewise.
It's no longer true that 1.0if has type float _Complex when GNU
extensions are enabled, so remove the hardcoded -std option.
libstdc++-v3/ChangeLog:
* testsuite/26_numerics/complex/literals/types.cc: Remove
dg-options and add target selector instead.
These test behaviour only seen with -std=c++03 so the target selector
should match.
libstdc++-v3/ChangeLog:
* testsuite/20_util/bitset/107037.cc: Add c++98_only selector.
* testsuite/26_numerics/complex/56111.cc: Likewise.
libstdc++-v3/ChangeLog:
* testsuite/20_util/duration/cons/2.cc: Use values that aren't
affected by rounding.
* testsuite/20_util/from_chars/5.cc: Cast arithmetic result to
double before comparing for equality.
* testsuite/20_util/from_chars/6.cc: Likewise.
* testsuite/20_util/variant/86874.cc: Use values that aren't
affected by rounding.
* testsuite/25_algorithms/lower_bound/partitioned.cc: Compare to
original value instead of to floating-point-literal.
* testsuite/26_numerics/random/discrete_distribution/cons/range.cc:
Cast arithmetic result to double before comparing for equality.
* testsuite/26_numerics/random/piecewise_constant_distribution/cons/range.cc:
Likewise.
* testsuite/26_numerics/random/piecewise_linear_distribution/cons/range.cc:
Likewise.
* testsuite/26_numerics/valarray/transcend.cc (eq): Check that
the absolute difference is less than 0.01 instead of comparing
to two decimal places.
* testsuite/27_io/basic_istream/extractors_arithmetic/char/01.cc:
Cast arithmetic result to double before comparing for equality.
* testsuite/27_io/basic_istream/extractors_arithmetic/char/09.cc:
Likewise.
* testsuite/27_io/basic_istream/extractors_arithmetic/char/10.cc:
Likewise.
* testsuite/27_io/basic_istream/extractors_arithmetic/wchar_t/01.cc:
Likewise.
* testsuite/27_io/basic_istream/extractors_arithmetic/wchar_t/09.cc:
Likewise.
* testsuite/27_io/basic_istream/extractors_arithmetic/wchar_t/10.cc:
Likewise.
* testsuite/ext/random/hoyt_distribution/cons/parms.cc: Likewise.
This test fails in C++20 and later due to a warning:
warning: C++20 says that these are ambiguous, even though the second is reversed:
note: candidate 1: 'bool MyClass::operator==(const MyClass&)'
note: candidate 2: 'bool MyClass::operator==(const MyClass&)' (reversed)
note: try making the operator a 'const' member function
FAIL: 26_numerics/pstl/numeric_ops/transform_reduce.cc (test for excess errors)
libstdc++-v3/ChangeLog:
* testsuite/26_numerics/pstl/numeric_ops/transform_reduce.cc:
Add const to equality operator.
Similar to the three commits r14-908, r14-909 and r14-910, the
_GLIBCXX_USE_C99_MATH_TR1 macro is misleading when it is also used for
<cmath>, not only for <tr1/cmath> headers. It is also wrong, because the
configure checks for TR1 use -std=c++98 and a target might define the
C99 features for C++11 but not for C++98.
Add separate configure checks for the <math.h> functions using
-std=c++11 for the checks. Use the new macro defined by those checks in
the C++11-specific parts of <cmath>, and in <complex>, <random> etc.
The check that defines _GLIBCXX_NO_C99_ROUNDING_FUNCS is only needed for
the C++11 <cmath> checks, so remove that from GLIBCXX_CHECK_C99_TR1 and
only do it for GLIBCXX_ENABLE_C99.
libstdc++-v3/ChangeLog:
* acinclude.m4 (GLIBCXX_ENABLE_C99): Add checks for C99 math
functions and define _GLIBCXX_USE_C99_MATH_FUNCS. Move checks
for C99 rounding functions to here.
(GLIBCXX_CHECK_C99_TR1): Remove checks for C99 rounding
functions from here.
* config.h.in: Regenerate.
* configure: Regenerate.
* include/bits/random.h: Use _GLIBCXX_USE_C99_MATH_FUNCS instead
of _GLIBCXX_USE_C99_MATH_TR1.
* include/bits/random.tcc: Likewise.
* include/c_compatibility/math.h: Likewise.
* include/c_global/cmath: Likewise.
* include/ext/random: Likewise.
* include/ext/random.tcc: Likewise.
* include/std/complex: Likewise.
* testsuite/20_util/from_chars/4.cc: Likewise.
* testsuite/20_util/from_chars/8.cc: Likewise.
* testsuite/26_numerics/complex/proj.cc: Likewise.
* testsuite/26_numerics/headers/cmath/60401.cc: Likewise.
* testsuite/26_numerics/headers/cmath/types_std_c++0x.cc:
Likewise.
* testsuite/lib/libstdc++.exp (check_v3_target_cstdint):
Likewise.
* testsuite/util/testsuite_random.h: Likewise.
As can be seen on the following testcase, for
std::{atan2,fmod,pow,copysign,fdim,fmax,fmin,hypot,nextafter,remainder,remquo,fma}
if one operand type is std::float{16,32,64,128}_t or std::bfloat16_t and
another one some integral type or some other floating point type which
promotes to the other operand's type, we can end up with endless recursion.
This is because of a declaration ordering problem in <cmath>, where the
float, double and long double overloads of those functions come before
the templates which use __gnu_cxx::__promote_{2,3}, but the
std::float{16,32,64,128}_t and std::bfloat16_t overloads come later in the
file. If the result of those promotions is _Float{16,32,64,128} or
__gnu_cxx::__bfloat16_t, say std::pow(_Float64, int) calls
std::pow(_Float64, _Float64) and the latter calls itself.
The following patch fixes that by moving those templates later in the file,
so that the calls from those templates see also the other overloads.
I think other templates in the file like e.g. isgreater etc. shouldn't be
a problem, because those just use __builtin_isgreater etc. in their bodies.
2023-05-17 Jakub Jelinek <jakub@redhat.com>
PR libstdc++/109883
* include/c_global/cmath (atan2, fmod, pow): Move
__gnu_cxx::__promote_2 using templates after _Float{16,32,64,128} and
__gnu_cxx::__bfloat16_t overloads.
(copysign, fdim, fmax, fmin, hypot, nextafter, remainder, remquo):
Likewise.
(fma): Move __gnu_cxx::__promote_3 using template after
_Float{16,32,64,128} and __gnu_cxx::__bfloat16_t overloads.
* testsuite/26_numerics/headers/cmath/constexpr_std_c++23.cc: New test.
The current implementation of this non-standard overload of std::abs
incorrectly returns a negative value for negative NaNs and negative
zero, because x < 0 is false in both cases.
Use fabsl(long double) or fabsf128(_Float128) if those do the right
thing. Otherwise, use __builtin_signbit(x) instead of x < 0 to detect
negative inputs. This assumes that __builtin_signbit handles __float128
correctly, but that seems to be true for all of GCC, clang and icc.
libstdc++-v3/ChangeLog:
PR libstdc++/109758
* include/bits/std_abs.h (abs(__float128)): Handle negative NaN
and negative zero correctly.
* testsuite/26_numerics/headers/cmath/109758.cc: New test.
Add assertions to diagnose incorrect uses of valarray masks.
The assignment operators of std::mask_array do not have any explicit
preconditions in the standard, but the assignment operator
valarray<T>::operator=(const mask_array<T>&) requires the lengths to
match, so it seems consistent to also require that when the operands are
reversed. In support of that interpretation, libstdc++ has undefined
behaviour if the right-hand operand has more elements than are selected
by the mask, and libc++ has undefined behaviour if it has fewer
elements. Our std::mask_array stores the number of selected elements as
_M_sz so it's easy to add an assertion that checks it.
For the valarray::operator[] that takes a valarray<bool> mask,
[valarray.sub] in the standard says: "In each case the selected
element(s) shall exist." This makes it undefined to have a mask that
refers to out-of-range elements. We can easily check this too.
libstdc++-v3/ChangeLog:
PR libstdc++/62196
* include/bits/mask_array.h (mask_array): Add assertions to
assignment operators.
* include/std/valarray (valarray::operator[](valarray<bool>)):
Add assertions.
* testsuite/26_numerics/valarray/mask-1_neg.cc: New test.
* testsuite/26_numerics/valarray/mask-2_neg.cc: New test.
* testsuite/26_numerics/valarray/mask-3_neg.cc: New test.
* testsuite/26_numerics/valarray/mask-4_neg.cc: New test.
* testsuite/26_numerics/valarray/mask-5_neg.cc: New test.
* testsuite/26_numerics/valarray/mask-6_neg.cc: New test.
* testsuite/26_numerics/valarray/mask-7_neg.cc: New test.
* testsuite/26_numerics/valarray/mask-8_neg.cc: New test.
* testsuite/26_numerics/valarray/mask.cc: New test.
This has an unnecessary UTF-8 non-breaking space.
libstdc++-v3/ChangeLog:
* testsuite/26_numerics/random/subtract_with_carry_engine/cons/lwg3809.cc:
Replace non-ASCII character.
This implements the proposed resolution of LWG 3809, so that
std::subtract_with_carry_engine can be used with a 16-bit result_type.
Currently this produces a narrowing error when instantiating the
std::linear_congruential_engine to create the initial state. It also
truncates the default_seed constant when passing it as a result_type
argument.
Change the type of the constant to uint_least32_t and pass 0u when the
default_seed should be used.
libstdc++-v3/ChangeLog:
PR libstdc++/107466
* include/bits/random.h (subtract_with_carry_engine): Use 32-bit
type for default seed. Use 0u as default argument for
subtract_with_carry_engine(result_type) constructor and
seed(result_type) member function.
* include/bits/random.tcc (subtract_with_carry_engine): Use
32-bit type for default seed and engine used for initial state.
* testsuite/26_numerics/random/subtract_with_carry_engine/cons/lwg3809.cc:
New test.
These tests fail in strict -std=c++20 mode but their equality ops don't
need to be non-const, it looks like an accident.
This fixes two FAILs with -std=c++20:
FAIL: 20_util/tuple/swap.cc (test for excess errors)
FAIL: 26_numerics/valarray/87641.cc (test for excess errors)
libstdc++-v3/ChangeLog:
* testsuite/20_util/tuple/swap.cc (MoveOnly::operator==): Add
const qualifier.
* testsuite/26_numerics/valarray/87641.cc (X::operator==):
Likewise.
The following patch adds the easy part of <charconv>, <istream> and
<ostream> changes for extended floats.
In particular, for the first one only overloads where the _Float* has
the same format as float/double/long double and for the latter two
everything but the _GLIBCXX_HAVE_FLOAT128_MATH case.
For charconv, I'm not really familiar with it, I'm pretty sure
we need new libstdc++.so.6 side implementation of from_chars for
{,b}float16_t and for to_chars not really sure but for unspecified precision
if it should emit minimum characters that to_chars then can unambiguously
parse, I think it is less than in the float case. For float128_t
{to,from}_chars I think we even have it on the library side already, just
ifdefed for powerpc64le only.
For i/o stream operator<</>>, not sure what is better, if not providing
anything at all, or doing what we in the end do if user doesn't override
the virtual functions, or use {to,from}_chars under the hood, something
else?
Besides this, the patch adds some further missed
// { dg-options "-std=gnu++2b" }
spots, I've also noticed I got the formatting wrong in some testcases
by not using spaces around VERIFY conditions and elsewhere by having
space before ( for calls.
The testsuite coverage is limited, I've added test for from_chars because
it was easy to port, but not really sure what to do about to_chars, it has
for float/double huge testcases which would be excessive to repeat.
And for i/ostream not really sure what exactly is worth testing.
2022-11-01 Jakub Jelinek <jakub@redhat.com>
* include/std/charconv (from_chars, to_chars): Add _Float{32,64,128}
overloads for cases where those types match {float,double,long double}.
* include/std/istream (basic_istream::operator>>): Add
_Float{16,32,64,128} and __gnu_cxx::__bfloat16_t overloads.
* include/std/ostream (basic_ostream::operator<<): Add
_Float{16,32,64,128} and __gnu_cxx::__bfloat16_t overloads.
* testsuite/20_util/from_chars/8.cc: New test.
* testsuite/26_numerics/headers/cmath/nextafter_c++23.cc (test):
Formatting fixes.
* testsuite/26_numerics/headers/cmath/functions_std_c++23.cc: Add
dg-options "-std=gnu++2b".
(test_functions, main): Formatting fixes.
* testsuite/26_numerics/headers/cmath/c99_classification_macros_c++23.cc:
Add dg-options "-std=gnu++2b".
The following patch adds <complex> support for extended floating point
types.
C++23 removes the float/double/long double specializations from the spec
and instead adds explicit(bool) specifier on the converting constructor.
The patch uses that for converting constructor of the base template as well
as the float/double/long double specializations's converting constructors
(e.g. so that it handles convertion construction also from complex of extended
floating point types). Copy ctor was already defaulted as the spec now
requires.
The patch also adds partial specialization for the _Float{16,32,64,128}
and __gnu_cxx::__bfloat16_t types because the base template doesn't use
__complex__ but a pair of floating point values.
The g++.dg/cpp23/ testcase verifies explicit(bool) works correctly.
2022-10-31 Jakub Jelinek <jakub@redhat.com>
gcc/testsuite/
* g++.dg/cpp23/ext-floating12.C: New test.
libstdc++-v3/
* include/std/complex (complex::complex converting ctor): For C++23
use explicit specifier with constant expression. Explicitly cast
both parts to _Tp.
(__complex_abs, __complex_arg, __complex_cos, __complex_cosh,
__complex_exp, __complex_log, __complex_sin, __complex_sinh,
__complex_sqrt, __complex_tan, __complex_tanh, __complex_pow): Add
__complex__ _Float{16,32,64,128} and __complex__ decltype(0.0bf16)
overloads.
(complex<float>::complex converting ctor,
complex<double>::complex converting ctor,
complex<long double>::complex converting ctor): For C++23 implement
as template with explicit specifier with constant expression
and explicit casts.
(__complex_type): New template.
(complex): New partial specialization for types with extended floating
point types.
(__complex_acos, __complex_asin, __complex_atan, __complex_acosh,
__complex_asinh, __complex_atanh): Add __complex__ _Float{16,32,64,128}
and __complex__ decltype(0.0bf16) overloads.
(__complex_proj): Likewise. Add template for complex of extended
floating point types.
* include/bits/cpp_type_traits.h (__is_floating): Specialize for
_Float{16,32,64,128} and __gnu_cxx::__bfloat16_t.
* testsuite/26_numerics/complex/ext_c++23.cc: New test.
The following patch
1) enables the std::float128_t overloads for x86 with glibc 2.26+
2) makes std::nextafter(std::float16_t, std::float16_t) and
std::nextafter(std::bfloat16_t, std::bfloat16_t) constexpr
3) adds (small) testsuite coverage for that
2022-10-21 Jakub Jelinek <jakub@redhat.com>
* config/os/gnu-linux/os_defines.h (_GLIBCXX_HAVE_FLOAT128_MATH):
Uncomment.
* include/c_global/cmath (nextafter(_Float16, _Float16)): Make it constexpr.
If std::__is_constant_evaluated() call __builtin_nextafterf16.
(nextafter(__gnu_cxx::__bfloat16_t, __gnu_cxx::__bfloat16_t)): Similarly
but call __builtin_nextafterf16b.
* testsuite/26_numerics/headers/cmath/nextafter_c++23.cc (test): Add
static assertions to test constexpr nextafter.
The following patch implements nextafter for std::{,b}float16_t,
though right now only without constexpr support, and adds a testcase for it.
The testcase unfortunately relevealed I've screwed up testing of my last
patch. I've tested earlier version of the patch with
--target_board=unix/-std=c++23
but didn't test the final version with that RUNTESTFLAGS, so missed
an invalid call to std::sph_neumann (too many arguments) in the test.
And, I've made a typo in the guard for numeric_limits (the reason
for the guard is I wanted to avoid defining a large macro that nothing
will then use because the std::{,b}float*_t types are C++23 only) and
so numeric_limits wasn't specialized for the types at all but
testsuite/18_support/headers/limits/synopsis_cxx23.cc test didn't
detect that.
In the nextafter implementation I'm calling __builtin_nextafterf
to get various required side-effects for nextafter from 0/-0, or from max
to inf or from min to largest subnormal to avoid needing to set errno
inline, or use inline asm specific for each processor to force math
evaluation barriers. Dunno if
#ifdef __INT16_TYPE__
using __float16_int_type = __INT16_TYPE__;
#else
using __float16_int_type = short int;
#endif
isn't too ugly, perhaps we could just blindly use short int and hope
or even assert it has the same size as _Float16 or __gnu_cxx::__bfloat16_t?
Only aarch64, arm, csky, gcn, x86, nvptx and riscv support these types
and all of them have 16-bit short (I think the only target with some
other short size is avr with certain command line switches where both
short and int are 8-bit, but such mode isn't compatible with C and C++
requirements).
2022-10-19 Jakub Jelinek <jakub@redhat.com>
PR c++/106652
* include/std/limits: Fix a typo, 202202L -> 202002L.
(numeric_limits::<_Float16>::radix, numeric_limits::<_Float32>::radix,
numeric_limits::<_Float64>::radix, numeric_limits::<_Float128>::radix,
numeric_limits::<__gnu_cxx::__bfloat16_t>::radix): Use __FLT_RADIX__
macro instead of type specific macros.
* include/c_global/cmath (nextafter(_Float16, _Float16)): New
overload.
(nextafter(__gnu_cxx::__bfloat16_t, __gnu_cxx::__bfloat16_t)):
Likewise.
* testsuite/26_numerics/headers/cmath/functions_std_c++23.cc
(test_functions): Uncomment nextafter test. Fix up sph_neumann call.
* testsuite/26_numerics/headers/cmath/nextafter_c++23.cc: New test.
The following patch is partial support for std::float{16,32,64,128}_t
and std::bfloat16_t in libstdc++.
https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p1467r9.html
says that <ostream>, <istream>, <charconv> and <complex>
need changes toom, but that isn't implemented so far.
In <cmath> the only thing missing I'm aware of is
std::nextafter std::float16_t and std::bfloat16_t overloads (I think
we probably need to implement that out of line somewhere, or inline? - might
need inline asm barriers) and std::nexttoward overloads (those are
intentional, you said there is a LWG issue about that).
Also, this patch has the glibc 2.26+ std::float128_t support for platforms
where long double isn't IEEE quad format temporarily disabled
because it depends on
https://gcc.gnu.org/pipermail/gcc-patches/2022-October/603665.html
changes which aren't in yet.
The patch also doesn't include any testcases to cover the <type_traits>
changes, it isn't clear to me where to put that.
2022-10-18 Jakub Jelinek <jakub@redhat.com>
PR c++/106652
* include/std/stdfloat: New file.
* include/std/numbers (__glibcxx_numbers): Define and use it
for __float128 explicit instantiations as well as
_Float{16,32,64,128} and __gnu_cxx::__bfloat16_t.
* include/std/atomic (atomic<_Float16>, atomic<_Float32>,
atomic<_Float64>, atomic<_Float128>, atomic<__gnu_cxx::__bfloat16_t>):
New explicit instantiations.
* include/std/type_traits (__is_floating_point_helper<_Float16>,
__is_floating_point_helper<_Float32>,
__is_floating_point_helper<_Float64>,
__is_floating_point_helper<_Float128>,
__is_floating_point_helper<__gnu_cxx::__bfloat16_t>): Likewise.
* include/std/limits (__glibcxx_concat3_, __glibcxx_concat3,
__glibcxx_float_n): Define.
(numeric_limits<_Float16>, numeric_limits<_Float32>,
numeric_limits<_Float64>, numeric_limits<_Float128>,
numeric_limits<__gnu_cxx::__bfloat16_t>): New explicit instantiations.
* include/bits/std_abs.h (abs): New overloads for
_Float{16,32,64,128} and __gnu_cxx::__bfloat16_t.
* include/bits/c++config (_GLIBCXX_LDOUBLE_IS_IEEE_BINARY128): Define
if long double is IEEE quad.
(__gnu_cxx::__bfloat16_t): New using.
* include/c_global/cmath (acos, asin, atan, atan2, ceil, cos, cosh,
exp, fabs, floor, fmod, frexp, ldexp, log, log10, modf, pow, sin,
sinh, sqrt, tan, tanh, fpclassify, isfinite, isinf, isnan, isnormal,
signbit, isgreater, isgreaterequal, isless, islessequal,
islessgreater, isunordered, acosh, asinh, atanh, cbrt, copysign, erf,
erfc, exp2, expm1, fdim, fma, fmax, fmin, hypot, ilogb, lgamma,
llrint, llround, log1p, log2, logb, lrint, lround, nearbyint,
nextafter, remainder, rint, round, scalbln, scalbn, tgamma, trunc,
lerp): New overloads with _Float{16,32,64,128} or
__gnu_cxx::__bfloat16_t types.
* config/os/gnu-linux/os_defines.h (_GLIBCXX_HAVE_FLOAT128_MATH):
Prepare for definition if glibc 2.26 and later implements *f128 APIs
but comment out the actual definition for now.
* include/ext/type_traits.h (__promote<_Float16>, __promote<_Float32>,
__promote<_Float64>, __promote<_Float128>,
__promote<__gnu_cxx::__bfloat16_t>): New specializations.
* include/Makefile.am (std_headers): Add stdfloat.
* include/Makefile.in: Regenerated.
* include/precompiled/stdc++.h: Include stdfloat.
* testsuite/18_support/headers/stdfloat/types_std.cc: New test.
* testsuite/18_support/headers/limits/synopsis_cxx23.cc: New test.
* testsuite/26_numerics/headers/cmath/c99_classification_macros_c++23.cc:
New test.
* testsuite/26_numerics/headers/cmath/functions_std_c++23.cc: New test.
* testsuite/26_numerics/numbers/4.cc: New test.
* testsuite/29_atomics/atomic_float/requirements_cxx23.cc: New test.
The template version of complex::proj returns its argument without
testing for infinities, and that's all we have when neither C99
complex nor C99 math functions are available, and it seems too hard to
do better without isinf and copysign.
I suppose just calling them and expecting users will supply
specializations as needed has been ruled out, and so has refraining
from defining it when it can't be implemented correctly.
It's pointless to run the proj.cc test under these circumstances, so
arrange for it to be skipped. In an unusual way, after trying to
introduce dg-require tests for ccomplex-or-cmath, and found their
results to be misleading due to variations across -std=* versions.
for libstdc++-v3/ChangeLog
* testsuite/26_numerics/complex/proj.cc: Skip test in the
circumstances in which the implementation of proj is known to
be broken.
This test uses std::log2 without including <cmath>, but it doesn't need
to use it at all. Just get the number of digits from numeric_limits
instead.
libstdc++-v3/ChangeLog:
* testsuite/26_numerics/random/random_device/entropy.cc: Use
numeric_limits<unsigned>::digits.
When I fixed PR libstdc++/92978 I introduced a regression whereby
std::lcm(INT_MIN, 1) and std::lcm(50000, 49999) would no longer produce
errors during constant evaluation. Those calls are undefined, because
they violate the preconditions that |m| and the result can be
represented in the return type (which is int in both those cases). The
regression occurred because __absu<unsigned>(INT_MIN) is well-formed,
due to the explicit casts to unsigned in that new helper function, and
the out-of-range multiplication is well-formed, because unsigned
arithmetic wraps instead of overflowing.
To fix 92978 I made std::gcm and std::lcm calculate |m| and |n|
immediately, yielding a common unsigned type that was used to calculate
the result. That was partly correct, but there's no need to use an
unsigned type. Doing so only suppresses the overflow errors so the
compiler can't detect them. This change replaces __absu with __abs_r
that returns the common type (not its corresponding unsigned type). This
way we can detect overflow in __abs_r when required, while still
supporting the most-negative value when it can be represented in the
result type. To detect LCM results that are out of range of the result
type we still need explicit checks, because neither constant evaluation
nor UBsan will complain about unsigned wrapping for cases such as
std::lcm(500000u, 499999u). We can detect those overflows efficiently by
using __builtin_mul_overflow and asserting.
libstdc++-v3/ChangeLog:
PR libstdc++/105844
* include/experimental/numeric (experimental::gcd): Simplify
assertions. Use __abs_r instead of __absu.
(experimental::lcm): Likewise. Remove use of __detail::__lcm so
overflow can be detected.
* include/std/numeric (__detail::__absu): Rename to __abs_r and
change to allow signed result type, so overflow can be detected.
(__detail::__lcm): Remove.
(gcd): Simplify assertions. Use __abs_r instead of __absu.
(lcm): Likewise. Remove use of __detail::__lcm so overflow can
be detected.
* testsuite/26_numerics/gcd/gcd_neg.cc: Adjust dg-error lines.
* testsuite/26_numerics/lcm/lcm_neg.cc: Likewise.
* testsuite/26_numerics/gcd/105844.cc: New test.
* testsuite/26_numerics/lcm/105844.cc: New test.
Some of these tests take several minutes on a simulator like cris-elf,
so we can conditionally run fewer iterations. The testDiscreteDist
helper already supports custom sizes so we just need to make use of that
when { target simulator } matches.
The relevant code is sufficiently tested on other targets, so we're not
losing anything by only running a small number of iterators for sims.
libstdc++-v3/ChangeLog:
* testsuite/26_numerics/random/bernoulli_distribution/operators/values.cc:
Run fewer iterations for simulator targets.
* testsuite/26_numerics/random/binomial_distribution/operators/values.cc:
Likewise.
* testsuite/26_numerics/random/discrete_distribution/operators/values.cc:
Likewise.
* testsuite/26_numerics/random/geometric_distribution/operators/values.cc:
Likewise.
* testsuite/26_numerics/random/negative_binomial_distribution/operators/values.cc:
Likewise.
* testsuite/26_numerics/random/poisson_distribution/operators/values.cc:
Likewise.
* testsuite/26_numerics/random/uniform_int_distribution/operators/values.cc:
Likewise.
This fixes a regression in std::normal_distribution deserialization that
caused the object to be left unchanged if the __state_avail value read
from the stream was false.
libstdc++-v3/ChangeLog:
PR libstdc++/105502
* include/bits/random.tcc
(operator>>(basic_istream<C,T>&, normal_distribution<R>&)):
Update state when __state_avail is false.
* testsuite/26_numerics/random/normal_distribution/operators/serialize.cc:
Check that deserialized object equals serialized one.
Our std::bit_cast was relying on the compiler to check for errors inside
__builtin_bit_cast, instead of checking them as constraints. That means
std::bit_cast was not SFINAE-friendly.
This fix uses a requires-clause, so for old versions of Clang without
concepts support the function will still be unconstrained. At some point
in future we can remove the #ifdef __cpp_concepts check and rely on all
compilers having full concepts support in C++20 mode.
libstdc++-v3/ChangeLog:
PR libstdc++/105027
* include/std/bit (bit_cast): Add constraints.
* testsuite/26_numerics/bit/bit.cast/105027.cc: New test.
This patch attempts to implement P1272R4 (except for the std::bit_cast
changes in there which seem quite unrelated to this and will need to be
fixed on the compiler side).
While at least for GCC __builtin_bswap{16,32,64,128} should work fine
in constant expressions, I wonder about other compilers, so I'm using
a fallback implementation for constexpr evaluation always.
If you think that is unnecessary, I can drop the
__cpp_if_consteval >= 202106L &&
if !consteval
{
and
}
and reformat.
The fallback implementation is an attempt to make it work even for integral
types that don't have number of bytes divisible by 2 or when __CHAR_BIT__
is e.g. 16.
2021-11-28 Jakub Jelinek <jakub@redhat.com>
* include/std/bit (__cpp_lib_byteswap, byteswap): Define.
* include/std/version (__cpp_lib_byteswap): Define.
* testsuite/26_numerics/bit/bit.byteswap/byteswap.cc: New test.
* testsuite/26_numerics/bit/bit.byteswap/version.cc: New test.
An effective target like foo-bar-baz will match a target selector of
*-*-* and cause problems in the testsuite. Several libstdc++ et keywords
are of the form foo-bar, which could still be a problem for *-*
selectors.
Replace hyphens with underscores in the et keywords "debug-mode",
"cxx11-abi", etc.
libstdc++-v3/ChangeLog:
* testsuite/lib/libstdc++.exp: Rename effective target keywords
to avoid dashes in the name.
* testsuite/*: Update effective targe keywords.
With each successive C++ standard the restrictions on the use of the
constexpr keyword for functions get weaker and weaker; it recently occurred
to me that it is heading toward the same fate as the C register keyword,
which was once useful for optimization but became obsolete. Similarly, it
seems to me that we should be able to just treat inlines as constexpr
functions and not make people add the extra keyword everywhere.
There were a lot of testcase changes needed; many disabling errors about
non-constexpr functions that are now constexpr, and many disabling implicit
constexpr so that the tests can check the same thing as before, whether
that's mangling or whatever.
gcc/c-family/ChangeLog:
* c.opt: Add -fimplicit-constexpr.
* c-cppbuiltin.c: Define __cpp_implicit_constexpr.
* c-opts.c (c_common_post_options): Disable below C++14.
gcc/cp/ChangeLog:
* cp-tree.h (struct lang_decl_fn): Add implicit_constexpr.
(decl_implicit_constexpr_p): New.
* class.c (type_maybe_constexpr_destructor): Use
TYPE_HAS_TRIVIAL_DESTRUCTOR and maybe_constexpr_fn.
(finalize_literal_type_property): Simplify.
* constexpr.c (is_valid_constexpr_fn): Check for dtor.
(maybe_save_constexpr_fundef): Try to set DECL_DECLARED_CONSTEXPR_P
on inlines.
(cxx_eval_call_expression): Use maybe_constexpr_fn.
(maybe_constexpr_fn): Handle flag_implicit_constexpr.
(var_in_maybe_constexpr_fn): Use maybe_constexpr_fn.
(potential_constant_expression_1): Likewise.
(decl_implicit_constexpr_p): New.
* decl.c (validate_constexpr_redeclaration): Allow change with
-fimplicit-constexpr.
(grok_special_member_properties): Use maybe_constexpr_fn.
* error.c (dump_function_decl): Don't print 'constexpr'
if it's implicit.
* Make-lang.in (check-c++-all): Update.
libstdc++-v3/ChangeLog:
* testsuite/20_util/to_address/1_neg.cc: Adjust error.
* testsuite/26_numerics/random/concept.cc: Adjust asserts.
gcc/testsuite/ChangeLog:
* lib/g++-dg.exp: Handle "impcx".
* lib/target-supports.exp
(check_effective_target_implicit_constexpr): New.
* g++.dg/abi/abi-tag16.C:
* g++.dg/abi/abi-tag18a.C:
* g++.dg/abi/guard4.C:
* g++.dg/abi/lambda-defarg1.C:
* g++.dg/abi/mangle26.C:
* g++.dg/cpp0x/constexpr-diag3.C:
* g++.dg/cpp0x/constexpr-ex1.C:
* g++.dg/cpp0x/constexpr-ice5.C:
* g++.dg/cpp0x/constexpr-incomplete2.C:
* g++.dg/cpp0x/constexpr-memfn1.C:
* g++.dg/cpp0x/constexpr-neg3.C:
* g++.dg/cpp0x/constexpr-specialization.C:
* g++.dg/cpp0x/inh-ctor19.C:
* g++.dg/cpp0x/inh-ctor30.C:
* g++.dg/cpp0x/lambda/lambda-mangle3.C:
* g++.dg/cpp0x/lambda/lambda-mangle5.C:
* g++.dg/cpp1y/auto-fn12.C:
* g++.dg/cpp1y/constexpr-loop5.C:
* g++.dg/cpp1z/constexpr-lambda7.C:
* g++.dg/cpp2a/constexpr-dtor3.C:
* g++.dg/cpp2a/constexpr-new13.C:
* g++.dg/cpp2a/constinit11.C:
* g++.dg/cpp2a/constinit12.C:
* g++.dg/cpp2a/constinit14.C:
* g++.dg/cpp2a/constinit15.C:
* g++.dg/cpp2a/spaceship-constexpr1.C:
* g++.dg/cpp2a/spaceship-eq3.C:
* g++.dg/cpp2a/udlit-class-nttp-neg2.C:
* g++.dg/debug/dwarf2/auto1.C:
* g++.dg/debug/dwarf2/cdtor-1.C:
* g++.dg/debug/dwarf2/lambda1.C:
* g++.dg/debug/dwarf2/pr54508.C:
* g++.dg/debug/dwarf2/pubnames-2.C:
* g++.dg/debug/dwarf2/pubnames-3.C:
* g++.dg/ext/is_literal_type3.C:
* g++.dg/ext/visibility/template7.C:
* g++.dg/gcov/gcov-12.C:
* g++.dg/gcov/gcov-2.C:
* g++.dg/ipa/devirt-35.C:
* g++.dg/ipa/devirt-36.C:
* g++.dg/ipa/devirt-37.C:
* g++.dg/ipa/devirt-44.C:
* g++.dg/ipa/imm-devirt-1.C:
* g++.dg/lookup/builtin5.C:
* g++.dg/lto/inline-crossmodule-1_0.C:
* g++.dg/modules/enum-1_a.C:
* g++.dg/modules/fn-inline-1_c.C:
* g++.dg/modules/pmf-1_b.C:
* g++.dg/modules/used-1_c.C:
* g++.dg/tls/thread_local11.C:
* g++.dg/tls/thread_local11a.C:
* g++.dg/tm/pr46653.C:
* g++.dg/ubsan/pr70035.C:
* g++.old-deja/g++.other/delete6.C:
* g++.dg/modules/pmf-1_a.H:
Adjust for implicit constexpr.
This adds additional "getentropy" and "arc4random" tokens to
std::random_device. The former is supported on Glibc and OpenBSD (and
apparently wasm), and the latter is supported on various BSDs.
libstdc++-v3/ChangeLog:
* acinclude.m4 (GLIBCXX_CHECK_GETENTROPY, GLIBCXX_CHECK_ARC4RANDOM):
Define.
* configure.ac (GLIBCXX_CHECK_GETENTROPY, GLIBCXX_CHECK_ARC4RANDOM):
Use them.
* config.h.in: Regenerate.
* configure: Regenerate.
* src/c++11/random.cc (random_device): Add getentropy and
arc4random as sources.
* testsuite/26_numerics/random/random_device/cons/token.cc:
Check new tokens.
* testsuite/26_numerics/random/random_device/entropy.cc:
Likewise.
