I first found this bug in GCC 4.5.0, but it is repeatable in mainline as of
159067. The attached preprocessed testcase, when compiled using "-O2 -S" will
show the problem.
We have a basic block [bb 3] with the following piece of code.
[32] X(SI) = unspec_volatile (const_int 3)
[33] var_location (some_var) = X
[34] (subreg:SI (reg:DI Z) 0) = X
...
[41] Y(SI) = unspec_volatile (const_int 3)
[42] var_location (some_var) = Y
[43] (subreg:SI (reg:DI Z) 4) = Y
Combine combines 32->34 and 41->43 and converts this into
[33] var_location (some_var) = unspec_volatile (const_int 3)
[34] (subreg:SI (reg:DI Z) 0) = unspec_volatile (const_int 3)
...
[42] var_location (some_var) = unspec_volatile (const_int 3)
[43] (subreg:SI (reg:DI Z) 4) = unspec_volatile (const_int 3
I am not sure if this is a valid transformation in itself. var_location debug
instructions now dont just use registers, but they have unspec_volatile which
is assumed to clobber all register/memory.
The scheduler dependency for this becomes 34->42->43 since the debug_insn in 42
actually clobbers everything. But, when scheduling instructions we ignore the
debug_insn in 42 and hence the dependency is broken. 34 and 43 are both deemed
ready, but 43 gets scheduled first which results in the two unspec_volatile
instructions being reordered.
I am not sure which of the steps above is incorrect. Any pointers on this would
be greatly appreciated.
Please let me know if you need any information.
Thanks
Hari
--
Summary: VTA produces wrong code
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: hariharans at picochip dot com
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: picochip-unknown-none
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44013
