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).