https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
Richard Earnshaw changed:
What|Removed |Added
Known to fail|10.0|
--- Comment #21 from Richard Earnsha
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
--- Comment #20 from Richard Earnshaw ---
Author: rearnsha
Date: Fri Aug 9 16:14:59 2019
New Revision: 274238
URL: https://gcc.gnu.org/viewcvs?rev=274238&root=gcc&view=rev
Log:
[aarch64] PR target/91386 Use copy_rtx to avoid modifying original
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
Martin Liška changed:
What|Removed |Added
Known to fail||10.0, 9.1.0
--- Comment #19 from Martin L
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
--- Comment #18 from Martin Liška ---
(In reply to Richard Earnshaw from comment #17)
> Created attachment 46686 [details]
> candidate patch
>
> Could you try this patch please? So far only very lightly tested.
Sure, I'll test the problematic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
--- Comment #17 from Richard Earnshaw ---
Created attachment 46686
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46686&action=edit
candidate patch
Could you try this patch please? So far only very lightly tested.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
Richard Earnshaw changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |rearnsha at gcc dot
gnu.org
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
--- Comment #15 from Richard Earnshaw ---
From looking at the dumps it would appear that one of the STP generating
peepholes might have bailed out, but that some of the changes have not been
undone.
From the pass before, we have:
(insn/f:TI 802
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
--- Comment #14 from Wilco ---
(In reply to Martin Liška from comment #13)
> >
> > The key question is how does one dump rtl with -flto? It doesn't work at
> > all, making debugging this difficult...
>
> It does, look:
>
> marxin@marxinbox:/tm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
--- Comment #13 from Martin Liška ---
>
> The key question is how does one dump rtl with -flto? It doesn't work at
> all, making debugging this difficult...
It does, look:
marxin@marxinbox:/tmp> gcc -c main.c -flto
marxin@marxinbox:/tmp> gcc m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
Wilco changed:
What|Removed |Added
CC||wilco at gcc dot gnu.org
--- Comment #12 from Wi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
--- Comment #11 from Martin Liška ---
And I can also verify that adding -fno-peephole -fno-peephole2 to CFLAGS helps
to resolve the issue.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
--- Comment #10 from Martin Liška ---
I'm attaching all tree and rtl dumps for the problematic LTRANS unit:
https://drive.google.com/file/d/1CW4cWvpm1VVXFIP80XCf1IzYXWwTsynZ/view?usp=sharing
I can confirm what Andreas sees:
(note 8303 8031 7890
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
--- Comment #8 from Richard Biener ---
So if one can reproduce a way for a smaller testcase (likely only for trunk
then) is to -fdump-tree-optimized-gimple and make a GIMPLE FE testcase from
main()
(adding relevant typedefs from the preprocessed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
--- Comment #7 from Martin Liška ---
I'm reducing the LTO files that are needed to expose the problem..
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
--- Comment #6 from Richard Biener ---
So I can't reproduce with a cross easily (w/o a libc I can only
do a partial link). Nevertheless I see some
58: 910e63e6add x6, sp, #0x398
...
90: a90008c2stp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
--- Comment #5 from Richard Earnshaw ---
(In reply to Richard Earnshaw from comment #4)
> R8 is the register used for the address of the return value location when
> the result cannot be stored in registers. Are you sure that this isn't a
> prob
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
--- Comment #4 from Richard Earnshaw ---
R8 is the register used for the address of the return value location when the
result cannot be stored in registers. Are you sure that this isn't a problem
in the caller?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
--- Comment #3 from Andreas Schwab ---
Created attachment 46683
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46683&action=edit
Preprocessed sources with Makefile, part 3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
--- Comment #2 from Andreas Schwab ---
Created attachment 46682
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46682&action=edit
Preprocessed sources with Makefile, part 2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91386
--- Comment #1 from Andreas Schwab ---
Created attachment 46681
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46681&action=edit
Preprocessed sources with Makefile, part 1
21 matches
Mail list logo
