On 06/05/2014 09:35 AM, Richard Biener wrote:
I suppose it's ok to re-order side-effects lhs, rhs to rhs, lhs?
Yes.
Jason
Hi,
On 06/05/2014 03:35 PM, Richard Biener wrote:
On Thu, Jun 5, 2014 at 3:26 PM, Paolo Carlini wrote:
Hi,
On 06/05/2014 03:20 PM, Richard Biener wrote:
I think the operands have to be reversed though - the type matches that of
op0. Sorry ;)
Something like this, then?
Yes. I suppose it's
On Thu, Jun 5, 2014 at 3:26 PM, Paolo Carlini wrote:
> Hi,
>
>
> On 06/05/2014 03:20 PM, Richard Biener wrote:
>>
>> I think the operands have to be reversed though - the type matches that of
>> op0. Sorry ;)
>
> Something like this, then?
Yes. I suppose it's ok to re-order side-effects lhs, rhs
Hi,
On 06/05/2014 03:20 PM, Richard Biener wrote:
I think the operands have to be reversed though - the type matches
that of op0. Sorry ;)
Something like this, then?
Thanks,
Paolo.
///
Index: cp-gimplify.c
===
--- cp-
On Thu, Jun 5, 2014 at 3:12 PM, Paolo Carlini wrote:
> Hi,
>
>
> On 06/05/2014 03:12 PM, Jason Merrill wrote:
>>
>> On 06/05/2014 09:05 AM, Richard Biener wrote:
>>>
>>> + *expr_p = build2 (COMPOUND_EXPR, TREE_TYPE (*expr_p),
>>> + op0, build_fold_addr
Hi,
On 06/05/2014 03:12 PM, Jason Merrill wrote:
On 06/05/2014 09:05 AM, Richard Biener wrote:
+ *expr_p = build2 (COMPOUND_EXPR, TREE_TYPE (*expr_p),
+ op0, build_fold_addr_expr (op1));
That seems like a fine approach.
Thanks a lot guys. Therefor
On 06/05/2014 09:05 AM, Richard Biener wrote:
+ *expr_p = build2 (COMPOUND_EXPR, TREE_TYPE (*expr_p),
+ op0, build_fold_addr_expr (op1));
That seems like a fine approach.
Jason
On Thu, Jun 5, 2014 at 2:59 PM, Paolo Carlini wrote:
> Hi,
>
> in this minor issue, after a permerror about "passing ‘volatile foo’ as
> ‘this’ argument discards qualifiers" we crash with an infinite recursion in
> the gimplifier. The testcase:
>
> struct foo { };
>
> typedef struct
> {
> volatile
