https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114947
Bug ID: 114947
Summary: [modules] ICE when processing class-scope constrained
partial specialisations
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114946
Bug ID: 114946
Summary: [concepts] No error for invalid requires constraint in
declaration
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008
--- Comment #12 from Jonathan Wakely ---
There's nothing fake about them, they are definitely inline functions as far as
the language rules. But in some cases we don't want the compiler to use that
fact as an optimisation hint.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114874
Paul Thomas changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93008
--- Comment #11 from Eric Gallager ---
(In reply to Jan Hubicka from comment #8)
> Reading the discussion again, I don't think we have a way to make inline
> keyword ignored by inliner. We can make not_really_inline attribute (better
> name woul
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114945
Andrew Pinski changed:
What|Removed |Added
Summary|[14 regression] Sporadic|[14/15 regression] Sporadic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #63 from Segher Boessenkool ---
(In reply to Sarah Julia Kriesch from comment #62)
> (In reply to Segher Boessenkool from comment #61)
> > (In reply to Sarah Julia Kriesch from comment #60)
> > > I have to agree with Richard. This pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114945
Bug ID: 114945
Summary: Sporadic std::vector::resize() -Wstringop-overflow or
-Warray-bounds warning with gcc 14
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114944
John Platts changed:
What|Removed |Added
Target||x86_64-*-*, i?86-*-*
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114944
Bug ID: 114944
Summary: Codegen of __builtin_shuffle for an 16-byte uint8_t
vector is suboptimal on SSE2
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Sever
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #62 from Sarah Julia Kriesch ---
(In reply to Segher Boessenkool from comment #61)
> (In reply to Sarah Julia Kriesch from comment #60)
> > I have to agree with Richard. This problem has been serious for a long time
> > but has been
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114943
Bug ID: 114943
Summary: X86 AVX2: inefficient code generated to convert SIMD
Vectors
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114940
--- Comment #7 from Arsen Arsenović ---
(In reply to Jonathan Wakely from comment #6)
> What would be needed to work without it? It looks like the allocation would
> have to be larger so the size could be stored as a cookie at the start of
> the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114940
--- Comment #6 from Jonathan Wakely ---
What would be needed to work without it? It looks like the allocation would
have to be larger so the size could be stored as a cookie at the start of the
allocated block?
Tangentially, could _M_alloc_size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71482
--- Comment #8 from Jonathan Wakely ---
(In reply to Eric Gallager from comment #6)
> Another reason this warning might be wanted: name mangling and demangling of
> global constructors has been buggy for awhile now; see bug 54254
Looks like that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114940
--- Comment #5 from Arsen Arsenović ---
imo, creating a divergent code path for this case isn't worth it, especially
for something that isn't trivial. I'd opt for checking for sized dealloc in
version.def.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114941
--- Comment #3 from jcmvbkbc at gcc dot gnu.org ---
(In reply to Ian Lance Taylor from comment #2)
> What is the correct way to get the address at which the shared library was
> loaded when using FDPIC?
There's no single base address in case of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114942
--- Comment #2 from Uroš Bizjak ---
This is the insn in question:
;; Alternative 1 is needed to work around LRA limitation, see PR82524.
(define_insn_and_split "*qi_ext_1_slp"
[(set (strict_low_part (match_operand:QI 0 "register_operand" "+
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101166
--- Comment #3 from Eric Gallager ---
The FSFE's REUSE tool could be helpful for this:
https://github.com/fsfe/reuse-tool
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99475
Eric Gallager changed:
What|Removed |Added
Keywords||needs-bisection
--- Comment #8 from Eric
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71482
Eric Gallager changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79341
--- Comment #78 from Eric Gallager ---
(In reply to Ilya Leoshkevich from comment #77)
> Apparently fixing the message in GCC will produce maintenance overhead [1].
> If that's not very important to you, I'd rather leave this message as is.
>
>
22 matches
Mail list logo
