On Mon, Jan 13, 2014 at 11:11 AM, Jakub Jelinek <ja...@redhat.com> wrote: > Hi! > > This patch fixes the following testcase by preevaluating rhs if it has > (can have) side-effects in lhs op= rhs expressions. Bootstrapped/regtested > on x86_64-linux and i686-linux, ok for trunk? > C++ already does a similar thing (though in that case with TARGET_EXPRs). > > Note1: had to tweak ssa-fre-33.c testcase a little bit (but it still fails > without the fix which went together with it and succeeds with the fix > and from that point onwards), because before fre1 there isn't enough forward > propagation that would make it constant (the addition result becomes > constant during fre1). > > Note2: c-c++-common/cilk-plus/AN/rank_mismatch2.c ICEs now, supposedly > array notation handling doesn't handle SAVE_EXPRs properly, Balaji, do you > think you can debug it and fix up afterwards? > > 2014-01-13 Jakub Jelinek <ja...@redhat.com> > > PR c/58943 > * c-typeck.c (build_modify_expr): For lhs op= rhs, if rhs has side > effects, preevaluate rhs using SAVE_EXPR first. > > * c-omp.c (c_finish_omp_atomic): Set in_late_binary_op around > build_modify_expr with non-NOP_EXPR opcode. Handle return from it > being COMPOUND_EXPR. > (c_finish_omp_for): Handle incr being COMPOUND_EXPR with first > operand a SAVE_EXPR and second MODIFY_EXPR. >
This caused: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59825 -- H.J.
