[Bug c++/83568] New: thread_local class members not initialized before accessed using operator ::

[tinrow at gmail dot com]

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

Bug ID: 83568
   Summary: thread_local class members not initialized before
accessed using operator ::
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tinrow at gmail dot com
  Target Milestone: ---

thread_local class members are not initialized as expected, if it is accessed
using member access operator (dot) instead of scope resolution operator :: .
The initialization only happens on the first time it is accessed using operator
:: .

reproducible code (gcc 4.8 - 7.1):

#include 
bool initialized = false;

int init() {
initialized = true;
return 1;
}

struct A {
static thread_local int foo;
};

thread_local int A::foo { init() };

int main() {
A a;
std::cout << (initialized ? "ok" : "bug" ) << std::endl;
std::cout << a.foo << std::endl;
std::cout << A::foo << std::endl;
return 0;
}


Output:
bug
0
1

[Bug c++/83568] thread_local class members not initialized before accessed using operator ::

[tinrow at gmail dot com]

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

--- Comment #1 from Kan Wang  ---
Sorry for wrong paste, the code should be

#include 
bool initialized = false;

int init() {
initialized = true;
return 1;
}

struct A {
static thread_local int foo;
};

thread_local int A::foo { init() };

int main() {
A a;
std::cout << a.foo << std::endl;
std::cout << (initialized ? "ok" : "bug" ) << std::endl;
std::cout << A::foo << std::endl;
return 0;
}


Output:
0
bug
1

[Bug c++/60702] thread_local initialization

[tinrow at gmail dot com]

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

Kan Wang  changed:

   What|Removed |Added

 CC||tinrow at gmail dot com

--- Comment #5 from Kan Wang  ---
+1 for this. If class member has thread-local storage and is first accessed
through member access operator (e.g. a.foo), it is not initialized as expected.

The short code snippet below reproduces the bug on g++ 4.8 - 7.1

#include 
int init() {
std::cout << "init" << std::endl;
return 0;
}

struct A {
static thread_local int foo;
};
thread_local int A::foo { init() };

int main() {
A a;
int i = a.foo;
std::cout << "--- should be initialized above ---" << std::endl;
i = A::foo;
return i;
}

Output:
--- should be initialized above ---
init

[Bug libstdc++/61667] New: setting max_load_factor of unordered_map cause buckets shrink

[tinrow at gmail dot com]

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

Bug ID: 61667
   Summary: setting max_load_factor of unordered_map cause buckets
shrink
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tinrow at gmail dot com

I want to build an unordered_map with at least 20 initial buckets and set
max load factor to 0.5. The bucket count shrinks to 2 during call to
max_load_factor.

Reproduce:
$ cat 1.cpp 
#include 
#include 

using namespace std;

int main () {
  unordered_map m(20);
  cout << m.bucket_count() << endl;
  m.max_load_factor(0.5);
  cout << m.bucket_count() << endl;
  return 0;
}

$ g++ -std=c++11 1.cpp 
$ ./a.out 
202409
2

$ g++ --version
g++ (GCC) 4.8.2

In the ISO/IEC 14882:2011 standard, here is a possible "increase" but no
"shrink".

b.max_load_factor() float
Returns a positive number that the container attempts to keep the load factor
less than or equal to. The container automatically increases the number of
buckets as necessary to keep the load factor below this number.