On Wed, Jul 25, 2018 at 8:03 PM Richard Earnshaw (lists) <richard.earns...@arm.com> wrote: > > On 24/07/18 18:26, Richard Biener wrote: > > So, please make resolve_overloaded_builtin return a no-op on such targets > > which means you can remove the above warning. Maybe such targets > > shouldn't advertise / initialize the builtins at all? > > So I tried to make resolve_overloaded_builtin collapse the builtin > entirely if it's not needed by the machine, transforming > > x = __b_s_s_v (y); > > into > > x = y; > > > but I can't see how to make any side-effects on the optional second > argument hang around. It's somewhat obscure, but if the user does write > > x = __b_s_s_v (y, z++); > > then z++ does still need to be performed. > > The problem seems to be that the callers of resolve_overloaded_builtin > expect just a simple value result - they can't, for example, deal with a > statement list and just calling save_expr on the argument isn't enough; > so I can't see an obvious way to force the z++ expression back into the > token stream at this point. > > Any ideas? The alternative seems to be that we must keep the call until > such time as the builtins are lowered during expansion, which pretty > much loses all the benefits you were looking for.
Use a COMPOUND_EXPR: (z++, y). So, if (TREE_SIDE_EFFECTS (2ndarg)) res = build2_loc (loc, COMPOUND_EXPR, type, 2ndarg, 1starg); else res = 2starg; Richard. > > R.
