https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109720
--- Comment #7 from Paul Smith ---
Just to note this code also throws this warning in GCC 12.3 but it doesn't
complain in GCC 11.3 which is what I was using before.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109720
--- Comment #6 from Paul Smith ---
I'm happy to provide the source for DynamicBitSet (it's basically a union of a
uint64_t and a boost::dynamic_bitset so that if you have <=64 bits you use the
uint64_t and if you have >64 bits you use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109720
--- Comment #5 from Richard Biener ---
We complain about the m_num_bits read. While PRE isolates it to BB3 even
before PRE that happens unconditionally:
[local count: 118111600]:
nbits ={v} {CLOBBER};
_25 = MEM[(const struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109720
--- Comment #4 from Andrew Pinski ---
Some internal GCC Notes:
PRE introduces the read from uninitialized memory though it is not used in some
pathes. The IR/CFG is very has some interesting twists and turns to it which
looks like it confuses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109720
--- Comment #3 from Paul Smith ---
Created attachment 54986
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54986=edit
bitset.i.gz compressed preprocessor output
Hm, I did attach it when I filed the bug; I guess I forgot to click some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109720
--- Comment #2 from Andrew Pinski ---
(In reply to Paul Smith from comment #1)
> Hm, maybe it's due to the union. Maybe GCC can't grok that we ensure that
> we only use the dynamic_bitset leg of the union after we've initialized it?
Once we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109720
--- Comment #1 from Paul Smith ---
Hm, maybe it's due to the union. Maybe GCC can't grok that we ensure that we
only use the dynamic_bitset leg of the union after we've initialized it?
I wonder if this warning could just assume that if the
