https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106676
Jiang An changed:
What|Removed |Added
CC||de34 at live dot cn
--- Comment #3 from Jian
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100972
Bernhard Reutner-Fischer changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
--- Comment #17 from Jakub Jelinek ---
Fixed for AMD on the library side too.
We need a statement from Zhaoxin and VIA for their CPUs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104688
--- Comment #16 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:4a7a846687e076eae58ad3ea959245b2bf7fdc07
commit r13-4048-g4a7a846687e076eae58ad3ea959245b2bf7fdc07
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107692
--- Comment #2 from Hongyu Wang ---
Created attachment 53897
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53897&action=edit
A patch
Sorry for introducing these fails. Here is the patch.
I've tested the patch with cross-compler and all
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105180
--- Comment #6 from Andrew Pinski ---
Here is a self contained tester:
int global = 0;
int func(void)
{
global++;
return global;
}
void crime(s, c)
char *s;
char c[static func()];
{
}
int main(void)
{
crime("1", "1");
if (gl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105180
--- Comment #5 from Andrew Pinski ---
(In reply to Andrew Pinski from comment #4)
> I am suspecting r0-108564-ga04a722b88baf5 .
That is https://gcc.gnu.org/legacy-ml/gcc-patches/2011-05/msg00319.html .
I suspect there was a missing old style p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105180
--- Comment #4 from Andrew Pinski ---
I am suspecting r0-108564-ga04a722b88baf5 .
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105158
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65699
Andrew Pinski changed:
What|Removed |Added
Target Milestone|13.0|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63873
--- Comment #5 from Andrew Pinski ---
>Can we move into the 21st century already?
We tried this year but sphinx needs to improved to cover the same feature set
as texinfo too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65699
Andrew Pinski changed:
What|Removed |Added
Status|RESOLVED|NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88472
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
See Also|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98167
--- Comment #21 from CVS Commits ---
The master branch has been updated by Hongyu Wang :
https://gcc.gnu.org/g:dc95e1e9702f2f6367bbc108c8d01169be1b66d2
commit r13-4044-gdc95e1e9702f2f6367bbc108c8d01169be1b66d2
Author: Hongyu Wang
Date: Mon J
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107692
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107693
Bug ID: 107693
Summary: undefined reference to
`_ZSt8to_charsPcS_DF128_St12chars_formati' std::format
does not work on x86_64-w64-mingw32
Product: gcc
Version: 1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107676
--- Comment #6 from Hongyu Wang ---
(In reply to Andrew Pinski from comment #5)
> (In reply to Jonathan Wakely from comment #4)
> > I don't think __atomic_compare_exchange emits such a loop. This is about
> > __atomic_fetch_xor and friends, whic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107638
--- Comment #4 from CVS Commits ---
The master branch has been updated by Patrick Palka :
https://gcc.gnu.org/g:fce38b7d13ae625301571dcd84f3774ddaa6ed04
commit r13-4039-gfce38b7d13ae625301571dcd84f3774ddaa6ed04
Author: Patrick Palka
Date: M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107660
--- Comment #6 from Jonathan Wakely ---
It's expected and required by the standard that std::mt19937 produces the same
numbers every time. And if I run a test for GCC 10 and GCC 11 I see the same
number produced for the first 2.14 billion result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107671
--- Comment #3 from Hongtao.liu ---
We already have
--cut from i386.md
15204;; Help combine recognize bt followed by setc
15205(define_insn_and_split "*bt_setcqi"
15206 [(set (subreg:SWI48 (match_operand:QI 0 "register_operand")
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107326
--- Comment #6 from Arseny Solokha ---
Yes, this one is fixed. Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107692
--- Comment #1 from Andrew Pinski ---
Some of these testcases might need -mno-unroll-only-small-loops now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107680
--- Comment #2 from anlauf at gcc dot gnu.org ---
We could prohibit the simplification of ** like in the following:
diff --git a/gcc/fortran/arith.cc b/gcc/fortran/arith.cc
index fc9224ebc5c..540b8e2b945 100644
--- a/gcc/fortran/arith.cc
+++ b/g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107692
Bug ID: 107692
Summary: [13 regression] r13-3950-g071e428c24ee8c breaks many
test cases
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107691
--- Comment #4 from rep.dot.nop at gmail dot com
---
The problem was encountered with configure --enable-valgrind-annotations with
valgrind not installed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107691
--- Comment #3 from Andrew Pinski ---
have_valgrind_h is never set anywhere.
Adding before that code in configure.ac:
dnl # This check AC_REQUIREs various stuff, so it *must not* be inside
dnl # an if statement. This was the source of very frus
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107576
--- Comment #8 from anlauf at gcc dot gnu.org ---
(In reply to G. Steinmetz from comment #7)
> $ gfortran -c z3.f90
> z3.f90:2:10:
>
> 2 |call s(null())
> | 1
> Error: MOLD argument to NULL required at (1)
I think that er
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107691
Andreas Schwab changed:
What|Removed |Added
Summary|[10/11/12/13 Regression]|[10/11/12/13 Regression]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107691
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107576
--- Comment #7 from G. Steinmetz ---
Yes, call s(z) is valid in z1, but is necessary to trigger
the ICE somehow with -std=legacy and null().
Yes, 15.4.2.2(3) was it, explicit interface of the callee with
all the characteristics of that procedu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107691
Bug ID: 107691
Summary: libcpp configure fails on bashism
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107681
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|--- |13.0
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107690
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |12.3
Summary|Regression in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96054
--- Comment #2 from H. Peter Anvin ---
I agree, my naming was very poor.
Perhaps "panic" or "abort" would work; those are classic names in software use
for this.
Another case of a function that could be so attributed would be the function
typica
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107690
--- Comment #1 from Andrew Pinski ---
-std=c++20 -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107690
Bug ID: 107690
Summary: Regression in ranges::transform vectorization
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107683
Marek Polacek changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107485
--- Comment #10 from Sebastian Pop ---
Thanks Richard.
The patch fixed the larger test as well.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107689
Andrew Pinski changed:
What|Removed |Added
Keywords||testsuite-fail
Component|fortr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107689
Bug ID: 107689
Summary: [13 regression] r13-3979-g9d29dd2fcf2922 causes
failures in diagnostic-format-json-2.c and others
Product: gcc
Version: 13.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107677
--- Comment #2 from Carlos Galvez ---
This is a general question which I hope can be answered without a full report.
My particular example gets a warning deep into Eigen-like code so it's not easy
to provide a minimal example.
My questions are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107686
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107688
Marek Polacek changed:
What|Removed |Added
Blocks||98940
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107688
Bug ID: 107688
Summary: [C++23] P2615 - Meaningful exports
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107686
--- Comment #2 from Andrew Pinski ---
vector(4) long intD.8 _10;
_10 = [vec_unpack_lo_expr] u.0_2;
_11 = [vec_unpack_hi_expr] u.0_2;
# VUSE <.MEM_8(D)>
d.1_4 = dD.3174;
_12 = BIT_FIELD_REF <_10, 64, 0>;
_1 = BIT_FIELD_REF ;
_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107687
Bug ID: 107687
Summary: [C++23] P2564 - consteval needs to propagate up
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Componen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107687
Marek Polacek changed:
What|Removed |Added
Blocks||98940
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103295
--- Comment #22 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:a088d93c210f9b662d706e2fcf63a59d05fe27c1
commit r12-8908-ga088d93c210f9b662d706e2fcf63a59d05fe27c1
Author: Nathaniel Sh
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95048
--- Comment #22 from CVS Commits ---
The releases/gcc-12 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:c6bd8fac5e3bc6003f889fbd6042c0d8aa9c40ed
commit r12-8909-gc6bd8fac5e3bc6003f889fbd6042c0d8aa9c40ed
Author: Jonathan Wake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107686
--- Comment #1 from Zdenek Sojka ---
Created attachment 53896
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53896&action=edit
reduced testcase
sr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r13-4023-20221114155950-g2b85d759dae-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20221114 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107685
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107685
Bug ID: 107685
Summary: [C++23] P2647 - Permitting static constexpr variables
in constexpr functions
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107684
--- Comment #1 from Marek Polacek ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605705.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107680
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107684
Marek Polacek changed:
What|Removed |Added
Last reconfirmed||2022-11-14
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107684
Bug ID: 107684
Summary: [C++23] P2589 - static operator[]
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107679
--- Comment #2 from anlauf at gcc dot gnu.org ---
Interesting. Adding a line
print *, z
after the call
call s1(z)
make the ICE go away.
Is it the CLOBBER that confuses us?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107485
Richard Biener changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107485
--- Comment #8 from CVS Commits ---
The releases/gcc-10 branch has been updated by Richard Biener
:
https://gcc.gnu.org/g:c17873d83aaeed037fb5d039df2e6303d4b6a553
commit r10-11083-gc17873d83aaeed037fb5d039df2e6303d4b6a553
Author: Richard Biene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107679
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107576
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107637
Marek Polacek changed:
What|Removed |Added
CC||mpolacek at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107675
Andrew Pinski changed:
What|Removed |Added
Status|NEW |UNCONFIRMED
Ever confirmed|1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107675
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |13.0
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107637
Jakub Jelinek changed:
What|Removed |Added
Summary|C++23: Implement P2644R1 - |C++23: Implement P2718R0 -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107678
--- Comment #4 from Andrew Pinski ---
Note aarch64_fallback_frame_state segfault is
if (pc[0] != MOVZ_X8_8B || pc[1] != SVC_0)
pc comes from:
unsigned *pc = context->ra;
>so the size of the vectors could be a hint?
It is not in this cas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107678
--- Comment #3 from Jakub Jelinek ---
I mean register sizes. So bet those compute as 0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107678
--- Comment #2 from Jakub Jelinek ---
Perhaps some previously latent buffer overflow?
I'm aware of e.g. __builtin_init_dwarf_reg_size_table theoretical problem with
SVE, the builtin computes register sizes in 8-bit unsigned integers, but SVE
can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107677
Marek Polacek changed:
What|Removed |Added
Component|c++ |middle-end
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107678
--- Comment #1 from Andrew Pinski ---
Hmm, maybe the outputted dwarf2 from the compiler is broken. Because this is a
call to throw itself.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107597
--- Comment #3 from Christoph Steefel ---
Address sanitizer is the one that flags it.
This is the code I used to reproduce the failure.
test.h:
class NonTemplated {
static inline int x;
public:
void doFoo() {
x++;
}
};
int fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107682
--- Comment #2 from Marek Polacek ---
I suppose pop_init_level needs to check that constructor_type isn't
FUNCTION_TYPE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107682
Marek Polacek changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107683
Bug ID: 107683
Summary: [13 Regression] ICE in int_fits_type_p, at
tree.cc:8044
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107682
Bug ID: 107682
Summary: [13 Regression] ICE in c_parser_braced_init, at
c/c-parser.cc:5619
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107576
--- Comment #5 from G. Steinmetz ---
I had in mind Fortran 2018, 15.4.2.2 Explicit interface,
and therefore had added the examples z1c.f90 and z2c.f90.
Some other compilers (via Compiler Explorer) show an error
for both z1.f90 and z2.f90 :
l
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107681
Bug ID: 107681
Summary: [13 Regression] ICE in gfc_type_is_extensible, at
fortran/resolve.cc:9018
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: norm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107676
--- Comment #5 from Andrew Pinski ---
(In reply to Jonathan Wakely from comment #4)
> I don't think __atomic_compare_exchange emits such a loop. This is about
> __atomic_fetch_xor and friends, which do emit cmpxchg loops. But there are
> four su
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107680
Bug ID: 107680
Summary: ICE in arith_power, at fortran/arith.cc:989 and :1006
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107679
Bug ID: 107679
Summary: [13 Regression] ICE in maybe_register_def, at
tree-into-ssa.cc:1914
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107676
--- Comment #4 from Jonathan Wakely ---
I don't think __atomic_compare_exchange emits such a loop. This is about
__atomic_fetch_xor and friends, which do emit cmpxchg loops. But there are four
such functions to name.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107676
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2022-11-14
Status|UNCONFIRM
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107678
Bug ID: 107678
Summary: [13 Regression] Segfault in
aarch64_fallback_frame_state
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Prio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107326
--- Comment #5 from avieira at gcc dot gnu.org ---
It looks that way on my end, but I'll let Arseny confirm.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107485
--- Comment #7 from Richard Biener ---
Note that while this might be part of the solution we then still "wreck" EH
anyway by throwing it away instead of trying to replicate it for each component
compare.
So I'm not sure the proposed change is a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107668
Jakub Jelinek changed:
What|Removed |Added
Last reconfirmed||2022-11-14
Assignee|unassigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107675
--- Comment #4 from Tamar Christina ---
(In reply to Jakub Jelinek from comment #2)
> Does the binary and libstdc++.so have PT_GNU_EH_FRAME header including
> binary search table (readelf -Wl | grep GNU_EH_FRAME)?
> During startup I think there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107639
--- Comment #3 from Andrew Macleod ---
(In reply to Richard Biener from comment #2)
> Confirmed. Something for ranger/VRP "symbolic" handling.
I'm not so sure. what is related? there are 2 loop values being bumped by
different amounts. the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107669
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107677
Bug ID: 107677
Summary: -Warray-bounds: unclear what exactly it's meant to
detect
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107663
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107669
Jakub Jelinek changed:
What|Removed |Added
Summary|[13 Regression] commit |[13 Regression] commit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107669
Richard Biener changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107668
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107676
--- Comment #2 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #0)
> 3) What does "atomic logic fetch builtins" mean?
>From the commit msg, it seems this means atomic_fetch_{or,xor,and,nand}.
But out of context in the GCC man
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107672
Richard Biener changed:
What|Removed |Added
Keywords||ice-on-valid-code
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107674
Richard Biener changed:
What|Removed |Added
Keywords||missed-optimization
Target Milestone
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107676
--- Comment #1 from Jonathan Wakely ---
Is it really better to do a load and check rather than just hoist the first
cmpxchg out of the loop, and add the pause in the loop if retrying?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107661
Richard Biener changed:
What|Removed |Added
Priority|P3 |P1
1 - 100 of 150 matches
Mail list logo
