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
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
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
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
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
> >
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111462
Stefan Schulze Frielinghaus changed:
What|Removed |Added
CC||stefansf at linux dot
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
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=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
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=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
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
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=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
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: stefansf at linux dot ibm.com
Target Milestone: ---
$ gfortran -c -o sgexx.fppized.o -I. -Iinclude -Inetcdf/include -O3 -std=legacy
-fconvert=big-endian sgexx.F90
during GIMPLE pass: dom
sgexx.F90:8996:23
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
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=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
: 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=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
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
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=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=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=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 )
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=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
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=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
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
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
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, _mode)
&& REG_VALUES (REGNO (x)) != NULL
&& (!cselib_current_insn || !DEBUG_INSN_P
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=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
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=edit
dump combine
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
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=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=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
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=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,
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=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
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
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).
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 =
int f, g, h, i, r, s;
static short j[8][1
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
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
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 =
static int g(int *h) {
c = *h;
return d;
}
static void f(int *h) {
e = *h;
*b = 0
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=edit
var-tracking d
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100263
Stefan Schulze Frielinghaus changed:
What|Removed |Added
Status|NEW |RESOLVED
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], _mode)
> || !MODES_OK_FOR_MOVE2ADD (mode, old_mode))
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
#
-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=edit
copyprop3
int a = 3, d, l, o, p, q;
unsig
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,
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
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: 'glob
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99253
Stefan Schulze Frielinghaus changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
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.
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;
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=edit
a-foo.i.307r.cprop_hardreg
: 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=edit
a-foo.i.301r.jump2
Consider the following reduced example:
in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98094
Stefan Schulze Frielinghaus changed:
What|Removed |Added
Resolution|--- |FIXED
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;
-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
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=edit
reduced failing example
Si
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-*,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97504
Stefan Schulze Frielinghaus changed:
What|Removed |Added
CC||stefansf at linux dot
: 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 = , **i = 0;
unsigned d = 0;
unsigned
1 - 100 of 119 matches
Mail list logo
