On Thu, Feb 9, 2012 at 11:53 AM, Richard Guenther <richard.guent...@gmail.com> wrote: > On Thu, Feb 9, 2012 at 11:29 AM, Richard Guenther > <richard.guent...@gmail.com> wrote: >> On Wed, Feb 8, 2012 at 10:25 PM, Kai Tietz <ktiet...@googlemail.com> wrote: >>> 2012/1/11 Richard Guenther <richard.guent...@gmail.com>: >>>> >>>> count despite being declared volatile and only loaded once in the source >>>> is loaded twice in gimple. If it were a HW register which destroys the >>>> device after the 2nd load without an intervening store you'd wrecked >>>> the device ;) >>>> >>>> Richard. >>> >>> Thanks for explaination. I tried to flip order for lhs/rhs in >>> gimplify_modify_expr & co. Issue here is that for some cases we are >>> relying here on lhs for gimplifying rhs (is_gimple_reg_rhs_or_call vs >>> is_gimple_mem_rhs_or_call) and this doesn't work for cases in C++ >>> like: >>> >>> typedef const unsigned char _Jv_Utf8Const; >>> typedef __SIZE_TYPE__ uaddr; >>> >>> void maybe_adjust_signature (_Jv_Utf8Const *&s, uaddr &special) >>> { >>> union { >>> _Jv_Utf8Const *signature; >>> uaddr signature_bits; >>> }; >>> signature = s; >>> special = signature_bits & 1; >>> signature_bits -= special; >>> s = signature; >>> } >>> >>> So I modified gimplify_self_mod_expr for post-inc/dec so that we use >>> following sequence >>> and add it to pre_p for it: >>> >>> tmp = lhs; >>> lvalue = tmp (+/-) rhs >>> *expr_p = tmp; >> >> As I explained this is the wrong place to fix the PR. The issue is not >> about self-modifying expressions but about evaluating call argument >> side-effects before side-effects of the lhs. > > I am testing the attached instead.
Doesn't work. Btw, Kai, your patch surely breaks things if you put the lvalue update into the pre queue. Consider a simple a[i++] = i; you gimplify that to i.0 = i; D.1709 = i.0; i = D.1709 + 1; a[D.1709] = i; which is wrong. Seems we are lacking some basic pre-/post-modify testcases ... Richard.