public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/94831] New: [10 Regression] vector<float[2]> no longer compiles
@ 2020-04-28 19:45 redi at gcc dot gnu.org
  2020-04-28 19:46 ` [Bug libstdc++/94831] " redi at gcc dot gnu.org
                   ` (4 more replies)
  0 siblings, 5 replies; 6+ messages in thread
From: redi at gcc dot gnu.org @ 2020-04-28 19:45 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94831

            Bug ID: 94831
           Summary: [10 Regression] vector<float[2]> no longer compiles
           Product: gcc
           Version: 10.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 r277342 I changed std::_Construct for P0784R7, "More constexpr containers"
and the non-void return type means this no longer compiles:

#include <vector>
std::vector<float[2]> v(1);

This was never valid in C++98, and in C++11 to C++17 it's undefined (because
the pseudo-destructor call in allocator_traits<std::allocator<T>>::destroy is
ill-formed for arrays). But for libstdc++ it happened to compile, because we
elide the calls to trivial destructors.

Since r277342 we impement std::construct_at semantics in std::_Construct which
means it returns non-void, but the result of the new-expression for an array
type is not convertible to a pointer to the array:

/home/jwakely/src/gcc/gcc/libstdc++-v3/include/bits/stl_construct.h:111:31:
error: cannot convert 'float*' to 'float (*)[2]' in return
  111 |       return std::construct_at(__p, std::forward<_Args>(__args)...);
      |              ~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
      |                               |
      |                               float*

This is arguably OK for C++20 where the specification of std::construct_at is
clear, but it's a regression for C++11/14/17.

I propose to restore support for vector<float[2]> for c++11/14/17 and gnu++20,
so we can at least introduce a period of deprecation before removing the
support completely.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug libstdc++/94831] [10 Regression] vector<float[2]> no longer compiles
  2020-04-28 19:45 [Bug libstdc++/94831] New: [10 Regression] vector<float[2]> no longer compiles redi at gcc dot gnu.org
@ 2020-04-28 19:46 ` redi at gcc dot gnu.org
  2020-04-28 20:01 ` redi at gcc dot gnu.org
                   ` (3 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: redi at gcc dot gnu.org @ 2020-04-28 19:46 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94831

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |redi at gcc dot gnu.org
   Last reconfirmed|                            |2020-04-28
   Target Milestone|---                         |10.0
             Status|UNCONFIRMED                 |ASSIGNED
     Ever confirmed|0                           |1

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug libstdc++/94831] [10 Regression] vector<float[2]> no longer compiles
  2020-04-28 19:45 [Bug libstdc++/94831] New: [10 Regression] vector<float[2]> no longer compiles redi at gcc dot gnu.org
  2020-04-28 19:46 ` [Bug libstdc++/94831] " redi at gcc dot gnu.org
@ 2020-04-28 20:01 ` redi at gcc dot gnu.org
  2020-04-28 21:39 ` redi at gcc dot gnu.org
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 6+ messages in thread
From: redi at gcc dot gnu.org @ 2020-04-28 20:01 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94831

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |rejects-valid

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Here's a testcase that is definitely valid in C++17 and C++20, but fails with
GCC 10:

#include <memory>

int main()
{
  float i[2];
  std::uninitialized_value_construct(&i, &i + 1);
}

The standard says this just uses a new-expression, but we have always
implemented it by a call to _Construct, which now fails in GCC 10.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug libstdc++/94831] [10 Regression] vector<float[2]> no longer compiles
  2020-04-28 19:45 [Bug libstdc++/94831] New: [10 Regression] vector<float[2]> no longer compiles redi at gcc dot gnu.org
  2020-04-28 19:46 ` [Bug libstdc++/94831] " redi at gcc dot gnu.org
  2020-04-28 20:01 ` redi at gcc dot gnu.org
@ 2020-04-28 21:39 ` redi at gcc dot gnu.org
  2020-04-28 22:48 ` cvs-commit at gcc dot gnu.org
  2020-04-28 22:54 ` redi at gcc dot gnu.org
  4 siblings, 0 replies; 6+ messages in thread
From: redi at gcc dot gnu.org @ 2020-04-28 21:39 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94831

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #0)
> In r277342 I changed std::_Construct for P0784R7, "More constexpr
> containers" and the non-void return type means this no longer compiles:
> 
> #include <vector>
> std::vector<float[2]> v(1);
> 
> This was never valid in C++98, and in C++11 to C++17 it's undefined (because
> the pseudo-destructor call in allocator_traits<std::allocator<T>>::destroy
> is ill-formed for arrays). But for libstdc++ it happened to compile, because
> we elide the calls to trivial destructors.

We should consider making this change in stage 1, to stop silently accepting
that non-standard code in strict mode:

--- a/libstdc++-v3/include/bits/alloc_traits.h
+++ b/libstdc++-v3/include/bits/alloc_traits.h
@@ -734,6 +734,10 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
     _Destroy(_ForwardIterator __first, _ForwardIterator __last,
             allocator<_Tp>&)
     {
+#if __cplusplus >= 201103L && defined __STRICT_ANSI__
+      static_assert(!is_array<_Tp>::value,
+         "arrays are not Erasable from containers using std::allocator");
+#endif
       _Destroy(__first, __last);
     }

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug libstdc++/94831] [10 Regression] vector<float[2]> no longer compiles
  2020-04-28 19:45 [Bug libstdc++/94831] New: [10 Regression] vector<float[2]> no longer compiles redi at gcc dot gnu.org
                   ` (2 preceding siblings ...)
  2020-04-28 21:39 ` redi at gcc dot gnu.org
@ 2020-04-28 22:48 ` cvs-commit at gcc dot gnu.org
  2020-04-28 22:54 ` redi at gcc dot gnu.org
  4 siblings, 0 replies; 6+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-04-28 22:48 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94831

--- Comment #3 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:162c40a4c127cc55d701bb8760e17708d0ca2fe0

commit r10-8021-g162c40a4c127cc55d701bb8760e17708d0ca2fe0
Author: Jonathan Wakely <jwakely@redhat.com>
Date:   Tue Apr 28 23:26:21 2020 +0100

    libstdc++: Fix regression in std::_Construct (PR 94831)

    By trying to reuse the existing std::_Construct function as a wrapper
    for std::construct_at I introduced regressions, because changing
    std::_Construct to return non-void made it ill-formed for array types.

    The solution is to revert _Construct to its former state, and change
    allocator_traits::construct to explicitly call construct_at instead.
    This decouples all the existing callers of _Construct from the new
    construct_at requirements.

            PR libstdc++/94831
            * include/bits/alloc_traits.h (_S_construct): Restore placement
            new-expression for C++11/14/17 and call std::construct_at directly
            for C++20.
            * include/bits/stl_construct.h (_Construct): Revert to
non-constexpr
            function returning void.
            * testsuite/20_util/specialized_algorithms/
            uninitialized_value_construct/94831.cc: New test.
            * testsuite/23_containers/vector/cons/94831.cc: New test.

^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug libstdc++/94831] [10 Regression] vector<float[2]> no longer compiles
  2020-04-28 19:45 [Bug libstdc++/94831] New: [10 Regression] vector<float[2]> no longer compiles redi at gcc dot gnu.org
                   ` (3 preceding siblings ...)
  2020-04-28 22:48 ` cvs-commit at gcc dot gnu.org
@ 2020-04-28 22:54 ` redi at gcc dot gnu.org
  4 siblings, 0 replies; 6+ messages in thread
From: redi at gcc dot gnu.org @ 2020-04-28 22:54 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94831

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|---                         |FIXED

--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Should now be fixed.

^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2020-04-28 22:54 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-04-28 19:45 [Bug libstdc++/94831] New: [10 Regression] vector<float[2]> no longer compiles redi at gcc dot gnu.org
2020-04-28 19:46 ` [Bug libstdc++/94831] " redi at gcc dot gnu.org
2020-04-28 20:01 ` redi at gcc dot gnu.org
2020-04-28 21:39 ` redi at gcc dot gnu.org
2020-04-28 22:48 ` cvs-commit at gcc dot gnu.org
2020-04-28 22:54 ` redi 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).