On Fri, Jul 8, 2016 at 9:42 AM, Jakub Jelinek wrote:
> On Thu, Jul 07, 2016 at 03:18:13PM -0400, Jason Merrill wrote:
>> How about this? I also have a patch to handle assignment order
>> entirely in the front end, but my impression has been that you wanted
>> to make this change for other reasons
On Thu, Jul 07, 2016 at 03:18:13PM -0400, Jason Merrill wrote:
> How about this? I also have a patch to handle assignment order
> entirely in the front end, but my impression has been that you wanted
> to make this change for other reasons as well.
So what exactly is supposed to be the evaluation
On Thu, Jul 7, 2016 at 9:18 PM, Jason Merrill wrote:
> On Tue, Jun 28, 2016 at 10:00 AM, Richard Biener
> wrote:
>> On Thu, Jun 16, 2016 at 6:15 PM, Jakub Jelinek wrote:
>>> On Thu, Jun 16, 2016 at 11:28:48AM -0400, Jason Merrill wrote:
gimple_predicate
rhs_predicate_for (tree lhs)
>
On Tue, Jun 28, 2016 at 10:00 AM, Richard Biener
wrote:
> On Thu, Jun 16, 2016 at 6:15 PM, Jakub Jelinek wrote:
>> On Thu, Jun 16, 2016 at 11:28:48AM -0400, Jason Merrill wrote:
>>> gimple_predicate
>>> rhs_predicate_for (tree lhs)
>>> {
>>> - if (is_gimple_reg (lhs))
>>> + if (will_be_gimpl
On Thu, Jun 16, 2016 at 6:15 PM, Jakub Jelinek wrote:
> On Thu, Jun 16, 2016 at 11:28:48AM -0400, Jason Merrill wrote:
>> gimple_predicate
>> rhs_predicate_for (tree lhs)
>> {
>> - if (is_gimple_reg (lhs))
>> + if (will_be_gimple_reg (lhs))
>> return is_gimple_reg_rhs_or_call;
>>else
On Thu, Jun 16, 2016 at 06:15:34PM +0200, Jakub Jelinek wrote:
> and then do in gimplify_modify_expr:
> ret = gimplify_expr (from_p, pre_p, post_p,
> is_gimple_reg (*to_p)
^^^ of course even this is a prediction and wrong one for
DECL_HAS_VALUE_EXPR_Ps. Conservative would b
On Thu, Jun 16, 2016 at 11:28:48AM -0400, Jason Merrill wrote:
> gimple_predicate
> rhs_predicate_for (tree lhs)
> {
> - if (is_gimple_reg (lhs))
> + if (will_be_gimple_reg (lhs))
> return is_gimple_reg_rhs_or_call;
>else
> return is_gimple_mem_rhs_or_call;
> @@ -4778,10 +4811,6
On Wed, Jun 15, 2016 at 6:30 AM, Richard Biener
wrote:
> On Tue, Jun 14, 2016 at 10:15 PM, Jason Merrill wrote:
>> As discussed in bug 71104, the C++ P0145 proposal specifies the evaluation
>> order of certain operations:
>>
>> 1. a.b
>> 2. a->b
>> 3. a->*b
>> 4. a(b1, b2, b3)
>> 5. b @= a
>> 6.
On Tue, Jun 14, 2016 at 10:15 PM, Jason Merrill wrote:
> As discussed in bug 71104, the C++ P0145 proposal specifies the evaluation
> order of certain operations:
>
> 1. a.b
> 2. a->b
> 3. a->*b
> 4. a(b1, b2, b3)
> 5. b @= a
> 6. a[b]
> 7. a << b
> 8. a >> b
>
> The second patch introduces a flag
