https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88935
Andrea Griffini changed:
What|Removed |Added
CC||agriff at tin dot it
--- Comment #12
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)
ty: 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
str
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 initializatio
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?
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 e
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105867
Andrea Griffini changed:
What|Removed |Added
CC||agriff at tin dot it
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70737
--- Comment #1 from Andrea Griffini ---
Forgot to mention that this a stripped-down version of a problem we had in
production code where indeed the result was an un-initialized value (resulting
in a random huge number).
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: agriff at tin dot it
Target Milestone: ---
When compiling the code
struct C {
C(){}
template explicit operator T () const { return T(42); }
operator int
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66086
--- Comment #6 from Andrea Griffini ---
The question is however: with a 32-bit intptr_t and a 64-bit double (that
has no problem with ints up to 2^53) is it legal for gcc to avoid
initialization of the memory? This is what gcc is doing.
Where it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66086
--- Comment #3 from Andrea Griffini ---
The problem remains even storing the intermediate result to a named variable
(not really surprising)...
uintptr_t ip = (uintptr_t)ptr;
return (double)ip;
but of course goes away if storing the poi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66086
--- Comment #2 from Andrea Griffini ---
(In reply to Andrea Griffini from comment #1)
> Not sure if this helps but I found that when compiling -m32 -O -fno-tree-dce
> the output of the program becomes correct but the generated code is not.
>
> M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66086
--- Comment #1 from Andrea Griffini ---
Not sure if this helps but I found that when compiling -m32 -O -fno-tree-dce
the output of the program becomes correct but the generated code is not.
More specifically the non-inlined version of `doit` con
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: agriff at tin dot it
Target Milestone: ---
Created attachment 35510
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35510&action=edit
Small program showing the problem
When compiling
doub
15 matches
Mail list logo
