https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115420
Andreas Krebbel changed:
What|Removed |Added
Resolution|FIXED |INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115420
Andreas Krebbel changed:
What|Removed |Added
Status|RESOLVED|CLOSED
Resolution|INVALID
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115420
Bug ID: 115420
Summary: Default constructor of unordered_map deleted
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
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 builti
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 ne
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 whe
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 alias
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 : 20
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&action=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 201
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 tr
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 I'
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&action=edit
Testcase - somewhat reduced from libecpint
Verified with rev 146f16c97f6
cc1plus -O2 t.cc
try_combine inv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
Andreas Krebbel changed:
What|Removed |Added
CC||stefansf at linux dot ibm.com
--- Com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112986
Andreas Krebbel changed:
What|Removed |Added
CC||shinwogud12 at gmail dot com
--- Comm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112665
Andreas Krebbel changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112319
Bug ID: 112319
Summary: segfault with pch and #pragma GCC diagnostic
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: pch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111039
Bug ID: 111039
Summary: Unable to coalesce ssa_names
Product: gcc
Version: 14.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
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 K
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;
> > i
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, in
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;
ds
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&action=edit
Testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108199
Bug ID: 108199
Summary: Bitfields and storage_order_attribute
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107632
Bug ID: 107632
Summary: has_facet does not work with -mlong-double-64
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c+
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&action=edit
Experimental Fix
Looks like the error while analyzing the data ref is not propagated to the
upper layers to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107372
Bug ID: 107372
Summary: Loop distribution create memcpy between structs with
different storage order
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: n
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 dis
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 s39
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 unmodified
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 i
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 S
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;
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105175
Bug ID: 105175
Summary: [12 Regression] Pointless warning about missed vector
optimization
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104034
Bug ID: 104034
Summary: Miscompilation of LLVM on s390x with -march=z13
-mtune=z14 in GCC 8.x
Product: gcc
Version: 8.5.0
Status: UNCONFIRMED
Severity: normal
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 openSUSE:Factory:zSystems/pos
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.
Why
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://
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 (b
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 g
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. Howev
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&action=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 try_combin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101523
Bug ID: 101523
Summary: Huge number of combine attempts
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
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&action=edit
Experimental Fix
With this patch the address is copied to a pseudo first. That way the register
allocator wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101426
Bug ID: 101426
Summary: Wrong code redirecting IPA thunk parms to tail-call
Product: gcc
Version: 10.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compo
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100908
Bug ID: 100908
Summary: asan clobberes register asm variables
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100281
Bug ID: 100281
Summary: ICE with SImode pointer assignment in C++
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
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&action=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&action=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&action=edit
RTL GCSE dump with -fgcse-sm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98973
Bug ID: 98973
Summary: [11 regression] Wrong code with gcse store motion pass
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Compon
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98847
Andreas Krebbel changed:
What|Removed |Added
CC||krebbel at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98736
Andreas Krebbel changed:
What|Removed |Added
Keywords||wrong-code
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98736
Bug ID: 98736
Summary: Wrong partition order generated in loop distribution
pass
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Prior
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98550
Andreas Krebbel changed:
What|Removed |Added
Status|WAITING |NEW
--- Comment #5 from Andreas Krebbe
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 bu
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&action=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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98269
Andreas Krebbel changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98221
Bug ID: 98221
Summary: [11 regression] Wrong unpack operation emitted in
tree-ssa-forwprop.c
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: major
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 i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98124
Andreas Krebbel changed:
What|Removed |Added
CC||krebbel at gcc dot gnu.org
Res
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 Kre
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 Kre
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
Status|UNCONFIR
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 t
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&action=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&action=edit
Proposed fix
With the patch only regs are considered which aren't "fixed" assuming that for
fixed_regs the ba
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97497
Bug ID: 97497
Summary: gcse wrong code generation with partial register
clobbers
Product: gcc
Version: 11.0
Status: UNCONFIRMED
Severity: normal
Prior
1 - 100 of 102 matches
Mail list logo
