Hi,
On Mon, 28 Jan 2019, Richard Biener wrote:
> > - MEM[(struct &)&buf1] ={v} {CLOBBER};
> > + buf1 ={v} {CLOBBER};
>
> Eww :/ That means they are not semantically the same which IMHO is
> bad.
But they really are different. One is saying "these bytes contain nothing
anymore", the other
On Mon, Jan 28, 2019 at 8:52 AM Jonathan Wakely wrote:
>
> On 28/01/19 14:29 +0100, Jakub Jelinek wrote:
> >On Mon, Jan 28, 2019 at 01:55:38PM +0100, Richard Biener wrote:
> >> So I guess in the end we're being lucky. Somehow. I've played with
> >>
> >> __attribute__((noipa)) void
> >> qux ()
>
On 28/01/19 14:29 +0100, Jakub Jelinek wrote:
On Mon, Jan 28, 2019 at 01:55:38PM +0100, Richard Biener wrote:
So I guess in the end we're being lucky. Somehow. I've played with
__attribute__((noipa)) void
qux ()
{
S buf1;
foo ((char *)&buf1);
S *p = new (&buf1) (S);
bar (p);
p->~S (
On Mon, Jan 28, 2019 at 01:55:38PM +0100, Richard Biener wrote:
> So I guess in the end we're being lucky. Somehow. I've played with
>
> __attribute__((noipa)) void
> qux ()
> {
> S buf1;
> foo ((char *)&buf1);
> S *p = new (&buf1) (S);
> bar (p);
> p->~S ();
> {
> char buf2[128]
On Mon, 28 Jan 2019, Jakub Jelinek wrote:
> On Mon, Jan 28, 2019 at 01:18:43PM +0100, Richard Biener wrote:
> > Eww :/ That means they are not semantically the same which IMHO is
> > bad. If you make buf1 volatile does it trip over
> > maybe_canonicalize_mem_ref_addr and miscompile? Or are we s
On Mon, Jan 28, 2019 at 01:18:43PM +0100, Richard Biener wrote:
> Eww :/ That means they are not semantically the same which IMHO is
> bad. If you make buf1 volatile does it trip over
> maybe_canonicalize_mem_ref_addr and miscompile? Or are we somehow
If buf1 is volatile, then no clobbers are a
On Mon, 28 Jan 2019, Jakub Jelinek wrote:
> Hi!
>
> While thinking about PR59813, I came up with following testcase.
> Is that valid C++?
>
> What I want to highlight here that we need to treat the clobbers created
> for C++ destructors differently from clobbers added for when variables go
> out
Hi!
While thinking about PR59813, I came up with following testcase.
Is that valid C++?
What I want to highlight here that we need to treat the clobbers created
for C++ destructors differently from clobbers added for when variables go
out of scope.
Right now we end up with:
char buf2[128];
ch