https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87178
--- Comment #13 from roland at gnu dot org ---
(In reply to Jakub Jelinek from comment #7)
> (In reply to Jonathan Wakely from comment #6)
> > OK.
> >
> > FWIW Clang seems to create two different sections called foo, one COMDAT and
> > one not.
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116187
Bug ID: 116187
Summary: -Wuninitialized warnings in
libgrust/libproc_macro_internal/literal.cc
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116188
Bug ID: 116188
Summary: Drop building libcody for stage1 for bootstraps
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116188
Sam James changed:
What|Removed |Added
Keywords||build
Blocks|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113341
--- Comment #16 from Sam James ---
glaubitz, could you check with gcc-14.2 or trunk? I have a feeling honza's IPA
fixes recently sort this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113652
--- Comment #29 from Sam James ---
csfore, erhard, could you test
https://inbox.sourceware.org/gcc-patches/zpioop6il_igm...@cowardly-lion.the-meissners.org/?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104626
Jerry DeLisle changed:
What|Removed |Added
Attachment #58798|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35199
Sam James changed:
What|Removed |Added
Keywords||patch
--- Comment #5 from Sam James ---
(In
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84402
Bug 84402 depends on bug 109051, which changed state.
Bug 109051 Summary: Configure takes long time for multibuild of run-time
libraries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109051
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109051
Sam James changed:
What|Removed |Added
Resolution|--- |WORKSFORME
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116185
--- Comment #1 from Andrew Pinski ---
Created attachment 58802
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58802&action=edit
Reduced testcase
`-fcompare-debug -fno-exceptions -fno-rtti -O2 -gno-statement-frontiers` is
able to reproduce
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110607
Sam James changed:
What|Removed |Added
Keywords||patch
--- Comment #3 from Sam James ---
We
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116185
--- Comment #2 from Andrew Pinski ---
Hmm, for my reduced testcase, the first issue is in gcse (pre) and it started
there in GCC 14.1.0 according to godbolt. So it looks like I reduced a
different compare debug issue as the original one is not t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116189
Bug ID: 116189
Summary: [14/15 Regression] compare debug failure at -O2 on sh
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: compare-debug-failure
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116189
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |14.3
--- Comment #1 from Andrew Pinski
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116185
--- Comment #3 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #2)
> Hmm, for my reduced testcase, the first issue is in gcse (pre) and it
> started there in GCC 14.1.0 according to godbolt. So it looks like I reduced
> a differen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51450
--- Comment #7 from Sam James ---
Possibly fixed by:
commit 11869b9c9eb8bcc8cb6a615141f522a447377324
Author: Gary V. Vaughan
Date: Sat Nov 26 11:06:35 2011 +0700
m4: fix logic error leading to -fno-rtti being added wrongly.
* m4/lib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116185
--- Comment #4 from Andrew Pinski ---
Note the original testcase seems to invoke a similar issue in gcse too. But why
there was no difference previously I have no idea.
Without:
```
(insn # # # 2 (set (reg/f:SI 296)
(symbol_ref:SI ("_Z1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115866
Andi Kleen changed:
What|Removed |Added
CC||andi-gcc at firstfloor dot org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116189
--- Comment #2 from Andrew Pinski ---
Hmm, GCC 13 also had the pre difference but we didn't start to compare debug
failure there either.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116179
Sam James changed:
What|Removed |Added
Summary|[15 regression] |[15 regression]
|-fcompar
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113204
--- Comment #9 from Sam James ---
(In reply to Xi Ruoyao from comment #5)
> I've hit a similar ICE testing libbacktrace with LTO bootstrapped GCC on
> LoongArch:
I hit this today too.
Unfortunately, it seems that libbacktrace gets relinked (an
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113204
Sam James changed:
What|Removed |Added
Last reconfirmed||2024-08-02
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113204
--- Comment #10 from Sam James ---
(My reluctance is because getting a proper set of C sources to reproduce it
seems to keep hiding from me.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113204
--- Comment #11 from Sam James ---
(In reply to Richard Biener from comment #4)
> the non-presence of n{1,2}->lto_file_data represented as -1 makes whether
> non-presence is first dependent on the value of the order of the other.
>
That might
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116163
--- Comment #9 from Sam James ---
* Missing dg- prefix (e.g. "// { message }") or "{ require-effective* ... }"
* s/dg/do/, e.g. "{ do-do compile }"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116163
--- Comment #10 from Sam James ---
* "dsg-message"
* "do-message"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116190
Bug ID: 116190
Summary: raised STORAGE_ERROR : stack overflow or erroneous
memory access with array of unbounded strings
Product: gcc
Version: 14.1.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116178
--- Comment #7 from antto ---
honestly, this was just a semi-serious idea, and then some people on IRC
surprisingly said that they like it and encouraged me to submit it (and i was
surprised, but here it is, i submitted it)
a possible usecase i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116178
--- Comment #8 from Sam James ---
Build systems like autoconf currently hardcode a list of C++ and C standards
which has to be updated every so often (and often gets forgotten about).
autoconf at least will aggressively pick the latest one it kn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116191
Bug ID: 116191
Summary: Avoid inlining in unlikely branches
Product: gcc
Version: 14.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116178
--- Comment #9 from Sam James ---
(In reply to Sam James from comment #8)
To give another example where it might be useful: ICU often ends up cranking
the C++ standard its headers expect before its consumers have bumped it,
recently this was w/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116178
--- Comment #10 from Sam James ---
> If you want to play with new features, there's a flag to enable them already.
> Does -std=c++whatever actually support some new use case that you can't do
> today? Or just "I can't be bothered to decide, gi
301 - 333 of 333 matches
Mail list logo
