https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109549
--- Comment #13 from Stefan Schulze Frielinghaus ---
I will take it and I've already prepared a patch. Currently, I'm still testing
the patch. I hope I get enough compute resources in order to make it into GCC
14.
Anyhow, you can assign the i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109549
--- Comment #11 from Stefan Schulze Frielinghaus ---
I will have a look at those s390x failures and come up with a
TARGET_NOCE_CONVERSION_PROFITABLE_P implementation.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113994
--- Comment #6 from Stefan Schulze Frielinghaus
---
Looks like wrong liveness information. The problem is that df_analyze_loop
only considers basic blocks which strictly belong to a loop which is not
enough. During loop2_doloop basic block 9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113960
--- Comment #9 from Stefan Schulze Frielinghaus
---
(In reply to Jonathan Wakely from comment #7)
> We can't use memcmp if the sizes are different. We don't want to use the
> min, we want to guard that code with the sizes being the same, then w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113960
--- Comment #6 from Stefan Schulze Frielinghaus
---
Guard __is_byte_iter checks for contiguous bytes which I guess is fine for
std::vector and then checks for __is_memcmp_ordered which is fine for
big-endian targets in conjunction with unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113960
Stefan Schulze Frielinghaus changed:
What|Removed |Added
CC||jwakely at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113960
--- Comment #3 from Stefan Schulze Frielinghaus
---
This seems to be a bug in the three way comparison introduced with C++20. The
bug happens while deciding whether key v2 already exists in the map or not.
template
constexpr auto
lexicogr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111462
--- Comment #6 from Stefan Schulze Frielinghaus
---
(In reply to Richard Biener from comment #5)
> (In reply to Stefan Schulze Frielinghaus from comment #4)
> > Since r14-4089-gd45ddc2c04e471 bootstrap fails on s390 with
> >
> > /devel/gcc/bui
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111462
Stefan Schulze Frielinghaus changed:
What|Removed |Added
CC||stefansf at linux dot ibm.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110939
--- Comment #11 from Stefan Schulze Frielinghaus ---
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/627024.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110867
--- Comment #9 from Stefan Schulze Frielinghaus
---
It looks like as if the first fix didn't entirely solve the problem. It turns
out that the normal form of const_int is not always met. Before releasing a
new patch, could you test it first i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110867
--- Comment #8 from Stefan Schulze Frielinghaus
---
Created attachment 55716
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55716&action=edit
Really fix narrow comparison
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110939
--- Comment #9 from Stefan Schulze Frielinghaus
---
Thanks for the reproducer and sorry for the hassle.
The normal form of a constant for a mode with fewer bits than in HOST_WIDE_INT
is a sign extended version of the original constant. This e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110939
--- Comment #6 from Stefan Schulze Frielinghaus
---
I tried to reproduce it with a cross compiler while using the reproducer from
PR110867 without getting an ICE. Can you attach a pre processed source file
and a corresponding gcc invocation?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110869
--- Comment #18 from Stefan Schulze Frielinghaus ---
Thanks again for testing. Very much appreciated!
I like the idea of a comment and posted a patch:
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626514.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110869
--- Comment #16 from Stefan Schulze Frielinghaus ---
Turns out that my dejagnu foo is weak ;-) I came up with a wrong target
selector. Should be fixed in the new attachment.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110869
--- Comment #15 from Stefan Schulze Frielinghaus ---
Created attachment 55688
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55688&action=edit
Increase optimization and skip sparc for 4-6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110869
--- Comment #14 from Stefan Schulze Frielinghaus ---
For -3 and -4 I can confirm that we do not end up with a proper comparison
during combine which means we should just ignore these on Sparc.
I'm currently puzzled that -5 and -6 are actually p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110869
--- Comment #12 from Stefan Schulze Frielinghaus ---
I have done a test with a cross-compiler and it looks to me as if we need -O2
instead of -O1 on Sparc in order to trigger the optimization. Can you give the
attached patch a try? Sorry for a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110869
--- Comment #11 from Stefan Schulze Frielinghaus ---
Created attachment 55686
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55686&action=edit
Increase optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110869
--- Comment #7 from Stefan Schulze Frielinghaus
---
I've send a patch for review:
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626075.html
and thanks for testing :)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110867
--- Comment #4 from Stefan Schulze Frielinghaus
---
Thanks for testing so quickly :)
I've send a patch for review:
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626075.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110869
--- Comment #4 from Stefan Schulze Frielinghaus
---
For sparc we already see some sort of pre-optimization which "breaks" the new
test cases. For example, for test cmp-mem-const-1.c we have prior combine:
(insn 14 13 41 2 (set (reg:SI 117)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110867
Stefan Schulze Frielinghaus changed:
What|Removed |Added
CC||stefansf at linux dot ibm.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109265
Bug ID: 109265
Summary: ICE for 527.cam4_r after r13-6787-g0963cb5fde158c
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102
--- Comment #16 from Stefan Schulze Frielinghaus ---
Fixed in mainline. Fine for me to close this now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108687
--- Comment #10 from Stefan Schulze Frielinghaus ---
Can confirm the attached patch solves this issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108687
--- Comment #8 from Stefan Schulze Frielinghaus
---
I came up with a cross compiler where I can reproduce it:
FROM fedora:37
RUN dnf -y upgrade \
&& dnf -y install 'dnf-command(builddep)' \
&& dnf -y builddep gcc \
&& dnf -y install binu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108687
--- Comment #6 from Stefan Schulze Frielinghaus
---
Just to be sure: in the initial commit I missed adding -march=z13 and only
mentioned it in commit 2
I will come up with those logs and mail them to you.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102
--- Comment #14 from Stefan Schulze Frielinghaus ---
I'm still working on this and currently test a new patch which should fix the
scheduler handling in the backend.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108687
--- Comment #4 from Stefan Schulze Frielinghaus
---
I have added a backtrace from GDB where I randomly interrupted. Hope this helps
to narrow it down.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108687
--- Comment #3 from Stefan Schulze Frielinghaus
---
Created attachment 54415
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54415&action=edit
Random backtrace after some time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108687
--- Comment #2 from Stefan Schulze Frielinghaus
---
(In reply to Stefan Schulze Frielinghaus from comment #0)
> Running gcc -O3 -c t.c on s390x does not terminate.
More specifically: gcc -O3 -march=z13 -c t.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108687
Bug ID: 108687
Summary: Non-termination since gcc-13-5630-g881bf8de9b0
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102
--- Comment #12 from Stefan Schulze Frielinghaus ---
The culprit seems to be that s390_sched_init is not called in one particular
case. We have the following basic blocks and edges:
6 --> 12 --> 13 --> 14
The edges from 12 to 13 and 13 to 14 a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102
--- Comment #11 from Stefan Schulze Frielinghaus ---
Please find attached a reduced version of the initial problem. If compiled
with
g++ -O2 -march=arch13 -fno-exceptions (-g)
there is still a difference whether build with debug information o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102
--- Comment #10 from Stefan Schulze Frielinghaus ---
Created attachment 54279
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54279&action=edit
RTL dump of sched2 if compiled with debug information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102
--- Comment #9 from Stefan Schulze Frielinghaus
---
Created attachment 54278
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54278&action=edit
RTL dump of sched2 if compiled without debug information
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102
--- Comment #8 from Stefan Schulze Frielinghaus
---
Created attachment 54277
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54277&action=edit
reduced version of the initial problem
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102
--- Comment #7 from Stefan Schulze Frielinghaus
---
The difference in the assembly output shown in comment 2 happens in function
void
AssociatedImplTrait::setup_associated_types (
const TyTy::BaseType *self, const TyTy::TypeBoundPredicate &b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102
--- Comment #6 from Stefan Schulze Frielinghaus
---
Created attachment 54154
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54154&action=edit
preprocessed rust-hir-trait-resolve.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102
--- Comment #4 from Stefan Schulze Frielinghaus
---
I was playing around with this and was wondering how can I actually execute the
stageN compiler? From the output of make I see two compilations for object
rust-hir-trait-resolve.o. Thus the fi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108102
Stefan Schulze Frielinghaus changed:
What|Removed |Added
CC||stefansf at linux dot ibm.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107088
--- Comment #10 from Stefan Schulze Frielinghaus ---
(In reply to rsand...@gcc.gnu.org from comment #8)
> Looks good, but maybe:
>
> GET_MODE_SIZE (int_mode) > 1
>
> would be more general.
I very much like the idea of a size guard. Posted a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107088
--- Comment #6 from Stefan Schulze Frielinghaus
---
I did a quick test using
diff --git a/gcc/cselib.cc b/gcc/cselib.cc
index 9b582e5d3d6..2fd0190bc79 100644
--- a/gcc/cselib.cc
+++ b/gcc/cselib.cc
@@ -1571,6 +1571,7 @@ new_cselib_val (unsigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107094
--- Comment #1 from Stefan Schulze Frielinghaus
---
Looks like related to PR107088
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107088
--- Comment #5 from Stefan Schulze Frielinghaus
---
Thanks for looking into this! Currently I'm out of office and have very limited
internet access. I will be back on Tuesday and look right into this. If this is
to late feel free to revert my p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107088
--- Comment #1 from Stefan Schulze Frielinghaus
---
The patch introduces
scalar_int_mode int_mode;
if (REG_P (x) && is_int_mode (mode, &int_mode)
&& REG_VALUES (REGNO (x)) != NULL
&& (!cselib_current_insn || !DEBUG_INSN_P (cselib_curre
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106355
--- Comment #4 from Stefan Schulze Frielinghaus
---
The problem is with sibling call optimization where parameters with BLKmode are
not handled correctly. I will prepare a patch and submit it shortly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100960
--- Comment #6 from Stefan Schulze Frielinghaus
---
Created attachment 53433
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53433&action=edit
a-t2.c.325r.vartrack
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100960
--- Comment #5 from Stefan Schulze Frielinghaus
---
However, I found another example (see attachment a-t2.c.325r.vartrack) which
does not profit from the patch:
__attribute__((noinline, noclone)) void
fn1 (int x)
{
__asm volatile ("" : "+r"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100960
--- Comment #4 from Stefan Schulze Frielinghaus
---
I really like the idea of enhancing cselib since there is a chance that other
passes might profit from it, too. The following patch fixes the initial
reported problem:
diff --git a/gcc/cselib
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101260
--- Comment #18 from Stefan Schulze Frielinghaus ---
Fixed for 12 and mainline.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104814
--- Comment #7 from Stefan Schulze Frielinghaus
---
Gave trunk a try and it worked fine for me. Thanks for the fix!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104814
--- Comment #3 from Stefan Schulze Frielinghaus
---
Oh forgot to mention it is just: gcc -O1 t.c
Works fine with -O{0,2,3}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104814
--- Comment #1 from Stefan Schulze Frielinghaus
---
Created attachment 52571
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52571&action=edit
dump combine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104814
Bug ID: 104814
Summary: [10/11/12 Regression] ifcvt: Deleting live variable in
IF-CASE-2
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103063
Bug ID: 103063
Summary: Wrong code while using -O3
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102752
--- Comment #6 from Stefan Schulze Frielinghaus
---
Thanks for confirmation! Bootstrap and regtest are still running on x86 as well
as IBM Z. I will commit the attached patch assuming successful runs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102752
--- Comment #5 from Stefan Schulze Frielinghaus
---
Created attachment 51606
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51606&action=edit
Fix determining precission of reduction_var
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102752
--- Comment #2 from Stefan Schulze Frielinghaus
---
It looks like I missed to take the TREE_TYPE of reduction_var. I just did a
quick test with
diff --git a/gcc/tree-loop-distribution.c b/gcc/tree-loop-distribution.c
index fb9250031b5..0559b9c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102720
Stefan Schulze Frielinghaus changed:
What|Removed |Added
CC||stefansf at linux dot ibm.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101260
--- Comment #10 from Stefan Schulze Frielinghaus ---
In regcprop we call find_oldest_value_reg which itself calls
maybe_mode_change (TImode, TImode, DImode, 10, 18)
where we have
regno += subreg_regno_offset (regno, orig_mode, offset, new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95681
--- Comment #4 from Stefan Schulze Frielinghaus
---
Running todays mainline (d97d71a1989) using options -O3 -Wall against the
reduced program on x86 as well as s390x results in
t.c: In function 'decNumberCompareTotalMag':
t.c:55:14: warning: '*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95681
--- Comment #3 from Stefan Schulze Frielinghaus
---
Created attachment 51160
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51160&action=edit
Reduced program
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101260
--- Comment #8 from Stefan Schulze Frielinghaus
---
Pass split2 transforms
(insn 218 222 114 15 (set (reg/v:TI 10 %r10 [orig:87 a ] [87])
(reg/v:TI 18 %f4 [orig:87 a ] [87])) 1466 {movti}
(nil))
into
(insn 234 222 235 15 (set (r
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101260
--- Comment #7 from Stefan Schulze Frielinghaus
---
I had a look at the optimized tree output which looks good to me. However, I
see that split2 transforms
(insn 218 222 114 15 (set (reg/v:TI 10 %r10 [orig:87 a ] [87])
(reg/v:TI 18 %f4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101260
--- Comment #5 from Stefan Schulze Frielinghaus
---
Yes, I'm already looking into this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101260
--- Comment #3 from Stefan Schulze Frielinghaus
---
The problem shows up for option -O1 (options -O{0,2,3} are fine) and GCC 10 and
11 (mainline and GCC 9 are fine).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101260
Bug ID: 101260
Summary: Backport 27381e78925 to GCC 11
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101066
--- Comment #4 from Stefan Schulze Frielinghaus
---
(In reply to Martin Jambor from comment #3)
> I have proposed a fix on the mailing list:
> https://gcc.gnu.org/pipermail/gcc-patches/2021-June/573338.html
I gave it a try on IBM Z where the t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99212
--- Comment #20 from Stefan Schulze Frielinghaus ---
The mentioned failing test cases are fixed on IBM Z, now. Thanks for your help!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99212
Stefan Schulze Frielinghaus changed:
What|Removed |Added
CC||stefansf at linux dot ibm.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101066
Bug ID: 101066
Summary: Wrong code after fixup_cfg3
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100960
Bug ID: 100960
Summary: var-tracking: parameter location in subregister not
tracked
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100562
Bug ID: 100562
Summary: ICE after commit
a076632e274abe344ca7648b7c7f299273d4cbe0
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Pri
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100263
Stefan Schulze Frielinghaus changed:
What|Removed |Added
Status|NEW |RESOLVED
Resoluti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100263
--- Comment #11 from Stefan Schulze Frielinghaus ---
(In reply to Eric Botcazou from comment #10)
> OK, then it's probably better to add it to:
>
> if (!is_a (reg_mode[regno], &old_mode)
> || !MODES_OK_FOR_MOVE2ADD (mode, old_mod
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100263
--- Comment #9 from Stefan Schulze Frielinghaus
---
Shouldn't we rather check for REG_CAN_CHANGE_MODE_P? A check for
TARGET_HARD_REGNO_MODE_OK for a FP register and QImode is successful.
Using the following also fixes the test for me:
diff --
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100263
--- Comment #6 from Stefan Schulze Frielinghaus
---
Prior postreload we have
(insn 12 379 332 3 (set (reg:QI 17 %f2 [orig:198 l_lsm_flag.27 ] [198])
(const_int 1 [0x1])) 1480 {*movqi}
(expr_list:REG_EQUIV (const_int 1 [0x1])
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100263
--- Comment #5 from Stefan Schulze Frielinghaus
---
It looks like a mode mismatch:
(insn 201 200 378 3 (set (reg:DI 17 %f2 [196])
(const_int 1 [0x1])) "t.c":23:36 1467 {*movdi_64}
(expr_list:REG_EQUIV (const_int 1 [0x1])
(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100263
--- Comment #4 from Stefan Schulze Frielinghaus
---
You are right. I got lured by the fact that the assignments c__lsm.20_94 = 1;
and c__lsm_flag.21_95 = 1; of bb5 are "moved" into the PHI as e.g.
# c__lsm.20_51 = PHI
# c__lsm_flag.21_5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100263
Bug ID: 100263
Summary: Wrong removal of statement in copyprop3
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99814
--- Comment #4 from Stefan Schulze Frielinghaus
---
Thanks for the pointers! I reported it upstream in issue
[1390](https://github.com/google/sanitizers/issues/1390)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99814
--- Comment #2 from Stefan Schulze Frielinghaus
---
Breakpoint 4, __interception::InterceptFunction (name=0x3fffd61e8f2 "regexec",
ver=0x3fffd61eb7e "GLIBC_2.3.4", ptr_to_real=0x3fffd677d08
<__interception::real_regexec>, func=16779728,
wra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99814
Bug ID: 99814
Summary: regexec fails with -fsanitize=address
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99313
Bug ID: 99313
Summary: ICE while changing global target options via pragma
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99253
Stefan Schulze Frielinghaus changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolutio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99253
--- Comment #2 from Stefan Schulze Frielinghaus
---
Still aborts with -fno-vect-cost-model on IBM Z.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99253
Bug ID: 99253
Summary: tree-vect-loop wrong code
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Comp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99221
--- Comment #1 from Stefan Schulze Frielinghaus
---
Created attachment 50243
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50243&action=edit
a-foo.i.307r.cprop_hardreg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99221
Bug ID: 99221
Summary: copyprop_hardreg_forward_1 deletes insn by mistake
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98094
Stefan Schulze Frielinghaus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|U
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98094
--- Comment #3 from Stefan Schulze Frielinghaus
---
I still run into the same error with e4c02ce4ab6fce1148f4025360096f18764deadf
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98094
--- Comment #1 from Stefan Schulze Frielinghaus
---
Reduced program:
struct {
unsigned a : 10
} b;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98094
Bug ID: 98094
Summary: ICE in decompose, at wide-int.h:984
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimizat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97545
Bug ID: 97545
Summary: ICE since commit 90e88fd376b and using
selective-scheduling2
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504
--- Comment #8 from Stefan Schulze Frielinghaus
---
(In reply to Alexandre Oliva from comment #5)
> Created attachment 49427 [details]
> patch that should fix the remaining s390 problem
>
> So, the issue is already fixed on aarch64-*, powerpc*-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504
Stefan Schulze Frielinghaus changed:
What|Removed |Added
CC||stefansf at linux dot ibm.c
99 matches
Mail list logo
