https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104928
--- Comment #2 from Nate Eldredge ---
This bug is still present. Tested and reproduced with g++ 13.1.0 (Ubuntu
package), and by inspection of the source code, it's still in the trunk as
well.
Encountered on StackOverflow:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112936
--- Comment #2 from Xi Ruoyao ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640012.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112936
Xi Ruoyao changed:
What|Removed |Added
Keywords||patch
URL|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111867
--- Comment #8 from Andrew Pinski ---
Created attachment 56842
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56842=edit
Patch which I will be submitting soon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111876
Andrew Pinski changed:
What|Removed |Added
Component|target |middle-end
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112942
--- Comment #4 from Andrew Pinski ---
(In reply to Artem Koton from comment #3)
> (In reply to Andrew Pinski from comment #1)
> > https://wg21.cmeerw.net/lwg/issue2749
>
> Could you elaborate? I understand that this issue discusses the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112942
--- Comment #3 from Artem Koton ---
(In reply to Andrew Pinski from comment #1)
> https://wg21.cmeerw.net/lwg/issue2749
Could you elaborate? I understand that this issue discusses the constraints in
question but a failure to meet them should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112942
--- Comment #2 from Andrew Pinski ---
https://gcc.gnu.org/pipermail/libstdc++/2016-November/045176.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112942
--- Comment #1 from Andrew Pinski ---
https://wg21.cmeerw.net/lwg/issue2749
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112942
Bug ID: 112942
Summary: swap(variant&, variant&) is incorrectly marked as
deleted
Product: gcc
Version: 13.2.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111867
Andrew Pinski changed:
What|Removed |Added
Keywords||testsuite-fail
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112941
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112940
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112758
--- Comment #11 from Eric Botcazou ---
> It says those upper bits are well-defined, i.e. whatever MD pattern is used
> for it eventually will emit machine code that has the exact same result for
> those upper bits.
No, that's not true, the set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109162
Bug 109162 depends on bug 111826, which changed state.
Bug 111826 Summary: __cpp_lib_format should be 202110, not 202106
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111826
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111826
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111826
--- Comment #2 from GCC Commits ---
The releases/gcc-13 branch has been updated by Jonathan Wakely
:
https://gcc.gnu.org/g:9f5011f9e6e347e0b91f47a118a0ce58a2c2d99a
commit r13-8140-g9f5011f9e6e347e0b91f47a118a0ce58a2c2d99a
Author: Jonathan
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112935
--- Comment #19 from Andrew Pinski ---
This patch gets us back to using `&-` rather than shifts/adds for x86_64:
```
diff --git a/gcc/expr.cc b/gcc/expr.cc
index 6da51f2aca2..4686cacd22f 100644
--- a/gcc/expr.cc
+++ b/gcc/expr.cc
@@ -10209,8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112887
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112887
--- Comment #4 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:c250ff90989a71dff11e9256e99d2fa965ab1295
commit r14-6360-gc250ff90989a71dff11e9256e99d2fa965ab1295
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112877
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112938
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112939
Andrew Pinski changed:
What|Removed |Added
Ever confirmed|0 |1
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112758
--- Comment #10 from Segher Boessenkool ---
(In reply to Jakub Jelinek from comment #6)
> I must say I have no idea what WORD_REGISTER_OPERATION says about the upper
> bits of a paradoxical SUBREG if it is a MEM and load_extend_op (inner_mode)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112876
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112876
Jonathan Wakely changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112786
Hans-Peter Nilsson changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96831
Bug 96831 depends on bug 112786, which changed state.
Bug 112786 Summary: [14 Regression] gcc.dg/tree-ssa/scev-3.c scev-4.c and
scev-5.c XPASSing on most ilp32 targets
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112786
What
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112919
--- Comment #2 from Xi Ruoyao ---
On LA464:
13095 with GCC 13.2.0
The best I've got is:
12639 with GCC 14.0.0 + -falign-loops=8 -falign-labels=4 -falign-jumps=4
-falign-functions=16
and I cannot really explain why this is the best.
With
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112930
Richard Sandiford changed:
What|Removed |Added
Last reconfirmed||2023-12-09
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112931
Richard Sandiford changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rsandifo at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112933
Richard Sandiford changed:
What|Removed |Added
Last reconfirmed||2023-12-09
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112827
Jakub Jelinek changed:
What|Removed |Added
CC||csfore at posteo dot net
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112924
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112924
--- Comment #4 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:af8bbd631f5425e9be084dfd1f2b9487a31a350e
commit r14-6359-gaf8bbd631f5425e9be084dfd1f2b9487a31a350e
Author: Jakub Jelinek
Date:
rap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231209 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112924
Jakub Jelinek changed:
What|Removed |Added
Keywords|needs-bisection |
CC|
4-6356-20231209102837-g36be2a0e91c-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231209 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112929
--- Comment #10 from JuzheZhong ---
OK. It seems it is VSETVL BUG. I will have look at it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111826
--- Comment #1 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:cdf45e00a936a76a785c592c9730f24ef1ac25cd
commit r14-6358-gcdf45e00a936a76a785c592c9730f24ef1ac25cd
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112876
--- Comment #5 from GCC Commits ---
The master branch has been updated by Jonathan Wakely :
https://gcc.gnu.org/g:a314edee2490259d7f7caec8eef77846bcdb608b
commit r14-6357-ga314edee2490259d7f7caec8eef77846bcdb608b
Author: Jonathan Wakely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112929
--- Comment #9 from Robin Dapp ---
In the good version the length is 32 here because directly before the vsetvl we
have:
li a4,32
That seems to get lost somehow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112929
--- Comment #8 from JuzheZhong ---
Li Pan will investigate it. He will note me if there is a bug in vsetvl pass.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98723
Luca Bacci changed:
What|Removed |Added
CC||luca.bacci at outlook dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112929
--- Comment #7 from Robin Dapp ---
Here
0x105c6 vse8.v v8,(a5)
is where we overwrite m. The vl is 128 but the preceding vsetvl gets a4 =
46912504507016 as AVL which seems already borken.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112929
--- Comment #6 from Robin Dapp ---
This seems to be gone when simple vsetvl (instead of lazy) is used or with
-fno-schedule-insns which might indicate a vsetvl pass problem.
We might have a few more of those. Maybe it would make sense to run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112264
Thomas Schwinge changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110987
--- Comment #3 from Kirill Chilikin ---
The derived type T3 has zero components but not zero length as it extends T1;
the test does not crash after the following changes:
diff --git a/gcc/fortran/trans.cc b/gcc/fortran/trans.cc
index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112939
Bug ID: 112939
Summary: ICE: verify_ssa failed with -O
-ftrivial-auto-var-init=zero
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112938
David Binderman changed:
What|Removed |Added
CC||aoliva at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112938
Bug ID: 112938
Summary: ice with -fstrub=internal
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112937
Bug ID: 112937
Summary: [14 Regression] GCN: FAILs due to unconditional
'f->use_flat_addressing = true;'
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112758
--- Comment #9 from Eric Botcazou ---
> Which means punt on this optimization for WORD_REGISTER_OPERATIONS if the
> outer mode is word_mode, except when sub is a MEM and load_extend_op
> (inner_mode) == ZERO_EXTEND?
Yes, this sounds like a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109267
Iain Sandoe changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93019
--- Comment #7 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:36be2a0e91c76da4afcd5ddc37e03f5800396387
commit r14-6356-g36be2a0e91c76da4afcd5ddc37e03f5800396387
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26
Xi Ruoyao changed:
What|Removed |Added
Target|riscv* (with zicond)|riscv* (with zicond),
|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112935
Andrew Pinski changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112935
Andrew Pinski changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112935
--- Comment #16 from Xi Ruoyao ---
BTW is it possible to get the value range info of (x) and combine (and y, (neg
x)) back to maskeqz in LoongArch backend? It will further improve the
performance. Or maybe expr.cc should invoke a target hook
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112936
Xi Ruoyao changed:
What|Removed |Added
Last reconfirmed||2023-12-09
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112935
--- Comment #15 from Andrew Pinski ---
I see what is happening and kinda of see why it is not there ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112935
--- Comment #14 from Xi Ruoyao ---
LoongArch cost model issue is now PR112936.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112936
Bug ID: 112936
Summary: LoongArch: Wrong instruction costs
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112758
--- Comment #8 from Jakub Jelinek ---
(In reply to Eric Botcazou from comment #7)
> > I must say I have no idea what WORD_REGISTER_OPERATION says about the upper
> > bits of a paradoxical SUBREG if it is a MEM and load_extend_op (inner_mode)
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112935
Andrew Pinski changed:
What|Removed |Added
Target||loongarch64-*-*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112935
Xi Ruoyao changed:
What|Removed |Added
Component|target |tree-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112935
--- Comment #11 from Xi Ruoyao ---
> and tree_nonzero_bits fails to _21 is either 0 or 1, for some reason.
^ report
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112935
--- Comment #10 from Xi Ruoyao ---
For the original test case we get:
x16_27 = _26 & 1;
data_28 = data_15 >> 1;
_29 = crc_18 >> 1;
_21 = (short unsigned int) x16_27;
_13 = _21 * 40961;
and tree_nonzero_bits fails to _21 is either 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112758
--- Comment #7 from Eric Botcazou ---
> I must say I have no idea what WORD_REGISTER_OPERATION says about the upper
> bits of a paradoxical SUBREG if it is a MEM and load_extend_op (inner_mode)
> is ZERO_EXTEND (zeros then?
Yes.
> Then this
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112932
--- Comment #1 from GCC Commits ---
The master branch has been updated by Pan Li :
https://gcc.gnu.org/g:9363d91956931bb28735bed97035b9ec965c850f
commit r14-6354-g9363d91956931bb28735bed97035b9ec965c850f
Author: Juzhe-Zhong
Date: Sat Dec 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112934
Jonathan Wakely changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
71 matches
Mail list logo
