-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: stefansf at linux dot ibm.com
Target Milestone: ---
Consider the following MWE:
int64_t f (int64_t x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94344
--- Comment #5 from Stefan Schulze Frielinghaus
---
(In reply to Jakub Jelinek from comment #4)
> Created attachment 48145 [details]
> gcc10-pr94344.patch
LGTM. I did some tests (including the initial one) which all succeeded in
detecting a sig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94344
Stefan Schulze Frielinghaus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|A
: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: stefansf at linux dot ibm.com
Target Milestone: ---
In function check_io_constraints local variable num is supposed to be
initialized by function compare_to_allowed_values. While bootstrapping GCC on
S/390 I get the following
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: stefansf at linux dot ibm.com
Target Milestone: ---
Created attachment 48377
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48377&action=edit
If SAFE then ret
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94769
--- Comment #3 from Stefan Schulze Frielinghaus
---
Since one call chain is gfc_resolve_dt -> check_io_constraints ->
compare_to_allowed_values and at least one parameter of
compare_to_allowed_values, from which the initialization of variable nu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94774
--- Comment #2 from Stefan Schulze Frielinghaus
---
(In reply to Martin Sebor from comment #1)
> Moving the guard up would suppress the dump output in the "unsafe" case so I
> don't think that's what we want. OTOH, ether initializing the array,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94769
--- Comment #7 from Stefan Schulze Frielinghaus
---
Since gfc_resolve_dt is a non-static function we cannot assume anything about
argument DT. Argument DT gets passed to function check_io_constraints which
passes values depending on DT, namely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94769
--- Comment #8 from Stefan Schulze Frielinghaus
---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544716.html
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 94769, which changed state.
Bug 94769 Summary: Possible use of uninitialized variable num
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94769
What|Removed |Added
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94769
Stefan Schulze Frielinghaus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|U
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: stefansf at linux dot ibm.com
Target Milestone: ---
Created attachment 48450
--> https://gcc.gnu.org/bugzi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
Bug 24639 depends on bug 94952, which changed state.
Bug 94952 Summary: Possible false positive of uninitialized variable usage
during release build in gimple-ssa-store-merging.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94952
What
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94952
Stefan Schulze Frielinghaus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|U
, diagnostic
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: stefansf at linux dot ibm.com
Target Milestone: ---
Target: s390
The following error/warning shows up on S/390 while
mal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: stefansf at linux dot ibm.com
Target Milestone: ---
Consider the following MWE:
extern void* malloc (long unsigned int);
void fun (unsigned *x) {
unsigned *a = malloc (*x);
if
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: stefansf at linux dot ibm.com
Target Milestone: ---
Consider the following example:
int a = 0, f = 0, g = 0, h = 0, i = 0;
int b = 0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96801
--- Comment #2 from Stefan Schulze Frielinghaus
---
Can confirm. This is resolved with the mentioned commit. Thanks!
: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: stefansf at linux dot ibm.com
Target Milestone: ---
Since commit b6ff3ddecfa the following program prints the wrong number to
stdout:
int a = 0, j = 0;
int *b = 0;
int **c = &b, **i = 0;
unsigned d
Priority: P3
Component: libitm
Assignee: unassigned at gcc dot gnu.org
Reporter: stefansf at linux dot ibm.com
Target Milestone: ---
Consider the following example:
void foo(int n) {
__transaction_atomic {
char a[8];
a[n] = 42;
}
}
Using GCC
Component: preprocessor
Assignee: unassigned at gcc dot gnu.org
Reporter: stefansf at linux dot ibm.com
Target Milestone: ---
#pragma GCC push_options
#pragma GCC target ("arch=z13")
#pragma GCC pop_options
$ gcc t.c -c -march=z900
test.c:3:9: internal compiler error: '
Assignee: unassigned at gcc dot gnu.org
Reporter: stefansf at linux dot ibm.com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at
gcc dot gnu.org
Target Milestone
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
--- 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=97504
Stefan Schulze Frielinghaus changed:
What|Removed |Added
CC||stefansf at linux dot
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*-
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: stefansf at linux dot ibm.com
Target Milestone: ---
Created attachment 49433
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49433&action=edit
reduced failing
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: stefansf at linux dot ibm.com
Target Milestone: ---
Compiling SPEC benchmark 502.gcc_r on S/390 results in the following ICE:
$ /devel/gcc-2/dst/bin/gcc -c -o tree.o -DSPEC -DNDEBUG -I. -I./include
-I./spec_qsort
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
--- 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
Stefan Schulze Frielinghaus changed:
What|Removed |Added
Resolution|--- |FIXED
Status|U
: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: stefansf at linux dot ibm.com
Target Milestone: ---
Created attachment 50242
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50242&action=edit
a-foo.i.301r.jump2
Consider the following reduced
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
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: stefansf at linux dot ibm.com
Target Milestone: ---
Target: s390x, x86_64-*-*
int a = 0;
static int b = 0;
long c = 0;
int
main() {
for (int d = 0; d < 8; d++) {
a ^= c;
b
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
Stefan Schulze Frielinghaus changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolutio
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: stefansf at linux dot ibm.com
Target Milestone: ---
Target: s390*-*-*
Created attachment 50676
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50676&action=edit
copyprop3
int a = 3, d, l,
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
--- 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 #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 #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 #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
Stefan Schulze Frielinghaus changed:
What|Removed |Added
Status|NEW |RESOLVED
Resoluti
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: stefansf at linux dot ibm.com
Target Milestone: ---
Target: s390*-*-*
Since commit g:a076632e274abe344ca7648b7c7f299273d4cbe0 building GCC with Go
language enabled on IBM Z
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: stefansf at linux dot ibm.com
Target Milestone: ---
Target: s390x-*-*
Created attachment 50960
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50960&action=e
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: stefansf at linux dot ibm.com
Target Milestone: ---
Target: s390*-*-*, x86_64-*-*
int a = 1, c, d, e;
int *b = &a;
static int g(int *h) {
c = *h;
return d;
}
static void f(int *h) {
e = *h;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99212
Stefan Schulze Frielinghaus changed:
What|Removed |Added
CC||stefansf at linux dot
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=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=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 #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 #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 #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 #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
: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: stefansf at linux dot ibm.com
Target Milestone: ---
typedef struct { int a[32]; } b;
b c;
int d, e, f;
void g () {
for (; c.a[f - 1]; f++) {
e = e * d;
c.a[f] = f / d;
}
}
Running gcc -O3 -c t.c on s390x
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
--- 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 #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=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 #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=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 #10 from Stefan Schulze Frielinghaus ---
Can confirm the attached patch solves this issue.
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.
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: stefansf at linux dot ibm.com
Target Milestone: ---
Target: s390x-*-*
Created attachment 52570
--> https://gcc.gnu.org/bugzi
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
--- 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 #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=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=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 #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=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=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=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=107094
--- Comment #1 from Stefan Schulze Frielinghaus
---
Looks like related to PR107088
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=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
Assignee: unassigned at gcc dot gnu.org
Reporter: stefansf at linux dot ibm.com
Target Milestone: ---
int a = 0;
unsigned char b = 0;
int main() {
a - 6;
for (; a >= -13; a = a - 8)
while((unsigned char)(b-- * 6))
;
if (b != 127)
__builtin_abort();
ret
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102720
Stefan Schulze Frielinghaus changed:
What|Removed |Added
CC||stefansf at linux dot
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=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 #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=108102
Stefan Schulze Frielinghaus changed:
What|Removed |Added
CC||stefansf at linux dot
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
--- 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 #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=101260
--- Comment #18 from Stefan Schulze Frielinghaus ---
Fixed for 12 and mainline.
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: stefansf at linux dot ibm.com
Target Milestone: ---
Target: s390*-*-*
struct a {
unsigned b : 7;
int c;
int d;
short e;
} p, *q = &p;
int f, g, h, i, r, s;
static short
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
--- Comment #5 from Stefan Schulze Frielinghaus
---
Yes, I'm already looking into this.
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 #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=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=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=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=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=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 #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
--- 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=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=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.
1 - 100 of 119 matches
Mail list logo
