On 01/04/2018 08:35 AM, Sudakshina Das wrote: > Hi > > The bug reported a particular test di-longlong64-sync-1.c failing when > run on arm-linux-gnueabi with options -mthumb -march=armv5t -O[g,1,2,3] > and -mthumb -march=armv6 -O[g,1,2,3]. > > According to what I could see, the crash was caused because of the > explicit VOIDmode argument that was sent to emit_store_flag_force (). > Since the comparing argument was a long long, it was being forced into a > VOID type register before the comparison (in prepare_cmp_insn()) is done. > > As pointed out by Kyrill, there is a comment on emit_store_flag() which > says "MODE is the mode to use for OP0 and OP1 should they be CONST_INTs. > If it is VOIDmode, they cannot both be CONST_INT". This condition is > not true in this case and thus I think it is suitable to change the > argument. > > Testing done: Checked for regressions on bootstrapped > arm-none-linux-gnueabi and arm-none-linux-gnueabihf and added new test > cases. > > Sudi > > ChangeLog entries: > > *** gcc/ChangeLog *** > > 2017-01-04 Sudakshina Das <sudi....@arm.com> > > PR target/82096 > * optabs.c (expand_atomic_compare_and_swap): Change argument > to emit_store_flag_force. > > *** gcc/testsuite/ChangeLog *** > > 2017-01-04 Sudakshina Das <sudi....@arm.com> > > PR target/82096 > * gcc.c-torture/compile/pr82096-1.c: New test. > * gcc.c-torture/compile/pr82096-2.c: Likwise. In the case where both (op0/op1) to emit_store_flag/emit_store_flag_force are constants, don't we know the result of the comparison and shouldn't we have optimized the store flag to something simpler?
I feel like I must be missing something here. Jeff >
