public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/107649] New: New std::complex specializations are never used
@ 2022-11-11 20:46 redi at gcc dot gnu.org
2022-11-11 20:49 ` [Bug libstdc++/107649] " redi at gcc dot gnu.org
` (7 more replies)
0 siblings, 8 replies; 9+ messages in thread
From: redi at gcc dot gnu.org @ 2022-11-11 20:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107649
Bug ID: 107649
Summary: New std::complex specializations are never used
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: redi at gcc dot gnu.org
Target Milestone: ---
In <complex> we have:
template<typename _Tp>
requires(__complex_type<_Tp>::type)
class complex<_Tp>
{
This partial specialization is never used. The constraint looks for a constant
expression with true value, and none of the __complex_type specializations
provide that.
To test for a type name the constraint must be:
template<typename _Tp>
requires requires { typename __complex_type<_Tp>::type; }
class complex<_Tp>
{
However if I fix this, so that the partial specialization is used for float64_t
etc., then I get a cascade of errors for every overloaded <math.h> function:
include/complex: In instantiation of '_Tp std::abs(const complex<_Tp>&) [with
_Tp = _Float16]':
testsuite/26_numerics/complex/ext_c++23.cc:28: required from 'void
test_functions(T*, std::complex<_Tp>*) [with T = _Float16]'
testsuite/26_numerics/complex/ext_c++23.cc:56: required from here
include/complex:629: error: call of overloaded
'__complex_abs(std::complex<_Float16>::_ComplexT)' is ambiguous
include/complex:618: note: candidate: 'float std::__complex_abs(__complex__
float)'
include/complex:621: note: candidate: 'double std::__complex_abs(__complex__
double)'
include/complex:624: note: candidate: 'long double std::__complex_abs(const
__complex__ long double&)'
include/complex: In instantiation of '_Tp std::arg(const complex<_Tp>&) [with
_Tp = _Float16]':
testsuite/26_numerics/complex/ext_c++23.cc:29: required from 'void
test_functions(T*, std::complex<_Tp>*) [with T = _Float16]'
testsuite/26_numerics/complex/ext_c++23.cc:56: required from here
include/complex:656: error: call of overloaded
'__complex_arg(std::complex<_Float16>::_ComplexT)' is ambiguous
include/complex:645: note: candidate: 'float std::__complex_arg(__complex__
float)'
include/complex:648: note: candidate: 'double std::__complex_arg(__complex__
double)'
include/complex:651: note: candidate: 'long double std::__complex_arg(const
__complex__ long double&)'
include/complex: In instantiation of 'std::complex<_Tp> std::cos(const
complex<_Tp>&) [with _Tp = _Float16]':
testsuite/26_numerics/complex/ext_c++23.cc:30: required from 'void
test_functions(T*, std::complex<_Tp>*) [with T = _Float16]'
testsuite/26_numerics/complex/ext_c++23.cc:56: required from here
This is because with the fix to the speclization, __rep() now returns a
__complex__ T and so we try to call one of the float/double/longdouble
overloads:
inline float
__complex_abs(__complex__ float __z) { return __builtin_cabsf(__z); }
inline double
__complex_abs(__complex__ double __z) { return __builtin_cabs(__z); }
inline long double
__complex_abs(const __complex__ long double& __z)
{ return __builtin_cabsl(__z); }
template<typename _Tp>
inline _Tp
abs(const complex<_Tp>& __z) { return __complex_abs(__z.__rep()); }
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug libstdc++/107649] New std::complex specializations are never used
2022-11-11 20:46 [Bug libstdc++/107649] New: New std::complex specializations are never used redi at gcc dot gnu.org
@ 2022-11-11 20:49 ` redi at gcc dot gnu.org
2022-11-11 20:52 ` redi at gcc dot gnu.org
` (6 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: redi at gcc dot gnu.org @ 2022-11-11 20:49 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107649
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2022-11-11
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I think we just need all the new __complex_abs, __complex_pow etc. overloads to
be earlier in the file.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug libstdc++/107649] New std::complex specializations are never used
2022-11-11 20:46 [Bug libstdc++/107649] New: New std::complex specializations are never used redi at gcc dot gnu.org
2022-11-11 20:49 ` [Bug libstdc++/107649] " redi at gcc dot gnu.org
@ 2022-11-11 20:52 ` redi at gcc dot gnu.org
2022-11-12 8:29 ` jakub at gcc dot gnu.org
` (5 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: redi at gcc dot gnu.org @ 2022-11-11 20:52 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107649
--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Although if the _GLIBCXX_FLOAT_IS_IEEE_BINARY32 macro is not defined, it will
still be ambiguous, because we won't define these overloads:
#if _GLIBCXX_USE_C99_COMPLEX
#if defined(__STDCPP_FLOAT16_T__) && defined(_GLIBCXX_FLOAT_IS_IEEE_BINARY32)
inline _Float16
__complex_abs(__complex__ _Float16 __z)
{ return _Float16(__builtin_cabsf(__z)); }
So should the __complex_type specializations that cause us to use __complex__
_Tp depend on those same macros? So we don't use the efficient representation
unless we can also define these overloads?
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug libstdc++/107649] New std::complex specializations are never used
2022-11-11 20:46 [Bug libstdc++/107649] New: New std::complex specializations are never used redi at gcc dot gnu.org
2022-11-11 20:49 ` [Bug libstdc++/107649] " redi at gcc dot gnu.org
2022-11-11 20:52 ` redi at gcc dot gnu.org
@ 2022-11-12 8:29 ` jakub at gcc dot gnu.org
2022-11-12 12:34 ` redi at gcc dot gnu.org
` (4 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-11-12 8:29 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107649
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 53887
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53887&action=edit
gcc13-pr107649.patch
So like this? Only lightly tested so far, will check further after the
weekend.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug libstdc++/107649] New std::complex specializations are never used
2022-11-11 20:46 [Bug libstdc++/107649] New: New std::complex specializations are never used redi at gcc dot gnu.org
` (2 preceding siblings ...)
2022-11-12 8:29 ` jakub at gcc dot gnu.org
@ 2022-11-12 12:34 ` redi at gcc dot gnu.org
2022-11-16 13:47 ` cvs-commit at gcc dot gnu.org
` (3 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: redi at gcc dot gnu.org @ 2022-11-12 12:34 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107649
--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Yes, that looks right.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug libstdc++/107649] New std::complex specializations are never used
2022-11-11 20:46 [Bug libstdc++/107649] New: New std::complex specializations are never used redi at gcc dot gnu.org
` (3 preceding siblings ...)
2022-11-12 12:34 ` redi at gcc dot gnu.org
@ 2022-11-16 13:47 ` cvs-commit at gcc dot gnu.org
2022-11-17 0:36 ` redi at gcc dot gnu.org
` (2 subsequent siblings)
7 siblings, 0 replies; 9+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-11-16 13:47 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107649
--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:0e2c5510e001e5ccbde9e4b7df757e2bba2fdb00
commit r13-4096-g0e2c5510e001e5ccbde9e4b7df757e2bba2fdb00
Author: Jakub Jelinek <jakub@redhat.com>
Date: Wed Nov 16 14:45:40 2022 +0100
libstdc++: Fix up <complex> for extended floating point types [PR107649]
As filed by Jonathan in the PR, I've screwed up the requires syntax
in the extended floating point specialization:
- requires(__complex_type<_Tp>::type)
+ requires requires { typename __complex_type<_Tp>::type; }
and doing this change resulted in lots of errors because __complex_whatever
overfloads from extended floating point types were declared after the
templates which used them.
The following patch fixes that.
Bootstrapped/regtested on x86_64-linux and i686-linux, additionally
I've tested that with _GLIBCXX_HAVE_FLOAT128_MATH not being defined
while __STDCPP_FLOAT128_T__ defined one can still use
std::complex<std::float128_t> for basic arithmetic etc., just one can't
expect std::sin etc. to work in that case (because we don't have any
implementation).
2022-11-16 Jakub Jelinek <jakub@redhat.com>
Jonathan Wakely <jwakely@redhat.com>
PR libstdc++/107649
* include/std/complex (__complex_abs, __complex_arg, __complex_cos,
__complex_cosh, __complex_exp, __complex_log, __complex_sin,
__complex_sinh, __complex_sqrt, __complex_tan, __complex_tanh,
__complex_pow): Move __complex__ _Float{16,32,64,128} and
__complex__ decltype(0.0bf16) overloads earlier in the file.
(complex): Fix up requires on the partial specialization for
extended
float types.
(__complex_acos, __complex_asin, __complex_atan, __complex_acosh,
__complex_asinh, __complex_atanh): Move
__complex__ _Float{16,32,64,128} and __complex__ decltype(0.0bf16)
overloads earlier in the file.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug libstdc++/107649] New std::complex specializations are never used
2022-11-11 20:46 [Bug libstdc++/107649] New: New std::complex specializations are never used redi at gcc dot gnu.org
` (4 preceding siblings ...)
2022-11-16 13:47 ` cvs-commit at gcc dot gnu.org
@ 2022-11-17 0:36 ` redi at gcc dot gnu.org
2022-11-19 15:08 ` cvs-commit at gcc dot gnu.org
2022-11-28 22:32 ` pinskia at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: redi at gcc dot gnu.org @ 2022-11-17 0:36 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107649
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |FIXED
--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Fixed
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug libstdc++/107649] New std::complex specializations are never used
2022-11-11 20:46 [Bug libstdc++/107649] New: New std::complex specializations are never used redi at gcc dot gnu.org
` (5 preceding siblings ...)
2022-11-17 0:36 ` redi at gcc dot gnu.org
@ 2022-11-19 15:08 ` cvs-commit at gcc dot gnu.org
2022-11-28 22:32 ` pinskia at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-11-19 15:08 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107649
--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>:
https://gcc.gnu.org/g:945e86ddaa6cc7251d7bb57be8bb65f182cd3a0c
commit r13-4167-g945e86ddaa6cc7251d7bb57be8bb65f182cd3a0c
Author: Jonathan Wakely <jwakely@redhat.com>
Date: Fri Nov 18 21:17:51 2022 +0000
libstdc++: Fix one more malformed requires-clause [PR107649]
libstdc++-v3/ChangeLog:
PR libstdc++/107649
* include/std/complex (__complex_proj): Fix requires-clause.
^ permalink raw reply [flat|nested] 9+ messages in thread
* [Bug libstdc++/107649] New std::complex specializations are never used
2022-11-11 20:46 [Bug libstdc++/107649] New: New std::complex specializations are never used redi at gcc dot gnu.org
` (6 preceding siblings ...)
2022-11-19 15:08 ` cvs-commit at gcc dot gnu.org
@ 2022-11-28 22:32 ` pinskia at gcc dot gnu.org
7 siblings, 0 replies; 9+ messages in thread
From: pinskia at gcc dot gnu.org @ 2022-11-28 22:32 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107649
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |13.0
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2022-11-28 22:32 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-11-11 20:46 [Bug libstdc++/107649] New: New std::complex specializations are never used redi at gcc dot gnu.org
2022-11-11 20:49 ` [Bug libstdc++/107649] " redi at gcc dot gnu.org
2022-11-11 20:52 ` redi at gcc dot gnu.org
2022-11-12 8:29 ` jakub at gcc dot gnu.org
2022-11-12 12:34 ` redi at gcc dot gnu.org
2022-11-16 13:47 ` cvs-commit at gcc dot gnu.org
2022-11-17 0:36 ` redi at gcc dot gnu.org
2022-11-19 15:08 ` cvs-commit at gcc dot gnu.org
2022-11-28 22:32 ` pinskia at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).