On 04/06/20 14:46 +0100, Jonathan Wakely wrote:
On 04/06/20 00:50 +0200, Marc Glisse wrote:
(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)
Ah, I missed this bit. I'll take care of it for you.
If it's due to the G
On 04/06/20 00:50 +0200, Marc Glisse wrote:
(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)
Ah, I missed this bit. I'll take care of it for you.
If it's due to the Git conversion let me know if it's something I can
On 04/06/20 10:34 +0300, Ville Voutilainen via Libstdc++ wrote:
On Thu, 4 Jun 2020 at 10:22, Marc Glisse wrote:
> So the change is correct. Can we test the change somehow?
It passes the testsuite, and libc++ has been doing it this way for years.
What I feared was some regression where it woul
On 04/06/20 13:41 +0200, Richard Biener via Libstdc++ wrote:
On Thu, Jun 4, 2020 at 11:34 AM Ville Voutilainen via Gcc-patches
wrote:
On Thu, 4 Jun 2020 at 11:53, Marc Glisse wrote:
>
> On Thu, 4 Jun 2020, Ville Voutilainen wrote:
>
> > On Thu, 4 Jun 2020 at 11:00, Marc Glisse wrote:
> >> Ma
On Thu, 4 Jun 2020, Richard Biener wrote:
On Thu, Jun 4, 2020 at 11:34 AM Ville Voutilainen via Gcc-patches
wrote:
On Thu, 4 Jun 2020 at 11:53, Marc Glisse wrote:
On Thu, 4 Jun 2020, Ville Voutilainen wrote:
On Thu, 4 Jun 2020 at 11:00, Marc Glisse wrote:
Maybe create a buffer, fill it
On Thu, 4 Jun 2020, Ville Voutilainen wrote:
On Thu, 4 Jun 2020 at 11:53, Marc Glisse wrote:
On Thu, 4 Jun 2020, Ville Voutilainen wrote:
On Thu, 4 Jun 2020 at 11:00, Marc Glisse wrote:
Maybe create a buffer, fill it with some non-zero values (-1?), then call
placement new, and read some
On Thu, 4 Jun 2020 at 14:41, Richard Biener wrote:
> Doesn't the placement new make the memory state of anything
> not explicitely initialized indeterminate? That is, isn't the
> testcase broken anyways since GCC can elide the memset
> when seeing the placement new?
Hmm, yes it does, and the tes
On Thu, Jun 4, 2020 at 11:34 AM Ville Voutilainen via Gcc-patches
wrote:
>
> On Thu, 4 Jun 2020 at 11:53, Marc Glisse wrote:
> >
> > On Thu, 4 Jun 2020, Ville Voutilainen wrote:
> >
> > > On Thu, 4 Jun 2020 at 11:00, Marc Glisse wrote:
> > >> Maybe create a buffer, fill it with some non-zero val
On Thu, 4 Jun 2020 at 11:53, Marc Glisse wrote:
>
> On Thu, 4 Jun 2020, Ville Voutilainen wrote:
>
> > On Thu, 4 Jun 2020 at 11:00, Marc Glisse wrote:
> >> Maybe create a buffer, fill it with some non-zero values (-1?), then call
> >> placement new, and read some value in the middle of the buffer
On Thu, 4 Jun 2020, Ville Voutilainen wrote:
On Thu, 4 Jun 2020 at 11:00, Marc Glisse wrote:
Maybe create a buffer, fill it with some non-zero values (-1?), then call
placement new, and read some value in the middle of the buffer, possibly
with some protection against optimizations? Ah, no, ac
On Thu, 4 Jun 2020 at 11:00, Marc Glisse wrote:
> Maybe create a buffer, fill it with some non-zero values (-1?), then call
> placement new, and read some value in the middle of the buffer, possibly
> with some protection against optimizations? Ah, no, actual constructors
> are fine, it is only th
On Thu, 4 Jun 2020, Ville Voutilainen wrote:
Right, I was just wondering whether we can reasonably verify in a test
that the whole shebang is not zeroed. That may need a tree-dump scan in
the test, and probably should go into PR86173 anyway, so I'm not saying
such a thing needs to be a part of
On Thu, 4 Jun 2020 at 10:22, Marc Glisse wrote:
> > So the change is correct. Can we test the change somehow?
>
> It passes the testsuite, and libc++ has been doing it this way for years.
> What I feared was some regression where it would yield worse code in some
> cases, or lose some property (n
On Thu, 4 Jun 2020, Ville Voutilainen wrote:
On Thu, 4 Jun 2020 at 03:05, Ville Voutilainen
wrote:
"noexcept" is a red herring, what matters is defaulted vs user-provided.
In one case, we end up zero-initializing the whole buffer, and not in the
other.
Yes, I just came to that conclusion. T
On Thu, 4 Jun 2020 at 03:05, Ville Voutilainen
wrote:
> > > "noexcept" is a red herring, what matters is defaulted vs user-provided.
> > > In one case, we end up zero-initializing the whole buffer, and not in the
> > > other.
> >
> > Yes, I just came to that conclusion. This is value-init, so the
On Thu, 4 Jun 2020 at 02:20, Ville Voutilainen
wrote:
>
> On Thu, 4 Jun 2020 at 02:13, Marc Glisse wrote:
> >
> > On Thu, 4 Jun 2020, Ville Voutilainen wrote:
> >
> > > On Thu, 4 Jun 2020 at 01:52, Marc Glisse wrote:
> > >>
> > >> Hello,
> > >>
> > >> is there any drawback to the attached patch?
On Thu, 4 Jun 2020 at 02:13, Marc Glisse wrote:
>
> On Thu, 4 Jun 2020, Ville Voutilainen wrote:
>
> > On Thu, 4 Jun 2020 at 01:52, Marc Glisse wrote:
> >>
> >> Hello,
> >>
> >> is there any drawback to the attached patch? It changes the code generated
> >> for
> >
> > I don't get it. The noexce
On Thu, 4 Jun 2020, Ville Voutilainen wrote:
On Thu, 4 Jun 2020 at 01:52, Marc Glisse wrote:
Hello,
is there any drawback to the attached patch? It changes the code generated for
I don't get it. The noexceptness of the defaulted default constructor
should be a computation
of the noexceptne
On Thu, 4 Jun 2020 at 01:52, Marc Glisse wrote:
>
> Hello,
>
> is there any drawback to the attached patch? It changes the code generated for
I don't get it. The noexceptness of the defaulted default constructor
should be a computation
of the noexceptness of the subobjects, and that should boil d
Hello,
is there any drawback to the attached patch? It changes the code generated for
std::optional>f(){return{};}
from
movq$0, (%rdi)
movq%rdi, %r8
leaq8(%rdi), %rdi
xorl%eax, %eax
movq$0, 4084(%rdi)
movq%r8, %rcx
20 matches
Mail list logo
