https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119600
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119605
--- Comment #2 from Richard Biener ---
I thought we verify this already ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119606
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |15.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119606
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119607
Bug ID: 119607
Summary: [15 regression] glib miscompiled since
r15-7895-gb191e8bdecf881
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Keywords: needs-source,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119607
--- Comment #1 from Sam James ---
Needs -O3 -m32 -march=x86-64 -mtune=znver2 -fno-semantic-interposition. I
suspect the -O3/-fno-semantic-interposition is just because of inlining.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119606
Bug ID: 119606
Summary: [15 regression] Commit 'Optimize string constructor'
causes regression in Snappy workload for
-mcpu=neoverse-v2 with LTO
Product: gcc
Ver
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119606
--- Comment #2 from Andrew Pinski ---
Is it really using std::string here?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119606
Andrew Pinski changed:
What|Removed |Added
Target Milestone|15.0|---
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119607
--- Comment #2 from Sam James ---
```
not ok /gobject/refcount/properties-1 - GLib-GObject-FATAL-CRITICAL:
g_closure_ref: assertion 'closure->ref_count > 0' failed
Bail out!
Thread 5 "properties-refc" received signal SIGTRAP, Trace/breakpoint t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119604
--- Comment #4 from Richard Biener ---
We should get rid of input_location uses in the middle-end instead ;)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119607
--- Comment #5 from Sam James ---
noipa on g_closure_ref is enough to fix it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119593
Tomasz Kamiński changed:
What|Removed |Added
Summary|Format width is not |Format width is not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119593
--- Comment #3 from Tomasz Kamiński ---
Two separate problems compound in this case:
* UTF-32LE, UTF-32BE used for wchar_t, are not recognized as unicode encoding
* character with is always assumed to be 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119594
--- Comment #6 from Jakub Jelinek ---
First of all, REG_UNUSED/REG_DEAD notes are only officially meaningful in
passes which df_add_note_problem before df_analyze, which is cse1 and regcprop
but not fwprop.
But I actually don't see anything inco
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119607
--- Comment #3 from Sam James ---
Created attachment 60971
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=60971&action=edit
gclosure.c.i.xz
gclosure.o seems to be the victim.
It's built with:
```
x86_64-pc-linux-gnu-gcc -m32 -Igobject/li
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119607
Sam James changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119608
Bug ID: 119608
Summary: ICE compiling module interface including boost.json in
GMF and exporting one entity
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Seve
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119594
--- Comment #5 from Jakub Jelinek ---
Note, with the PR115910 patch this is latent again, the difference is one extra
(expr_list:REG_EQUAL (const_int 4294967295 [0x])
note.
(insn 28 27 29 (set (reg:DI 105)
(const_int 4294967295 [
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113281
--- Comment #38 from GCC Commits ---
The master branch has been updated by Alexandre Oliva :
https://gcc.gnu.org/g:6f72af0c2e389e9252b6994643155e51ef68821b
commit r15-9169-g6f72af0c2e389e9252b6994643155e51ef68821b
Author: Alexandre Oliva
Date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119606
Andrew Pinski changed:
What|Removed |Added
Component|tree-optimization |libstdc++
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119597
--- Comment #3 from Richard Biener ---
Possibly issues of the manual layout of cobol FE <-> libgcobol interoperability
structs?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119606
--- Comment #3 from Andrew Pinski ---
Is this benchmarking the whole benchmark program running or a function of the
benchmark? If the former I am not sure this benchmark is a good one ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119482
--- Comment #15 from Richard Biener ---
(In reply to ak from comment #13)
> This patch gives another 23% speedup due to reducing time handling the
> linked lists for lazy bitmaps. Probably there is more tuning potential in
> bitmaps
> (most of t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119607
Sam James changed:
What|Removed |Added
Summary|[15 regression] glib|[15 regression] glib
|mis
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119593
--- Comment #2 from Tomasz Kamiński ---
The problem is not limited to wide characters, and also appears for wide
strings:
std::format(L"{:+<3}", L"\U0001f921"); // two '+' of paddings
// https://godbolt.org/z/o4s7qTEz9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119607
--- Comment #6 from Richard Biener ---
Does -fno-ipa-ra fix it? The bisection is odd if fwprop1 already differs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119594
--- Comment #7 from Jakub Jelinek ---
The steps are in particular that the fwprop pass proper optimizes
(insn 26 24 27 7 (set (reg:DI 104 [ g ])
(zero_extend:DI (subreg:SI (reg/v:DI 101 [ g ]) 0))) "pr119594.c":11:8
175 {*zero_extendsidi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119607
--- Comment #7 from Sam James ---
It doesn't, but neither does -fdisable-rtl-fwprop{1,2}, so let me check again.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119564
--- Comment #11 from Cameron Angus ---
Okay, updated attachments reproduce bug on gcc version 15.0.1 20250330, from a
few days ago. The change added a bit more to the GMF, and also required
exporting something. Very slightly different output, bu
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=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 #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=119616
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
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=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=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=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=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=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=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=119610
Alex Coplan changed:
What|Removed |Added
Summary|aarch64: Wrong unwind info |aarch64: Wrong unwind info
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=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=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=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=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=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
--- 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=119607
Sam James changed:
What|Removed |Added
CC||bugzilla at tecnocode dot co.uk
--- Comment
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=118538
Andrew Pinski changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
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=119607
Sam James changed:
What|Removed |Added
Resolution|--- |MOVED
Status|UNCONFIRMED
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
--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
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)
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119612
Sam James changed:
What|Removed |Added
Keywords||testsuite-fail
CC|
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=119610
Sam James changed:
What|Removed |Added
Target Milestone|--- |12.5
Summary|aarch64: Wrong unwi
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=119308
Peter Bergner changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=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=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=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=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=119596
Andrew Pinski changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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
--- 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=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=119611
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
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=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=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=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=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=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=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=119613
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
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=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=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 #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
--- Comment #4 from Sam James ---
WFM.
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=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=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=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=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=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
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
1 - 100 of 179 matches
Mail list logo
