[Bug libstdc++/88935] std::random_shuffle does not work if the sequence is longer than RAND_MAX elements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88935 Andrea Griffini changed: What|Removed |Added CC||agriff at tin dot it --- Comment #12 from Andrea Griffini --- Even assuming rand() were generating hardware random numbers (not allowed by the standard because of srand, obviously), gcc would still be broken and performing a terrible random_shuffle with ranges larger than 64k elements (indeed non-uniformity becomes evident even at much smaller ranges). Mingw's rand() numbers are decent enough (and the period is not just 2**16, for example) but they're only 16 bit. This is allowed. The gcc bug is that it uses rand() (that can be just 16) bit to pick a random number between 0 and the size of the range even when the range is much bigger than 65536. Using rand() to feed data into a xorshift64 or something similar only for large ranges would fix, and would also keep shuffle of small ranges backward compatible (shuffling elements in small ranges exactly as current implementation does if starting from the same random seed). I've somewhere an half backed patch for doing that but quite frankly I don't know if I should polish it and submit here as, in all honesty, seems that in this case the maintainers simply don't want to have this bug fixed, for reasons that I really cannot understand.
[Bug c++/111123] Warning about "used uninitialized" member shown or hidden randomly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23 --- Comment #1 from Andrea Griffini --- Forgot to say that -O3 is needed to see the warning (this is however expected)
[Bug c++/111123] New: Warning about "used uninitialized" member shown or hidden randomly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23
Bug ID: 23
Summary: Warning about "used uninitialized" member shown or
hidden randomly
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: agriff at tin dot it
Target Milestone: ---
This code should warning (with -Wall) about the use of `border` that is
uninitialized
#include
#include
struct Camera {
struct P2d {
float x, y;
};
std::vector clip_area;
float border = 10.f;
int z = 3;
Camera() : clip_area({{border, border},
{1-border, border},
{1-border, 1-border},
{border, 1-border}})
{ }
};
int main() {
Camera c;
printf("%.18g\n", c.clip_area[0].x);
}
However does so only if member `z` is present; commenting out the line `int z =
3;` silences the warning.
This show/hide of the warning happens also pseudo-randomly in other cases
(while I was trying to get the minimum code showing the problem I found many
cases in which removing even an executable statement in the body of a method
triggered the behavior change).
[Bug c++/108299] toplevel thread_local variables are not initialized if not referenced and initialized at wrong moment when referenced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108299 --- Comment #9 from Andrea Griffini --- I agree that comment 0 is wrong and was based on a text that I thought was taken from the standard but apparently was not (cppreference.com). Sorry for the noise. I think that if the dynamic initialization should be tied only to uses of other thread locals requiring dynamic initialization this should be stated more precisely in the standard text.
[Bug c++/108299] toplevel thread_local variables are not initialized if not referenced and initialized at wrong moment when referenced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108299 --- Comment #5 from Andrea Griffini --- So you are saying that the standard forgot to add "that requires dynamic initialization" and that this is the intention?
[Bug c++/108299] toplevel thread_local variables are not initialized if not referenced and initialized at wrong moment when referenced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108299
--- Comment #3 from Andrea Griffini ---
Thread storage duration is different from static storage duration.
The text I found on the topic is different from the one you are linking,
but even in this version (that is indeed more permissive) it's explicitly
stated that a thread_local variable must be initialized before any other
thread_local variable is accessed in the same compilation unit.
> it is implementation-defined whether the dynamic initialization of a
> non-block non-inline variable with thread storage duration is sequenced
> before the first statement of the initial function of a thread or is deferred.
>
> If it is deferred, the initialization associated with the entity for thread
> t is sequenced before the first non-initialization odr-use by t of any
> non-inline variable with thread storage duration defined in the same
> translation unit as the variable to be initialized.
>
> It is implementation-defined in which threads and at which points in
> the program such deferred dynamic initialization occurs.
g++ doesn't seem to follow the rule
#include
thread_local int flag = ([](){
printf("HERE!\n"); // This initialization never happens
return 1;
})();
thread_local int flag2;
int main() {
printf("Hello, world.\n");
flag2 = 0; // accesses another thread_local variable in same compilation
unit
return 0;
}
[Bug c++/108299] New: toplevel thread_local variables are not initialized if not referenced and initialized at wrong moment when referenced
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108299
Bug ID: 108299
Summary: toplevel thread_local variables are not initialized if
not referenced and initialized at wrong moment when
referenced
Product: gcc
Version: 12.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: agriff at tin dot it
Target Milestone: ---
The standard mandates that thread_local variables at top level must be
initialized in case anything in the compilation unit is referred to. There is a
specific note on the fact that they must be initialized even if they're not
used in the program.
Also they must be initialized at thread start or before anything from the
compilation unit is accessed by the thread.
This code however shows that g++ doesn't follow this rule
#include
thread_local int flag = ([](){
printf("HERE!\n");
return 1;
})();
int main() {
printf("Hello, world.\n");
return 0;
}
In this version the thread local initialization is skipped.
Mover if after the printf the statement
flag;
is added then the initialization is performed, but AFTER the "Hello, world"
message (another violation of the standard).
Trying on godbolt I saw the problem is present even in trunk and in clang
(works as expected in MSVC).
The problems are present both on the main implicit thread and with threads
started explicitly with std::thread.
[Bug tree-optimization/105867] [12/13 Regression] incorrect dangling-pointer warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105867 Andrea Griffini changed: What|Removed |Added CC||agriff at tin dot it --- Comment #4 from Andrea Griffini --- Created attachment 53891 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53891&action=edit Simpler version that triggers the bug This code compiled on 12.2.0 with -O3 -Wall generates a warning about storing the address of a local variable. Surprisingly (for me) adding either of the two `printf` statements makes the warning go away. The code seems correct to me; a doubly linked list of all instances of Node is kept by inserting nodes in constructor and removing them in destructor.
