[Bug c++/100710] New: static_cast to derived* of base* pointing to non-static data member of base type not rejected in constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100710
Bug ID: 100710
Summary: static_cast to derived* of base* pointing to
non-static data member of base type not rejected in
constant expression
Product: gcc
Version: 11.1.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jason.e.cobb at gmail dot com
Target Milestone: ---
In the following code:
[code]
class B {};
class D : public B {
public:
B member;
};
constexpr bool test(bool do_ub = true) {
if (do_ub) {
D d;
return static_cast(&d.member) != nullptr;
}
return false;
}
static_assert(test());
[/code]
On Compiler Explorer: https://godbolt.org/z/eKEcT7bhb
GCC 11.1 accepts when it should reject due to the static_cast being UB during
the evaluation of a constant expression, as the pointer to B does not actually
point to a base class subobject of an object of type D.
>From [expr.static.cast]/11:
> If the prvalue of type “pointer to cv1 B” points to a B that is actually a
> subobject of an object of type D, the resulting pointer points to the
> enclosing object of type D. Otherwise, the behavior is undefined.
This wording is slightly broken because it says "actually a subobject" instead
of "actually a base class subobject", but there is an editorial PR to fix this:
https://github.com/cplusplus/draft/pull/4605
[Bug c++/99902] New: Deduced return type of lambda in default template argument takes return type from variable template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99902
Bug ID: 99902
Summary: Deduced return type of lambda in default template
argument takes return type from variable template
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jason.e.cobb at gmail dot com
Target Milestone: ---
In the following code:
[BEGIN EXAMPLE]
template
struct foo {};
template
inline constexpr auto foo_v = foo<>{};
auto x = foo_v;
[END EXAMPLE]
On Compiler Explorer: https://godbolt.org/z/nor57d4Ke
GCC believes the return type of the lambda to be long, even though the return
type should be deduced as void. This is apparent from the error message that
GCC rejects with:
[BEGIN ERROR]
: In instantiation of 'constexpr const auto foo_v':
:7:10: required from here
:1:26: error: return-statement with no value, in function returning
'long int' [-fpermissive]
1 | template
| ^~
:5:23: error: conversion from 'long int (*)()' to 'void (*)()' in a
converted constant expression
5 | inline constexpr auto foo_v = foo<>{};
| ^
:5:23: error: could not convert '{}'
from '' to 'void (*)()'
Compiler returned: 1
[END ERROR]
GCC rejects with a similar error message in the following case with an alias
template instead of a variable template:
[BEGIN EXAMPLE]
template
struct foo {};
template
using foo_t = foo<>;
using some_foo = foo_t;
[END EXAMPLE]
In the case where foo_t or foo_v has multiple template arguments, the first is
taken to be the return type.
In the case where the first template parameter foo_t or foo_v is a non-type
template parameter, GCC ICEs:
[BEGIN EXAMPLE]
template
struct foo {};
template
using foo_t = foo<>;
using some_foo = foo_t<12>;
[END EXAMPLE]
On Compiler Explorer: https://godbolt.org/z/MoPEGzYP7
This results in the following error:
[BEGIN ERROR]
: In substitution of 'template > using foo_t = foo<>
[with int = 12]':
:7:26: required from here
:1:22: internal compiler error: in tsubst, at cp/pt.c:15578
1 | template
| ^
0x1cfd119 internal_error(char const*, ...)
???:0
0x6baa1b fancy_abort(char const*, int, char const*)
???:0
0x9182c1 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x916211 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x949897 tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
???:0
0x941fc6 tsubst_template_args(tree_node*, tree_node*, int, tree_node*)
???:0
0x91658d tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x916637 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x94ce32 instantiate_template(tree_node*, tree_node*, int)
???:0
0x916b31 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x92a38e lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
???:0
0x97ff1d finish_template_type(tree_node*, tree_node*, int)
???:0
0x8e140d c_parse_file()
???:0
0xa606f2 c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
[END ERROR]
On Compiler Explorer: https://godbolt.org/z/713js5aq7
[Bug c++/98061] CV qualifiers are incorrectly stripped from the type of void prvalues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98061 Jason Cobb changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from Jason Cobb --- I was wrong. GCC is correct. >From https://bugs.llvm.org/show_bug.cgi?id=48331#c1 > This is an ICC bug. See [expr.type]p2: > > "If a prvalue initially has the type “cv T”, where T is a cv-unqualified > non-class, non-array type, the type of the expression is adjusted to T prior > to any further analysis."
[Bug c++/98061] New: CV qualifiers are incorrectly stripped from the type of void prvalues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98061
Bug ID: 98061
Summary: CV qualifiers are incorrectly stripped from the type
of void prvalues
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jason.e.cobb at gmail dot com
Target Milestone: ---
When creating a prvalue of a cv void type, cv qualifiers are incorrectly
stripped.
Consider:
BEGIN EXAMPLE
#include
template
using id_t = T;
static_assert(std::is_same_v()), void>);
END EXAMPLE
On Compiler Explorer: https://godbolt.org/z/z3PebY
GCC, Clang, and MSVC accept. ICC rejects, believing the type to instead be
const void (https://godbolt.org/z/Tqvjoo). The results are similar for
volatile.
ICC is correct. The correct type is const void per [expr.type.conv]/2:
> Otherwise, if the type is cv void and the initializer is () or {} (after pack
> expansion, if any), the expression is a prvalue of the specified type that
> performs no initialization.
[Bug c++/96815] internal compiler error: in tsubst_pack_expansion, at cp/pt.c:12928
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96815
Jason Cobb changed:
What|Removed |Added
CC||jason.e.cobb at gmail dot com
--- Comment #2 from Jason Cobb ---
I think I've stumbled upon this and have a reduced version with the same
elements (constexpr if in a lambda in a pack expansion in a lambda in a
template).
Source w/ -std=c++17:
template
inline constexpr auto true_v = true;
template
auto test() {
return [](auto... x) {
([]{ if constexpr (true_v); }, ...);
}();
}
auto foo() {
test();
}
END SOURCE
Compiler output:
: In instantiation of 'test:: [with auto:1 =
{}]':
:8:6: required from 'auto test() [with =
void]'
:12:16: required from here
:6:19: internal compiler error: in tsubst_pack_expansion, at
cp/pt.c:12952
6 | return [](auto... x) {
| ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://gcc.gnu.org/bugs/> for instructions.
END COMPILER OUTPUT
Seen on Compiler Explorer: https://godbolt.org/z/jqEP65
This appears to ICE back through to 8.1 (as tested on Compiler Explorer). Clang
trunk accepts as valid.
GCC does not ICE if "test" is not a template or if the body of the outer-most
lambda is placed into a separate function.
[Bug c++/92777] ICE on concept containing lambda with auto variable declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92777 Jason Cobb changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Jason Cobb --- Fixed in trunk.
[Bug c++/89743] [concepts] ICE when using decltype(requires-expr) as type template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89743 Jason Cobb changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jason Cobb --- Fixed in trunk.
[Bug c++/89657] [concepts] ICE when calling lambda returning requires-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89657 Jason Cobb changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #3 from Jason Cobb --- Fixed at some point.
[Bug c++/67491] [meta-bug] concepts issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491 Bug 67491 depends on bug 89657, which changed state. Bug 89657 Summary: [concepts] ICE when calling lambda returning requires-expression https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89657 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug c++/92777] New: ICE on concept containing lambda with auto variable declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92777
Bug ID: 92777
Summary: ICE on concept containing lambda with auto variable
declaration
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jason.e.cobb at gmail dot com
Target Milestone: ---
With GCC trunk in std=c++2a mode and the following code:
[begin code]
template
concept auto_in_lambda = requires() {
[](){
auto x = 4;
}();
};
static_assert(auto_in_lambda);
[end code]
GCC ICEs with the following message:
: In lambda function:
:4:14: internal compiler error: in tsubst_decl, at cp/pt.c:14375
4 | auto x = 4;
| ^
GCC does not ICE if the concept is never instantiated, nor does it ICE if the
"auto" variable is changed to have a defined type.
On Compiler Explorer: https://godbolt.org/z/myujUX
[Bug libstdc++/92156] New: Cannot in-place construct std::any with std::any
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92156
Bug ID: 92156
Summary: Cannot in-place construct std::any with std::any
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: jason.e.cobb at gmail dot com
Target Milestone: ---
GCC (and clang, when using libstdc++) claim that the following program is
ill-formed when compiled with "-std=c++17":
#include
int main() {
auto a = std::any(std::in_place_type, 5);
}
[end code]
Both clang with libc++ and MSVC accept this program.
On Compiler Explorer: https://godbolt.org/z/ckzMsg .
The standard says that this is correct. Under
http://eel.is/c++draft/any.cons#itemdecl:5 , the only requirements are that T
be copy-constructible and constructible from the in-place args. std::any is
copy-constructible and constructible from int, so this program should be
well-formed.
[Bug c++/89743] [concepts] ICE when using decltype(requires-expr) as type template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89743 --- Comment #2 from Jason Cobb --- (In reply to Jonathan Wakely from comment #1) > GCC 8 gives: > > c.cc:5:23: error: expected nested-name-specifier > using type = typename use_type^~ > 1; > ~~ > })>; > ~~~ > > But I think that might be because my GCC 8 builds use > --enable-checking=release Yes, that would actually be an error if it didn't ICE. However, the ICE does still occur without the typename keyword.
[Bug c++/89743] New: [concepts] ICE when using decltype(requires-expr) as type template parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89743
Bug ID: 89743
Summary: [concepts] ICE when using decltype(requires-expr) as
type template parameter
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jason.e.cobb at gmail dot com
Target Milestone: ---
Example code:
template
struct use_type {};
template // needed to fulfill requirement that requires appears only
in templates
using type = typename use_type;
Example compiler output:
:7:3: internal compiler error: tree check: expected tree that contains
'typed' structure, have 'simple_req' in strip_typedefs_expr, at cp/tree.c:1855
7 | })>;
On Compiler Explorer: https://godbolt.org/z/CsgSH7
Note: tested with both struct and templated alias-declaration, ICE occurs with
both.
[Bug c++/89657] ICE when calling lambda returning requires-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89657
--- Comment #1 from Jason Cobb ---
(In reply to Jason Cobb from comment #0)
> In the code:
> auto x = [](){
> return requires() {
> 1;
> };
> }();
>
> When compiling with trunk as of 2019-03-10, GCC fails with an internal
> compiler error:
> : In instantiation of ' [with int = 0]':
>
> :5:3: required from here
>
> :5:1: internal compiler error: tree check: expected tree that
> contains 'typed' structure, have 'simple_req' in copy_tree_body_r, at
> tree-inline.c:1325
>
> 5 | }();
>
> | ^
>
> Show on Compiler Explorer: https://gcc.godbolt.org/z/jwasQ9
Sorry, clarification: the contents of the requires-expression do not matter,
any requires-expression causes this issue.
[Bug c++/89657] New: ICE when calling lambda returning requires-expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89657
Bug ID: 89657
Summary: ICE when calling lambda returning requires-expression
Product: gcc
Version: c++-concepts
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: jason.e.cobb at gmail dot com
Target Milestone: ---
In the code:
auto x = [](){
return requires() {
1;
};
}();
When compiling with trunk as of 2019-03-10, GCC fails with an internal compiler
error:
: In instantiation of ' [with int = 0]':
:5:3: required from here
:5:1: internal compiler error: tree check: expected tree that contains
'typed' structure, have 'simple_req' in copy_tree_body_r, at tree-inline.c:1325
5 | }();
| ^
Show on Compiler Explorer: https://gcc.godbolt.org/z/jwasQ9
