https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #44 from Andrew Downing ---
(In reply to Richard Biener from comment #43)
> (In reply to Andrew Downing from comment #41)
> > > Thus for types without a non-trivial ctor/dtor you do not need to use
> > > placement new. So take your e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #41 from Andrew Downing ---
> Thus for types without a non-trivial ctor/dtor you do not need to use
> placement new. So take your example and remove the placement new.
> Does that change its semantics?
These are C++17 rules.
4.5/1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #38 from Andrew Downing ---
> int *p;
> int x;
> if ()
>p = &x;
> else
>p = malloc (4);
> memcpy (p, q, 4);
>
> there is a single memcpy call and the standard says that both the dynamic
> type transfers (from q) and that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #35 from Andrew Downing ---
I agree that the new implicit object creation rules sound very difficult to
implement correctly especially because the behavior in C is different. I'm
curious to see how that will all play out.
In this sit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #33 from Andrew Downing ---
Those are all perfectly good arguments, but the problem ended up not having
anything to do with std::launder or new implicit object creation rules or
anything else introduced in the most recent standards ri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #31 from Andrew Downing ---
What would you say is the solution here? There's a disconnect between what the
c++ standard says should work, and what actually works.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #29 from Andrew Downing ---
So I think this sort of equivalent example in C shows what's going wrong in the
C++ example. https://godbolt.org/z/ZMz4Cp
gcc knows that if the object mem points to is modified inside pun() its
effective t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #28 from Andrew Downing ---
Hey that's cheating, but yea the second part did it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #26 from Andrew Downing ---
I mean without modifying the definition of start_lifetime_as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #25 from Andrew Downing ---
Do you know how to change that example so that gcc's knowledge is incomplete
and it not longer does the correct thing?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #23 from Andrew Downing ---
But gcc already can implement std::start_lifetime_as with no overhead.
https://godbolt.org/z/YdoEcH
My intent wasn't to draw attention to std::start_lifetime_as in this bug
report, I only mentioned it as t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #19 from Andrew Downing ---
Not that it would make a difference in this particular situation, but is the
intent of P0593R6 to only allow implicitly creating an object in the relevant
storage location where one hasn't already been impl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #17 from Andrew Downing ---
Also none of the behavior described in p0593 is required for this C++ program
to be well defined. All objects that are required to exists here are created
explicitly. It's not relying on the implicit creati
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #15 from Andrew Downing ---
(In reply to Richard Biener from comment #10)
> (In reply to Andrew Downing from comment #8)
> > From the C standard:
> > If a value is copied into an object having no declared type using memcpy or
> > memm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #8 from Andrew Downing ---
>From the C standard:
If a value is copied into an object having no declared type using memcpy or
memmove, or is copied as an array of character type, then the effective type of
the modified object for that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #7 from Andrew Downing ---
(In reply to Jonathan Wakely from comment #6)
> (In reply to Andrew Downing from comment #5)
> > Also, I'm not sure if operations that implicitly create
> > objects in storage are allowed to do so if an obje
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #5 from Andrew Downing ---
(In reply to Richard Biener from comment #1)
> I think std::launder merely acts as optimization barrier here and without we
> manage to propagate the constant. We still "miscompile" things dependent on
> wh
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: andrew2085 at gmail dot com
Target Milestone: ---
Created attachment 48609
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48609&action=edit
preproce
18 matches
Mail list logo
