Clang looses constexpr.

[DenisYaroshevskiy]

Bugzilla Link	41093
Resolution	INVALID
Resolved on	Jun 29, 2020 09:29
Version	unspecified
OS	All
CC	@DaemonSnake,@jonathanpoelen,@zygoloid,@rogerorr,@fiesh

Extended Description

The following code doesn't compile with clang and compiles with gcc.
https://gcc.godbolt.org/z/L6dcAu

[zygoloid]

This is a GCC bug. This code:

constexpr void table_map_one_helper(const Table& t, OutTable& out_table, Op op) {
constexpr auto multi_s = t.math.template as_multi_s();
//...

is ill-formed, because the reference 't' cannot be used in a constant expression (naming a reference resolves it to the referenced object, which is unknown here).

You can fix your code by changing that to

constexpr auto multi_s = decltype(t.math)::template as_multi_s();

https://gcc.godbolt.org/z/MBb1-9

[DenisYaroshevskiy]

Thank you, Richard.

Can you please clarify for me: the fact that the function is static doesn't matter - as soon as I reference any symbol that is not constexpr - my whole expression is not constexpr, correct?

[zygoloid]

It's not entirely that simple: constexpr evaluation is symbolic evaluation, and:

void f(int n) {
constexpr bool b = &n == &n;
}

... is OK, because symbolic evaluation of that succeeds. The problem is specific to references. Any time you name a reference, the evaluation semantics of that expression involve resolving the reference to the object that it refers to, so that's immediately non-constant if the reference binding is not "visible" to the evaluation. For example:

void f(int &n) {
constexpr bool b = &n == &n;
}

... is an error, because we cannot resolve 'n' to the object it refers to. And that resolution is not delayed until it's needed; it happens the moment you name 'n'. So even this is ill-formed:

void f(int &n) {
constexpr bool b = (n, true);
}

... even though it doesn't try to read or write through the reference.

[DenisYaroshevskiy]

Thanks!

[zygoloid]

*** Bug #29085 has been marked as a duplicate of this bug. ***

[zygoloid]

*** Bug #30060 has been marked as a duplicate of this bug. ***

[zygoloid]

*** Bug #30972 has been marked as a duplicate of this bug. ***

[zygoloid]

*** Bug llvm/llvm-bugzilla-archive#43732 has been marked as a duplicate of this bug. ***

[zygoloid]

*** Bug #26067 has been marked as a duplicate of this bug. ***

[zygoloid]

*** Bug #34365 has been marked as a duplicate of this bug. ***

[zygoloid]

*** Bug llvm/llvm-bugzilla-archive#46499 has been marked as a duplicate of this bug. ***

[zygoloid]

mentioned in issue llvm/llvm-bugzilla-archive#43732

[zygoloid]

mentioned in issue llvm/llvm-bugzilla-archive#46499

[erichkeane]

mentioned in issue llvm/llvm-bugzilla-archive#46865

[pinskia]

Note https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2022/p2280r4.html changes this to be valid from invalid ...

[llvmbot]

@llvm/issue-subscribers-clang-frontend

Author: None (e0e1e613-dccb-47a5-85db-3dc989429265)

| | | | --- | --- | | Bugzilla Link | [41093](https://llvm.org/bz41093) | | Resolution | INVALID | | Resolved on | Jun 29, 2020 09:29 | | Version | unspecified | | OS | All | | CC | @DaemonSnake,@jonathanpoelen,@zygoloid,@rogerorr,@fiesh |

Extended Description

The following code doesn't compile with clang and compiles with gcc.
https://gcc.godbolt.org/z/L6dcAu

[shafik]

This is really a dup of: #63139