Hello,

is there any drawback to the attached patch? It changes the code generated for

std::optional<std::array<int,1024>>f(){return{};}

from

        movq    $0, (%rdi)
        movq    %rdi, %r8
        leaq    8(%rdi), %rdi
        xorl    %eax, %eax
        movq    $0, 4084(%rdi)
        movq    %r8, %rcx
        andq    $-8, %rdi
        subq    %rdi, %rcx
        addl    $4100, %ecx
        shrl    $3, %ecx
        rep stosq
        movq    %r8, %rax

or with different tuning

        subq    $8, %rsp
        movl    $4100, %edx
        xorl    %esi, %esi
        call    memset
        addq    $8, %rsp

to the much shorter

        movb    $0, 4096(%rdi)
        movq    %rdi, %rax

i.e. the same as the nullopt constructor.

The constructor was already non-trivial, so we don't lose that. It passes the
testsuite without regression. I thought I remembered there was a reason not to
do this...

2020-06-04  Marc Glisse  <marc.gli...@inria.fr>

        * include/std/optional (optional()): Explicitly define it.

(I don't currently have a setup that would enable me to commit anything. I'll
try to fix it eventually, but likely not so soon)

--
Marc Glisse
diff --git a/libstdc++-v3/include/std/optional b/libstdc++-v3/include/std/optional
index 37c2ba7a025..e84ba28a806 100644
--- a/libstdc++-v3/include/std/optional
+++ b/libstdc++-v3/include/std/optional
@@ -688,7 +688,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
     public:
       using value_type = _Tp;
 
-      constexpr optional() = default;
+      constexpr optional() noexcept { }
 
       constexpr optional(nullopt_t) noexcept { }
 

Reply via email to