public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/102090] New: Placement-new is not constexpr
@ 2021-08-27 3:29 friedkeenan at protonmail dot com
2021-08-27 3:42 ` [Bug libstdc++/102090] " pinskia at gcc dot gnu.org
` (8 more replies)
0 siblings, 9 replies; 10+ messages in thread
From: friedkeenan at protonmail dot com @ 2021-08-27 3:29 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102090
Bug ID: 102090
Summary: Placement-new is not constexpr
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: friedkeenan at protonmail dot com
Target Milestone: ---
When calling placement-new in a constant expression, a compiler error occurs
saying that `void* operator new(std::size_t, void*)` is not constexpr; see
https://godbolt.org/z/8enoG9G57 for a minimal example.
As far as I can tell, the fix should just be adding constexpr to the signature.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug libstdc++/102090] Placement-new is not constexpr
2021-08-27 3:29 [Bug libstdc++/102090] New: Placement-new is not constexpr friedkeenan at protonmail dot com
@ 2021-08-27 3:42 ` pinskia at gcc dot gnu.org
2021-08-27 3:43 ` pinskia at gcc dot gnu.org
` (7 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-08-27 3:42 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102090
--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I don't think inplacement new is valid for constexpr. See PR 61105 also.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug libstdc++/102090] Placement-new is not constexpr
2021-08-27 3:29 [Bug libstdc++/102090] New: Placement-new is not constexpr friedkeenan at protonmail dot com
2021-08-27 3:42 ` [Bug libstdc++/102090] " pinskia at gcc dot gnu.org
@ 2021-08-27 3:43 ` pinskia at gcc dot gnu.org
2021-08-27 3:45 ` pinskia at gcc dot gnu.org
` (6 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-08-27 3:43 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102090
--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
clang produces:
<source>:3:16: error: consteval function never produces a constant expression
[-Winvalid-constexpr]
consteval auto fuck() {
^
<source>:5:23: note: call to placement 'operator new'
const auto data = new(buf) int(1);
^
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug libstdc++/102090] Placement-new is not constexpr
2021-08-27 3:29 [Bug libstdc++/102090] New: Placement-new is not constexpr friedkeenan at protonmail dot com
2021-08-27 3:42 ` [Bug libstdc++/102090] " pinskia at gcc dot gnu.org
2021-08-27 3:43 ` pinskia at gcc dot gnu.org
@ 2021-08-27 3:45 ` pinskia at gcc dot gnu.org
2021-08-27 3:52 ` friedkeenan at protonmail dot com
` (5 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-08-27 3:45 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102090
--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
DR 1312 also mentions something similar with respect to casting to void*.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug libstdc++/102090] Placement-new is not constexpr
2021-08-27 3:29 [Bug libstdc++/102090] New: Placement-new is not constexpr friedkeenan at protonmail dot com
` (2 preceding siblings ...)
2021-08-27 3:45 ` pinskia at gcc dot gnu.org
@ 2021-08-27 3:52 ` friedkeenan at protonmail dot com
2021-08-27 4:00 ` pinskia at gcc dot gnu.org
` (4 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: friedkeenan at protonmail dot com @ 2021-08-27 3:52 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102090
--- Comment #4 from friedkeenan at protonmail dot com ---
I think you're correct. That's really strange, but I guess that's what
std::construct_at is for? But that also confuses me, how is GCC's
implementation of std::construct_at working if placement-new isn't constexpr:
https://github.com/gcc-mirror/gcc/blob/16e2427f50c208dfe07d07f18009969502c25dc8/libstdc%2B%2B-v3/include/bits/stl_construct.h#L97
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug libstdc++/102090] Placement-new is not constexpr
2021-08-27 3:29 [Bug libstdc++/102090] New: Placement-new is not constexpr friedkeenan at protonmail dot com
` (3 preceding siblings ...)
2021-08-27 3:52 ` friedkeenan at protonmail dot com
@ 2021-08-27 4:00 ` pinskia at gcc dot gnu.org
2021-08-27 8:47 ` jakub at gcc dot gnu.org
` (3 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-08-27 4:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102090
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |INVALID
Status|UNCONFIRMED |RESOLVED
--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I know cppreference is not the standard but from:
https://en.cppreference.com/w/cpp/memory/construct_at
except that construct_at may be used in evaluation of constant expressions.
(In reply to friedkeenan from comment #4)
> I think you're correct. That's really strange, but I guess that's what
> std::construct_at is for? But that also confuses me, how is GCC's
> implementation of std::construct_at working if placement-new isn't
> constexpr:
> https://github.com/gcc-mirror/gcc/blob/
> 16e2427f50c208dfe07d07f18009969502c25dc8/libstdc%2B%2B-v3/include/bits/
> stl_construct.h#L97
Because it is still broken ...
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug libstdc++/102090] Placement-new is not constexpr
2021-08-27 3:29 [Bug libstdc++/102090] New: Placement-new is not constexpr friedkeenan at protonmail dot com
` (4 preceding siblings ...)
2021-08-27 4:00 ` pinskia at gcc dot gnu.org
@ 2021-08-27 8:47 ` jakub at gcc dot gnu.org
2021-08-27 8:48 ` jakub at gcc dot gnu.org
` (2 subsequent siblings)
8 siblings, 0 replies; 10+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-08-27 8:47 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102090
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
It is not broken. The C++ FE knows std::construct_at is special and allows
placement new in there as implementation detail in constant expressions.
See uses of is_std_construct_at in gcc/cp/constexpr.c.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug libstdc++/102090] Placement-new is not constexpr
2021-08-27 3:29 [Bug libstdc++/102090] New: Placement-new is not constexpr friedkeenan at protonmail dot com
` (5 preceding siblings ...)
2021-08-27 8:47 ` jakub at gcc dot gnu.org
@ 2021-08-27 8:48 ` jakub at gcc dot gnu.org
2021-08-27 15:26 ` friedkeenan at protonmail dot com
2021-08-27 18:44 ` jakub at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-08-27 8:48 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102090
--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
http://eel.is/c++draft/new.syn doesn't say placement new should be constexpr.
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug libstdc++/102090] Placement-new is not constexpr
2021-08-27 3:29 [Bug libstdc++/102090] New: Placement-new is not constexpr friedkeenan at protonmail dot com
` (6 preceding siblings ...)
2021-08-27 8:48 ` jakub at gcc dot gnu.org
@ 2021-08-27 15:26 ` friedkeenan at protonmail dot com
2021-08-27 18:44 ` jakub at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: friedkeenan at protonmail dot com @ 2021-08-27 15:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102090
--- Comment #8 from friedkeenan at protonmail dot com ---
Sorry for wasting your time with this bug report. It just didn't make sense to
me why placement-new couldn't be constexpr
^ permalink raw reply [flat|nested] 10+ messages in thread
* [Bug libstdc++/102090] Placement-new is not constexpr
2021-08-27 3:29 [Bug libstdc++/102090] New: Placement-new is not constexpr friedkeenan at protonmail dot com
` (7 preceding siblings ...)
2021-08-27 15:26 ` friedkeenan at protonmail dot com
@ 2021-08-27 18:44 ` jakub at gcc dot gnu.org
8 siblings, 0 replies; 10+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-08-27 18:44 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102090
--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
One of the reasons might be that placement new returns void *, and cast of that
to pointer to some other type is not valid in constant expressions.
std::construct_at bypasses all of that just by being a magic function, it is up
to the implementation how it achieves what it is supposed to do.
^ permalink raw reply [flat|nested] 10+ messages in thread
end of thread, other threads:[~2021-08-27 18:44 UTC | newest]
Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-08-27 3:29 [Bug libstdc++/102090] New: Placement-new is not constexpr friedkeenan at protonmail dot com
2021-08-27 3:42 ` [Bug libstdc++/102090] " pinskia at gcc dot gnu.org
2021-08-27 3:43 ` pinskia at gcc dot gnu.org
2021-08-27 3:45 ` pinskia at gcc dot gnu.org
2021-08-27 3:52 ` friedkeenan at protonmail dot com
2021-08-27 4:00 ` pinskia at gcc dot gnu.org
2021-08-27 8:47 ` jakub at gcc dot gnu.org
2021-08-27 8:48 ` jakub at gcc dot gnu.org
2021-08-27 15:26 ` friedkeenan at protonmail dot com
2021-08-27 18:44 ` jakub at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).