https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114676
--- Comment #16 from Andreas Krebbel ---
(In reply to Aleksei Nikiforov from comment #15)
> I think fixing compiled code should be possible. I'm not sure if this bug
> should be just closed.
In addition to fixing the PyTorch usage of the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114676
--- Comment #13 from Andreas Krebbel ---
We will go and fix PyTorch instead. Although it is not clearly documented, the
way PyTorch uses the builtin right now is probably not what was intended. It is
pretty clear that the element type pointer
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114676
--- Comment #11 from Andreas Krebbel ---
The documentation of vec_xl and vec_xst doesn't seem to mention anything
special with regard to that. So I understand the memory is only accessed
through pointers which are compatible to the ones used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114676
--- Comment #8 from Andreas Krebbel ---
Apparently, I decided to go with a MEM_REF already for the load variant of the
builtin - vec_xl. I've to check whether there was any reason not to do this
also for vec_xst.
Making it a pointer which
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #33 from Andreas Krebbel ---
(In reply to Andrew Pinski from comment #26)
...
> I suspect if we change the s390 backend just slightly to set the cost when
> there is an index to the address to 1 for the MEM, combine won't be acting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #32 from Andreas Krebbel ---
(In reply to Segher Boessenkool from comment #25)
> So this testcase compiles on powerpc64-linux (-O2) in about 34s. Is s390x
> way worse, or is this in lie what you are seeing?
Way worse. See #c22 :
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #23 from Andreas Krebbel ---
Created attachment 57646
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57646=edit
Testcase for comment #22
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #22 from Andreas Krebbel ---
I did a git bisect which ended up pointing at this commit, somewhere between
GCC 8 and 9:
commit c4c5ad1d6d1e1e1fe7a1c2b3bb097cc269dc7306 (bad)
Author: Segher Boessenkool
Date: Mon Jul 30 15:18:17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #21 from Andreas Krebbel ---
(In reply to Segher Boessenkool from comment #16)
...
> When some insns have changed (or might have changed, combine does not always
> know
> the details), combinations of the insn with later insns are
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #20 from Andreas Krebbel ---
(In reply to Segher Boessenkool from comment #17)
...
> So what is really happening? And, when did this start, anyway, because
> apparently at some point in time all was fine?
Due to the C++ constructs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #19 from Andreas Krebbel ---
(In reply to Sarah Julia Kriesch from comment #15)
> (In reply to Segher Boessenkool from comment #13)
> > (In reply to Sarah Julia Kriesch from comment #12)
> > A bigger case of what? What do you mean?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #14 from Andreas Krebbel ---
If my analysis from comment #1 is correct, combine does superfluous steps here.
Getting rid of this should not cause any harm, but should be beneficial for
other targets as well. I agree that the patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
--- Comment #10 from Andreas Krebbel ---
Created attachment 57599
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57599=edit
Testcase - somewhat reduced from libecpint
Verified with rev 146f16c97f6
cc1plus -O2 t.cc
try_combine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
Andreas Krebbel changed:
What|Removed |Added
CC||stefansf at linux dot ibm.com
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112986
Andreas Krebbel changed:
What|Removed |Added
CC||shinwogud12 at gmail dot com
---
|--- |DUPLICATE
CC||krebbel at gcc dot gnu.org
--- Comment #2 from Andreas Krebbel ---
I can confirm this when running the program with qemu but not on real hardware.
The code is also using the chrl instruction so I guess this is another
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112986
Andreas Krebbel changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112996
Andreas Krebbel changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112986
--- Comment #3 from Andreas Krebbel ---
*** Bug 112996 has been marked as a duplicate of this bug. ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112986
Andreas Krebbel changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
: pch
Assignee: unassigned at gcc dot gnu.org
Reporter: krebbel at gcc dot gnu.org
Target Milestone: ---
touch s.h
touch u.h
main.cpp:
#include "s.h"
#include "u.h"
g++ s.h
g++ -c main.cpp --save-temps
In file included from main.cpp:2:
u.h:1:9: int
Assignee: unassigned at gcc dot gnu.org
Reporter: krebbel at gcc dot gnu.org
Target Milestone: ---
compiler_corruption_function(flags) {
int nowait = flags & 1048576, isexpand = flags & 8388608;
abcd();
_setjmp(flags);
if (nowait && isexpand)
fla
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108199
Andreas Krebbel changed:
What|Removed |Added
Version|13.0|12.2.1
--- Comment #16 from Andreas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108199
Andreas Krebbel changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108199
--- Comment #7 from Andreas Krebbel ---
(In reply to Andrew Pinski from comment #6)
> (In reply to Andreas Krebbel from comment #5)
> > In:
> >
> > _1 = src_6(D)->a;
> > dst$val_9 = _1;
> > _2 = BIT_FIELD_REF ;
> > _3 = _2 & 64;
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108199
--- Comment #5 from Andreas Krebbel ---
In:
_1 = src_6(D)->a;
dst$val_9 = _1;
_2 = BIT_FIELD_REF ;
_3 = _2 & 64;
if (_3 != 0)
src, dst and the BIT_FIELD_REF carry storage order flags which result in either
bswaps being emitted or,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108199
--- Comment #3 from Andreas Krebbel ---
Moving the local definition of dst out of the function to global scope prevents
the store from getting eliminated.
union DST dst;
As expected the store is still in the FRE dump:
_1 = src_6(D)->a;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108199
Andreas Krebbel changed:
What|Removed |Added
Target||x86_64
Build|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108199
--- Comment #1 from Andreas Krebbel ---
Created attachment 54150
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54150=edit
Testcase
-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: krebbel at gcc dot gnu.org
Target Milestone: ---
++
Assignee: unassigned at gcc dot gnu.org
Reporter: krebbel at gcc dot gnu.org
Target Milestone: ---
#include
#include
using namespace std;
int main(int argc, char *argv[]) {
locale oGlobalLocale;
if (!has_facet< num_get > >
>( oGlobalLocale ))
__b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107372
--- Comment #1 from Andreas Krebbel ---
Created attachment 53764
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53764=edit
Experimental Fix
Looks like the error while analyzing the data ref is not propagated to the
upper layers to
: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: krebbel at gcc dot gnu.org
Target Milestone: ---
For t.c with "gcc -O3 t.c":
struct L
{
unsigned int val[256];
} __attribute__((scalar_sto
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101
--- Comment #22 from Andreas Krebbel ---
The longer a have been looking at these STRICT_LOW_PART issue the more I think
that STRICT_LOW_PART is an awful way to express what we need:
- the information needed to understand what it is doing is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101
--- Comment #21 from Andreas Krebbel ---
I have committed a patch now which accepts only SUBREGs before reload and then
also REGs to deal with how LRA operates right now.
I've continued a bit with the patch from Comment 18. It bootstraps on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101
--- Comment #18 from Andreas Krebbel ---
(In reply to Segher Boessenkool from comment #17)
...
> Yes, but that says the high 48 bits of the hardware reg are untouched, which
> is not true (only the high 16 of the low 32 are guaranteed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101
--- Comment #16 from Andreas Krebbel ---
(In reply to Segher Boessenkool from comment #15)
> (In reply to Andreas Krebbel from comment #14)
> > > So you are suggesting that every strict_low_part after reload can just be
> > > removed? If that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101
--- Comment #14 from Andreas Krebbel ---
(In reply to Segher Boessenkool from comment #13)
> (Sorry I missed this)
>
> (In reply to Andreas Krebbel from comment #11)
> > I've tried to change our movstrict backend patterns to use a predicate on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101
--- Comment #11 from Andreas Krebbel ---
I've tried to change our movstrict backend patterns to use a predicate on the
dest operand which enforces a subreg. However, since reload strips the subreg
away when assigning hard regs we end up with a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106101
--- Comment #10 from Andreas Krebbel ---
We generate the movstrict target operand with gen_lowpart. If the operand for
gen_lowpart is already a paradoxical subreg the two subregs cancel each other
out and we end up with a plain reg. I'm testing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105175
--- Comment #2 from Andreas Krebbel ---
I would expect the vectorizer to only generate vector modes which would fit
into word mode if no hardware vector support is available. E.g. for:
struct {
unsigned a, b, c, d;
} s;
foo() {
s.a &= 42;
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: krebbel at gcc dot gnu.org
Target Milestone: ---
For this code snippet extracted from Qemu source:
enum { QEMU_MIGRATION_COOKIE_PERSISTENT = 1 };
struct {
unsigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104327
--- Comment #8 from Andreas Krebbel ---
I will work on a patch. Thanks for the hint!
I agree for HTM. VX is an ABI switch since it changes the calling conventions
for vector types.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104327
--- Comment #5 from Andreas Krebbel ---
Yes, that's the right fix I think. Thanks!
MVCLE is a shorter version of a loop doing MVCs but has some startup overhead.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103364
Andreas Krebbel changed:
What|Removed |Added
Status|WAITING |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104034
Andreas Krebbel changed:
What|Removed |Added
Last reconfirmed||2022-01-14
Ever confirmed|0
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: krebbel at gcc dot gnu.org
Target Milestone: ---
Created attachment 52194
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52194=edit
Testcase
Initial analy
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=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 #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 #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 #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=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=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=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=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.
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
-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=86681
--- Comment #6 from Andreas Krebbel ---
Do you have the command line for the tattr-1.c test? The verbose options line
appears to contain the options for a different test. I could not reproduce the
problem with these options.
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
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=100908
--- Comment #1 from Andreas Krebbel ---
https://gcc.gnu.org/pipermail/gcc/2021-June/236269.html
-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=100281
Andreas Krebbel changed:
What|Removed |Added
Attachment #50685|0 |1
is obsolete|
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.
++
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=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 #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 #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=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
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=98847
Andreas Krebbel changed:
What|Removed |Added
CC||krebbel at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98736
Andreas Krebbel changed:
What|Removed |Added
Keywords||wrong-code
Priority|P3
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=98550
Andreas Krebbel changed:
What|Removed |Added
Status|WAITING |NEW
--- 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=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=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=98221
Andreas Krebbel changed:
What|Removed |Added
Priority|P3 |P2
Keywords|
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=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
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=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=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=96456
Andreas Krebbel changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #5 from Andreas
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=97502
Andreas Krebbel changed:
What|Removed |Added
Last reconfirmed||2020-10-21
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 #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 #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=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
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=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
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.
1 - 100 of 648 matches
Mail list logo
