Bug 92411 - conformance issue with reinterpret_cast in constant expressions
Summary: conformance issue with reinterpret_cast in constant expressions
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: unknown
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
Keywords: accepts-invalid
Depends on:
Blocks: constexpr
  Show dependency treegraph
Reported: 2019-11-07 18:00 UTC by Darrell Wright
Modified: 2021-12-03 08:45 UTC (History)
2 users (show)

See Also:
Known to work:
Known to fail:
Last reconfirmed: 2019-11-28 00:00:00


Note You need to log in before you can comment on or make changes to this bug.
Description Darrell Wright 2019-11-07 18:00:25 UTC
It looks like there is a regression in trunk(20171107 on CE) that allows reinterpret_casts in constant expressions.

using size_t = decltype(sizeof(int));

constexpr char const * func( char const * ptr ) {
    return reinterpret_cast<char const *>( ptr );

static_assert( func( nullptr ) == nullptr );

template<size_t N>
constexpr char const * func2( char const (&s)[N] ) {
    return reinterpret_cast<char const *>( s );

static_assert( *func2( "Hello" ) == 'H' );

I think this should be ill formed with a diag according to the following links, but it is allowed 
Comment 1 Darrell Wright 2019-11-27 21:17:17 UTC
sorry, posted incorrect CE link, but code below demonstrates it
Comment 2 Jonathan Wakely 2019-11-28 09:02:51 UTC
I see no regression, it has always been accepted by G++.

Possibly a dup of Bug 82304.
Comment 3 Will Wray 2020-07-22 13:29:57 UTC
This particular cast, from const char array to const char pointer, is implicit
so static_cast suffices (and the reinterpret_cast is implictly a static_cast).

Editing your code sample to change reinterpret_cast to static_cast
it is accepted without diagnostic on gcc, clang, msvc, icc

The final comment on the bug linked as a possible duplicate shows that
some fixes were committed last month, fixing other cases.
I guess this particular case can be closed.
Comment 4 Will Wray 2020-07-22 15:30:27 UTC
I mis-read this so was too hasty in suggesting "can be closed".
The standard states that a expression evaluation fails to be a constant
expression if it evaluates "reinterpret_cast" (i.e., by named token,
not by the actual strength of cast required, so seems to be the intent).
It's a 50/50 split with gcc & icc accepting, clang and msvc rejecting