[Bug middle-end/111659] document that -Wstrict-flex-arrays depends on -ftree-vrp

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111659

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED

--- Comment #6 from Jonathan Wakely  ---
This rewrite seems to have garbled the docs.

The attribute says:

  @var{level}=0 is the least strict level, all trailing arrays of structures
  are treated as flexible array members. @var{level}=3 is the strictest level,
  only when the trailing array is declared as a flexible array member per C99
  standard onwards (@samp{[]}), it is treated as a flexible array member.

The -fstrict-flex-arrays option used to agree, but now it says:

  @option{-fstrict-flex-arrays=3}, which is the strictest; all
  trailing arrays of structures are treated as flexible array members.

  The negative form @option{-fno-strict-flex-arrays} is equivalent to
  @option{-fstrict-flex-arrays=0}, which is the least strict.  In this
  case a trailing array is treated as a flexible array member only when
  it is declared as a flexible array member per C99 standard onwards.

So they disagree on what "strictest" means. This is very confusing now.

[Bug libstdc++/115285] [12/13/14 Regression] std::unordered_set can have duplicate value

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115285

--- Comment #16 from Jonathan Wakely  ---
(In reply to frs.dumont from comment #15)
> It's surprising that we need to handle this use case. The user wants K 
> is to be explicitly built from int but then insert ints, weird.

How else would you insert a range of values constructed from the ints into the
container?

The user can insert them one-by-one like this:

for (auto i : int_range)
  m.emplace(i);

So there's no reason to prevent them from doing it using insert(first, last).

> Are other Standard library handling this ?

Yes, because the standard requires it.

The requirement on insert(i, j) is "value_type is Cpp17EmplaceConstructible
into X from *i", which means that allocator_traits::construct(m, p, *i) must
be valid.

allocator_traits::construct always does explicit construction of a new object,
there is no implicit conversion.

This means that insert(i, j) must be equivalent to emplace(*i) in a loop. Which
is what my patch does.

[Bug libstdc++/115285] [12/13/14 Regression] std::unordered_set can have duplicate value

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115285

--- Comment #14 from Jonathan Wakely  ---
We're assuming that an iterator's reference type can be converted to the
key_type. This doesn't compile on trunk:

#include 

struct K {
  explicit K(int) noexcept { }
  bool operator==(const K&) const { return true; }
};

template<> struct std::hash {
  auto operator()(const K&) const { return 0ul; }
};

int i[1];
std::unordered_set s(i, i+1);


This fails for similar reasons:

#include 

struct K {
  explicit K(int) noexcept { }
  bool operator==(const K&) const { return true; }
};

template<> struct std::hash {
  auto operator()(const K&) const { return 0ul; }
};

const std::pair p[2]{{1,2}, {3,4}};
std::unordered_map m(p, p+2);


This fails because of a missing specialization for const rvalues:

#include 
#include 

struct Pair
{
  explicit operator std::pair() const&& { return {1, 2}; }
};

Pair p2[1];
std::unordered_map um(std::make_move_iterator(p2),
std::make_move_iterator(p2+1));


Finally, the _ConvertToValueType<_Select1st, T> specialization needs to handle
all value categories of std::pair arguments.

[Bug c++/117446] Rejects valid code on template parameter packs not expanded with '...'

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117446

--- Comment #1 from Jonathan Wakely  ---
(In reply to Yuchang Su from comment #0)
> It is rejected by Clang, but accepted by GCC.

Is this backwards? It's rejected by GCC, and gives a warning with clang.

[Bug c++/117410] [CWG2949] Ambiguous overload with variadic arguments

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117410

Jonathan Wakely  changed:

   What|Removed |Added

 Blocks||94404
 Status|NEW |SUSPENDED
Summary|Ambiguous overload with |[CWG2949] Ambiguous
   |variadic arguments  |overload with variadic
   ||arguments

--- Comment #6 from Jonathan Wakely  ---
Great, thanks. If I'm reading it correctly, the proposed resolution matches
GCC's current behaviour.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94404
[Bug 94404] [meta-bug] C++ core issues

[Bug c++/117410] Ambiguous overload with variadic arguments

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117410

--- Comment #4 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #2)
> I think the reason GCC rejects the original one is because it's the only
> compiler that correctly implements P2113.

Clang apparently supports P2113 since version 16.

[Bug c++/117410] Ambiguous overload with variadic arguments

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117410

--- Comment #2 from Jonathan Wakely  ---
But without the variadic arguments, the functions have equivalent function
parameter lists, so the constraints are checked. With the ellipsis, they do not
have equivalent function parameter lists, so the constraints are ignored.

That was specified by https://wg21.link/P2113 and implemented by
r11-1571-g57b4daf8dc4ed7

Since the constraints are not checked, we can remove them without changing the
meaning of the program:


template 
bool foo() { return false; }

template 
bool foo(...) { return true; }

template 
bool bar() { return false; }

template 
bool bar(...) { return true; }

int main() {
(foo());
(bar());
}


All compilers agree that this is ambiguous.

I think the reason GCC rejects the original one is because it's the only
compiler that correctly implements P2113.

[Bug libstdc++/111055] [C++23] Implement P1206R7, Conversions from ranges to containers

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111055

--- Comment #9 from Jonathan Wakely  ---
Still to do:

-  and  (I have a patch but it needs more tests)
- 
- 
- 
- 
- 

[Bug libstdc++/117404] New: [C++26] Implement P2077R3 Heterogeneous erasure overloads for associative containers

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117404

Bug ID: 117404
   Summary: [C++26] Implement P2077R3 Heterogeneous erasure
overloads for associative containers
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
Blocks: 110339
  Target Milestone: ---

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2021/p2077r3.html


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110339
[Bug 110339] Implement C++26 library features

[Bug libstdc++/117405] std::type_info::before() fails the asymmetry requirement

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117405

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-11-01
 Status|UNCONFIRMED |NEW

[Bug libstdc++/117403] New: [C++26] Implement P1901R2 Enabling the Use of weak_ptr as Keys in Unordered Associative Containers

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117403

Bug ID: 117403
   Summary: [C++26] Implement P1901R2 Enabling the Use of weak_ptr
as Keys in Unordered Associative Containers
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
Blocks: 110339
  Target Milestone: ---

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p1901r2.html


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110339
[Bug 110339] Implement C++26 library features

[Bug libstdc++/117402] New: [C++26] Implement P2363R5 Extending associative containers with the remaining heterogeneous overloads

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117402

Bug ID: 117402
   Summary: [C++26] Implement P2363R5 Extending associative
containers with the remaining heterogeneous overloads
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
Blocks: 110339
  Target Milestone: ---

https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p2363r5.html


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110339
[Bug 110339] Implement C++26 library features

[Bug web/117401] Spell that ./configure --enable-link-mutex is deprecated

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117401

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Keywords||documentation
   Last reconfirmed||2024-11-01

[Bug libstdc++/102445] [meta-bug] std::regex issues

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102445
Bug 102445 depends on bug 117394, which changed state.

Bug 117394 Summary: evil regex causes a stack overflow and a crash
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117394

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

[Bug libstdc++/117394] evil regex causes a stack overflow and a crash

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117394

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE
 Blocks||102445

--- Comment #1 from Jonathan Wakely  ---
There are lots of existing bugs about this.

*** This bug has been marked as a duplicate of bug 61601 ***


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102445
[Bug 102445] [meta-bug] std::regex issues

[Bug libstdc++/61601] C++11 regex resource exhaustion

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61601

Jonathan Wakely  changed:

   What|Removed |Added

 CC||vincent.lebourlot@starqube.
   ||com

--- Comment #12 from Jonathan Wakely  ---
*** Bug 117394 has been marked as a duplicate of this bug. ***

[Bug libstdc++/112596] GCC regex error in Opentelemetry C++

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112596

Jonathan Wakely  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #5 from Jonathan Wakely  ---
No testcase after a year so I'm closing this.

[Bug libstdc++/96088] Range insertion into unordered_map is less effective than a loop with insertion

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96088

--- Comment #9 from Jonathan Wakely  ---
There are so many ways to break our current optimizations that try to avoid
creating temporaries:

#include 
#include 
#include 

struct K {
  explicit K(int) noexcept { }
  bool operator==(const K&) const { return true; }
};

template<> struct std::hash {
  auto operator()(const K&) const { return 0ul; }
};

int i[1]{};
std::unordered_set s(i, i);

This fails because it tries to do the lookup using an int, which is not a valid
argument to std::hash. The int can't be implicitly converted to K because
the constructor is explicit. For Antony's original example in comment 0 the
implicit conversion from const char* to std::string is valid, so the lookup
causes an allocation.

So the optimization either makes valid code fail to compile, or causes unwanted
extra conversions.

Another way to make it fail would be:

struct Hash
{
  auto operator()(const K&) const { return 0ul; }
  auto operator()(int) const { return 1ul; }
};

struct Eq
{
  bool operator()(const K&, const K&) const { return true; }
  bool operator()(const K&, int) const { return false; }
  bool operator()(int, const K&) const { return false; }
};

int i[2]{};
std::unordered_set s(i, i+2);

Here we can pass an int to the hash function. It compiles OK, but gives the
wrong hash code, so we insert two identical values into a unique container.

We should just stop trying to avoid creating a temporary.

[Bug libstdc++/96088] Range insertion into unordered_map is less effective than a loop with insertion

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96088

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED

--- Comment #8 from Jonathan Wakely  ---
(In reply to François Dumont from comment #1)
> In f2 you use insert(Pair&&) method so a temporary is generated but then
> moved into the container. In f1 we try to check for insertion before
> generating the value_type and to do so we use hash that
> generates an additional temporary.

I think we're trying to be too clever. Trying to avoid creating temporaries
just makes things complicated and fragile, and it's buggy and rejects valid
code.

(In reply to Marc Glisse from comment #3)
> Indeed. If we want to, I think it is possible to add some overloads for when
> the argument is exactly const char* or string_view, which should remain
> conforming and provide a significant part of the benefits.

I think we should try to do this instead.

For the general case, we should just create a value_type and see if it should
be inserted. Trying to avoid that temporary causes too many bugs.

But when key_type is std::string, Hash is std::hash and Eq is
std::equal_to, we could internally use std::hash
and std::equal_to instead.

[Bug c++/117382] Conversion of integral to enumeration outside of range is UB but works in consteval context

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117382

--- Comment #3 from Jonathan Wakely  ---
[dcl.enum] p5:

Each enumeration also has an underlying type. The underlying type can be
explicitly specified using an enum-base. For a scoped enumeration type, the
underlying type is int if it is not explicitly specified. In both of these
cases, the underlying type is said to be
fixed.

[Bug c++/117382] Conversion of integral to enumeration outside of range is UB but works in consteval context

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117382

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #2 from Jonathan Wakely  ---
(In reply to Tilir from comment #0)
> [expr.static.cast] / 10
> 
> If the enumeration type does not have a fixed underlying type,

A scoped enumeration type (i.e. "enum class) always has a fixed underlying
type, and all values of the underlying type are valid values of the enum.

[Bug target/117365] Captured this lost after assignment to std::function

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117365

Jonathan Wakely  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=77686

--- Comment #2 from Jonathan Wakely  ---
Almost certainly a duplicate of bug 77686

[Bug testsuite/28032] gfortran.dg tests use dg-options with -On even though it is already torture tests

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28032

--- Comment #14 from Jonathan Wakely  ---
Aha, it needs a non-empty set of args, which can be ignored. So:

proc dg-gfortran-onepass { args } {
global DO_ONE_PASS 
set DO_ONE_PASS 1
puts "\nRunning dg-gfortran-onepass\n"
}

and then in the tests:

! { dg-gfortran-onepass "" }

[Bug c++/117294] Concept swallow diagnostics when they're defined in terms of type traits

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117294

--- Comment #1 from Jonathan Wakely  ---
I agree it would be nice, but I'm not sure how to do it.

The message *does* say why it fails, but as you point out, the reason it fails
is that it's defined in terms of type traits.

I think we'd need to special case every std type trait and teach the compiler
how to expand it to an explanation of why it evaluates to false.

Even if we remove the constrained function template and just write an assertion
based on the underlying built-in, there's no more information:

struct A {
explicit A(int) {}
};

template 
struct Foo {
T a = 1;
};

auto tryit() {
  static_assert( __is_constructible(Foo) );
}

def.cc:11:18: error: static assertion failed
   11 |   static_assert( __is_constructible(Foo) );
  |  ^~

This is invalid because the "is constructible from zero args" property is
false. Why is it false? Well that's a different question!

Even if the compiler was taught how to explain why is_constructible_v is false for any given set of args, presumably you'd only want a more
detailed breakdown with -fconcepts-diagnostics-depth increased, or if there's
only a single candidate in the overload set. For a bigger overload set, you
probably don't want every candidate with unsatisfied constraints to go into
great detail, when most of them were not the overload you intended to call
anyway.

The diagnostic for the unconstrained case would be even better if it said that
'1' is not convertible to 'A' because the relevant constructor is 'explicit'.

[Bug c++/117294] Concept swallow diagnostics when they're defined in terms of type traits

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117294

--- Comment #3 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #1)
> Even if we remove the constrained function template and just write an
> assertion based on the underlying built-in, there's no more information:
> 
> struct A {
> explicit A(int) {}
> };
> 
> template 
> struct Foo {
> T a = 1;
> };
> 
> auto tryit() {
>   static_assert( __is_constructible(Foo) );
> }

For this simpler case, Clang gives:

def.cc:7:11: error: no viable conversion from 'int' to 'A'
7 | T a = 1;
  |   ^
def.cc:6:8: note: in instantiation of default member initializer 'Foo::a'
requested here
6 | struct Foo {
  |^
def.cc:11:18: note: in evaluation of exception specification for 'Foo::Foo'
needed here
   11 |   static_assert( __is_constructible(Foo) );
  |  ^
def.cc:1:8: note: candidate constructor (the implicit copy constructor) not
viable: no known conversion from 'int' to 'const A &' for 1st argument
1 | struct A {
  |^
def.cc:1:8: note: candidate constructor (the implicit move constructor) not
viable: no known conversion from 'int' to 'A &&' for 1st argument
1 | struct A {
  |^
def.cc:2:14: note: explicit constructor is not a candidate
2 | explicit A(int) {}
  |  ^
1 error generated.


Which I suppose is much closer to what Barry is asking for. So it's certainly
possible, and I'm just not very imaginative.

[Bug c++/117294] Concept swallow diagnostics when they're defined in terms of type traits

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117294

--- Comment #2 from Jonathan Wakely  ---
Interestingly, Clang *does* say why the concept failed, and says that there was
an explicit constructor that wasn't a candidate. But it also prints notes about
implicit copy constructor and implicit move constructor (which don't seem
useful) and it says that the ill-formed conversion from '1' to 'A' occurred "in
evaluation of exception specification for 'Foo::Foo'" which is just
confusing.

def.cc:15:11: error: no viable conversion from 'int' to 'A'
   15 | T a = 1;
  |   ^
def.cc:14:8: note: in instantiation of default member initializer 'Foo::a'
requested here
   14 | struct Foo {
  |^
/usr/bin/../lib/gcc/x86_64-redhat-linux/14/../../../../include/c++/14/type_traits:3383:46:
note: in evaluation of exception specification for 'Foo::Foo' needed here
 3383 |   inline constexpr bool is_constructible_v = __is_constructible(_Tp,
_Args...);
  |  ^
/usr/bin/../lib/gcc/x86_64-redhat-linux/14/../../../../include/c++/14/concepts:160:30:
note: in instantiation of variable template specialization
'std::is_constructible_v>' requested here
  160 |   = destructible<_Tp> && is_constructible_v<_Tp, _Args...>;
  |  ^
/usr/bin/../lib/gcc/x86_64-redhat-linux/14/../../../../include/c++/14/concepts:160:30:
note: while substituting template arguments into constraint expression here
  160 |   = destructible<_Tp> && is_constructible_v<_Tp, _Args...>;
  |  ^
/usr/bin/../lib/gcc/x86_64-redhat-linux/14/../../../../include/c++/14/concepts:164:37:
note: while checking the satisfaction of concept 'constructible_from>'
requested here
  164 | concept default_initializable = constructible_from<_Tp>
  | ^~~
/usr/bin/../lib/gcc/x86_64-redhat-linux/14/../../../../include/c++/14/concepts:164:37:
note: while substituting template arguments into constraint expression here
  164 | concept default_initializable = constructible_from<_Tp>
  | ^~~
def.cc:3:11: note: while checking the satisfaction of concept
'default_initializable>' requested here
3 | template 
  |   ^
def.cc:3:11: note: while substituting template arguments into constraint
expression here
3 | template 
  |   ^~
def.cc:20:10: note: while checking constraint satisfaction for template
'make>' required here
   20 |   return make>();
  |  ^~~~
def.cc:20:10: note: in instantiation of function template specialization
'make>' requested here
def.cc:9:8: note: candidate constructor (the implicit copy constructor) not
viable: no known conversion from 'int' to 'const A &' for 1st argument
9 | struct A {
  |^
def.cc:9:8: note: candidate constructor (the implicit move constructor) not
viable: no known conversion from 'int' to 'A &&' for 1st argument
9 | struct A {
  |^
def.cc:10:14: note: explicit constructor is not a candidate
   10 | explicit A(int) {}
  |  ^
def.cc:20:10: error: no matching function for call to 'make'
   20 |   return make>();
  |  ^~~~
def.cc:4:6: note: candidate template ignored: constraints not satisfied [with T
= Foo]
4 | auto make() {
  |  ^
def.cc:3:11: note: because 'Foo' does not satisfy 'default_initializable'
3 | template 
  |   ^
/usr/bin/../lib/gcc/x86_64-redhat-linux/14/../../../../include/c++/14/concepts:167:2:
note: because '_Tp{}' would be invalid
  167 | _Tp{};
  | ^
2 errors generated.


Why is it showing anything about _Tp{} when the earlier constructible_from<_Tp>
requirement already failed?

[Bug target/117365] Captured this lost after assignment to std::function

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117365

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2024-10-30
 Target|arm-poky-linux-gnueabi-g++  |arm-*-linux-gnueabi
 Ever confirmed|0   |1
  Component|c++ |target
 Status|UNCONFIRMED |WAITING

--- Comment #1 from Jonathan Wakely  ---
(In reply to Koen Poppe from comment #0)
> As this is compiling for an embedded target, I have not been able to run
> this with a more recent version to check whether this is already fixed.

Somebody needs to check this on a non-ancient release though.

[Bug libgcc/65281] Lots of macros using non-reserved names in gthr headers

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65281

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #4 from Jonathan Wakely  ---
There was PR103650 but I fixed that a while ago.

[Bug testsuite/28032] gfortran.dg tests use dg-options with -On even though it is already torture tests

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28032

--- Comment #12 from Jonathan Wakely  ---
I think you should also do:

 set DO_ONE_PASS 0

After checking it, so that it doesn't remain set between tests.

[Bug testsuite/28032] gfortran.dg tests use dg-options with -On even though it is already torture tests

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28032

--- Comment #11 from Jonathan Wakely  ---
It needs to be on a line on its own, and start with dg-

So: 

! { dg-gfortran-onepass }

And rename the proc to match.

[Bug c++/117331] constexpr with "long double" fails on ppc64el

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117331

--- Comment #4 from Jonathan Wakely  ---
As noted in PR 19779, using -ffast-math or -funsafe-math-optimizations allows
your examples to compile.

[Bug c++/117331] constexpr with "long double" fails on ppc64el

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117331

--- Comment #3 from Jonathan Wakely  ---
This is one of many reasons that the world is moving to -mabi=ieeelongdouble
instead of ibmlongdouble

[Bug libstdc++/117321] std::float16_t: undefined reference to `nextafterf16'

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117321

--- Comment #3 from Jonathan Wakely  ---
Yup, with optimization enabled the compiler can expand nextafter16 directly,
but for -O0 we need an extern symbol, which does not come from libstdc++
(although possibly we could define one as a weak symbol in the library).

[Bug c++/117308] Undocumented implementation limits of C++ specification (ISO/IEC 14882)

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117308

--- Comment #3 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #2)
> (In reply to Thomas Kieß from comment #0)
> > the current implementation limits overview
> > (https://gcc.gnu.org/onlinedocs/gcc-14.2.0/cpp/Implementation-limits.html)
> 
> N.B. this page is for cpp the C preprocessor, not for C++.

That's why it only lists things like the number of nested includes and other
limits relevant to preprocessing.

I don't think there's an equivalent page for the C++ compiler, but I don't
think there are any set limits for any of the other quantities. They are
limited only by available memory, but as I said, in practice you'll probably
encounter unacceptably slow compile times on modern machines with multiple
gigabytes of memory available. Some algorithms within the compiler are
quadratic or worse, so when dealing with ridiculously complicated expressions,
source files, or numbers of data members in a struct, performance may slow to a
crawl even before memory is exhausted.

If you encounter practical limits, please report them as bugs with one of the
keywords "compile-time-hog" or "memory-hog".

[Bug c++/117308] Undocumented implementation limits of C++ specification (ISO/IEC 14882)

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117308

--- Comment #2 from Jonathan Wakely  ---
(In reply to Thomas Kieß from comment #0)
> the current implementation limits overview
> (https://gcc.gnu.org/onlinedocs/gcc-14.2.0/cpp/Implementation-limits.html)

N.B. this page is for cpp the C preprocessor, not for C++.

[Bug c++/117308] Undocumented implementation limits of C++ specification (ISO/IEC 14882)

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117308

--- Comment #1 from Jonathan Wakely  ---
I don't think there is any particular limit, it's only limited by your
available RAM when compiling. You will probably experience unacceptably slow
compile times long before you reach a physical limit, but at some point GCC
will just fail to allocate any more memory and either be killed by the OOM
Killer or abort due to a failed allocation.

[Bug c++/117309] [Docs] C++23 is not mentioned on the "supported standards" doc page

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117309

--- Comment #3 from Jonathan Wakely  ---
(In reply to Andrew Pinski from comment #1)
> Well c++23 was only published within the last month.

Within the last week!

[Bug libstdc++/117284] Debug Mode vector invalidates all iterators on assignment

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117284

--- Comment #3 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #1)
> else if (__old_size < _Base::size())

And that should be > not <

[Bug libstdc++/117284] Debug Mode vector invalidates all iterators on assignment

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117284

--- Comment #2 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #1)
> if (__old_data != _Base::data())
>   {
> this->_M_invalidate_all();
> this->_M_update_guaranteed_capacity();
>   }
> else if (__old_size < _Base::size())
>   this->_M_invalidate_after_nth(_Base::size());

I think we also want:

  else
this->_M_update_guaranteed_capacity();

For the case where new elements are inserted into existing capacity without
reallocating.

[Bug libstdc++/117284] Debug Mode vector invalidates all iterators on assignment

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117284

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2024-10-24
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Currently __gnu_debug::vector::assign does:

  this->_M_invalidate_all();
  this->_M_update_guaranteed_capacity();

But I think it should be:

if (__old_data != _Base::data())
  {
this->_M_invalidate_all();
this->_M_update_guaranteed_capacity();
  }
else if (__old_size < _Base::size())
  this->_M_invalidate_after_nth(_Base::size());

where __old_data and __old_size are _Base::data() and _Base::size() before
calling _Base::assign.

[Bug libstdc++/117284] New: Debug Mode vector invalidates all iterators on assignment

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117284

Bug ID: 117284
   Summary: Debug Mode vector invalidates all iterators on
assignment
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

I don't see why the iterator should be invalidated here:

#define _GLIBCXX_DEBUG
#include 

int main()
{
  std::vector v(3);
  auto i = v.begin();
  v.assign(2, 0);
  v.assign({1,2,3});
  return *i;
}

[Bug c++/117272] CWG2518 static_assert(false) when returning

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117272

--- Comment #3 from Jonathan Wakely  ---
(In reply to Richard Kellnberger from comment #0)
> Since gcc 13 this is valid code:
> 
> ```C++
> template void f(){
> static_assert(false);
> }

Only because this function template is never instantiated.

> int main() {
> 
> }
> ```
> 
> This is as well:
> 
> ```C++
> #include 
> 
> template void f(){
> if constexpr(std::is_same_v) {
> 
> } else {
> static_assert(false);
> }
> }
> 
> int main() {
> f();
> }
> ```
> 
> The `static_assert(false)` is ignored if it is not reached due to
> templating.

It's not that it's not "reached", because this isn't about control flow. It's
about whether it's in a discarded statement or not. A discarded statement in a
function template is not instantiated at all. The static_assert is not even
part of the function when the type is int.

> If I placed it into the `if` block instead the code would be
> ill-formed.

Yes, because when the type is int the static_assert(false) would be
instantiated.

> By the same logic the following should be valid, but it is not.

No, because it's literally not "the same logic".

In your last example the static_assert(false) is not in a discarded statement
so is always instantiated by every specialization of the function. It's just
like your first example which is ill-formed if ever called. Returning "before"
the static_assert doesn't make any difference. A static_assert is checked when
the function is instantiated at compile time, not when it's executed at
runtime.

[Bug libstdc++/117276] std::sort(par_unseq ,...) leaks memory when called repeatedly

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117276

Jonathan Wakely  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2024-10-23
 Status|UNCONFIRMED |ASSIGNED

[Bug c/117267] 'setjmp' can never be copied because it receives a non-local goto

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117267

--- Comment #16 from Jonathan Wakely  ---
If the program never executes the code with UB, then the program is correct,
and refusing to compile it with an error would be non-conforming. A warning
would be OK.

[Bug c++/70498] Libiberty Demangler segfaults (3)

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70498

--- Comment #9 from Jonathan Wakely  ---
This was fixed for 4.9.4, 5.4.0, 6.2.0 and later.

[Bug c++/70481] [Regression] Libiberty Demangler segfaults

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70481

--- Comment #7 from Jonathan Wakely  ---
For the record, this was fixed for 4.9.4, 5.4.0, 6.1.0 and later.

[Bug c++/117257] Problem of std::complex and maybe GCC accepts invalid

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117257

--- Comment #6 from Jonathan Wakely  ---
We could consider disabling those extensions for strict modes:

--- a/libstdc++-v3/include/std/complex
+++ b/libstdc++-v3/include/std/complex
@@ -1357,7 +1357,9 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   typedef float value_type;
   typedef __complex__ float _ComplexT;

+#ifndef __STRICT_ANSI__
   _GLIBCXX_CONSTEXPR complex(_ComplexT __z) : _M_value(__z) { }
+#endif

   _GLIBCXX_CONSTEXPR complex(float __r = 0.0f, float __i = 0.0f)
 #if __cplusplus >= 201103L


But I don't think it's necessary. A conforming ISO C++ program cannot use the
type _Complex double, so can't call that constructor anyway.

It doesn't affect the std::is_constructible trait either, because you can't use
std::is_constructible, _Complex double> in a strict ISO
C++ program, and you can't use std::is_constructible to test whether
construction from an initializer-list {1.0, 1.0} works.

It's possible to write a concept or SFINAE check using {1.0, 1.0} but I can't
see it affecting real code, only contrived tests for checking strict
conformance.

[Bug c++/117257] Problem of std::complex and maybe GCC accepts invalid

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117257

--- Comment #5 from Jonathan Wakely  ---
(In reply to Jakub Jelinek from comment #3)
> Though, in the libstdc++ case, aren't those complex(_Complex double x); etc.
> ctors an extension which is causing this?

Yes, without those constructors std::complex({1.0, 1.0}) is just
ill-formed. So the fact that it compiles with GCC is an extension, which is
fine.

If you use the standard-conforming std::complex(1.0, 1.0) then it works
fine. So if you want portable behaviour, write portable code.

[Bug c++/117257] Problem of std::complex and maybe GCC accepts invalid

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117257

--- Comment #2 from Jonathan Wakely  ---
Further reduced:

void f(_Complex double);

int main()
{
f({1.0, 0.0});
}

GCC accepts this, Clang doesn't.

This is the underlying reason why Clang won't accept std::complex({1.0,
1.0}).

[Bug c++/117257] Problem of std::complex and maybe GCC accepts invalid

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117257

Jonathan Wakely  changed:

   What|Removed |Added

  Component|libstdc++   |c++

--- Comment #1 from Jonathan Wakely  ---
(In reply to qurong from comment #0)
> This causes an error in clang, but GCC didn't report the error.
> 
> Compiler Explorer link: https://godbolt.org/z/4sbb3qEqq

This link is using libstdc++ for both cases, so it isn't likely to be a
libstdc++ bug.

I think the difference is how GCC and Clang handle the _Complex keyword, which
is not in standard C++ so there's no requirement for them to behave the same.

Reduced:

template struct complex { };

template<> struct complex {
using CF = _Complex float;
complex(float, float = 0) { }
complex(CF) { }
explicit complex(const complex&) { }
};

template<> struct complex {
using CF = _Complex double;
complex(double = 0, double = 0) { }
complex(CF) { }
explicit complex(const complex&) { }
};

int main()
{
complex c({1.0, 0.0});
}

[Bug c++/117256] When initializing an object, padding bits are not set to zero

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117256

Jonathan Wakely  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=85548,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=78620
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2024-10-22

--- Comment #1 from Jonathan Wakely  ---
Seems like a dup of Bug 78620 (but with a simpler testcase).

[Bug libstdc++/117220] [15 regression] is broken with Clang (stl_iterator.h:1080:42: error: an attribute list cannot appear here)

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117220

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Jonathan Wakely  ---
Fixed

[Bug c++/117246] g++ O1 finline bug

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117246

--- Comment #4 from Jonathan Wakely  ---
The 'delete test' is undefined behaviour as well. You should enable warnings
when compiling: -Wall

[Bug c++/117246] g++ O1 finline bug

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117246

--- Comment #3 from Jonathan Wakely  ---
(In reply to Andrew Pinski from comment #1)
> https://gcc.gnu.org/onlinedocs/gcc-14.2.0/gcc/Optimize-Options.html#index-
> flifetime-dse
> 
> `To preserve stores before the constructor starts (e.g. because your
> operator new clears the object storage) but still treat the object as dead
> after the destructor, you can use -flifetime-dse=1.`

The code is not valid C++ though, so should be fixed instead of disabling
optimizations.
https://gcc.gnu.org/gcc-6/porting_to.html#flifetime-dse

operator new is for allocating memory, not initializing members. A constructor
is for initializing members.

[Bug libstdc++/116754] libstdc++ std::ranges::copy performance issue

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116754

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #8 from Jonathan Wakely  ---
Fixed for 13.4 and 14.3, thanks for the report

[Bug libstdc++/117221] Add smoketest for alternative compiler for libstdc++ headers (like CXX_UNDER_TEST)

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117221

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-10-19
 Status|UNCONFIRMED |NEW

--- Comment #3 from Jonathan Wakely  ---
I have my own:

$ ls ~/src/gcc/extra_tests/clang-smoke-test/
Makefileatomic.cc constexpr.ofunctional.o  link_string
memory.o  random.cc  ranges.o  srcloc.cc  stdatomic.cc   stop_token.o
all_headers.cc  atomic.o  depr.ccis_same.cclink_string.cc 
net.ccrandom.o   span.cc   srcloc.o   stdatomic.ovariant.cc
all_headers.o   constexpr.cc  functional.cc  is_same.o memory.cc  
net.o ranges.cc  span.ostacktrace.cc  stop_token.cc  variant.o

I just forget to run them.

To add this to the testsuite we'll need DG directive or effective target that
checks whether clang++ is in the PATH and is usable.

[Bug libstdc++/117220] [15 regression] is broken with Clang (stl_iterator.h:1080:42: error: an attribute list cannot appear here)

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117220

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2024-10-19
   Target Milestone|--- |15.0
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org

[Bug libstdc++/117214] chrono format error for time point using %c: D_T_FMT cannot be directly used as chrono-specs

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117214

--- Comment #1 from Jonathan Wakely  ---
We should probably just use std::time_put

[Bug tree-optimization/104547] std::vector::resize(v.size() - n) produces poor code

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104547

--- Comment #12 from Jonathan Wakely  ---
Actually, maybe not.

CI was failing for an earlier iteration of r15-4473-g3abe751ea86e34 but the
final version I pushed seems to be optimized well by vrp2. False alarm.

[Bug libstdc++/68350] std::uninitialized_copy overly restrictive for trivially_copyable types

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68350

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #19 from Jonathan Wakely  ---
Fixed for GCC 15

Barry's example in comment 8 now gives:

copy_b(A*, A*, A*):
subq%rdi, %rsi
movq%rdx, %rax
movq%rsi, %rdx
testq   %rsi, %rsi
jle .L1
movq%rdi, %rsi
movq%rax, %rdi
jmp memcpy
.L1:
ret


copy_b(B*, B*, B*):
subq%rdi, %rsi
movq%rdx, %rax
movq%rsi, %rdx
testq   %rsi, %rsi
jle .L4
movq%rdi, %rsi
movq%rax, %rdi
jmp memcpy
.L4:
ret

[Bug libstdc++/114817] Wrong codegen for std::copy of "trivially copyable but not trivially assignable" type

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114817

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #7 from Jonathan Wakely  ---
Fixed for GCC 15

[Bug libstdc++/115444] std::copy_n generates more code than needed

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115444

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #13 from Jonathan Wakely  ---
This should be fixed now.

[Bug tree-optimization/104547] std::vector::resize(v.size() - n) produces poor code

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104547

--- Comment #11 from Jonathan Wakely  ---
This testcase now fails, because _M_default_append is not removed by vrp2. The
body of resize does get optimized pretty well by some later pass. But the
_M_default_append definition remains in the asm even though it's unused.

[Bug middle-end/117208] Miscompilation at -O0

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117208

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-10-18
 Status|UNCONFIRMED |WAITING

--- Comment #1 from Jonathan Wakely  ---
GCC 11.4.0 is no longer supported (it's not even the newest in the GCC 11
release series). Please try to reproduce this with a more recent release.

But I can't reproduce it even with GCC 11.4.0, so maybe this is a bug in
Ubuntu's gcc.

https://godbolt.org/z/Y6o6vYrMT

[Bug libstdc++/108846] std::copy, std::copy_n and std::copy_backward on potentially overlapping subobjects

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108846

--- Comment #31 from Jonathan Wakely  ---
(In reply to Jiang An from comment #4)
> But I think it's only closedly related to uninitialized memory algorithms
> (which perform initialization instead of assignment), and there's already a
> note saying that it's UB to use them to initialize potentially-overlapping
> objects ([specialized.algorithms.general]/3).

For the record, that note was removed for C++23, see
https://github.com/cplusplus/draft/issues/6143
But the uninitialized algos do still reuse storage, so this problem doesn't
apply to them.

[Bug libstdc++/115854] Copy-initialization or implicit conversion is used when creating an allocator whose type is obtained by rebind

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115854

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|14.3|13.4

--- Comment #8 from Jonathan Wakely  ---
Backported for 13.4 too.

[Bug libstdc++/117094] ranges::fill misses std::move for output_iterator

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117094

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #4 from Jonathan Wakely  ---
Fixed for 13.4 and 14.3

[Bug libstdc++/116549] std::disable_sized_sentinel_for is missing specialisation for std::move_iterator

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116549

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #10 from Jonathan Wakely  ---
Fixed for 13.4 and 14.3

[Bug libstdc++/117085] chrono formatting: %c does not honor locale after expansion

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117085

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to fail||13.3.0, 14.2.0
 Resolution|--- |FIXED

--- Comment #8 from Jonathan Wakely  ---
OK, it should be fixed now (for GCC 13.4 and 14.3)

[Bug libstdc++/117187] __niter_base overloads need to be declare before use

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117187

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Jonathan Wakely  ---
Actually this is due to an unpushed change in my tree, so I just need to fix it
there.

[Bug libstdc++/117187] New: __niter_base overloads need to be declare before use

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117187

Bug ID: 117187
   Summary: __niter_base overloads need to be declare before use
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

This fails to compile:

#include 
#include 
#include 

struct S { };

int main()
{
  std::vector v;
  std::vector out;
  std::copy(v.begin(), v.end(), std::make_move_iterator(vout.begin()));
}

The problem is that the __niter_wrap function calls std::__niter_base on the
move_iterator but the __niter_base(move_iterator) overload has not been
declared at that point.

[Bug c/117178] -Wunterminated-string-initialization should ignore trailing NUL byte for nonstring char arrays

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117178

--- Comment #5 from Jonathan Wakely  ---
(In reply to Alejandro Colomar from comment #4)
> As for C++, maybe such an initialization should be acceptable as a GNU
> extension.

Please, no. The C++ rule is a very deliberate language design choice. It would
not be a useful extension to directly contradict that unless users add extra
options to disable it again.

[Bug c++/71029] large fold expressions compile slowly with -Wall

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71029

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |11.0

--- Comment #5 from Jonathan Wakely  ---
Seems to have been fixed for GCC 11.1 with r11-5826:

c-family: Fix hang with -Wsequence-point [PR98126]

verify_sequence_points uses verify_tree to recursively walk the
subexpressions of an expression, and while recursing, it also
keeps lists of expressions found after/before a sequence point.
For a large expression, the list can grow significantly.  And
merge_tlist is at least N(n^2): for a list of length n it will
iterate n(n -1) times, and call candidate_equal_p each time, and
that can recurse further.  warn_for_collision also has to go
through the whole list.  With a large-enough expression, the
compilation can easily get stuck here for 24 hours.

This patch is a simple kludge: if we see that the expression is
overly complex, don't even try.

[Bug libstdc++/117085] chrono formatting: %c does not honor locale after expansion

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117085

Jonathan Wakely  changed:

   What|Removed |Added

 Status|RESOLVED|ASSIGNED
 Resolution|FIXED   |---

--- Comment #6 from Jonathan Wakely  ---
Please leave it open, it still needs to be backported.

[Bug c++/117154] Aggregate initialization with protected destructor in Base class: GCC vs Clang difference

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117154

--- Comment #5 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #4)
> (and Richard Smith aid so in

*said so

[Bug c++/117154] Aggregate initialization with protected destructor in Base class: GCC vs Clang difference

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117154

--- Comment #4 from Jonathan Wakely  ---
Why should access to a protected destructor be different to access to a
protected constructor? It's obviously related (and Richard Smith aid so in the
llvm issue too).

[Bug c++/117156] not applied option “-Wchanges-meaning”

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117156

--- Comment #2 from Jonathan Wakely  ---
The post should say -Wno-changes-meaning disables it.

[Bug c++/117156] not applied option “-Wchanges-meaning”

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117156

--- Comment #1 from Jonathan Wakely  ---
The blog post is wrong, GCC is behaving as intended.

[Bug libstdc++/115444] std::copy_n generates more code than needed

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115444

--- Comment #11 from Jonathan Wakely  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-October/665537.html

[Bug libstdc++/114817] Wrong codegen for std::copy of "trivially copyable but not trivially assignable" type

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114817

--- Comment #5 from Jonathan Wakely  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-October/665537.html

[Bug libstdc++/68350] std::uninitialized_copy overly restrictive for trivially_copyable types

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68350

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #17 from Jonathan Wakely  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-October/665536.html

[Bug c++/117155] Bogus -Wdangling-reference warning after r13-3511-gd2249cd9adf

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117155

--- Comment #2 from Jonathan Wakely  ---
(In reply to Dimitry Andric from comment #0)
> Clearly, there is no dangling reference here, and not even a temporary. And
> even if there was a temporary, its lifetime should have been extended.

No, the temporary it's talking about is the by-value match_t parameter, which
is created when initializing the find parameter. That would not have its
lifetime extended.

The reason there's a warning here is that match_t does contain a std::string,
so the compiler conservatively assumes that the returned const std::string&
refers to the name+ member of the function parameter. If that were the case, it
would indeed be a dangling reference.

You can use [[gnu::no_dangling]] on the fund function template to tell GCC that
it never dangles (although that's not quite true, because find({""}, match)
could dangle).

[Bug c++/117155] Bogus -Wdangling-reference warning after r13-3511-gd2249cd9adf

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117155

--- Comment #1 from Jonathan Wakely  ---
(In reply to Dimitry Andric from comment #0)
> After r15-3941-g2531f014fb2364 ("c++: Implement -Wdangling-reference

I think the correct commit is
r13-3511-gd2249cd9adf5ae638577139177a50f7e62d8abd9

> [PR106393]") for 106393, we are now seeing bogus instances of this new
> warning. Since the commit message marks this as an "experimental warning", I
> would suggest to not put this under -Wall, at least until it is no longer
> experimental, and false positives have been ferreted out.

It was already taken out of -Wall, see r15-2703-g5ebfaf2d4994c1

[Bug libstdc++/106676] [C++20] Automatic iterator_category detection misbehaves when `::reference` is an rvalue reference, refuses to accept a forward iterator

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106676

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
   Target Milestone|--- |15.0

--- Comment #15 from Jonathan Wakely  ---
Fixed on trunk. I might backport it later.

[Bug c++/117154] Aggregate initialization with protected destructor in Base class: GCC vs Clang difference

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117154

--- Comment #1 from Jonathan Wakely  ---
This is https://wg21.link/cwg2244 and it looks like GCC already implements the
suggested resolution.

[Bug c++/117153] [12/13/14/15 Regression] internal compiler error: Segmentation fault at is_overloaded_fn(tree_node*)

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117153

--- Comment #2 from Jonathan Wakely  ---
The backtrace with locations is:

117153.cc: In instantiation of ‘void f() [with T = double]’:
117153.cc:10:25:   required from here
117153.cc:8:5: internal compiler error: Segmentation fault
8 |   d + 0;
  |   ~~^~~
unrecognized DWARF version in .debug_info at 6
0x166e77a crash_signal
../../gcc/toplev.c:330
0xd141aa is_overloaded_fn(tree_node*)
../../gcc/cp/tree.c:2441
0xa2dfd0 potential_constant_expression_1
../../gcc/cp/constexpr.c:7760
0xa2e03c potential_constant_expression_1
../../gcc/cp/constexpr.c:7769
0xa2da5e potential_constant_expression_1
../../gcc/cp/constexpr.c:7668
0xa2dd51 potential_constant_expression_1
../../gcc/cp/constexpr.c:7702
0xa301b4 potential_constant_expression_1
../../gcc/cp/constexpr.c:8272
0xa308cf potential_constant_expression_1(tree_node*, bool, bool, bool, int)
../../gcc/cp/constexpr.c:8377
0xa308fe potential_constant_expression(tree_node*)
../../gcc/cp/constexpr.c:8386
0xc8bab0 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:19620
0xc88eae tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:18919
0xc81945 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:18024
0xc816d7 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:17994
0xc8421f tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:18311
0xca6419 instantiate_body
../../gcc/cp/pt.c:25616
0xca7dee instantiate_decl(tree_node*, bool, bool)
../../gcc/cp/pt.c:25905
0xca819a instantiate_pending_templates(int)
../../gcc/cp/pt.c:25984
0xb01b85 c_parse_final_cleanups()
../../gcc/cp/decl2.c:4904
0xdfecfb c_common_parse_file()
../../gcc/c-family/c-opts.c:1210
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/117152] [15 Regression] Segmentation fault in permerror(unsigned int, char const*, ...)

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117152

--- Comment #3 from Jonathan Wakely  ---
The backtrace with locations is:

117152.cc:3:48: error: could not convert ‘{0}’ from ‘’ to ‘S&&’
3 | friend constexpr S::S(S&& = {0}) noexcept;
  |^~~~
  ||
  |
‘
Segmentation fault
0x2d6b0b2 internal_error(char const*, ...)
../../gcc/diagnostic-global-context.cc:491
0x1172d5b crash_signal
../../gcc/toplev.cc:319
0x5b045f dump_function_name
../../gcc/cp/error.cc:2033
0x5af2ea dump_function_decl
../../gcc/cp/error.cc:1838
0x5abf61 dump_decl
../../gcc/cp/error.cc:1427
0x5b6b80 decl_to_string
../../gcc/cp/error.cc:3324
0x5bad63 cp_printer
../../gcc/cp/error.cc:4497
0x2d98ffb pretty_printer::format(text_info*, urlifier const*)
../../gcc/pretty-print.cc:1774
0xad8a0e pp_format(pretty_printer*, text_info*, urlifier const*)
../../gcc/pretty-print.h:575
0x2d59a39 diagnostic_context::report_diagnostic(diagnostic_info*)
../../gcc/diagnostic.cc:1472
0x2d5a0de diagnostic_context::diagnostic_impl(rich_location*,
diagnostic_metadata const*, int, char const*, __va_list_tag (*) [1],
diagnostic_t)
../../gcc/diagnostic.cc:1618
0x2d6a369 permerror(unsigned int, char const*, ...)
../../gcc/diagnostic-global-context.cc:307
0x5526c0 grokfndecl
../../gcc/cp/decl.cc:10739
0x561dc9 grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
../../gcc/cp/decl.cc:14789
0x586ab5 grokfield(cp_declarator const*, cp_decl_specifier_seq*, tree_node*,
bool, tree_node*, tree_node*)
../../gcc/cp/decl2.cc:1054
0x6f04cf cp_parser_member_declaration
../../gcc/cp/parser.cc:28714
0x6ef0f5 cp_parser_member_specification_opt
../../gcc/cp/parser.cc:28078
0x6ec98c cp_parser_class_specifier
../../gcc/cp/parser.cc:27067
0x6dd9e1 cp_parser_type_specifier
../../gcc/cp/parser.cc:20234
0x6d7a13 cp_parser_decl_specifier_seq
../../gcc/cp/parser.cc:16760
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/117152] [15 Regression] Segmentation fault in permerror(unsigned int, char const*, ...)

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117152

Jonathan Wakely  changed:

   What|Removed |Added

  Known to fail||15.0
   Target Milestone|--- |15.0
  Known to work|14.1.0  |14.2.0

--- Comment #2 from Jonathan Wakely  ---
Aside: why does this crash without printing "internal compiler error: " before
the "Segmentation fault" string?

It caused a minor hiccup for my bisection scripts, I had to match on the
diagnostic string, where normally I could just say I'm searching for an ICE.

[Bug c++/117153] [12/13/14/15 Regression] internal compiler error: Segmentation fault at is_overloaded_fn(tree_node*)

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117153

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2024-10-15
 Ever confirmed|0   |1
 CC||mpolacek at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #1 from Jonathan Wakely  ---
Regressed with r11-4501

c++: Prevent warnings for value-dependent exprs [PR96742]

Here, in r11-155, I changed the call to uses_template_parms to
type_dependent_expression_p_push to avoid a crash in C++98 in
value_dependent_expression_p on a non-constant expression.  But that
prompted a host of complaints that we now warn for value-dependent
expressions in templates.  Those warnings are technically valid, but
people still don't want them because they're awkward to avoid.  This
patch uses value_dependent_expression_p or type_dependent_expression_p.
But make sure that we don't ICE in value_dependent_expression_p by
checking potential_constant_expression first.

[Bug c++/117152] [15 Regression] Segmentation fault in permerror(unsigned int, char const*, ...)

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117152

Jonathan Wakely  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #1 from Jonathan Wakely  ---
Regressed with r15-1635

diagnostics: introduce diagnostic-global-context.cc

This moves all of the uses of global_dc within diagnostic.cc (including
the definition) to a new diagnostic-global-context.cc.  My intent is to
make clearer those parts of our internal API that implicitly use
global_dc, and to perhaps avoid linking global_dc into a future
libdiagnostics.so.

No functional change intended.

[Bug c++/117152] [15 Regression] Segmentation fault in permerror(unsigned int, char const*, ...)

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117152

Jonathan Wakely  changed:

   What|Removed |Added

Summary|Segmentation fault in   |[15 Regression]
   |permerror(unsigned int, |Segmentation fault in
   |char const*, ...)   |permerror(unsigned int,
   ||char const*, ...)
   Keywords||ice-on-invalid-code
  Known to work||14.1.0
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-10-15

[Bug libstdc++/117151] _GLIBCXX_USE_C99_COMPLEX_ARC and _GLIBCXX_USE_C99_COMPLEX are not defined in a consistent way

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117151

--- Comment #1 from Jonathan Wakely  ---
(In reply to vincenzo Innocente from comment #0)
> Not sure if it is intended or not but
> if _GLIBCXX_USE_C99_COMPLEX is defined to be "0" (say on the command line)

That's undefined behaviour, it's an internal macro for internal use.

> it will not be redifined in
> x86_64-pc-linux-gnu/libstdc++-v3/include/x86_64-pc-linux-gnu/bits/c++config.h
> while _GLIBCXX_USE_C99_COMPLEX_ARC is defined "1" unconditionally
> (I would have expected that _GLIBCXX_USE_C99_COMPLEX_ARC to have the same
> value of _GLIBCXX_USE_C99_COMPLEX )
> 
> so "c++ -D_GLIBCXX_USE_C99_COMPLEX=0 -D_GLIBCXX_USE_C99_COMPLEX_ARC=0"
> will use C99 functions for arc and the inline definitions for the others...

Don't do that, it's undefined.

[Bug libstdc++/44952] #include implies global constructor.

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44952

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
   Target Milestone|--- |13.0

--- Comment #20 from Jonathan Wakely  ---
Yes I think so - let's close it.

[Bug libstdc++/97088] 17_intro/names.cc and experimental/names.cc fail with --disable-libstdcxx-pch

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97088

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|--- |12.0
 Status|NEW |RESOLVED

--- Comment #9 from Jonathan Wakely  ---
I don't think this is still failing, please reopen if I'm wrong.

[Bug libstdc++/117135] 22_locale/time_get/get/wchar_t/5.cc fails on arm since gcc-15-4016-gc534e37facc

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117135

--- Comment #13 from Jonathan Wakely  ---
Heh, I completely forgot we have --enable-clocale=newlib

It only has one non-generic file, ctype_members.cc

We should probably add time_members.cc too.

[Bug libstdc++/117135] 22_locale/time_get/get/wchar_t/5.cc fails on arm since gcc-15-4016-gc534e37facc

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117135

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED

--- Comment #11 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #9)
> I think I should also make configure print a warning for this case to say
> that --enable-clocale=gnu is being ignored.

Or we could make --enable-clocale=gnu actually work for newlib, and change
time_members to conditionally use newlib's _NL_TIME_WD_T_FMT instead of glibc's
_NL_WD_T_FMT.

Anyway, this should be fixed now. Sorry it turned out to be a silly coding
mistake not a target-specific newlib oddity.

[Bug ipa/102528] Unused out-of-line functions emitted for trivial coroutines

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102528

--- Comment #10 from Jonathan Wakely  ---
(In reply to Iain Sandoe from comment #9)
> hmm ... I thought that adding the tag "obsolete" should hide it - but maybe
> it has to be done by the OP. I tried to add it and it didn't seem to make
> any difference.

Replying late just to clarify this:

The obsolete tag does hide it, and anybody with a @gcc.gnu.org can add that
tag. You just need to refresh the page for tagged comments to become hidden.

[Bug target/116833] [12/13/14/15 Regression] Symbian: incorrect configuration for crtfastmath.o

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116833

--- Comment #8 from Jonathan Wakely  ---
(In reply to Fiodar from comment #5)
> Which tests you need to run?

For ports of GCC to be considered supported we require results of the gcc
testsuite to be posted to the gcc-testresults mailing list. Without that, we
have no way to know if the port is working or not.

But it's also good to know that it does actually build and work for your uses.

[Bug libstdc++/117135] 22_locale/time_get/get/wchar_t/5.cc fails on arm since gcc-15-4016-gc534e37facc

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117135

--- Comment #9 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #8)
> Ah! that explains it. The --enable-clocale=gnu configure option gets ignored:
> 
>   # Sanity check model, and test for special functionality.
>   if test $enable_clocale_flag = gnu; then
> AC_EGREP_CPP([_GLIBCXX_ok], [
> #include 
> #if (__GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 3)) &&
> !defined(__UCLIBC__)
>   _GLIBCXX_ok
> #endif
> ], enable_clocale_flag=gnu, enable_clocale_flag=generic)

I think I should also make configure print a warning for this case to say that
--enable-clocale=gnu is being ignored.

If somebody wanted to, they could also implement a
config/locale/newlib/time_members.cc model that used the newlib extensions
_NL_TIME_WD_T_FMT etc.

[Bug libstdc++/117135] 22_locale/time_get/get/wchar_t/5.cc fails on arm since gcc-15-4016-gc534e37facc

[redi at gcc dot gnu.org via Gcc-bugs]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117135

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
 Status|NEW |ASSIGNED
   Assignee|jwakely.gcc at gmail dot com   |redi at gcc dot gnu.org

--- Comment #8 from Jonathan Wakely  ---
Ah! that explains it. The --enable-clocale=gnu configure option gets ignored:

  # Sanity check model, and test for special functionality.
  if test $enable_clocale_flag = gnu; then
AC_EGREP_CPP([_GLIBCXX_ok], [
#include 
#if (__GLIBC__ > 2 || (__GLIBC__ == 2 && __GLIBC_MINOR__ >= 3)) &&
!defined(__UCLIBC__)
  _GLIBCXX_ok
#endif
], enable_clocale_flag=gnu, enable_clocale_flag=generic)

So it's using the generic impl not the gnu one. That makes a lot more sense.

Looks like I didn't fix the wchar_t strings in generic/time_members.cc code to
make this test work:

  _M_data->_M_date_time_format = L"";
  _M_data->_M_date_time_era_format = L"";

Those should have been set in r15-4016-gc534e37faccf48