https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92828
--- Comment #4 from Andreas Krebbel ---
(In reply to Andrew Pinski from comment #3)
> Are you saying the warning shows up which causes the bootstrap to fail?
> Because at runtime there should be no out of bounds access.
Yes. It is just the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92176
--- Comment #7 from Andreas Krebbel ---
Created attachment 47432
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47432=edit
Updated testcase
This is an updated testcase with the changes I propose.
Your testcase works fine. However, I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92828
Andreas Krebbel changed:
What|Removed |Added
Priority|P3 |P2
--- Comment #5 from Andreas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92950
Andreas Krebbel changed:
What|Removed |Added
Keywords||wrong-code
Target|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92950
--- Comment #1 from Andreas Krebbel ---
Author: krebbel
Date: Mon Dec 16 08:03:28 2019
New Revision: 279410
URL: https://gcc.gnu.org/viewcvs?rev=279410=gcc=rev
Log:
Fix PR92950: Wrong code emitted for movv1qi
The backend emits 16 bit memory
Assignee: unassigned at gcc dot gnu.org
Reporter: krebbel at gcc dot gnu.org
Target Milestone: ---
The following testcase abort when being compiled with -O3 -march=z13 on IBM Z:
struct a {
int b;
char c;
};
struct a d = {1, 16};
struct a *e =
int f = 0;
int main
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: krebbel at gcc dot gnu.org
Target Milestone: ---
Created attachment 47083
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47083=edit
reduced testcase
The attached testcase core dumps when compiled with
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: krebbel at gcc dot gnu.org
Target Milestone: ---
Compiling the following testcase with: gcc -O2 -Wall t.c
char *strncpy(char *, const char *, long unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92176
--- Comment #1 from Andreas Krebbel ---
Created attachment 47387
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47387=edit
Another reduced testcase
gcc -O3 -march=z13 t.c -o t
./t
prints "checksum = 0" with head GCC
prints "checksum =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92176
--- Comment #2 from Andreas Krebbel ---
Created attachment 47388
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47388=edit
Experimental patch
This patch fixes the second testcase. The first one currently doesn't fail on
head.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92176
Andreas Krebbel changed:
What|Removed |Added
Priority|P3 |P2
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92176
--- Comment #3 from Andreas Krebbel ---
276.ira:
(insn 6 85 11 2 (set (reg:SI 100 [ f ])
(mem/c:SI (symbol_ref:DI ("*.LANCHOR0") [flags 0x182]) [2 f+0 S4 A32]))
"t.c":13:8 1372 {*movsi_zarch}
(expr_list:REG_EQUIV (mem/c:SI
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91035
--- Comment #7 from Andreas Krebbel ---
Author: krebbel
Date: Thu Oct 10 07:56:25 2019
New Revision: 276790
URL: https://gcc.gnu.org/viewcvs?rev=276790=gcc=rev
Log:
S/390: PR91035 Fix call to __morestack
For the call to __morestack we use a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91035
--- Comment #8 from Andreas Krebbel ---
With that patch GCCGO bootstraps fine until r275473 where libgo got updated to
version 1.13beta1. Then there are a few problems with hardware crypto support
on Z. I'll try to address these with separate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91035
--- Comment #9 from Andreas Krebbel ---
I've just posted two patches to fix the remaining GO build problems on S/390.
Ian could you please pick those up to make GO build again on S/390?
Sync hardware facility names with other files in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93272
Andreas Krebbel changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93272
Andreas Krebbel changed:
What|Removed |Added
Attachment #47656|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93272
--- Comment #5 from Andreas Krebbel ---
(In reply to Vladimir Makarov from comment #4)
> (In reply to Andreas Krebbel from comment #3)
> > Created attachment 47714 [details]
> > IRA EH fix - only when added at start of BB
> >
> > A probably
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93272
--- Comment #1 from Andreas Krebbel ---
Created attachment 47656
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47656=edit
Experimental patch
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: krebbel at gcc dot gnu.org
Target Milestone: ---
Created attachment 47655
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47655=edit
Reduced testcase
When compiling the attached testcase for IB
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93272
Andreas Krebbel changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93272
--- Comment #2 from Andreas Krebbel ---
This problem to some degree is specific to IBM Z since our EH regs are
call-saved registers. For targets using call-clobbered EH regs such a
collisions usually cannot happen. Perhaps it can be provoked
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92176
--- Comment #11 from Andreas Krebbel ---
(In reply to CVS Commits from comment #10)
> The master branch has been updated by Andreas Krebbel :
>
> https://gcc.gnu.org/g:3b5757ea87ad2274b841340335bf7536204e615b
>
> commit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94613
Andreas Krebbel changed:
What|Removed |Added
Keywords||wrong-code
Priority|P3
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: krebbel at gcc dot gnu.org
Target Milestone: ---
Created attachment 48284
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48284=edit
autoreduced testcase
When compil
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91628
Andreas Krebbel changed:
What|Removed |Added
CC||krebbel at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94666
Andreas Krebbel changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
Assignee: unassigned at gcc dot gnu.org
Reporter: krebbel at gcc dot gnu.org
Target Milestone: ---
Created attachment 48308
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48308=edit
Testcase
Compiling the attached testcase with:
cc1plus -O3 -march=z13 t.cc
ICEs:
t
|1
Last reconfirmed||2020-04-20
Assignee|unassigned at gcc dot gnu.org |krebbel at gcc dot
gnu.org
--- Comment #1 from Andreas Krebbel ---
Created attachment 48309
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48309=e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94666
Andreas Krebbel changed:
What|Removed |Added
CC||doko at debian dot org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94670
Andreas Krebbel changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94670
Andreas Krebbel changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94613
Andreas Krebbel changed:
What|Removed |Added
Priority|P1 |P2
Summary|combine: Wrong
at gcc dot gnu.org |krebbel at gcc dot
gnu.org
--- Comment #6 from Andreas Krebbel ---
My debugging went into the wrong direction. The problem arises from wrong RTL
being generated in the backend for the vec_sel builtin.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94613
--- Comment #2 from Andreas Krebbel ---
-fno-ipa-sra is required to get the same results as in the first comment. The
full command line then is:
c1plus -O3 -march=z14 t.ii -quiet -o t.s -fno-ipa-sra
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94613
--- Comment #5 from Andreas Krebbel ---
(In reply to Richard Biener from comment #3)
> Why is it not correct to split the insn the way you describe? I see nothing
> wrong with that - the use of r115 is still under r110 == 0. Is the issue
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94613
Andreas Krebbel changed:
What|Removed |Added
Target Milestone|--- |10.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94613
--- Comment #1 from Andreas Krebbel ---
If we have to assume that we already applied simplifications on the THEN or
ELSE branches it doesn't appear to be correct to look for split points inside
an IF_THEN_ELSE expression anymore.
This patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92950
Andreas Krebbel changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #5 from Andreas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94704
Andreas Krebbel changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94666
Andreas Krebbel changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #4 from Andreas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94969
--- Comment #1 from Andreas Krebbel ---
The problem arises from dr_analyze_innermost not being able to analyze the
bitfield access. However, the returned error is ignored in
find_data_references_in_stmt and execution continues with bogus values
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94969
Andreas Krebbel changed:
What|Removed |Added
Priority|P3 |P2
Host|
Assignee: unassigned at gcc dot gnu.org
Reporter: krebbel at gcc dot gnu.org
Target Milestone: ---
Created attachment 48461
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48461=edit
Testcase
The attached testcase aborts on x86 when compiled with -O3. It succeeds with
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94969
--- Comment #2 from Andreas Krebbel ---
Created attachment 48462
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48462=edit
Experimental patch
With this patch the returned error is propagated. Unfortunately this prevents
some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96456
--- Comment #1 from Andreas Krebbel ---
Confirmed for current gcc 10 branch. Does not appear to happen on trunk though.
I'll have a look.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95721
Andreas Krebbel changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94969
Andreas Krebbel changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94969
Andreas Krebbel changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #14 from Andreas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97439
--- Comment #1 from Andreas Krebbel ---
Created attachment 49375
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49375=edit
Fix
decimal_real_maxval misses to set the sign flag in the REAL_VALUE_TYPE.
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: krebbel at gcc dot gnu.org
Target Milestone: ---
Created attachment 49374
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49374=edit
Testcase
The attached testcase aborts on IBM Z when compiled with:
gcc -O1
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: krebbel at gcc dot gnu.org
Target Milestone: ---
Compiling the attached testcase produces wrong code on IBM Z:
cc1 t.c -m31 -mzarch -march=z900 -O2 -fpic -o t.s
foo:
stm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97497
--- Comment #1 from Andreas Krebbel ---
Created attachment 49402
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49402=edit
Proposed fix
With the patch only regs are considered which aren't "fixed" assuming that for
fixed_regs the backend
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97497
--- Comment #4 from Andreas Krebbel ---
Reading from symbol t uses the GOT pointer in r12. The call then partially
clobbers r12 but does not affect the lower 32 bits where the GOT pointer
resides. So the GOT pointer stays in fact live across the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97497
--- Comment #6 from Andreas Krebbel ---
Alternatively I could also mark r12 as preserved across function calls for
-fpic in the backend. In fact all the bits we care about are preserved. Since
the register is fixed all the accesses do come from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97497
--- Comment #3 from Andreas Krebbel ---
Created attachment 49405
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49405=edit
testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96456
Andreas Krebbel changed:
What|Removed |Added
Resolution|--- |FIXED
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96456
Andreas Krebbel changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #5 from Andreas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98550
--- Comment #4 from Andreas Krebbel ---
The problem occurs starting with:
commit 1e1e1edf88a7c40ae4ae0de9e6077179e13ccf6d
Author: Richard Biener
Date: Thu Oct 29 08:48:15 2020 +0100
More BB vectorization tweaks
This tweaks the op
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98550
--- Comment #3 from Andreas Krebbel ---
Created attachment 49944
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49944=edit
Reduced testcase
This testcase fails on bcb3065b2ba with
cc1plus t.cpp -march=z13 -O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98550
Andreas Krebbel changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #5 from Andreas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98124
Andreas Krebbel changed:
What|Removed |Added
CC||krebbel at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98124
--- Comment #2 from Andreas Krebbel ---
(In reply to Andreas Krebbel from comment #1)
> LTDBR turns SNaNs into QNaNs and that's not supposed to happen in your
> testcase. We emit LTDBR only with -fno-trapping-math
... or if the result of LTDBR
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: krebbel at gcc dot gnu.org
Target Milestone: ---
Created attachment 49728
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49728=edit
Fix
The vec-abi-varargs-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98221
Andreas Krebbel changed:
What|Removed |Added
Priority|P3 |P2
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98221
--- Comment #3 from Andreas Krebbel ---
tree-vect-loop-manip.c: vect_maybe_permute_loop_masks also emits
VEC_UNPACKS_HI/LO dependent on BYTES_BIG_ENDIAN.
What is the expectation wrt the meaning of hi/lo in RTL standard names? I
couldn't find it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78559
Andreas Krebbel changed:
What|Removed |Added
CC||stli at linux dot ibm.com
--- Comment
|--- |DUPLICATE
CC||krebbel at gcc dot gnu.org
--- Comment #4 from Andreas Krebbel ---
The problem is a CC mode mismatch generated by combine. After splitting the add
insn 135 generates a CCL1mode cc while the conditional jump consumes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97326
--- Comment #2 from Andreas Krebbel ---
Probably my fault. I did forget supporting floats in vec_cmp. I'm testing a
patch.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97326
Andreas Krebbel changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97326
Andreas Krebbel changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #5 from Andreas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97502
Andreas Krebbel changed:
What|Removed |Added
Last reconfirmed||2020-10-21
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: krebbel at gcc dot gnu.org
Target Milestone: ---
int a[6];
char b, c;
int main() {
int d[4] = {0, 0, 0, 0};
for (c = 0; c <= 5; c++) {
for (b = 2; b != 0; b++)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98736
Andreas Krebbel changed:
What|Removed |Added
Keywords||wrong-code
Priority|P3
-end
Assignee: unassigned at gcc dot gnu.org
Reporter: krebbel at gcc dot gnu.org
Target Milestone: ---
Created attachment 50933
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50933=edit
Testcase
Compiling the testcase with either:
gcc -O3 t1.c -o t -fsanitize=addr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100908
--- Comment #1 from Andreas Krebbel ---
https://gcc.gnu.org/pipermail/gcc/2021-June/236269.html
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: krebbel at gcc dot gnu.org
Target Milestone: ---
Created attachment 51135
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51135=edit
Testcase
Building the attached testcase with:
cc1p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101426
--- Comment #1 from Andreas Krebbel ---
Created attachment 51136
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51136=edit
Experimental Fix
With this patch the address is copied to a pseudo first. That way the register
allocator will
++
Assignee: unassigned at gcc dot gnu.org
Reporter: krebbel at gcc dot gnu.org
Target Milestone: ---
Created attachment 50685
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50685=edit
Experimental Fix
typedef void * __attribute__((mode (SI))) __ptr32_t;
void
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100281
--- Comment #3 from Andreas Krebbel ---
This is a hard requirement for the z/TPF operating system supported as part of
our IBM Z backend. It happens to work for many years already and they make
extensive use of it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100281
Andreas Krebbel changed:
What|Removed |Added
Attachment #50685|0 |1
is obsolete|
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: krebbel at gcc dot gnu.org
Target Milestone: ---
This test aborts when compiled on IBM Z with:
gcc -O3 t.c -o t -fgcse-sm
it succeeds with -O2 or without -fgcse-sm
Tested with Commit ID: 072f20c5559
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98973
--- Comment #4 from Andreas Krebbel ---
The update of global variable c is moved out of the loop. Due to that c stays
at 8 although it should be counted down to 2.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98973
--- Comment #5 from Andreas Krebbel ---
Created attachment 50132
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50132=edit
RTL dump from store motion pass
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98973
--- Comment #2 from Andreas Krebbel ---
Created attachment 50130
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50130=edit
RTL GCSE dump with -fgcse-sm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98973
--- Comment #3 from Andreas Krebbel ---
Created attachment 50131
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50131=edit
RTL GCSE dump without -fgcse-sm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98847
Andreas Krebbel changed:
What|Removed |Added
CC||krebbel at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96127
--- Comment #4 from Andreas Krebbel ---
The testcase does not appear to fail on current GCC 10 branch. So I would just
close it as fixed in GCC 11.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10
--- Comment #6 from Andreas Krebbel ---
(insn 9 8 10 2 (set (strict_low_part (reg:SI 66))
(mem/c:SI (plus:SI (reg/f:SI 64)
(const_int 4 [0x4])) [1 read_inode_val+0 S4 A32]))
With -mesa this should be a simple move.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10
Andreas Krebbel changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |krebbel at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103364
--- Comment #20 from Andreas Krebbel ---
(In reply to Sarah Julia Kriesch from comment #18)
...
> sudo zypper in osc build obs-service-format_spec_file bsdtar #also possible
> with other Linux distributions
> osc co
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103364
--- Comment #22 from Andreas Krebbel ---
(In reply to Sarah Julia Kriesch from comment #21)
> Did you use a mainframe as a local system?
I did run these commands on a z15 Lpar with Fedora33 installed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103028
--- Comment #3 from Andreas Krebbel ---
So I think what is needed is something like this:
diff --git a/gcc/ifcvt.c b/gcc/ifcvt.c
index 017944f4f79a..1f5b9476ac2e 100644
--- a/gcc/ifcvt.c
+++ b/gcc/ifcvt.c
@@ -4341,7 +4341,8 @@ find_if_header
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103028
--- Comment #2 from Andreas Krebbel ---
IF-convert generates the compare *after* reload. The operands get checked for
validity only by invoking the predicates. That means everything which is
accepted by TARGET_LEGITIMATE_CONSTANT_P is ok for a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103364
--- Comment #15 from Andreas Krebbel ---
(In reply to Sarah Julia Kriesch from comment #0)
...
> Full PostgreSQL log:
> https://build.opensuse.org/build/openSUSE:Factory:zSystems/standard/s390x/
> postgresql14/_log
>
> Full Rust log:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103364
--- Comment #17 from Andreas Krebbel ---
(In reply to Sarah Julia Kriesch from comment #12)
> that is happening during the build process in OBS with a really minimal
> openSUSE Tumbleweed. We are using VMs using QEMU and with 4GB of memory.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103364
--- Comment #11 from Andreas Krebbel ---
Could you please provide the steps to reproduce the issue. I just tried real
quick with a container image and couldn't reproduce it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #2 from Andreas Krebbel ---
Created attachment 51174
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51174=edit
Experimental Fix
With that patch the number of combine attempts goes back to normal.
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: krebbel at gcc dot gnu.org
Target Milestone: ---
Compiling the attached testcase on s390x with:
cc1plus -fpreprocessed t.ii -quiet -march=z196 -g -O2 -std=c++11
produces a huge amount of combine attempts compared to x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #1 from Andreas Krebbel ---
This appears to be triggered by try_combine unnecessarily setting back the
position by returning the i2 insn.
When 866 is inserted into 973 866 still needs to be kept around for other
users. So
501 - 600 of 648 matches
Mail list logo
