[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() != 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
[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.
