public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/96416] New: address_of() is broken by static_assert in pointer_traits
@ 2020-08-02 4:17 whatwasthataddress at gmail dot com
2020-08-03 12:58 ` [Bug libstdc++/96416] " redi at gcc dot gnu.org
` (26 more replies)
0 siblings, 27 replies; 28+ messages in thread
From: whatwasthataddress at gmail dot com @ 2020-08-02 4:17 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
Bug ID: 96416
Summary: address_of() is broken by static_assert in
pointer_traits
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: whatwasthataddress at gmail dot com
Target Milestone: ---
pointer_traits contains this static_assert:
static_assert(!is_same<element_type, __undefined>::value,
"pointer type defines element_type or is like SomePointer<T, Args>");
When trying to use address_of() with an iterator that has a usable
operator->(), address_of() fails because the static_assert causes a hard error
in the trailing decltype here:
template<typename _Ptr>
constexpr auto
__to_address(const _Ptr& __ptr) noexcept
-> decltype(std::pointer_traits<_Ptr>::to_address(__ptr))
{ return std::pointer_traits<_Ptr>::to_address(__ptr); }
template<typename _Ptr, typename... _None>
constexpr auto
__to_address(const _Ptr& __ptr, _None...) noexcept
{
if constexpr (is_base_of_v<__gnu_debug::_Safe_iterator_base, _Ptr>)
return std::__to_address(__ptr.base().operator->());
else
return std::__to_address(__ptr.operator->());
}
When I comment out the static_assert, to_address() works with the iterator in
question.
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/96416] address_of() is broken by static_assert in pointer_traits
2020-08-02 4:17 [Bug libstdc++/96416] New: address_of() is broken by static_assert in pointer_traits whatwasthataddress at gmail dot com
@ 2020-08-03 12:58 ` redi at gcc dot gnu.org
2020-08-03 15:34 ` whatwasthataddress at gmail dot com
` (25 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: redi at gcc dot gnu.org @ 2020-08-03 12:58 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I think this is the "correct" behaviour.
The specification of pointer_traits<Ptr>::element_type says that if
Ptr::element_type isn't valid, and Ptr isn't a template that can be "rebound",
then "otherwise, the specialization is ill-formed."
This explicitly says "the specialization" (meaning pointer_traits<Ptr> itself).
Compare this with th rebind member which only says "the instantiation of rebind
is ill-formed".
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/96416] address_of() is broken by static_assert in pointer_traits
2020-08-02 4:17 [Bug libstdc++/96416] New: address_of() is broken by static_assert in pointer_traits whatwasthataddress at gmail dot com
2020-08-03 12:58 ` [Bug libstdc++/96416] " redi at gcc dot gnu.org
@ 2020-08-03 15:34 ` whatwasthataddress at gmail dot com
2020-08-03 15:38 ` redi at gcc dot gnu.org
` (24 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: whatwasthataddress at gmail dot com @ 2020-08-03 15:34 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
--- Comment #2 from Zach Laine <whatwasthataddress at gmail dot com> ---
Fair enough. [pointer.conversion] says that to_pointer(const Ptr& p) is
"pointer_traits<Ptr>::to_address(p) if that expression is well-formed (see
[pointer.traits.optmem]), otherwise to_address(p.operator->())". Do we then
have a spec bug?
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/96416] address_of() is broken by static_assert in pointer_traits
2020-08-02 4:17 [Bug libstdc++/96416] New: address_of() is broken by static_assert in pointer_traits whatwasthataddress at gmail dot com
2020-08-03 12:58 ` [Bug libstdc++/96416] " redi at gcc dot gnu.org
2020-08-03 15:34 ` whatwasthataddress at gmail dot com
@ 2020-08-03 15:38 ` redi at gcc dot gnu.org
2020-11-11 17:46 ` redi at gcc dot gnu.org
` (23 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: redi at gcc dot gnu.org @ 2020-08-03 15:38 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Ugh, yes, I think we do.
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/96416] address_of() is broken by static_assert in pointer_traits
2020-08-02 4:17 [Bug libstdc++/96416] New: address_of() is broken by static_assert in pointer_traits whatwasthataddress at gmail dot com
` (2 preceding siblings ...)
2020-08-03 15:38 ` redi at gcc dot gnu.org
@ 2020-11-11 17:46 ` redi at gcc dot gnu.org
2020-11-11 18:52 ` redi at gcc dot gnu.org
` (22 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: redi at gcc dot gnu.org @ 2020-11-11 17:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2020-11-11
Ever confirmed|0 |1
Target Milestone|--- |10.3
--- Comment #4 from Jonathan Wakely <redi at gcc dot gnu.org> ---
On reading this again, I think the implementation should be required to check
whether the specialization pointer_traits<Ptr> would be well-formed as part
of checking the expression pointer_traits<Ptr>::to_address(p).
So it's unnecessarily awkward, but still the implementation's job to do that.
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/96416] address_of() is broken by static_assert in pointer_traits
2020-08-02 4:17 [Bug libstdc++/96416] New: address_of() is broken by static_assert in pointer_traits whatwasthataddress at gmail dot com
` (3 preceding siblings ...)
2020-11-11 17:46 ` redi at gcc dot gnu.org
@ 2020-11-11 18:52 ` redi at gcc dot gnu.org
2020-11-11 19:10 ` redi at gcc dot gnu.org
` (21 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: redi at gcc dot gnu.org @ 2020-11-11 18:52 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
But on third thoughts, I don't know how to implement this reliably.
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/96416] address_of() is broken by static_assert in pointer_traits
2020-08-02 4:17 [Bug libstdc++/96416] New: address_of() is broken by static_assert in pointer_traits whatwasthataddress at gmail dot com
` (4 preceding siblings ...)
2020-11-11 18:52 ` redi at gcc dot gnu.org
@ 2020-11-11 19:10 ` redi at gcc dot gnu.org
2020-11-11 20:05 ` glenjofe at gmail dot com
` (20 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: redi at gcc dot gnu.org @ 2020-11-11 19:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |NEW
Assignee|redi at gcc dot gnu.org |unassigned at gcc dot gnu.org
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/96416] address_of() is broken by static_assert in pointer_traits
2020-08-02 4:17 [Bug libstdc++/96416] New: address_of() is broken by static_assert in pointer_traits whatwasthataddress at gmail dot com
` (5 preceding siblings ...)
2020-11-11 19:10 ` redi at gcc dot gnu.org
@ 2020-11-11 20:05 ` glenjofe at gmail dot com
2020-11-11 20:40 ` redi at gcc dot gnu.org
` (19 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: glenjofe at gmail dot com @ 2020-11-11 20:05 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
Glen Joseph Fernandes <glenjofe at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |glenjofe at gmail dot com
--- Comment #6 from Glen Joseph Fernandes <glenjofe at gmail dot com> ---
> Do we then have a spec bug?
The to_address(const P&) overload always assumed a valid pointer_traits<P>.
Even before it was std::to_address in C++20, when it was __to_address in
libstdc++, or boost::to_address, or __to_raw_pointer in libc++, and was used in
C++11 and above, its return type was 'typename
std::pointer_traits<P>::element_type*' which requires a valid pointer_traits.
i.e. Our allocator-aware containers would only ever work with fancy pointer P
for which pointer_traits<P> is valid.
std::to_address being used for more than just raw-or-fancy-pointers came later
(since Casey's P1474 which chose to use it for contiguous iterators). My guess
is they didn't realize pointer_traits<I> wouldn't be valid for those iterator
types.
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/96416] address_of() is broken by static_assert in pointer_traits
2020-08-02 4:17 [Bug libstdc++/96416] New: address_of() is broken by static_assert in pointer_traits whatwasthataddress at gmail dot com
` (6 preceding siblings ...)
2020-11-11 20:05 ` glenjofe at gmail dot com
@ 2020-11-11 20:40 ` redi at gcc dot gnu.org
2020-11-11 20:41 ` redi at gcc dot gnu.org
` (18 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: redi at gcc dot gnu.org @ 2020-11-11 20:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |INVALID
--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Thanks, Glen. So it seems I was right the first time, and using std::to_address
does require a type that can be used with std::pointer_traits.
Not a bug then. Sorry, Zach!
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/96416] address_of() is broken by static_assert in pointer_traits
2020-08-02 4:17 [Bug libstdc++/96416] New: address_of() is broken by static_assert in pointer_traits whatwasthataddress at gmail dot com
` (7 preceding siblings ...)
2020-11-11 20:40 ` redi at gcc dot gnu.org
@ 2020-11-11 20:41 ` redi at gcc dot gnu.org
2021-03-26 14:19 ` dangelog at gmail dot com
` (17 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: redi at gcc dot gnu.org @ 2020-11-11 20:41 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I suppose I could change the static_assert message to also suggest defining
your own specialization of std::pointer_traits, which is another way to make it
work.
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/96416] address_of() is broken by static_assert in pointer_traits
2020-08-02 4:17 [Bug libstdc++/96416] New: address_of() is broken by static_assert in pointer_traits whatwasthataddress at gmail dot com
` (8 preceding siblings ...)
2020-11-11 20:41 ` redi at gcc dot gnu.org
@ 2021-03-26 14:19 ` dangelog at gmail dot com
2021-03-26 14:45 ` dangelog at gmail dot com
` (16 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: dangelog at gmail dot com @ 2021-03-26 14:19 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
Giuseppe D'Angelo <dangelog at gmail dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |dangelog at gmail dot com
--- Comment #9 from Giuseppe D'Angelo <dangelog at gmail dot com> ---
Hi,
Stumbled across this indeed when trying to use contiguous iterators.
Sure enough, pointer_traits for them is ill-formed. But then I don't understand
why the "otherwise to_address(p.operator->())" part is in the Standard at all,
if it can never be used.
Has this been raised as a library defect?
And are you recommending that everyone who defines their custom contiguous
iterators specializes pointer_traits for them? Call it _quite_ annoying...
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/96416] address_of() is broken by static_assert in pointer_traits
2020-08-02 4:17 [Bug libstdc++/96416] New: address_of() is broken by static_assert in pointer_traits whatwasthataddress at gmail dot com
` (9 preceding siblings ...)
2021-03-26 14:19 ` dangelog at gmail dot com
@ 2021-03-26 14:45 ` dangelog at gmail dot com
2021-03-26 23:44 ` glenjofe at gmail dot com
` (15 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: dangelog at gmail dot com @ 2021-03-26 14:45 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
--- Comment #10 from Giuseppe D'Angelo <dangelog at gmail dot com> ---
(By the way, finding this bug is quite hard. Could "address_of" be changed to
"to_address" , in the bug description? I think that's the intended meaning.
And, "to_pointer", mentioned a few times, doesn't exist.)
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/96416] address_of() is broken by static_assert in pointer_traits
2020-08-02 4:17 [Bug libstdc++/96416] New: address_of() is broken by static_assert in pointer_traits whatwasthataddress at gmail dot com
` (10 preceding siblings ...)
2021-03-26 14:45 ` dangelog at gmail dot com
@ 2021-03-26 23:44 ` glenjofe at gmail dot com
2021-03-27 0:48 ` [Bug libstdc++/96416] to_address() " redi at gcc dot gnu.org
` (14 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: glenjofe at gmail dot com @ 2021-03-26 23:44 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
--- Comment #11 from Glen Joseph Fernandes <glenjofe at gmail dot com> ---
> if it can never be used.
You're misunderstanding. to_address(p) requires that pointer_traits<P> is
valid. It just doesn't need to have a to_address member function.
Example 1. You have a pointer-like type Ptr1. You haven't specialized
pointer_traits<Ptr1>, but pointer_traits<Ptr1> is valid. Here it will call
to_address(p1.operator->()).
Example 2. You have a pointer-like type Ptr2. You have specialized
pointer_traits<Ptr2> with a to_address function. Here it will call
pointer_traits<Ptr2>::to_address(p2).
to_address() was intended for used with pointers and pointer-like types (and
pointer_traits<Ptr> was always required to be valid).
It was intended for use with allocator pointers, and the original standard
library implementations had a return type of: typename
pointer_traits<Ptr>::element_type*
If (for contiguous iterators, which came later) you want pointer_traits<X> to
be valid even when X does not have element_type, that is a design change to
pointer_traits.
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/96416] to_address() is broken by static_assert in pointer_traits
2020-08-02 4:17 [Bug libstdc++/96416] New: address_of() is broken by static_assert in pointer_traits whatwasthataddress at gmail dot com
` (11 preceding siblings ...)
2021-03-26 23:44 ` glenjofe at gmail dot com
@ 2021-03-27 0:48 ` redi at gcc dot gnu.org
2021-03-27 1:41 ` arthur.j.odwyer at gmail dot com
` (13 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: redi at gcc dot gnu.org @ 2021-03-27 0:48 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|address_of() is broken by |to_address() is broken by
|static_assert in |static_assert in
|pointer_traits |pointer_traits
--- Comment #12 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Giuseppe D'Angelo from comment #10)
> (By the way, finding this bug is quite hard. Could "address_of" be changed
> to "to_address" , in the bug description?
Done.
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/96416] to_address() is broken by static_assert in pointer_traits
2020-08-02 4:17 [Bug libstdc++/96416] New: address_of() is broken by static_assert in pointer_traits whatwasthataddress at gmail dot com
` (12 preceding siblings ...)
2021-03-27 0:48 ` [Bug libstdc++/96416] to_address() " redi at gcc dot gnu.org
@ 2021-03-27 1:41 ` arthur.j.odwyer at gmail dot com
2021-03-27 16:53 ` dangelog at gmail dot com
` (12 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: arthur.j.odwyer at gmail dot com @ 2021-03-27 1:41 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
--- Comment #13 from Arthur O'Dwyer <arthur.j.odwyer at gmail dot com> ---
> And are you recommending that everyone who defines their custom contiguous
> iterators specializes pointer_traits for them? Call it _quite_ annoying...
Definitely not! When you define a contiguous iterator type, you should just
give it a sixth nested typedef alongside the other five (or three in C++20):
`using element_type = value_type;`. This enables contiguous-iterator machinery.
See
https://stackoverflow.com/questions/65712091/in-c20-how-do-i-write-a-contiguous-iterator/66050521#66050521
You should never specialize std::pointer_traits for your own type.
("Can" you? Yes. "Should" you? No.)
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/96416] to_address() is broken by static_assert in pointer_traits
2020-08-02 4:17 [Bug libstdc++/96416] New: address_of() is broken by static_assert in pointer_traits whatwasthataddress at gmail dot com
` (13 preceding siblings ...)
2021-03-27 1:41 ` arthur.j.odwyer at gmail dot com
@ 2021-03-27 16:53 ` dangelog at gmail dot com
2021-03-27 19:46 ` redi at gcc dot gnu.org
` (11 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: dangelog at gmail dot com @ 2021-03-27 16:53 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
--- Comment #14 from Giuseppe D'Angelo <dangelog at gmail dot com> ---
Hello,
(In reply to Glen Joseph Fernandes from comment #11)
> > if it can never be used.
>
> You're misunderstanding. to_address(p) requires that pointer_traits<P> is
> valid. It just doesn't need to have a to_address member function.
Thank you for clarifying this. I think the wording in the standard is very
unfortunate, but combined with the realization that pointer_traits isn't
SFINAE-friendly, then it's the only intended meaning.
> If (for contiguous iterators, which came later) you want pointer_traits<X>
> to be valid even when X does not have element_type, that is a design change
> to pointer_traits.
One might claim that pointer_traits should become SFINAE-friendly (like C++17's
iterator_traits), but sure, that's a different design question and not
necessarily needed here.
(In reply to Jonathan Wakely from comment #12)
> (In reply to Giuseppe D'Angelo from comment #10)
> > (By the way, finding this bug is quite hard. Could "address_of" be changed
> > to "to_address" , in the bug description?
>
> Done.
Thank you!
(In reply to Arthur O'Dwyer from comment #13)
> > And are you recommending that everyone who defines their custom contiguous
> > iterators specializes pointer_traits for them? Call it _quite_ annoying...
>
> Definitely not! When you define a contiguous iterator type, you should just
> give it a sixth nested typedef alongside the other five (or three in C++20):
> `using element_type = value_type;`. This enables contiguous-iterator
> machinery.
> See
> https://stackoverflow.com/questions/65712091/in-c20-how-do-i-write-a-
> contiguous-iterator/66050521#66050521
This gets evil really quick: the presence of both value_type and element_type
in an contiguous iterator will make you smash face-first against LWG3446, which
isn't implemented in GCC 10 AFAICS.
https://cplusplus.github.io/LWG/issue3446
What's more, the accepted resolution wording for it appears to be wrong:
template<classhas-member-value-type T>
requires has-member-element-type<T> &&
same_as<remove_cv_t<typename T::element_type>,
remove_cv_t<typename T::value_type>>
struct indirectly_readable_traits<T>
: cond-value-type<typename T::value_type> { };
For const iterators, value_type is actually different from element_type (!).
Thankfully libstdc++ seems to have considered this as a non-standard extension,
https://github.com/gcc-mirror/gcc/commit/186aa6304570e15065f31482e9c27326a3a6679f
To summarize:
* should a wording defect be raised against std::to_address(Ptr), to state that
pointer_traits<Ptr> being well-formed is actually a prerequisite?
* should LWG3446's resolution be amended?
* if there's going to be a GCC 10.3, is the commit above solving LWG3446 going
to be cherry-picked into it? Otherwise, either one blacklists GCC 10, or has to
specialize pointer_traits there as a workaround (?).
Thank you all for the insightful comments.
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/96416] to_address() is broken by static_assert in pointer_traits
2020-08-02 4:17 [Bug libstdc++/96416] New: address_of() is broken by static_assert in pointer_traits whatwasthataddress at gmail dot com
` (14 preceding siblings ...)
2021-03-27 16:53 ` dangelog at gmail dot com
@ 2021-03-27 19:46 ` redi at gcc dot gnu.org
2021-03-29 3:08 ` glenjofe at gmail dot com
` (10 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: redi at gcc dot gnu.org @ 2021-03-27 19:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
--- Comment #15 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Giuseppe D'Angelo from comment #14)
> This gets evil really quick: the presence of both value_type and
> element_type in an contiguous iterator will make you smash face-first
> against LWG3446, which isn't implemented in GCC 10 AFAICS.
That's right, but it's on my list to backport to the gcc-10 branch, probably in
the next 48 hours.
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/96416] to_address() is broken by static_assert in pointer_traits
2020-08-02 4:17 [Bug libstdc++/96416] New: address_of() is broken by static_assert in pointer_traits whatwasthataddress at gmail dot com
` (15 preceding siblings ...)
2021-03-27 19:46 ` redi at gcc dot gnu.org
@ 2021-03-29 3:08 ` glenjofe at gmail dot com
2021-04-20 20:11 ` redi at gcc dot gnu.org
` (9 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: glenjofe at gmail dot com @ 2021-03-29 3:08 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
--- Comment #16 from Glen Joseph Fernandes <glenjofe at gmail dot com> ---
> should a wording defect be raised against std::to_address(Ptr), to state that
> pointer_traits<Ptr> being well-formed is actually a prerequisite?
That's not an omission in the specification of to_address. The function is
intended for pointers, and specified in terms of checking for a
pointer_traits<P> member, and this means pointer_traits<P> must be well-formed.
Adding an additional text to the specification saying this explicitly is
unlikely to help anyone. The real change that users of iterators[1] would want
is to make pointer_traits SFINAE friendly.
[1] Users of pointers don't care much, since all the pointer types people are
using with to_address(p) already have a well-formed pointer_traits<P>.
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/96416] to_address() is broken by static_assert in pointer_traits
2020-08-02 4:17 [Bug libstdc++/96416] New: address_of() is broken by static_assert in pointer_traits whatwasthataddress at gmail dot com
` (16 preceding siblings ...)
2021-03-29 3:08 ` glenjofe at gmail dot com
@ 2021-04-20 20:11 ` redi at gcc dot gnu.org
2021-04-21 8:45 ` dangelog at gmail dot com
` (8 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: redi at gcc dot gnu.org @ 2021-04-20 20:11 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
--- Comment #17 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Giuseppe D'Angelo from comment #14)
> To summarize:
>
> * should a wording defect be raised against std::to_address(Ptr), to state
> that pointer_traits<Ptr> being well-formed is actually a prerequisite?
I'd prefer if pointer_traits was just SFINAE friendly.
> * should LWG3446's resolution be amended?
See https://cplusplus.github.io/LWG/issue3541
> * if there's going to be a GCC 10.3, is the commit above solving LWG3446
> going to be cherry-picked into it? Otherwise, either one blacklists GCC 10,
> or has to specialize pointer_traits there as a workaround (?).
It missed the 10.3 release, but it's on the gcc-10 branch as r10-9698, which
will be in GCC 10.4:
https://gcc.gnu.org/g:32a859531e854382c18abf0b14a306d83f793eb5
That also includes the fix for LWG 3541.
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/96416] to_address() is broken by static_assert in pointer_traits
2020-08-02 4:17 [Bug libstdc++/96416] New: address_of() is broken by static_assert in pointer_traits whatwasthataddress at gmail dot com
` (17 preceding siblings ...)
2021-04-20 20:11 ` redi at gcc dot gnu.org
@ 2021-04-21 8:45 ` dangelog at gmail dot com
2021-08-05 22:55 ` gcc-bugs at marehr dot dialup.fu-berlin.de
` (7 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: dangelog at gmail dot com @ 2021-04-21 8:45 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
--- Comment #18 from Giuseppe D'Angelo <dangelog at gmail dot com> ---
Hello,
(In reply to Jonathan Wakely from comment #17)
> (In reply to Giuseppe D'Angelo from comment #14)
> > To summarize:
> >
> > * should a wording defect be raised against std::to_address(Ptr), to state
> > that pointer_traits<Ptr> being well-formed is actually a prerequisite?
>
> I'd prefer if pointer_traits was just SFINAE friendly.
I guess that's a reasonable thing to wish for, given I'm not the first falling
for it; I hope I'll be the last :)
> > * should LWG3446's resolution be amended?
>
> See https://cplusplus.github.io/LWG/issue3541
>
> > * if there's going to be a GCC 10.3, is the commit above solving LWG3446
> > going to be cherry-picked into it? Otherwise, either one blacklists GCC 10,
> > or has to specialize pointer_traits there as a workaround (?).
>
> It missed the 10.3 release, but it's on the gcc-10 branch as r10-9698, which
> will be in GCC 10.4:
> https://gcc.gnu.org/g:32a859531e854382c18abf0b14a306d83f793eb5
> That also includes the fix for LWG 3541.
Thank you very much for the new issue and the cherry-pick of the fix.
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/96416] to_address() is broken by static_assert in pointer_traits
2020-08-02 4:17 [Bug libstdc++/96416] New: address_of() is broken by static_assert in pointer_traits whatwasthataddress at gmail dot com
` (18 preceding siblings ...)
2021-04-21 8:45 ` dangelog at gmail dot com
@ 2021-08-05 22:55 ` gcc-bugs at marehr dot dialup.fu-berlin.de
2021-09-28 14:00 ` [Bug libstdc++/96416] [DR 3545] " redi at gcc dot gnu.org
` (6 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: gcc-bugs at marehr dot dialup.fu-berlin.de @ 2021-08-05 22:55 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
gcc-bugs at marehr dot dialup.fu-berlin.de changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |gcc-bugs at marehr dot dialup.fu-b
| |erlin.de
--- Comment #19 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
> I guess that's a reasonable thing to wish for, given I'm not the first
> falling for it; I hope I'll be the last :)
>
Unfortunately not, I ran into the same issue :(
But thanks to the thread, I got some insight into the question: Should every
type with an "operator->()" really be considered a pointer?
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/96416] [DR 3545] to_address() is broken by static_assert in pointer_traits
2020-08-02 4:17 [Bug libstdc++/96416] New: address_of() is broken by static_assert in pointer_traits whatwasthataddress at gmail dot com
` (19 preceding siblings ...)
2021-08-05 22:55 ` gcc-bugs at marehr dot dialup.fu-berlin.de
@ 2021-09-28 14:00 ` redi at gcc dot gnu.org
2021-11-25 23:12 ` cvs-commit at gcc dot gnu.org
` (5 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: redi at gcc dot gnu.org @ 2021-09-28 14:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |SUSPENDED
Summary|to_address() is broken by |[DR 3545] to_address() is
|static_assert in |broken by static_assert in
|pointer_traits |pointer_traits
Resolution|INVALID |---
--- Comment #20 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Reopening and suspending, until https://wg21.link/lwg3545 is resolved.
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/96416] [DR 3545] to_address() is broken by static_assert in pointer_traits
2020-08-02 4:17 [Bug libstdc++/96416] New: address_of() is broken by static_assert in pointer_traits whatwasthataddress at gmail dot com
` (20 preceding siblings ...)
2021-09-28 14:00 ` [Bug libstdc++/96416] [DR 3545] " redi at gcc dot gnu.org
@ 2021-11-25 23:12 ` cvs-commit at gcc dot gnu.org
2021-11-26 17:46 ` cvs-commit at gcc dot gnu.org
` (4 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-11-25 23:12 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
--- Comment #21 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>:
https://gcc.gnu.org/g:b8018e5c5ec0e9b6948182f13fba47c67b758d8a
commit r12-5532-gb8018e5c5ec0e9b6948182f13fba47c67b758d8a
Author: Jonathan Wakely <jwakely@redhat.com>
Date: Thu Nov 25 16:49:45 2021 +0000
libstdc++: Make std::pointer_traits SFINAE-friendly [PR96416]
This implements the resolution I'm proposing for LWG 3545, to avoid hard
errors when using std::to_address for types that make pointer_traits
ill-formed.
Consistent with std::iterator_traits, instantiating std::pointer_traits
for a non-pointer type will be well-formed, but give an empty type with
no member types. This avoids the problematic cases for std::to_address.
Additionally, the pointer_to member is now only declared when the
element type is not cv void (and for C++20, when the function body would
be well-formed). The rebind member was already SFINAE-friendly in our
implementation.
libstdc++-v3/ChangeLog:
PR libstdc++/96416
* include/bits/ptr_traits.h (pointer_traits): Reimplement to be
SFINAE-friendly (LWG 3545).
* testsuite/20_util/pointer_traits/lwg3545.cc: New test.
* testsuite/20_util/to_address/1_neg.cc: Adjust dg-error line.
* testsuite/20_util/to_address/lwg3545.cc: New test.
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/96416] [DR 3545] to_address() is broken by static_assert in pointer_traits
2020-08-02 4:17 [Bug libstdc++/96416] New: address_of() is broken by static_assert in pointer_traits whatwasthataddress at gmail dot com
` (21 preceding siblings ...)
2021-11-25 23:12 ` cvs-commit at gcc dot gnu.org
@ 2021-11-26 17:46 ` cvs-commit at gcc dot gnu.org
2021-11-26 17:52 ` redi at gcc dot gnu.org
` (3 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-11-26 17:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
--- Comment #22 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-11 branch has been updated by Jonathan Wakely
<redi@gcc.gnu.org>:
https://gcc.gnu.org/g:8d3391d64799d490117ad48432a9ad2cf38b0091
commit r11-9317-g8d3391d64799d490117ad48432a9ad2cf38b0091
Author: Jonathan Wakely <jwakely@redhat.com>
Date: Thu Nov 25 23:29:08 2021 +0000
libstdc++: Make std::pointer_traits SFINAE-friendly [PR96416]
This is a simplified version of r12-5532 for the release branches. It
still removes the problematic static_assert, but rather than making
std::pointer_traits completely empty when the element_type can't be
deduced, it just disables element_type and pointer_to. Additionally, the
pointer_to member is not completely absent when element_type is cv void,
it just has an unusable signature.
This is sufficient to avoid errors outside the immediate context when
trying to use std::to_address.
libstdc++-v3/ChangeLog:
PR libstdc++/96416
* include/bits/ptr_traits.h (pointer_traits): Remove
static_assert checking for valid element_type.
(pointer_traits::element_type, pointer_traits::pointer_to):
Do not define when element type cannot be deduced.
* testsuite/20_util/pointer_traits/lwg3545.cc: New test.
* testsuite/20_util/to_address/1_neg.cc: Adjust dg-error line.
* testsuite/20_util/to_address/lwg3545.cc: New test.
(cherry picked from commit b8018e5c5ec0e9b6948182f13fba47c67b758d8a)
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/96416] [DR 3545] to_address() is broken by static_assert in pointer_traits
2020-08-02 4:17 [Bug libstdc++/96416] New: address_of() is broken by static_assert in pointer_traits whatwasthataddress at gmail dot com
` (22 preceding siblings ...)
2021-11-26 17:46 ` cvs-commit at gcc dot gnu.org
@ 2021-11-26 17:52 ` redi at gcc dot gnu.org
2021-12-09 1:24 ` whatwasthataddress at gmail dot com
` (2 subsequent siblings)
26 siblings, 0 replies; 28+ messages in thread
From: redi at gcc dot gnu.org @ 2021-11-26 17:52 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|10.3 |10.4
Known to work| |12.0
Status|SUSPENDED |ASSIGNED
Known to fail| |10.3.0, 11.2.0
--- Comment #23 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Fixed for 11.3 now.
If any of you who hit this bug could test GCC trunk or the gcc-11 branch and
confirm it works for your cases now, that would be much appreciated (there are
no actual testcases here in this bug).
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/96416] [DR 3545] to_address() is broken by static_assert in pointer_traits
2020-08-02 4:17 [Bug libstdc++/96416] New: address_of() is broken by static_assert in pointer_traits whatwasthataddress at gmail dot com
` (23 preceding siblings ...)
2021-11-26 17:52 ` redi at gcc dot gnu.org
@ 2021-12-09 1:24 ` whatwasthataddress at gmail dot com
2022-06-28 10:41 ` jakub at gcc dot gnu.org
2023-07-07 9:00 ` rguenth at gcc dot gnu.org
26 siblings, 0 replies; 28+ messages in thread
From: whatwasthataddress at gmail dot com @ 2021-12-09 1:24 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
--- Comment #24 from Zach Laine <whatwasthataddress at gmail dot com> ---
Sorry for the delay. I confirmed that this makes my case well-formed with
releases/gcc-11, and that it's ill-formed with GCC 11.2 and GCC 10.x.
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/96416] [DR 3545] to_address() is broken by static_assert in pointer_traits
2020-08-02 4:17 [Bug libstdc++/96416] New: address_of() is broken by static_assert in pointer_traits whatwasthataddress at gmail dot com
` (24 preceding siblings ...)
2021-12-09 1:24 ` whatwasthataddress at gmail dot com
@ 2022-06-28 10:41 ` jakub at gcc dot gnu.org
2023-07-07 9:00 ` rguenth at gcc dot gnu.org
26 siblings, 0 replies; 28+ messages in thread
From: jakub at gcc dot gnu.org @ 2022-06-28 10:41 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|10.4 |10.5
--- Comment #25 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 10.4 is being released, retargeting bugs to GCC 10.5.
^ permalink raw reply [flat|nested] 28+ messages in thread
* [Bug libstdc++/96416] [DR 3545] to_address() is broken by static_assert in pointer_traits
2020-08-02 4:17 [Bug libstdc++/96416] New: address_of() is broken by static_assert in pointer_traits whatwasthataddress at gmail dot com
` (25 preceding siblings ...)
2022-06-28 10:41 ` jakub at gcc dot gnu.org
@ 2023-07-07 9:00 ` rguenth at gcc dot gnu.org
26 siblings, 0 replies; 28+ messages in thread
From: rguenth at gcc dot gnu.org @ 2023-07-07 9:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96416
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|10.5 |11.3
Known to fail| |10.5.0
Resolution|--- |FIXED
Status|ASSIGNED |RESOLVED
Known to work| |11.3.0
--- Comment #26 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed in 11.3.
^ permalink raw reply [flat|nested] 28+ messages in thread
end of thread, other threads:[~2023-07-07 9:00 UTC | newest]
Thread overview: 28+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-08-02 4:17 [Bug libstdc++/96416] New: address_of() is broken by static_assert in pointer_traits whatwasthataddress at gmail dot com
2020-08-03 12:58 ` [Bug libstdc++/96416] " redi at gcc dot gnu.org
2020-08-03 15:34 ` whatwasthataddress at gmail dot com
2020-08-03 15:38 ` redi at gcc dot gnu.org
2020-11-11 17:46 ` redi at gcc dot gnu.org
2020-11-11 18:52 ` redi at gcc dot gnu.org
2020-11-11 19:10 ` redi at gcc dot gnu.org
2020-11-11 20:05 ` glenjofe at gmail dot com
2020-11-11 20:40 ` redi at gcc dot gnu.org
2020-11-11 20:41 ` redi at gcc dot gnu.org
2021-03-26 14:19 ` dangelog at gmail dot com
2021-03-26 14:45 ` dangelog at gmail dot com
2021-03-26 23:44 ` glenjofe at gmail dot com
2021-03-27 0:48 ` [Bug libstdc++/96416] to_address() " redi at gcc dot gnu.org
2021-03-27 1:41 ` arthur.j.odwyer at gmail dot com
2021-03-27 16:53 ` dangelog at gmail dot com
2021-03-27 19:46 ` redi at gcc dot gnu.org
2021-03-29 3:08 ` glenjofe at gmail dot com
2021-04-20 20:11 ` redi at gcc dot gnu.org
2021-04-21 8:45 ` dangelog at gmail dot com
2021-08-05 22:55 ` gcc-bugs at marehr dot dialup.fu-berlin.de
2021-09-28 14:00 ` [Bug libstdc++/96416] [DR 3545] " redi at gcc dot gnu.org
2021-11-25 23:12 ` cvs-commit at gcc dot gnu.org
2021-11-26 17:46 ` cvs-commit at gcc dot gnu.org
2021-11-26 17:52 ` redi at gcc dot gnu.org
2021-12-09 1:24 ` whatwasthataddress at gmail dot com
2022-06-28 10:41 ` jakub at gcc dot gnu.org
2023-07-07 9:00 ` rguenth 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).