[Bug libstdc++/112551] New: Incompatibility of libstdc++ liked statically and -Bsymbolic-functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112551 Bug ID: 112551 Summary: Incompatibility of libstdc++ liked statically and -Bsymbolic-functions Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: serge.guel...@telecom-bretagne.eu Target Milestone: --- Created attachment 56595 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56595=edit reproducer Hey folks, While debugging a firefox issue, we found an interesting bug where a program linked statically against libstdc++ and dynamically against a library that's itself statically linked against libstdc++, both with -Bsymbolic-functions, is segfaulting at startup (during Elf con structor init) The attached tarball provides a minimal reproducer. Our understanding of the problem is that an initializer from the libstdc++ is run by the host binary, updating locale::_S_once from the host. Then the shared libray initializes itself, calls the same initializer through its non-interposed version, checks the interposed symbol locale::_S_once (remember we only have -Bsymbolic-functions and not -Bsymbolic), decides everything is initialized, and proceeds to call a local function that references local storage that's not initialized, kaboom. Given the setup, I'm not quite sure libstdc++ should actually support the scenario, but maybe there's a way?
[Bug c++/110816] New: Emit initialization code for empty class under -ftrivial-auto-var-init
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110816 Bug ID: 110816 Summary: Emit initialization code for empty class under -ftrivial-auto-var-init Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: serge.guel...@telecom-bretagne.eu Target Milestone: --- As show cased by https://godbolt.org/z/o5asYGq8G, gcc doesn't fill the byte used by empty class/struct under -ftrivial-auto-var-init. This potentially leaks a byte of memory.
[Bug c++/108158] New: modification of '...' is not a constant expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108158 Bug ID: 108158 Summary: modification of '...' is not a constant expression Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: serge.guel...@telecom-bretagne.eu Target Milestone: --- Since version 11.3, gcc fails on compiling a (complex) constant expression from the frozen[0] library. gcc 11.2 is fine, and so are clang and msvc. I've reduced the code to the following: https://godbolt.org/z/e5bje7v35 It's still a relatively large piece of code, I failed to reduce it more significantly, sorry about that. The error message is ``` :458:39: in 'constexpr' expansion of 'ze_set.frozen::unordered_set::lookup >(4, frozen::elsa())' :453:32: in 'constexpr' expansion of '((const frozen::unordered_set*)this)->frozen::unordered_set::tables_.frozen::bits::pmh_tables<8, frozen::elsa >::lookup >((* & key), (* & hash))' :458:67: in 'constexpr' expansion of 'frozen::bits::seed_or_index()' :458:67: error: modification of 'ze_set' is not a constant expression 458 | constexpr auto nocount = ze_set.lookup(4, frozen::elsa()); | ``` But I don't see where such a modification would happen, and the fact that older version of gcc and clang and msvc correctly evaluate that expression makes me think it could be a GCC bug. Maybe bisecting between 11.2 and 11.3 would help understanding the origin of the regression? [0] https://github.com/serge-sans-paille/frozen
[Bug target/107328] New: bzhi pattern not recognized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107328
Bug ID: 107328
Summary: bzhi pattern not recognized
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: serge.guel...@telecom-bretagne.eu
Target Milestone: ---
This bug looks similar to #93346 and #94860 but the pattern is slightly
different. My understanding is that it is still a valid one (my understanding
is that the shift invokes UB for values of `sz' that would be troublesome for
bzhi)
The pattern:
unsigned bzhi(unsigned y, unsigned sz) {
return y & (~0u >> (CHAR_BIT * sizeof(unsigned) - sz));
}
it should work if `sizeof(unsigned)` is either 4 or 8.
Reproducer on godbolt: https://godbolt.org/z/4PfesvY7Y
