https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #46 from Jakub Jelinek ---
Author: jakub
Date: Thu Feb 21 12:04:26 2019
New Revision: 269067
URL: https://gcc.gnu.org/viewcvs?rev=269067=gcc=rev
Log:
PR bootstrap/88714
* constraints.md (q): Remove.
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #45 from Jakub Jelinek ---
Author: jakub
Date: Mon Feb 18 12:52:36 2019
New Revision: 268985
URL: https://gcc.gnu.org/viewcvs?rev=268985=gcc=rev
Log:
PR bootstrap/88714
* config/arm/arm.md (*arm_movdi,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #44 from Jakub Jelinek ---
Author: jakub
Date: Mon Feb 11 10:39:59 2019
New Revision: 268766
URL: https://gcc.gnu.org/viewcvs?rev=268766=gcc=rev
Log:
PR bootstrap/88714
* config/arm/ldrdstrd.md (*arm_ldrd,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #42 from Matthew Malcomson ---
Author: matmal01
Date: Thu Feb 7 14:54:15 2019
New Revision: 268644
URL: https://gcc.gnu.org/viewcvs?rev=268644=gcc=rev
Log:
[Patch] [arm] Fix 88714, Arm LDRD/STRD peepholes.
These peepholes match a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #41 from Jakub Jelinek ---
Author: jakub
Date: Thu Feb 7 14:27:09 2019
New Revision: 268619
URL: https://gcc.gnu.org/viewcvs?rev=268619=gcc=rev
Log:
Backported from mainline
2019-01-11 Jakub Jelinek
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #39 from Matthew Malcomson ---
(In reply to Jakub Jelinek from comment #38)
> I don't mind if you take over, I don't really have good opportunities to
> test on arm anyway. Though, do you have copyright assignment on file (or
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #38 from Jakub Jelinek ---
I don't mind if you take over, I don't really have good opportunities to test
on arm anyway. Though, do you have copyright assignment on file (or covered by
ARM or Linaro or similar assignments)?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #40 from Jakub Jelinek ---
Oops, sorry, ignore the question, I see you in MAINTAINERS as well as in
several commits.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #37 from Matthew Malcomson ---
Good point (and interesting about the HOST_WIDE_INT_MIN exception -- I didn't
know that).
To avoid duplication of effort would you prefer I make the change or do you
want to handle it?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #36 from Jakub Jelinek ---
Furthermore, nothing really guarantees you it must match,
gen_operands_ldrd_strd doesn't call plus_constant, it calls
mem_ok_for_ldrd_strd on each mem and subtracts the offsets. So, probably a
helper that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #35 from Jakub Jelinek ---
That is a bad idea. plus_constant will create new RTL expressions any time it
is called.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #34 from Matthew Malcomson ---
Yes, I needed to redo that check for an offset of 4 -- I compared the
expression of the first MEM with the result of `plus_constant` with 4 on the
expression of the second MEM in the condition.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #33 from Jakub Jelinek ---
How could you avoid the arm.c changes from my patch if you are using rtx_equal
on the MEM's addr and first operand of PLUS? I believe either that arm.c
change is needed, or the predicate used on the new
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #32 from Matthew Malcomson ---
Created attachment 45584
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45584=edit
Single define_insn version of above patch
FWIW I've attached the patch I'd made.
The only interesting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #31 from Matthew Malcomson ---
(In reply to Jakub Jelinek from comment #30)
> (In reply to Matthew Malcomson from comment #29)
> > I've been working on a patch that does very similar to the draft patch
> > posted
> > above, and I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #30 from Jakub Jelinek ---
(In reply to Matthew Malcomson from comment #29)
> I've been working on a patch that does very similar to the draft patch posted
> above, and I notice a few things I've tried to avoid in it.
> I doubt there
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
Matthew Malcomson changed:
What|Removed |Added
CC||matmal01 at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #28 from Jakub Jelinek ---
#c27 now successfully bootstrapped where it previously failed, regtest still
pending.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #27 from Jakub Jelinek ---
Created attachment 45566
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45566=edit
gcc9-pr88714.patch
Untested full patch, will try to bootstrap it now on armv7hl, no access to
other variants though.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #26 from Jakub Jelinek ---
Created attachment 45455
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45455=edit
gcc9-pr88714.patch
I needed a temporary solution for our distro packages and with this patch
armv7hl passes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #25 from ktkachov at gcc dot gnu.org ---
Thanks, I've reproduced the failure with the reduced testcase (aborts at -O2
but not at -O0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #24 from Jakub Jelinek ---
Created attachment 45438
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45438=edit
gcc9-pr88714-poc.patch
Proof of concept that fixes the short testcase.
One would need to write remaining non-thumb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #23 from Jakub Jelinek ---
On the #c22 testcase this started with r242549, but guess it has been latent
before.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #22 from Jakub Jelinek ---
Self-contained testcase which actually fails because of this bug, even e.g.
when compiled with -O0 and gcc 8.2.1. That doesn't mean this bug shouldn't be
P1, because preventing bootstrap on a primary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #21 from Jakub Jelinek ---
Short testcase -O2 -mtune=cortex-a9 -mfloat-abi=hard -mfpu=vfpv3-d16
-mtls-dialect=gnu -marm -march=armv7-a+fp:
struct S { int a, b, c; int *d; };
void bar (int, int, int, int);
void
foo (struct S *x,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #20 from ktkachov at gcc dot gnu.org ---
Thanks for investigating this.
At an initial glance, I guess this is something gen_operands_ldrd_strd in
config/arm/arm.c should handle
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
Jakub Jelinek changed:
What|Removed |Added
CC||ktkachov at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #18 from Jakub Jelinek ---
So, I've hacked up assembly version which contained 2 versions of this function
(good and bad) plus a wrapper function:
void *
vn_reference_lookup_2b (ao_ref *op, tree vuse, unsigned int cnt, void *vr_);
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #17 from Segher Boessenkool ---
It's not obvious to me what machine code is wrong here. Maybe it is obvious
to someone who is better at Arm code than I am?
Does it all work if you use -fno-if-conversion2 though? Or, what other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #16 from Jakub Jelinek ---
Some more progress.
I've used
--- gcc/combine.c.jj2019-01-10 11:43:17.050333949 +0100
+++ gcc/combine.c 2019-01-15 14:47:28.009094300 +0100
@@ -2319,6 +2319,9 @@ contains_muldiv (rtx x)
}
}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #15 from Jakub Jelinek ---
Ah, except that isn't all that r265398 did. It has both the make_more_copies
part and
|| (HARD_REGISTER_P (dest)
- && ! TEST_HARD_REG_BIT (fixed_reg_set, REGNO (dest))
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #14 from Jakub Jelinek ---
That said, if I compile this with r267800 (cross-compiler, but identical output
to the attached one) and then on the problematic do_rpo_vn function return in
gdb at the start of make_more_copies so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #13 from Jakub Jelinek ---
Created attachment 45428
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45428=edit
tree-ssa-sccvn.s.xz
And resulting (bad) assembly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #12 from Jakub Jelinek ---
Created attachment 45427
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45427=edit
tree-ssa-sccvn.ii.xz
Preprocessed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #11 from Jakub Jelinek ---
If I add __attribute__((optimize (0))) to:
static unsigned
do_rpo_vn (function *fn, edge entry, bitmap exit_bbs,
bool iterate, bool eliminate)
and recompile stage2 tree-ssa-sccvn.o + relink
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #10 from Jakub Jelinek ---
In armv7hl --enable-checking=release profiledbootstrap I see:
checking for strtoull... ../../libdecnumber/decNumber.c: In function 'decLnOp':
../../libdecnumber/decNumber.c:5581:13: error: number of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #9 from Jakub Jelinek ---
Author: jakub
Date: Fri Jan 11 12:05:54 2019
New Revision: 267839
URL: https://gcc.gnu.org/viewcvs?rev=267839=gcc=rev
Log:
PR bootstrap/88714
* passes.c (finish_optimization_passes): Call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #8 from Jakub Jelinek ---
Note, the stage1-gcc compiled tree-ssa-sccvn.o is identical no matter whether
-fno-checking or -fchecking=1 was used, and doesn't fail -fcompare-debug with
either, so it is simply that something is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #6 from Jakub Jelinek ---
The profile_estimate difference is a bug introduced in r191883 and later
extended in r193821 I have a fix for, but it can be ignored, it should have
went into the combine dump instead.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #5 from Mikael Pettersson ---
With -da -fdump-tree-all, stage1 and stage2 output starts to differ in
043t.profile_estimate and then more visibly in 130t.pre:
diff -ru stage1/sort.i.043t.profile_estimate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #4 from Jakub Jelinek ---
Thanks.
So, can you for that sort.i do -da -fdump-tree-all when compiled both with
stage1 and stage2 and see where things start to differ?
Or, try to change either:
STAGE1_TFLAGS += -fno-checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #3 from Mikael Pettersson ---
Created attachment 45384
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45384=edit
pre-processed source for libiberty/sort.c
One of the smallest .o files that differ is from libiberty's sort.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
--- Comment #2 from Segher Boessenkool ---
Or, do we have any machine in the compile farm on which this can be reproduced?
If so, could you give instructions for that please?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
Richard Biener changed:
What|Removed |Added
Keywords||build
Priority|P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88714
Richard Biener changed:
What|Removed |Added
Target Milestone|--- |9.0
48 matches
Mail list logo
