https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #52 from Jonathan Wakely ---
(In reply to Christopher Nerz from comment #45)
> This is a critical bug which renders gcc unusable for safety relevant
> systems using expected/variant or simple ipc.
I don't think your example
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #51 from Jonathan Wakely ---
(In reply to Richard Biener from comment #48)
> (In reply to Christopher Nerz from comment #47)
> > But shouldn't both give the same value?
>
> I'm not sure what the standard says to this. Does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #50 from rguenther at suse dot de ---
On Mon, 3 Jun 2024, Christopher.Nerz at de dot bosch.com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
>
> --- Comment #49 from Christopher Nerz
> ---
> Ah, misunderstood and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #49 from Christopher Nerz ---
Ah, misunderstood and therefore forgot optimization to a constant.
In the current code example, we have the problem that the (second)
initialization does not initialize with a value (ergo undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #48 from Richard Biener ---
(In reply to Christopher Nerz from comment #47)
> But shouldn't both give the same value?
I'm not sure what the standard says to this. Does std::launder(...)
sanitize earlier "undefined behavior"? For
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #47 from Christopher Nerz ---
But shouldn't both give the same value?
The return of the new and the std::launder(...) point to the same object and
are both equal read-operations! It is imho not predictable that they behave
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
Richard Biener changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
Christopher Nerz changed:
What|Removed |Added
CC||Christopher.Nerz at de dot
bosch.c
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #43 from Richard Biener ---
(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 example and remove the placement new.
> > Does that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #42 from Richard Biener ---
See PR101641 for an interesting case where eliding a round-trip causes
wrong-code generation. It's union related so might not apply 1:1 to C++.
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #40 from rguenther at suse dot de ---
On Mon, 15 Jun 2020, richard-gccbugzilla at metafoo dot co.uk wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
>
> --- Comment #37 from Richard Smith
> ---
> (In reply to Richard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #39 from rguenther at suse dot de ---
On Tue, 16 Jun 2020, andrew2085 at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
>
> --- Comment #38 from Andrew Downing ---
> > int *p;
> > int x;
> > if ()
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #38 from Andrew Downing ---
> int *p;
> int x;
> if ()
>p =
> 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 #37 from Richard Smith
---
(In reply to Richard Biener from comment #36)
> The main issue I see is that this differing expectations of C and C++ are
> impossible to get correct at the same time.
That is a rather bold claim. I think
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #36 from Richard Biener ---
(In reply to Andrew Downing from comment #35)
> 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
>
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #34 from Richard Biener ---
(In reply to Andrew Downing from comment #33)
> 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
>
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #32 from rguenther at suse dot de ---
On Thu, 4 Jun 2020, andrew2085 at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
>
> --- Comment #31 from Andrew Downing ---
> What would you say is the solution
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 #30 from Richard Biener ---
(In reply to Andrew Downing from comment #29)
> 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
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
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 #27 from rguenther at suse dot de ---
On June 2, 2020 6:34:12 PM GMT+02:00, andrew2085 at gmail dot com
wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
>
>--- Comment #25 from Andrew Downing ---
>Do you know how to
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 #24 from rguenther at suse dot de ---
On Tue, 2 Jun 2020, andrew2085 at gmail dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
>
> --- Comment #23 from Andrew Downing ---
> But gcc already can implement
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #22 from Richard Biener ---
(In reply to Richard Smith from comment #20)
> (In reply to Andrew Downing from comment #19)
> > Not that it would make a difference in this particular situation, but is the
> > intent of P0593R6 to only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #21 from Richard Biener ---
(In reply to Andrew Downing from comment #15)
> This is all kind of besides the point anyway though, because gcc is handling
> everything ok except for std::launder. std::launder is only supposed to be
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #20 from Richard Smith
---
(In reply to Andrew Downing from comment #19)
> 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
>
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #18 from Richard Smith
---
(In reply to Andrew Downing from comment #17)
> 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
>
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #16 from Richard Smith
---
Per p0593, memcpy implicitly creates objects (of any implicit lifetime type) in
the destination. It does not propagate the objects in the source memory to the
destination memory, and can therefore be used
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
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #14 from rguenther at suse dot de ---
On Fri, 29 May 2020, ed at catmur dot uk wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
>
> --- Comment #12 from Ed Catmur ---
> (In reply to Richard Biener from comment #11)
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
Jonathan Wakely changed:
What|Removed |Added
CC||richard-gccbugzilla@metafoo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #12 from Ed Catmur ---
(In reply to Richard Biener from comment #11)
> Note that for C++ types you can apply memcpy to the placement new is not
> needed since object re-use terminates lifetime of the previous object and
> starts
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #11 from Richard Biener ---
(In reply to Ed Catmur from comment #9)
> (In reply to Jonathan Wakely from comment #4)
> > I don't know the answer, and I don't know why it's useful to try this
> > anyway.
>
> If I'm reading P0593
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #10 from Richard Biener ---
(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
> memmove, or is copied as an array of character type, then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #9 from Ed Catmur ---
(In reply to Jonathan Wakely from comment #4)
> I don't know the answer, and I don't know why it's useful to try this anyway.
If I'm reading P0593 correctly (I may not be), this would be a valid
implementation
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #6 from Jonathan Wakely ---
(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 object has already explicitly
> created in that
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
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #4 from Jonathan Wakely ---
I don't know the answer, and I don't know why it's useful to try this anyway.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #3 from rguenther at suse dot de ---
On Wed, 27 May 2020, redi at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
>
> --- Comment #2 from Jonathan Wakely ---
> Using
>
> auto t = new(p)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
--- Comment #2 from Jonathan Wakely ---
Using
auto t = new(p) std::uint64_t;
std::memcpy(t, std::launder(storage), sizeof(storage));
return t;
also prevents GCC from propagating the dynamic type of p to t.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95349
Richard Biener changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
52 matches
Mail list logo
