https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119620
Bug ID: 119620
Summary: flat_set::emplace is constrained
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119616
--- Comment #15 from Andrew Pinski ---
Why it fails for FF with PGO is because we decide not to inline a few things
and things just go down hill. Why it works at -O1 vs -O2 is because the
musttail pass skips over non-musttail edges.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119616
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119616
--- Comment #13 from Andrew Pinski ---
Created attachment 60991
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60991&action=edit
Reduced as far as I can reduce it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119619
Bug ID: 119619
Summary: fdump-passes says musttail pass is off when a function
with musttail exists
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119618
--- Comment #5 from Sam James ---
This one fails at > -O0 with -g:
```
typedef struct {
} a;
_Bool b();
int *c() {
if (b())
return 0;
{
a d;
do
[[clang::musttail]] return ((int *(*)(int, a *, int, int, int))1)(1, 0,
1,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119618
--- Comment #4 from Sam James ---
```
typedef struct {
int a;
} b;
b c;
int d;
void e(int *);
int f() {
{
b g = c;
e((int *)g.a);
if (d) [[clang::musttail]]
return f();
}
return 1;
}
```
This has slightly different beh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119618
--- Comment #3 from Sam James ---
(In reply to Sam James from comment #2)
> It's compare-debug. `gcc -c ceval.i -fprofile-generate -g` works, but `gcc
> -c ceval.i -fprofile-generate -g -O1` fails.
Sorry, and: -O0 and -O1 without -g work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119618
Sam James changed:
What|Removed |Added
Keywords|tail-call |compare-debug-failure
--- Comment #2 from S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119618
Andrew Pinski changed:
What|Removed |Added
Keywords||tail-call
--- Comment #1 from Andrew Pi
lib zstd
gcc version 15.0.1 20250403 (experimental)
92ca72b41a74aef53978cadbda33dd38b69d3ed3 (Gentoo Hardened 15.0. p, commit
43e87541519c3e496094d7febd6b772ce0fb33b9)
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119601
Sam James changed:
What|Removed |Added
Last reconfirmed||2025-04-04
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119602
Sam James changed:
What|Removed |Added
Last reconfirmed||2025-04-04
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119617
Bug ID: 119617
Summary: ICE: in standard_sse_constant_opcode, at
config/i386/i386.cc:5465 with
-fzero-call-used-regs=all -mabi=ms -mavx512f
-mno-evex512
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119300
--- Comment #2 from Zdenek Sojka ---
It fails the same way with -std=c11 -mfpmath=387:
$ x86_64-pc-linux-gnu-gcc -std=c11 -mfpmath=387 testcase.c
testcase.c: In function 'foo':
testcase.c:5:1: error: unrecognizable insn:
5 | }
| ^
(i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119608
Nathaniel Shead changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |nshead at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119564
Nathaniel Shead changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119616
--- Comment #10 from Andrew Pinski ---
Created attachment 60988
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60988&action=edit
non-PGO but no reduced
Works at -O1 but fails at -O2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119616
Andrew Pinski changed:
What|Removed |Added
Keywords||needs-reduction
--- Comment #12 from An
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119616
--- Comment #11 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #10)
> Created attachment 60988 [details]
> non-PGO but no reduced
>
> Works at -O1 but fails at -O2.
The difference between this and the original preprocessed sour
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119616
Andrew Pinski changed:
What|Removed |Added
Component|gcov-profile|tree-optimization
Keywords|EH
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119616
--- Comment #8 from Andrew Pinski ---
_25 = google::protobuf::internal::TcParser::MiniParse (msg_14(D), pretmp_68,
ctx_21(D), table_16(D), hasbits_15(D), data); [must tail call]
goto ; [100.00%]
[count: 1073741824]:
# _10 = PHI
retu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119616
--- Comment #7 from Sam James ---
Created attachment 60987
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60987&action=edit
generated_message_tctable_lite.ii.222t.tailc.xz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119616
--- Comment #6 from Sam James ---
Created attachment 60986
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60986&action=edit
generated_message_tctable_lite.ii.133t.tailr2.xz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119616
--- Comment #5 from Sam James ---
Created attachment 60985
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60985&action=edit
generated_message_tctable_lite.ii.048t.tailr1.xz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119616
--- Comment #4 from Sam James ---
Created attachment 60984
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60984&action=edit
generated_message_tctable_lite.ii.269t.optimized-O2.xz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119616
--- Comment #3 from Sam James ---
Created attachment 60983
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60983&action=edit
generated_message_tctable_lite.ii.269t.optimized-O1.xz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111499
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.5
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119616
--- Comment #2 from Sam James ---
Reducing this is going to be hell. If needed, I can try run the protobuf
testsuite with PGO which will be more manageable..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119616
--- Comment #1 from Sam James ---
Created attachment 60982
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60982&action=edit
generated_message_tctable_lite.gcda.xz
-include-dir=/usr/include/c++/v1
--with-build-config='bootstrap-O3 bootstrap-lto'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.1 20250403 (experimental)
92ca72b41a74aef53978cadbda33dd38b69d3ed3 (Gentoo Hardened 15.0. p, commit
43e87541519c3e496094d7febd6b772ce0fb33b9)
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63572
--- Comment #34 from Andrew Pinski ---
https://discourse.llvm.org/t/rfc-new-dwarf-attribute-for-symbolication-of-merged-functions/79434
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119592
--- Comment #3 from Andrew Pinski ---
I think the missed optimization is just reduces down to PR 23384 but I could be
wrong.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119564
Nathaniel Shead changed:
What|Removed |Added
Last reconfirmed|2025-04-01 00:00:00 |2025-04-03
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119608
Nathaniel Shead changed:
What|Removed |Added
Last reconfirmed||2025-04-03
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119607
--- Comment #19 from Philip Withnall ---
Thanks both, that’s quite an old latent bug fixed :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119564
--- Comment #12 from Andrew Pinski ---
Reducing this.
And yes it looks GC related:
```
In module gcc_repro_a, imported at t1.cc:84182:
t0.cc: In member function ‘virtual bool
boost::system::error_category::failed(int) const’:
t0.cc:154191:18: i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119596
--- Comment #18 from Mateusz Guzik ---
Ok, I see.
I think I also see the discrepancy here.
When you bench "libcall", you are going to glibc with SIMD-enabled routines.
In contrast, the kernel avoids SIMD for performance reasons and instead wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119613
--- Comment #6 from Andrew Pinski ---
;; _9 = d (D.2936); [tail call] [must tail call]
(call_insn/j 14 13 15 3 (set (reg:DI 0 ax)
(call (mem:QI (symbol_ref:DI ("_Z1d1b") [flags 0x41] ) [0 _Z1d1bD.2875 S1 A8])
(const_int 0 [
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119615
--- Comment #4 from Sam James ---
WFM.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119547
--- Comment #13 from Robin Dapp ---
Hmm, now I compiled with -O3 on top of --param logical-op-non-short-circuit=0
(which shouldn't actually be necessary or change anything as it's the default)
but there is a segmentation fault in
_ZN2cv12cpu_b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119615
--- Comment #1 from Sam James ---
(In reply to Sam James from comment #0)
> For the following (gnarly reduction from PR119614):
(Ignore that bit, I changed my mind and used something simpler.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119615
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119596
--- Comment #17 from Uroš Bizjak ---
(In reply to Alexander Monakov from comment #16)
> Mateusz, please have a look at PR 95435 for the previous round of tuning for
> AMD, there's a benchmarking script linked from there in PR 43052.
FYI, this b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119615
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119614
--- Comment #3 from Sam James ---
Created attachment 60980
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60980&action=edit
reduced.ii
Attaching the gnarly thing cvise put out, jakub's is far more useful, but I'm
putting this here as I'm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119615
Bug ID: 119615
Summary: Divergence with Clang on musttail (differing tailcall
target signature)
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: accept
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119547
--- Comment #12 from Robin Dapp ---
> I recompile the opencv application with current gcc(commit b6aafe9a5b), and
> it still reproduce this bug. Do you have apply the patch of step 3 which
> enable vector implement of cvt_64f function?
Yes, I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119613
Andrew Pinski changed:
What|Removed |Added
Attachment #60978|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119613
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119613
--- Comment #3 from Andrew Pinski ---
Created attachment 60978
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60978&action=edit
Reduced testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119573
--- Comment #4 from GCC Commits ---
The trunk branch has been updated by Thomas Schwinge :
https://gcc.gnu.org/g:5deeae29dab2af64e3342daf7a3e424c64ea
commit r15-9190-g5deeae29dab2af64e3342daf7a3e424c64ea
Author: Thomas Schwinge
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119596
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119596
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119612
uecker at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103616
--- Comment #8 from Vladimir Makarov ---
I looked at the generated code and I see only one issue with func foo:
void foo (void)
{
double d = 0.0, e = 7.8;
__asm ("# %0 %1" : : "m" (d), "m" (e));
}
for which GCC generates:
movq
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119387
--- Comment #17 from GCC Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:a926345f22b500a2620adb83e6821e01fb8cc8fd
commit r15-9189-ga926345f22b500a2620adb83e6821e01fb8cc8fd
Author: Patrick Palka
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117983
--- Comment #8 from GCC Commits ---
The releases/gcc-14 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:4366711d2d66ea9a2d4fe9dd112795ef0c6f785c
commit r14-11508-g4366711d2d66ea9a2d4fe9dd112795ef0c6f785c
Author: Jonathan Wak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112934
Jonathan Wakely changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Targ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119533
--- Comment #9 from Vineet Gupta ---
(In reply to Andrew Pinski from comment #3)
> I suspect if you run the testsuite with -fnon-call-exceptions you might find
> a reduced C (or C++) testcae for the same issue.
No joy.
With the toggle forced,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119614
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119614
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119614
--- Comment #1 from Jakub Jelinek ---
Reduced testcase:
volatile int v;
[[gnu::noinline]] const char *
foo (int x)
{
v += x;
return 0;
}
const char *
bar (int x)
{
if (x == 42)
[[gnu::musttail]] return foo (42);
[[gnu::musttail]]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119613
Andrew Pinski changed:
What|Removed |Added
Keywords||tail-call
--- Comment #2 from Andrew Pi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119614
Sam James changed:
What|Removed |Added
Keywords||tail-call
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119613
Sam James changed:
What|Removed |Added
Target Milestone|--- |15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119613
--- Comment #1 from Sam James ---
Created attachment 60976
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60976&action=edit
generated_message_tctable_lite.cc.ii.xz
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119612
Sam James changed:
What|Removed |Added
Keywords||testsuite-fail
CC|
o'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.1 20250403 (experimental)
92ca72b41a74aef53978cadbda33dd38b69d3ed3 (Gentoo Hardened 15.0. p, commit
43e87541519c3e496094d7febd6b772ce0fb33b9)
```
--enable-default-ssp --disable-fixincludes
--with-gxx-libcxx-include-dir=/usr/include/c++/v1
--with-build-config='bootstrap-O3 bootstrap-lto'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 15.0.1 20250403 (experimental)
92ca72b41a74aef53978cadbda33dd38b69d3e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119604
--- Comment #5 from Andrew Pinski ---
(In reply to Richard Biener from comment #4)
> We should get rid of input_location uses in the middle-end instead ;)
Agreed but that is huge task. I will try to get rid of some of them once stage
1 opens up
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119377
--- Comment #4 from Iain Sandoe ---
on Darwin the newly-added tests:
INSPECT_ISO_Example_1, 2, 3, 4, 5-f, 5-r, 6 and 7 fail with the same symptoms.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119611
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119612
Bug ID: 119612
Summary: gcc.dg/pr106465.c newly re-broken
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
As
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119596
--- Comment #15 from Mateusz Guzik ---
so tl;dr
Suggested action: don't use rep for sizes <= 256 with by default
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119596
--- Comment #14 from Mateusz Guzik ---
So I reran the bench on AMD EPYC 9R14 and also experienced a win.
To recap gcc emits rep movsq/stosq for sizes > 40. I'm replacing that with
unrolled loops for sizes up to 256 and punting to actual funcs p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119605
--- Comment #3 from Andrew Pinski ---
(In reply to Richard Biener from comment #2)
> I thought we verify this already ...
We don't. Even Jan thought we verfified this already too, see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117892#c4 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119610
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119607
Sam James changed:
What|Removed |Added
Resolution|--- |MOVED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119610
Andrew Pinski changed:
What|Removed |Added
CC||disservin.social at gmail dot
com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118538
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119414
nightstrike changed:
What|Removed |Added
CC||nightstrike at gmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119607
--- Comment #17 from Jakub Jelinek ---
I don't have cycles to test this nor push upstream, so if you could do that, it
would be great.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119607
--- Comment #16 from Sam James ---
https://gitlab.gnome.org/GNOME/glib/-/issues/1672 references the assertion not
being atomic at least:
> Unsynchronized read of ref_count in g_closure_ref / g_closure_unref from
> assertion.
Looks like gvarian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119607
Sam James changed:
What|Removed |Added
CC||bugzilla at tecnocode dot co.uk
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118892
--- Comment #17 from pavol at rusnak dot io ---
Is the fix going to be backported from master to 14.x release? Possibly
targeting 14.3.0 release?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119607
--- Comment #14 from Jakub Jelinek ---
To me this looks like just not thread safe code in glib2.
The important part of the function is just trying to atomically increment the
closure->ref_count bitfield.
In *.optimized dump this is
[local cou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119414
Iain Sandoe changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |iains at gcc dot gnu.org
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119596
--- Comment #13 from Mateusz Guzik ---
I see there is a significant disconnect here between what I meant with this
problem report and your perspective, so I'm going to be more explicit.
Of course for best performance on a given uarch you would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102294
--- Comment #15 from Andrew Pinski ---
*** Bug 119596 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119596
ak at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|NEW
Resolution|DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119596
--- Comment #11 from ak at gcc dot gnu.org ---
#define m_CORE_AVX512 (m_SKYLAKE_AVX512 | m_CANNONLAKE \
| m_ICELAKE_CLIENT | m_ICELAKE_SERVER | m_CASCADELAKE \
| m_TIGERLAKE | m_COOPERLAKE | m_SAPPHIR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119547
--- Comment #11 from 曾治金 ---
(In reply to Robin Dapp from comment #10)
> > 4. run
> > ```
> > export LD_LIBRARY_PATH=//lib
> > ./opencv_test_core
> > --gtest_filter="Core_ConvertScale/ElemWiseTest.accuracy/0"
> > ```
>
> [==] Runni
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119596
ak at gcc dot gnu.org changed:
What|Removed |Added
CC||ak at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119607
--- Comment #13 from Sam James ---
Manually inlining g_closure_ref into g_closure_invoke means things work.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119607
--- Comment #12 from Jakub Jelinek ---
I don't see any IL differences in that function between r15-7894 and r15-7895
before the ira pass.
There are significant differences in the IRA pass but that is to be expected.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119147
--- Comment #4 from Jan Hubicka ---
Re-benchmarked current trunk -flto -Ofast -march=native (base) and -flto
-Ofast -march=native + PGO (peak) on znver3
Estimated Estimated
Base
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119308
--- Comment #10 from GCC Commits ---
The master branch has been updated by Peter Bergner :
https://gcc.gnu.org/g:c669ab0a866697577fec0c8c2e662640c4be4c94
commit r15-9188-gc669ab0a866697577fec0c8c2e662640c4be4c94
Author: Peter Bergner
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119611
Bug ID: 119611
Summary: Function call substitution cause confusing warning
messages
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119607
--- Comment #10 from Sam James ---
(In reply to Jakub Jelinek from comment #9)
> It seems g_closure_ref is inlined into 3 different functions,
> g_closure_invoke
g_closure_invoke is it
1 - 100 of 179 matches
Mail list logo
