https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67181
Bug ID: 67181 Summary: wrong dependence may cause runtime bug on some target with vliw Product: gcc Version: 4.9.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: regression Assignee: unassigned at gcc dot gnu.org Reporter: zhongyunde at huawei dot com Target Milestone: --- as we known , some target with vliw, then some insns can be issued at the same cycle. in file sched-deps.c, the following code are add for improve the speed of compile. But it may bring wrong dependence. /* Pending lists can't get larger with a readonly context. */ if (!deps->readonly && ((deps->pending_read_list_length + deps->pending_write_list_length) > MAX_PENDING_LIST_LENGTH)) { /* Flush all pending reads and writes to prevent the pending lists from getting any larger. Insn scheduling runs too slowly when these lists get long. When compiling GCC with itself, this flush occurs 8 times for sparc, and 10 times for m88k using the default value of 32. */ flush_pending_lists (deps, insn, false, true); } else .... + when entry the above trunk, true-deps are mistaken for anti-deps. + for example: + + store a3, mem1 (suppose we flush pending_write_insns here) + load a4, mem1 + + here, store is pushed into last_pending_memory_flush when pending_read_insns + and pending_write_insns are flushed. The sequential load is reckoned as + anti-dependent rather than true-dependent on the previous store. + + In general, the vliw {store a3,mem1; load a3, mem1} may be recognized as read first , then write, i.e., it executed similar to anti-dependent. In this case, the true-dependent reckoned as anti-dependent will bring runtime error.