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 { }