Skip to content

fix: constexpr function local must not be static (GCC 11/12 portability) - #390

Merged
nholthaus merged 1 commit into
mainfrom
fix/static-constexpr-local-gcc11
Aug 18, 2026
Merged

fix: constexpr function local must not be static (GCC 11/12 portability)#390
nholthaus merged 1 commit into
mainfrom
fix/static-constexpr-local-gcc11

Conversation

@nholthaus

Copy link
Copy Markdown
Owner

unit::value() declared its needs_fp compile-time selector as a static constexpr local. A static local inside a constexpr function is only well-formed from GCC 13 / Clang 17 (P2647); GCC 11 and 12 reject it:

error: 'needs_fp' declared 'static' in 'constexpr' function

so a translation unit that instantiates value() fails to compile on those compilers. (Surfaced by a downstream project whose CI builds on GCC 11.)

needs_fp is used only as a std::conditional_t condition — its address is never taken and it is never materialized — so dropping static is behavior-identical on every compiler while restoring the build on GCC 11/12.

Verified: full suite 467/467 on GCC 15; and under a GCC 11 container the pre-fix tree fails with the error above while the fixed tree compiles. The declared support floor stays GCC 13 (this is a free portability widening, not a new supported target).

`value()` declared its `needs_fp` compile-time selector as a `static constexpr`
local. A `static` local in a `constexpr` function is only well-formed from GCC
13 / Clang 17 (P2647); GCC 11 and 12 reject it with "declared 'static' in
'constexpr' function", so a translation unit that instantiates `value()` fails
to compile there. The variable is used only as a `std::conditional_t` condition
— its address is never taken and it is never materialized — so dropping
`static` is behavior-identical on every compiler while restoring the build on
GCC 11/12.
@nholthaus
nholthaus merged commit 167c294 into main Aug 18, 2026
12 checks passed
@nholthaus
nholthaus deleted the fix/static-constexpr-local-gcc11 branch August 18, 2026 00:12
@nholthaus nholthaus mentioned this pull request Aug 18, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant