[PATCH] libstdc++: Make constexpr initializer_list a C++14 feature [PR113782]

[Jonathan Wakely]

On Mon, 21 Sept 2026 at 08:21, Tomasz Kaminski <tkaminsk@redhat.com> wrote:
>
>
>
>
> On Sun, Sep 20, 2026 at 12:19 PM Jonathan Wakely <jwakely.gcc@gmail.com> wrote:
>>
>> On Fri, 18 Sept 2026 at 14:35, Albon Wu (BLOOMBERG/ 731 LEX)
>> <awu574@bloomberg.net> wrote:
>> >
>> > Hi all,
>> >
>> > libstdc++ declares multiple methods on initializer_list as constexpr
>> > unconditionally, but N3471 only added these in C++14, so in C++11 this is
>> > non-conforming. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113782
>> >
>> > This also covers the private constructor of initializer_list, meaning it is
>> > no longer a literal type in C++11. Some unrelated tests that used constexpr
>> > initializer_list implicitly are retargeted to C++14.
>> >
>> > Built and tested on x86_64-pc-linux-gnu. Okay for trunk?
>>
>> Thanks for the patch. My concern with this approach is that it's a
>> breaking change for anybody who is (inadvertently or intentionally)
>> relying on this non-conforming behaviour. The benefit of rejecting the
>> code is minimal - does it actually do any harm?
>
> I do not see anything in C++11 standard that would specify compiler-magic
> thjat cosntruct initializer_list out of braces is not usable at compile time,
> and I do not see how N3471 changed that.


So the private constructor can be constexpr for -std=c++11.

We still need to decide if we want to change the public members, or
just close the bug as WONTFIX.


>>
>>
>> So I would prefer to keep these functions as constexpr for
>> -std=gnu++11 and only change -std=c++11
>>