public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/101539] New: [C++20] Implement builtins for layout-compatibility and pointer-interconvertibility traits
@ 2021-07-20 20:41 jason at gcc dot gnu.org
2021-07-20 20:42 ` [Bug c++/101539] " mpolacek at gcc dot gnu.org
` (10 more replies)
0 siblings, 11 replies; 12+ messages in thread
From: jason at gcc dot gnu.org @ 2021-07-20 20:41 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101539
Bug ID: 101539
Summary: [C++20] Implement builtins for layout-compatibility
and pointer-interconvertibility traits
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jason at gcc dot gnu.org
Blocks: 88322, 88323
Target Milestone: ---
https://wg21.link/p0466
Referenced Bugs:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88322
[Bug 88322] Implement C++20 library features.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88323
[Bug 88323] implement C++20 language features.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/101539] [C++20] Implement builtins for layout-compatibility and pointer-interconvertibility traits
2021-07-20 20:41 [Bug c++/101539] New: [C++20] Implement builtins for layout-compatibility and pointer-interconvertibility traits jason at gcc dot gnu.org
@ 2021-07-20 20:42 ` mpolacek at gcc dot gnu.org
2021-07-21 13:58 ` jakub at gcc dot gnu.org
` (9 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2021-07-20 20:42 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101539
Marek Polacek <mpolacek at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2021-07-20
Status|UNCONFIRMED |NEW
CC| |mpolacek at gcc dot gnu.org
Ever confirmed|0 |1
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/101539] [C++20] Implement builtins for layout-compatibility and pointer-interconvertibility traits
2021-07-20 20:41 [Bug c++/101539] New: [C++20] Implement builtins for layout-compatibility and pointer-interconvertibility traits jason at gcc dot gnu.org
2021-07-20 20:42 ` [Bug c++/101539] " mpolacek at gcc dot gnu.org
@ 2021-07-21 13:58 ` jakub at gcc dot gnu.org
2021-07-21 14:10 ` jakub at gcc dot gnu.org
` (8 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-07-21 13:58 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101539
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 51186
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51186&action=edit
gcc12-pr101539.patch
So, I've tried to play with the __is_layout_compatible trait, here is the
result. There is one known bug, the C++ FE unfortunately removes zero sized
bit-fields early, for layout compatibility we need them (and now just that they
were present but how many as well and their types). Can we not remove them or
remove them when the FE parses the whole TU?
The testcase also contains various cornercases where layout-compatibility as
currently defined is just weird.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/101539] [C++20] Implement builtins for layout-compatibility and pointer-interconvertibility traits
2021-07-20 20:41 [Bug c++/101539] New: [C++20] Implement builtins for layout-compatibility and pointer-interconvertibility traits jason at gcc dot gnu.org
2021-07-20 20:42 ` [Bug c++/101539] " mpolacek at gcc dot gnu.org
2021-07-21 13:58 ` jakub at gcc dot gnu.org
@ 2021-07-21 14:10 ` jakub at gcc dot gnu.org
2021-07-21 15:12 ` jakub at gcc dot gnu.org
` (7 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-07-21 14:10 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101539
--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
As for __builtin_is_corresponding_member, could be perhaps implemented as
varargs FE builtin and only check during folding it has exactly two arguments
that are pointer to data members with layout-compatible types and standard
layout structs.
For constexpr, especially if we can see unfolded PMR address which says which
FIELD_DECL it is implementing it shouldn't be hard, but it seems that it can't
be always folded at compile time, we can have cases where we need to decide at
runtime.
#include <type_traits>
struct A { int a; long long b; int c; int e; int d; };
struct B { int a; long long b; long long c; int d; };
bool
foo (int A::*x, int B::*y)
{
return std::is_corresponding_member (x, y);
}
This should return true if called e.g. with &A::a, &B::a, but not with &A::d,
&B::d. So I guess at compile time we need to check if the types (int in this
case twice) is layout-compatible and whether A and B are standard-layout
structure types, but then actually at compile time need to compare the
OFFSET_TYPEs for equality and compare it against pre-computed value of an upper
bound for the initial common sequence of the two types.
The U and V structs show that it is harder though, at least the offset would be
dependent on the type of the field.
No plans on my side to work on the pointer interconvertibility on my side.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/101539] [C++20] Implement builtins for layout-compatibility and pointer-interconvertibility traits
2021-07-20 20:41 [Bug c++/101539] New: [C++20] Implement builtins for layout-compatibility and pointer-interconvertibility traits jason at gcc dot gnu.org
` (2 preceding siblings ...)
2021-07-21 14:10 ` jakub at gcc dot gnu.org
@ 2021-07-21 15:12 ` jakub at gcc dot gnu.org
2021-07-22 7:42 ` jakub at gcc dot gnu.org
` (6 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-07-21 15:12 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101539
--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I think the implementation of is_corresponding_member heavily depends on
layout-compatibility ensuring the same sizes and alignments of the members,
otherwise
any comparison of the OFFSET_TYPE values (which just hold at runtime byte
offset from the start of struct and at compile time hold also the type of the
pointed non-static data member and type of the object the offset is relative
to) is going to be a nighmare. So I think we first need a clarification of the
standard for the various alignas cases or the [[no_unique_address]] cases that
are shown e.g. in the #c1 testcase and only when we can count on the
corresponding members to have the exact same offset we can move further on.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/101539] [C++20] Implement builtins for layout-compatibility and pointer-interconvertibility traits
2021-07-20 20:41 [Bug c++/101539] New: [C++20] Implement builtins for layout-compatibility and pointer-interconvertibility traits jason at gcc dot gnu.org
` (3 preceding siblings ...)
2021-07-21 15:12 ` jakub at gcc dot gnu.org
@ 2021-07-22 7:42 ` jakub at gcc dot gnu.org
2021-07-28 15:57 ` jakub at gcc dot gnu.org
` (5 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-07-22 7:42 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101539
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #51186|0 |1
is obsolete| |
--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 51192
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51192&action=edit
gcc12-pr101539.patch
Updated patch that throws away the :0 bitfield removal. The C FE doesn't
remove those and it passes bootstrap/regtest that way too.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/101539] [C++20] Implement builtins for layout-compatibility and pointer-interconvertibility traits
2021-07-20 20:41 [Bug c++/101539] New: [C++20] Implement builtins for layout-compatibility and pointer-interconvertibility traits jason at gcc dot gnu.org
` (4 preceding siblings ...)
2021-07-22 7:42 ` jakub at gcc dot gnu.org
@ 2021-07-28 15:57 ` jakub at gcc dot gnu.org
2021-07-28 17:16 ` jakub at gcc dot gnu.org
` (4 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-07-28 15:57 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101539
--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 51219
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51219&action=edit
gcc12-pr101539-2.patch
Untested patch for the __is_pointer_interconvertible_base_of trait and
__builtin_is_pointer_interconvertible_with_class. This part doesn't seem to
suffer any issues on the standard side unlike the layout-compatible stuff,
but I'm not sure I understood everything right.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/101539] [C++20] Implement builtins for layout-compatibility and pointer-interconvertibility traits
2021-07-20 20:41 [Bug c++/101539] New: [C++20] Implement builtins for layout-compatibility and pointer-interconvertibility traits jason at gcc dot gnu.org
` (5 preceding siblings ...)
2021-07-28 15:57 ` jakub at gcc dot gnu.org
@ 2021-07-28 17:16 ` jakub at gcc dot gnu.org
2021-07-30 16:51 ` cvs-commit at gcc dot gnu.org
` (3 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-07-28 17:16 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101539
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I've tried my testcases with MSVC on godbolt that claims to implement it, and
https://godbolt.org/z/3PnjM33vM
for the first testcase shows it disagrees with my expectations on
static_assert (std::is_pointer_interconvertible_base_of_v<D, F>);
static_assert (std::is_pointer_interconvertible_base_of_v<E, F>);
static_assert (!std::is_pointer_interconvertible_base_of_v<D, G>);
static_assert (!std::is_pointer_interconvertible_base_of_v<D, I>);
static_assert (std::is_pointer_interconvertible_base_of_v<H, volatile I>);
Is that a bug in my patch or is MSVC buggy on these (or mix thereof)?
https://godbolt.org/z/aYeYnne9d
shows the second testcase, here it differs on:
static_assert (std::is_pointer_interconvertible_with_class<F, int> (&F::b));
static_assert (std::is_pointer_interconvertible_with_class<I, int> (&I::g));
static_assert (std::is_pointer_interconvertible_with_class<L, int> (&L::b));
static_assert (std::is_pointer_interconvertible_with_class (&V::a));
static_assert (std::is_pointer_interconvertible_with_class (&V::b));
Again, my bug, MSVC bug, mix thereof?
Oh, and there is another thing, the standard has an example:
struct A { int a; }; // a standard-layout class
struct B { int b; }; // a standard-layout class
struct C: public A, public B { }; // not a standard-layout class
static_assert( is_pointer_interconvertible_with_class( &C::b ) );
// Succeeds because, despite its appearance, &C::b has type
// “pointer to member of B of type int”.
static_assert( is_pointer_interconvertible_with_class<C>( &C::b ) );
// Forces the use of class C, and fails.
It seems to work as written with MSVC (second assertion fails), but fails with
GCC with the patch:
/tmp/1.C:22:57: error: no matching function for call to
‘is_pointer_interconvertible_with_class<C>(int B::*)’
22 | static_assert( is_pointer_interconvertible_with_class<C>( &C::b ) );
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~
/tmp/1.C:8:1: note: candidate: ‘template<class S, class M> constexpr bool
std::is_pointer_interconvertible_with_class(M S::*)’
8 | is_pointer_interconvertible_with_class (M S::*m) noexcept
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/tmp/1.C:8:1: note: template argument deduction/substitution failed:
/tmp/1.C:22:57: note: mismatched types ‘C’ and ‘B’
22 | static_assert( is_pointer_interconvertible_with_class<C>( &C::b ) );
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~
the second int argument isn't deduced.
This boils down to:
template <class S, class M>
bool foo (M S::*m) noexcept;
struct A { int a; };
struct B { int b; };
struct C : public A, public B {};
bool a = foo (&C::b);
bool b = foo<C, int> (&C::b);
bool c = foo<C> (&C::b);
which with /std:c++20 or -std=c++20 is accepted by latest MSVC and ICC but
rejected by GCC and clang (in both cases on the last line).
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/101539] [C++20] Implement builtins for layout-compatibility and pointer-interconvertibility traits
2021-07-20 20:41 [Bug c++/101539] New: [C++20] Implement builtins for layout-compatibility and pointer-interconvertibility traits jason at gcc dot gnu.org
` (6 preceding siblings ...)
2021-07-28 17:16 ` jakub at gcc dot gnu.org
@ 2021-07-30 16:51 ` cvs-commit at gcc dot gnu.org
2021-08-02 14:40 ` jakub at gcc dot gnu.org
` (2 subsequent siblings)
10 siblings, 0 replies; 12+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-07-30 16:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101539
--- Comment #7 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:6cd005a255f15c1b4b3eaae71c844ea2592c9dce
commit r12-2628-g6cd005a255f15c1b4b3eaae71c844ea2592c9dce
Author: Jakub Jelinek <jakub@redhat.com>
Date: Fri Jul 30 18:38:41 2021 +0200
c++: Implement P0466R5 __cpp_lib_is_pointer_interconvertible compiler
helpers [PR101539]
The following patch attempts to implement the compiler helpers for
libstdc++ std::is_pointer_interconvertible_base_of trait and
std::is_pointer_interconvertible_with_class template function.
For the former __is_pointer_interconvertible_base_of trait that checks
first
whether base and derived aren't non-union class types that are the same
ignoring toplevel cv-qualifiers, otherwise if derived is unambiguously
derived from base without cv-qualifiers, derived being a complete type,
and if so, my limited understanding of any derived object being
pointer-interconvertible with base subobject IMHO implies (because one
can't
inherit from unions or unions can't inherit) that we check if derived is
standard layout type and we walk bases of derived
recursively, stopping on a class that has any non-static data members and
check if any of the bases is base. On class with non-static data members
no bases are compared already.
Upon discussions, this is something that maybe should have been changed
in the standard with CWG 2254 and the patch no longer performs this and
assumes all base subobjects of standard-layout class types are
pointer-interconvertible with the whole class objects.
The latter is implemented using a FE
__builtin_is_pointer_interconvertible_with_class, but because on the
library
side it will be a template function, the builtin takes ... arguments and
only during folding verifies it has a single argument with pointer to
member
type. The initial errors IMHO can only happen if one uses the builtin
incorrectly by hand, the template function should ensure that it has
exactly a single argument that has pointer to member type.
Otherwise, again with my limited understanding of what
the template function should do and pointer-interconvertibility,
it folds to false for pointer-to-member-function, errors if
basetype of the OFFSET_TYPE is incomplete, folds to false
for non-std-layout non-union basetype, then finds the first non-static
data member in the basetype or its bases (by ignoring
DECL_FIELD_IS_BASE FIELD_DECLs that are empty, recursing into
DECL_FIELD_IS_BASE FIELD_DECLs type that are non-empty (I think
std layout should ensure there is at most one), for unions
checks if membertype is same type as any of the union FIELD_DECLs,
for non-unions the first other FIELD_DECL only, and for anonymous
aggregates similarly (union vs. non-union) but recurses into the
anon aggr types with std layout check for anon structures. If
membertype doesn't match the type of first non-static data member
(or for unions any of the members), then the builtin folds to false,
otherwise the built folds to a check whether the argument is equal
to OFFSET_TYPE of 0 or not, either at compile time if it is constant
(e.g. for constexpr folding) or at runtime otherwise.
As I wrote in the PR, I've tried my testcases with MSVC on godbolt
that claims to implement it, and https://godbolt.org/z/3PnjM33vM
for the first testcase shows it disagrees with my expectations on
static_assert (std::is_pointer_interconvertible_base_of_v<D, F>);
static_assert (std::is_pointer_interconvertible_base_of_v<E, F>);
static_assert (!std::is_pointer_interconvertible_base_of_v<D, G>);
static_assert (!std::is_pointer_interconvertible_base_of_v<D, I>);
static_assert (std::is_pointer_interconvertible_base_of_v<H, volatile I>);
Is that a bug in my patch or is MSVC buggy on these (or mix thereof)?
https://godbolt.org/z/aYeYnne9d
shows the second testcase, here it differs on:
static_assert (std::is_pointer_interconvertible_with_class<F, int>
(&F::b));
static_assert (std::is_pointer_interconvertible_with_class<I, int>
(&I::g));
static_assert (std::is_pointer_interconvertible_with_class<L, int>
(&L::b));
static_assert (std::is_pointer_interconvertible_with_class (&V::a));
static_assert (std::is_pointer_interconvertible_with_class (&V::b));
Again, my bug, MSVC bug, mix thereof?
According to Jason the <D, G>, <D, I> case are the subject of the
CWG 2254 above discussed change and the rest are likely MSVC bugs.
Oh, and there is another thing, the standard has an example:
struct A { int a; }; // a standard-layout class
struct B { int b; }; // a standard-layout class
struct C: public A, public B { }; // not a standard-layout class
static_assert( is_pointer_interconvertible_with_class( &C::b ) );
// Succeeds because, despite its appearance, &C::b has type
// âpointer to member of B of type intâ.
static_assert( is_pointer_interconvertible_with_class<C>( &C::b ) );
// Forces the use of class C, and fails.
It seems to work as written with MSVC (second assertion fails),
but fails with GCC with the patch:
/tmp/1.C:22:57: error: no matching function for call to
âis_pointer_interconvertible_with_class<C>(int B::*)â
22 | static_assert( is_pointer_interconvertible_with_class<C>( &C::b )
);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~
/tmp/1.C:8:1: note: candidate: âtemplate<class S, class M> constexpr bool
std::is_pointer_interconvertible_with_class(M S::*)â
8 | is_pointer_interconvertible_with_class (M S::*m) noexcept
| ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/tmp/1.C:8:1: note: template argument deduction/substitution failed:
/tmp/1.C:22:57: note: mismatched types âCâ and âBâ
22 | static_assert( is_pointer_interconvertible_with_class<C>( &C::b )
);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~
the second int argument isn't deduced.
This boils down to:
template <class S, class M>
bool foo (M S::*m) noexcept;
struct A { int a; };
struct B { int b; };
struct C : public A, public B {};
bool a = foo (&C::b);
bool b = foo<C, int> (&C::b);
bool c = foo<C> (&C::b);
which with /std:c++20 or -std=c++20 is accepted by latest MSVC and ICC but
rejected by GCC and clang (in both cases on the last line).
Is this a GCC/clang bug in argument deduction (in that case I think we want
a separate PR), or a bug in ICC/MSVC and the standard itself that should
specify in the examples both template arguments instead of just the first?
And this has been raised with the CWG.
2021-07-30 Jakub Jelinek <jakub@redhat.com>
PR c++/101539
gcc/c-family/
* c-common.h (enum rid): Add
RID_IS_POINTER_INTERCONVERTIBLE_BASE_OF.
* c-common.c (c_common_reswords): Add
__is_pointer_interconvertible_base_of.
gcc/cp/
* cp-tree.h (enum cp_trait_kind): Add
CPTK_IS_POINTER_INTERCONVERTIBLE_BASE_OF.
(enum cp_built_in_function): Add
CP_BUILT_IN_IS_POINTER_INTERCONVERTIBLE_WITH_CLASS.
(fold_builtin_is_pointer_inverconvertible_with_class): Declare.
* parser.c (cp_parser_primary_expression): Handle
RID_IS_POINTER_INTERCONVERTIBLE_BASE_OF.
(cp_parser_trait_expr): Likewise.
* cp-objcp-common.c (names_builtin_p): Likewise.
* constraint.cc (diagnose_trait_expr): Handle
CPTK_IS_POINTER_INTERCONVERTIBLE_BASE_OF.
* decl.c (cxx_init_decl_processing): Register
__builtin_is_pointer_interconvertible_with_class builtin.
* constexpr.c (cxx_eval_builtin_function_call): Handle
CP_BUILT_IN_IS_POINTER_INTERCONVERTIBLE_WITH_CLASS builtin.
* semantics.c (pointer_interconvertible_base_of_p,
first_nonstatic_data_member_p,
fold_builtin_is_pointer_inverconvertible_with_class): New
functions.
(trait_expr_value): Handle
CPTK_IS_POINTER_INTERCONVERTIBLE_BASE_OF.
(finish_trait_expr): Likewise. Formatting fix.
* cp-gimplify.c (cp_gimplify_expr): Fold
CP_BUILT_IN_IS_POINTER_INTERCONVERTIBLE_WITH_CLASS. Call
fndecl_built_in_p just once.
(cp_fold): Likewise.
* tree.c (builtin_valid_in_constant_expr_p): Handle
CP_BUILT_IN_IS_POINTER_INTERCONVERTIBLE_WITH_CLASS. Call
fndecl_built_in_p just once.
* cxx-pretty-print.c (pp_cxx_trait_expression): Handle
CPTK_IS_POINTER_INTERCONVERTIBLE_BASE_OF.
gcc/testsuite/
* g++.dg/cpp2a/is-pointer-interconvertible-base-of1.C: New test.
* g++.dg/cpp2a/is-pointer-interconvertible-with-class1.C: New test.
* g++.dg/cpp2a/is-pointer-interconvertible-with-class2.C: New test.
* g++.dg/cpp2a/is-pointer-interconvertible-with-class3.C: New test.
* g++.dg/cpp2a/is-pointer-interconvertible-with-class4.C: New test.
* g++.dg/cpp2a/is-pointer-interconvertible-with-class5.C: New test.
* g++.dg/cpp2a/is-pointer-interconvertible-with-class6.C: New test.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/101539] [C++20] Implement builtins for layout-compatibility and pointer-interconvertibility traits
2021-07-20 20:41 [Bug c++/101539] New: [C++20] Implement builtins for layout-compatibility and pointer-interconvertibility traits jason at gcc dot gnu.org
` (7 preceding siblings ...)
2021-07-30 16:51 ` cvs-commit at gcc dot gnu.org
@ 2021-08-02 14:40 ` jakub at gcc dot gnu.org
2021-08-17 19:18 ` cvs-commit at gcc dot gnu.org
2021-08-17 19:21 ` jakub at gcc dot gnu.org
10 siblings, 0 replies; 12+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-08-02 14:40 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101539
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #51192|0 |1
is obsolete| |
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
Status|NEW |ASSIGNED
--- Comment #8 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 51241
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51241&action=edit
gcc12-pr101539.patch
Updated __is_layout_compatible trait patch that now also implements
__builtin_is_corresponding_member. For now it implements the IMHO buggy but
standard definition of layout-compatible and std::is_layout_compatible
comments,
including ignoring of alignment differences, mishandling of bitfields in unions
and [[no_unique_address]] issues with empty classes.
For __builtin_is_corresponding_member, it will sorry if corresponding members
could have different offsets (doesn't do so during constant evaluation but
unless one uses the builtin directly, even using std::is_corresponding_member
in constant expressions only will result in instantiation of the template and
the code in the template doesn't have constant arguments and so can emit
sorry).
For anonymous structs (GCC extension) it will recurse into the anonymous
structs. For anonymous unions it will emit another sorry if it can't prove
such
member types can't appear in the anonymous unions or anonymous aggregates in
that union, because corresponding member is defined only using common initial
sequence which is only defined for std-layout non-union class types.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/101539] [C++20] Implement builtins for layout-compatibility and pointer-interconvertibility traits
2021-07-20 20:41 [Bug c++/101539] New: [C++20] Implement builtins for layout-compatibility and pointer-interconvertibility traits jason at gcc dot gnu.org
` (8 preceding siblings ...)
2021-08-02 14:40 ` jakub at gcc dot gnu.org
@ 2021-08-17 19:18 ` cvs-commit at gcc dot gnu.org
2021-08-17 19:21 ` jakub at gcc dot gnu.org
10 siblings, 0 replies; 12+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-08-17 19:18 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101539
--- Comment #9 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:32c3a75390623a0470df52af13f78baddd562981
commit r12-2975-g32c3a75390623a0470df52af13f78baddd562981
Author: Jakub Jelinek <jakub@redhat.com>
Date: Tue Aug 17 21:06:39 2021 +0200
c++: Implement P0466R5 __cpp_lib_is_layout_compatible compiler helpers
[PR101539]
The following patch implements __is_layout_compatible trait and
__builtin_is_corresponding_member helper function for the
std::is_corresponding_member template function.
As the current definition of layout compatible type has various problems,
which result e.g. in corresponding members in layout compatible types
having
different member offsets, the patch anticipates some changes to the C++
standard:
1) class or enumeral types aren't layout compatible if they have different
alignment or size
2) if two members have different offsets, they can't be corresponding
members
([[no_unique_address]] with empty types can change that, or alignas
on the member decls)
3) in unions, bitfields can't correspond to non-unions, or bitfields can't
correspond to bitfields with different widths, or members with
[[no_unique_address]] can't correspond to members without that attribute
__builtin_is_corresponding_member for anonymous structs (GCC extension)
will
recurse into the anonymous structs. For anonymous unions it will emit
a sorry if it can't prove such member types can't appear in the
anonymous unions or anonymous aggregates in that union, because
corresponding member is defined only using common initial sequence which is
only defined for std-layout non-union class types and so I have no idea
what
to do otherwise in that case.
2021-08-17 Jakub Jelinek <jakub@redhat.com>
PR c++/101539
gcc/c-family/
* c-common.h (enum rid): Add RID_IS_LAYOUT_COMPATIBLE.
* c-common.c (c_common_reswords): Add __is_layout_compatible.
gcc/cp/
* cp-tree.h (enum cp_trait_kind): Add CPTK_IS_LAYOUT_COMPATIBLE.
(enum cp_built_in_function): Add
CP_BUILT_IN_IS_CORRESPONDING_MEMBER.
(fold_builtin_is_corresponding_member, next_common_initial_seqence,
layout_compatible_type_p): Declare.
* parser.c (cp_parser_primary_expression): Handle
RID_IS_LAYOUT_COMPATIBLE.
(cp_parser_trait_expr): Likewise.
* cp-objcp-common.c (names_builtin_p): Likewise.
* constraint.cc (diagnose_trait_expr): Handle
CPTK_IS_LAYOUT_COMPATIBLE.
* decl.c (cxx_init_decl_processing): Register
__builtin_is_corresponding_member builtin.
* constexpr.c (cxx_eval_builtin_function_call): Handle
CP_BUILT_IN_IS_CORRESPONDING_MEMBER builtin.
* semantics.c (is_corresponding_member_union,
is_corresponding_member_aggr,
fold_builtin_is_corresponding_member):
New functions.
(trait_expr_value): Handle CPTK_IS_LAYOUT_COMPATIBLE.
(finish_trait_expr): Likewise.
* typeck.c (next_common_initial_seqence, layout_compatible_type_p):
New functions.
* cp-gimplify.c (cp_gimplify_expr): Fold
CP_BUILT_IN_IS_CORRESPONDING_MEMBER.
(cp_fold): Likewise.
* tree.c (builtin_valid_in_constant_expr_p): Handle
CP_BUILT_IN_IS_CORRESPONDING_MEMBER.
* cxx-pretty-print.c (pp_cxx_trait_expression): Handle
CPTK_IS_LAYOUT_COMPATIBLE.
* class.c (remove_zero_width_bit_fields): Remove.
(layout_class_type): Don't call it.
gcc/testsuite/
* g++.dg/cpp2a/is-corresponding-member1.C: New test.
* g++.dg/cpp2a/is-corresponding-member2.C: New test.
* g++.dg/cpp2a/is-corresponding-member3.C: New test.
* g++.dg/cpp2a/is-corresponding-member4.C: New test.
* g++.dg/cpp2a/is-corresponding-member5.C: New test.
* g++.dg/cpp2a/is-corresponding-member6.C: New test.
* g++.dg/cpp2a/is-corresponding-member7.C: New test.
* g++.dg/cpp2a/is-corresponding-member8.C: New test.
* g++.dg/cpp2a/is-layout-compatible1.C: New test.
* g++.dg/cpp2a/is-layout-compatible2.C: New test.
* g++.dg/cpp2a/is-layout-compatible3.C: New test.
^ permalink raw reply [flat|nested] 12+ messages in thread
* [Bug c++/101539] [C++20] Implement builtins for layout-compatibility and pointer-interconvertibility traits
2021-07-20 20:41 [Bug c++/101539] New: [C++20] Implement builtins for layout-compatibility and pointer-interconvertibility traits jason at gcc dot gnu.org
` (9 preceding siblings ...)
2021-08-17 19:18 ` cvs-commit at gcc dot gnu.org
@ 2021-08-17 19:21 ` jakub at gcc dot gnu.org
10 siblings, 0 replies; 12+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-08-17 19:21 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101539
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Implemented now.
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2021-08-17 19:21 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-07-20 20:41 [Bug c++/101539] New: [C++20] Implement builtins for layout-compatibility and pointer-interconvertibility traits jason at gcc dot gnu.org
2021-07-20 20:42 ` [Bug c++/101539] " mpolacek at gcc dot gnu.org
2021-07-21 13:58 ` jakub at gcc dot gnu.org
2021-07-21 14:10 ` jakub at gcc dot gnu.org
2021-07-21 15:12 ` jakub at gcc dot gnu.org
2021-07-22 7:42 ` jakub at gcc dot gnu.org
2021-07-28 15:57 ` jakub at gcc dot gnu.org
2021-07-28 17:16 ` jakub at gcc dot gnu.org
2021-07-30 16:51 ` cvs-commit at gcc dot gnu.org
2021-08-02 14:40 ` jakub at gcc dot gnu.org
2021-08-17 19:18 ` cvs-commit at gcc dot gnu.org
2021-08-17 19:21 ` 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).