https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114430
Bug ID: 114430
Summary: False positive for -Wformat
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assign
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114426
--- Comment #4 from Andrew Pinski ---
(In reply to Sam James from comment #2)
> Any idea why this only happened on arm btw?
because arm is the only target that returns true for
`targetm.cxx.cdtor_returns_this()`.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
Richard Biener changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
--- Comment #16 from Richard Biener ---
Created attachment 57766
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57766&action=edit
patch
Oddly enough the following patch doesn't fix it but it correctly prevents us
from recording the access
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114194
Christoph Müllner changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
--- Comment #33 from Ajit Kumar Agarwal ---
Sent the patch for review.
Here is the patch:
PATCH] rs6000: Stackoverflow in optimized code on PPC (PR100799)
When using FlexiBLAS with OpenBLAS we noticed corruption of
the parameters passed to Ope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100799
--- Comment #34 from Ajit Kumar Agarwal ---
Sent the patch for review.
Here is the patch:
PATCH] rs6000: Stackoverflow in optimized code on PPC (PR100799)
When using FlexiBLAS with OpenBLAS we noticed corruption of
the parameters passed to Ope
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
--- Comment #17 from Jakub Jelinek ---
Created attachment 57767
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57767&action=edit
gcc14-pr111683.patch
Patch I've tested overnight for this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
--- Comment #18 from Jakub Jelinek ---
Using wi::multiple_of_p is what I've tried first but that regressed the
generated code for pr71083.c (the test still PASSed, but predcom no longer
triggered on it).
I think it has access size 3 and step 4,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104282
--- Comment #8 from Fedor Chelnokov ---
One more inconsistency here:
struct A {
A() {}
A(A&&) = delete;
};
struct B : A { };
int main() {
// ok in GCC
B{ A{} };
// error in GCC
B b{ A{} };
}
GCC allows temporary creatio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114426
--- Comment #5 from Sam James ---
Reduced:
```
struct Object {
virtual ~Object();
};
struct Configurator : virtual Object {
virtual void doConfigure() = 0;
};
struct DOMConfigurator : Configurator {
DOMConfigurator() {}
};
```
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114065
--- Comment #4 from Eric Botcazou ---
> is that the correct approach? most likely has to be guarded with a configure
> option.
The conditional setting is very likely superfluous, i.e. you can use the POSIX
2008 version whatever the multilib on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
--- Comment #19 from Richard Biener ---
But note that {0, +, 3 } and {2, + , 3} with size 2 will still eventually
overlap. See dr_analyze_indices where we attempt to make DR_INIT a
multiple of the element size (probably also not a perfect solut
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
Richard Biener changed:
What|Removed |Added
Known to fail||14.0
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
--- Comment #20 from Jakub Jelinek ---
That is true. I've been also wondering whether e.g. for the pr71083.c case we
couldn't just look through all COMPONENT_REFs of the DR_REF (and maybe
ARRAY_REFs with constant indexes) and check type size of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114405
--- Comment #3 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:982250b230967776f0da708a1572b78a38561e08
commit r14-9609-g982250b230967776f0da708a1572b78a38561e08
Author: Jakub Jelinek
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111736
--- Comment #25 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:ddd4a3ca87410886b039cc225907b4f6e650082e
commit r14-9610-gddd4a3ca87410886b039cc225907b4f6e650082e
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114405
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114150
--- Comment #1 from GCC Commits ---
The master branch has been updated by Rainer Orth :
https://gcc.gnu.org/g:3d406af2008a19914305966dddbc02ae980b8cd7
commit r14-9611-g3d406af2008a19914305966dddbc02ae980b8cd7
Author: Rainer Orth
Date: Fri M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114150
Rainer Orth changed:
What|Removed |Added
URL||https://gcc.gnu.org/piperma
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96147
--- Comment #13 from GCC Commits ---
The master branch has been updated by Rainer Orth :
https://gcc.gnu.org/g:644a7033cc09b79a5cfefe1fe9b307d835009b17
commit r14-9612-g644a7033cc09b79a5cfefe1fe9b307d835009b17
Author: Rainer Orth
Date: Fri M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96147
Rainer Orth changed:
What|Removed |Added
Resolution|--- |FIXED
Status|REOPENED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109619
--- Comment #5 from GCC Commits ---
The trunk branch has been updated by Andrew Pinski :
https://gcc.gnu.org/g:dbe9062ce070c861cd3fa6435187618413b1b3d1
commit r14-9613-gdbe9062ce070c861cd3fa6435187618413b1b3d1
Author: Andrew Pinski
Date: Th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109619
Andrew Pinski changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112724
--- Comment #3 from GCC Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:ca27c3b3a09fa051c0112769ba680e43b197aa97
commit r14-9614-gca27c3b3a09fa051c0112769ba680e43b197aa97
Author: Jakub Jelinek
Date: F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #43 from Richard Biener ---
The interesting bit is that there are only 12026 overall loglinks, the
number of combine attempts is way higher than that would suggest also
given the few successful combinations. So something is odd here
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #44 from Sam James ---
I'm really curious as to if there's other test cases which could be shared, as
Andreas mentioned distributions were complaining about this even. That's
unlikely if it's a single degenerate case.
Even listing s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #45 from Sam James ---
(ah, not andreas, but sarah)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #6 from Sam James ---
Modifying llvm/include/llvm/ADT/iterator.h like so helps (!):
```
#pragma GCC push_options
#pragma GCC optimize ("O0")
friend bool operator==(const iterator_adaptor_base &LHS,
const it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #7 from Sam James ---
I'll go back to trying to see which specific loop it is.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #46 from Richard Biener ---
Maybe combine already knows that it just "keeps i2" rather than replacing it?
When !newi2pat we seem to delete i2. Anyway, somebody more familiar with
combine should produce a good(TM) patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114431
Bug ID: 114431
Summary: bpf: GCC generates unverifiable code for systemd
restrict_fs_bpf
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
--- Comment #21 from Jakub Jelinek ---
Created attachment 57768
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57768&action=edit
gcc14-pr111683.patch
Updated patch which uses wi::multiple_of_p but doesn't regress pr71083.c.
To be precise,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
Jakub Jelinek changed:
What|Removed |Added
Attachment #57768|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59429
--- Comment #16 from Mathias Stearn ---
Trunk still generates different code for all cases (in some cases subtly so)
for both aarch64 and x86_64: https://www.godbolt.org/z/1s6sxrMWq. For both
arches, it seems like LE and LG generate the best code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #8 from Sam James ---
Created attachment 57770
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57770&action=edit
EarlyCSE.cpp.cpp.179t.vect.diff
(In reply to Sam James from comment #7)
> I'll go back to trying to see which spec
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #9 from Richard Biener ---
Nothing obviously suspicious here ... I wonder if you can attach
177t.ch_vect, 178t.ifcvt and 179t.vect for the case with the single vectorized
bad loop?
Maybe we're running into a latent issue downstream?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
--- Comment #23 from Richard Biener ---
It looks like this could go to suitable_reference_p instead?
That said, I do wonder why with my patch split_data_refs_to_components
doesn't fixup. I think it's supposed to handle the case where
dependenc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114425
--- Comment #1 from Zdenek Sojka ---
Created attachment 57771
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57771&action=edit
another testcase, using __builtin_mul_overflow_p
Output for second testcase:
$ x86_64-pc-linux-gnu-gcc -O2 test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
--- Comment #24 from Jakub Jelinek ---
(In reply to Richard Biener from comment #23)
> It looks like this could go to suitable_reference_p instead?
You mean return false for those making them not suitable at all?
I thought without a write such
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114425
--- Comment #2 from Jakub Jelinek ---
Strangely it is dependent on the printf loop, without that it works fine.
Slightly adjusted testcase:
#if __BITINT_MAXWIDTH__ >= 2000
_BitInt(8) a;
_BitInt(300) b;
_BitInt(2000) c;
unsigned
foo (_BitInt(2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114425
--- Comment #3 from Zdenek Sojka ---
Created attachment 57772
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57772&action=edit
unreduced testcase ; output differs between -O0 and -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114425
--- Comment #4 from Zdenek Sojka ---
Created attachment 57773
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57773&action=edit
another unreduced testcase ; output differs between -O0 and -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111781
--- Comment #10 from GCC Commits ---
The master branch has been updated by Mikael Morin :
https://gcc.gnu.org/g:44c0398e65347def316700911a51ca8b4ec0a411
commit r14-9618-g44c0398e65347def316700911a51ca8b4ec0a411
Author: Mikael Morin
Date: Fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #47 from Richard Biener ---
The rtx_equal_p change gets us 50% improvement only, it's necessary to also
disable the added_{links,notes}_insn extra re-processing to get us all the
way to -O1 speed. We'd need the worklist to avoid com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114414
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114412
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P2
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114411
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P2
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114408
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114426
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #48 from Richard Biener ---
So another "simple" way is to keep the redundant insn walking ("it's O(1)") but
remember processsed insns and only re-process those we mark as such.
There might be a free "visited" bit on rtx_insn, who kn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
--- Comment #25 from rguenther at suse dot de ---
On Fri, 22 Mar 2024, jakub at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111683
>
> --- Comment #24 from Jakub Jelinek ---
> (In reply to Richard Biener from comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112697
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
Bug 26163 depends on bug 112697, which changed state.
Bug 112697 Summary: [14 Regression] 30-40% exec time regression of 433.milc on
zen2 since r14-4972-g8aa47713701b1f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112697
What|Remo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #10 from Sam James ---
Created attachment 57774
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57774&action=edit
EarlyCSE.cpp.cpp.177t.ch_vect-bad
optimize("O2") on `template
hash_code hash_combine_range_impl(InputIteratorT f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114432
Bug ID: 114432
Summary: [13 Regression] ICE in connect_traces, at
dwarf2cfi.cc:3079 on s390x-linux-gnu
Product: gcc
Version: 13.2.1
Status: UNCONFIRMED
Severit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #11 from Sam James ---
Created attachment 57775
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57775&action=edit
EarlyCSE.cpp.cpp.178t.ifcvt-bad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #12 from Sam James ---
Created attachment 57776
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57776&action=edit
EarlyCSE.cpp.cpp.179t.vect-bad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #13 from Sam James ---
Created attachment 5
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=5&action=edit
valgrind output when broken
/repo/gcc-trunk//binary-trunk-r14-9610-20240322092442-gddd4a3ca874-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240322 (experimental) (GCC)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114377
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114374
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P2
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107426
--- Comment #8 from GCC Commits ---
The master branch has been updated by Mikael Morin :
https://gcc.gnu.org/g:a44d7e8a52007c2d45217709ca02947c6600de87
commit r14-9619-ga44d7e8a52007c2d45217709ca02947c6600de87
Author: Mikael Morin
Date: Thu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112415
Jeffrey A. Law changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111655
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111305
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111231
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110987
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P4
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110842
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110401
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110285
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110273
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P2
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109990
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #14 from Richard Biener ---
There are a few vectorizations in the dumps but only one early-exit where
we vectorize
[local count: 102053600]:
first$I_39 = MEM[(struct value_op_iterator *)&first];
last$I_40 = MEM[(struct value_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112652
--- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE ---
> --- Comment #9 from Jakub Jelinek ---
> (In reply to r...@cebitec.uni-bielefeld.de from comment #8)
>> FWIW, the iconv conversion tables in /usr/lib/iconv can be regenerated
>> from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #15 from Richard Biener ---
The valgrind output might be because we vectorize the loads a[i], a[i+8], ...
as full vector loads at a[i], a[i+8] but the last we access as scalar. So
the uninit load might be harmless.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113357
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P4
--- Comment #5 from Jeffrey A. Law
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108708
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P4
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63426
Bug 63426 depends on bug 108278, which changed state.
Bug 108278 Summary: [13/14 Regression] runtime error with -O1 -Wall
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108278
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108278
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
Sta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107058
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114425
Jakub Jelinek changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106955
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105760
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P2
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105275
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104995
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104088
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P2
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99599
--- Comment #23 from Patrick Palka ---
(In reply to Jonathan Wakely from comment #22)
> Here we go, this still fails on trunk, just by making the data member
> private:
That's because for a non-dependent conversion to a class type we only check i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102264
Jeffrey A. Law changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111731
--- Comment #20 from GCC Commits ---
The master branch has been updated by Thomas Neumann :
https://gcc.gnu.org/g:a364148530c28645ce87adbc58a66c9f32a325ab
commit r14-9620-ga364148530c28645ce87adbc58a66c9f32a325ab
Author: Thomas Neumann
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101463
Jeffrey A. Law changed:
What|Removed |Added
CC||law at gcc dot gnu.org
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95185
Jeffrey A. Law changed:
What|Removed |Added
Priority|P3 |P2
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109835
--- Comment #5 from Sam James ---
FWIW, after doing more of this work, I've decided I don't really care that much
about this one.
I still think FP mismatches are often worse, but there's enough junk pointer
type mismatches that I'm not sure we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114425
--- Comment #6 from Jakub Jelinek ---
Though, guess it would help if evrp avoided undesirable propagation here:
It is changing:
:
# DEBUG BEGIN_STMT
_8 = .ADD_OVERFLOW (d_7(D), 0);
_1 = IMAGPART_EXPR <_8>;
_2 = (_Bool) _1;
# D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114432
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |13.3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #16 from Sam James ---
-fdisable-tree-cunroll seems to help.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114403
--- Comment #17 from Sam James ---
Created attachment 57780
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57780&action=edit
EarlyCSE.cpp.cpp.182t.cunroll-bad
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114101
--- Comment #9 from John David Anglin ---
These two fails are different and not addressed by patch:
FAIL: std/text_encoding/cons.cc -std=gnu++26 (test for excess errors)
UNRESOLVED: std/text_encoding/cons.cc -std=gnu++26 compilation failed to
1 - 100 of 169 matches
Mail list logo
