[C PATCH] Preevaluate rhs for lhs op= rhs in C (PR c/58943)

H.J. Lu hjl.tools@gmail.com
Wed Jan 15 13:33:00 GMT 2014


On Mon, Jan 13, 2014 at 11:11 AM, Jakub Jelinek <jakub@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  <jakub@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.



More information about the Gcc-patches mailing list