Hi Ramana,
On 11/06/2018 10:57 AM, Ramana Radhakrishnan wrote:
On Tue, Nov 6, 2018 at 10:52 AM Renlin Li <renlin...@foss.arm.com> wrote:
Hi Jeff & Peter,
On 11/05/2018 07:41 PM, Jeff Law wrote:
On 11/5/18 12:36 PM, Peter Bergner wrote:
On 11/5/18 1:20 PM, Jeff Law wrote:
On 11/1/18 4:07 PM, Peter Bergner wrote:
On 11/1/18 1:50 PM, Renlin Li wrote:
Is there any update on this issues?
arm-none-linux-gnueabihf native toolchain has been mis-compiled for a while.
From the analysis I've done, my commit is just exposing latent issues
in LRA. Can you try the patch I submitted here to see if it helps?
https://gcc.gnu.org/ml/gcc-patches/2018-10/msg01757.html
It survives on powerpc64le-linux, x86_64-linux and s390x-linux.
Jeff threw it on his testers and said he saw an arm issue and was
trying to come up with a test case for me to debug.
So I don't think the ARM issues are related to your patch, they may have
been related the combiner changes that went in around the same time.
Yes, there are issues related to the combiner changes.
But didn't the combiner changes come *after* these patches ? So IIUC,
Renlin has been trying to get these fixed *without* the combine
patches but just with your patch applied on top of the revision where
the problem started showing up .
Can you confirm that Renlin ?
I just did a bootstrap again with everything up to r264897 which is Oct 6.
it produce the ICE I mentioned on the PR87899.
The first combiner patch on Oct 22.
Regards,
Renlin
Ramana
But the IRA/LRA change dose cause the arm-none-linux-gnueabihf bootstrap native
toolchain mis-compiled.
And the new patch seems not fix this problem.
I am trying to extract a test case, but it is a little bit hard as the
toolchain itself is mis-compiled.
And it ICEs when compile test case with it.
I created a bugzilla ticket for this, PR87899.
./gcc/cc1 ~/gcc/./gcc/testsuite/gcc.c-torture/execute/pr36034-1.c -O3
test main
Analyzing compilation unit
Performing interprocedural optimizations
<*free_lang_data> <visibility> <build_ssa_passes> <opt_local_passes> <targetclone>
<free-fnsummary> <increase_alignment>Streaming LTO
<whole-program> <profile_estimate> <icf> <devirt> <cp> <fnsummary> <inline> <pure-const>
<free-fnsummary> <static-var> <single-use>
<comdats>Assembling functions:
<materialize-all-clones> testduring GIMPLE pass: ldist
gcc/./gcc/testsuite/gcc.c-torture/execute/pr36034-1.c: In function ‘test’:
gcc/./gcc/testsuite/gcc.c-torture/execute/pr36034-1.c:9:1: internal compiler
error: Segmentation fault
9 | test (void)
| ^~~~
0x5c3a37 crash_signal
../../gcc/gcc/toplev.c:325
0x63ef6b inchash::hash::add(void const*, unsigned int)
../../gcc/gcc/inchash.h:100
0x63ef6b inchash::hash::add_ptr(void const*)
../../gcc/gcc/inchash.h:94
0x63ef6b ddr_hasher::hash(data_dependence_relation const*)
../../gcc/gcc/tree-loop-distribution.c:143
0x63ef6b hash_table<ddr_hasher, xcallocator>::find_slot(data_dependence_relation*
const&, insert_option)
../../gcc/gcc/hash-table.h:414
0x63ef6b get_data_dependence
../../gcc/gcc/tree-loop-distribution.c:1184
0x63f2bd data_dep_in_cycle_p
../../gcc/gcc/tree-loop-distribution.c:1210
0x63f2bd update_type_for_merge
../../gcc/gcc/tree-loop-distribution.c:1255
0x64064b build_rdg_partition_for_vertex
../../gcc/gcc/tree-loop-distribution.c:1302
0x64064b rdg_build_partitions
../../gcc/gcc/tree-loop-distribution.c:1754
0x64064b distribute_loop
../../gcc/gcc/tree-loop-distribution.c:2795
0x642299 execute
../../gcc/gcc/tree-loop-distribution.c:3133
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
Regards
Renlin
At this point your patch appears to be DTRT across the board. The only
fallout is the bogus s390 asm it caught in the kernel.
Cool. I will note that I contacted the s390 kernel guys and gave them a
fix to their broken constraints in that asm and they are going to fix it.
Sounds good. I've got a hack in my tester to "fix" that bogus asm until
the kernel folks do it right.
Is the above an approval to commit the patch mentioned above or do you
still want to wait until the ARM issues are fully resolved?
I think knowing the patch addresses all the known issues related to the
earlier IRA/LRA change unblocks the review step. I don't think we need
to wait for the other ARM issues to be resolved -- they seem to be
unrelated to the IRA/LRA changes.
jeff
