Re: [PATCH] Add save_expr langhook (PR c/68513)

2015-11-30 Thread Joseph Myers
On Mon, 30 Nov 2015, Marek Polacek wrote: > On Sat, Nov 28, 2015 at 08:50:12AM +0100, Richard Biener wrote: > > Different approach: after the FE folds (unexpectedly?), scan the result for > > SAVE_EXPRs and if found, drop the folding. > > Neither this fixes this problem completely, because we sim

Re: [PATCH] Add save_expr langhook (PR c/68513)

2015-11-30 Thread Richard Biener
On Mon, 30 Nov 2015, Richard Biener wrote: > On Mon, 30 Nov 2015, Marek Polacek wrote: > > > On Sat, Nov 28, 2015 at 08:50:12AM +0100, Richard Biener wrote: > > > Different approach: after the FE folds (unexpectedly?), scan the result > > > for > > > SAVE_EXPRs and if found, drop the folding. >

Re: [PATCH] Add save_expr langhook (PR c/68513)

2015-11-30 Thread Richard Biener
On Mon, 30 Nov 2015, Marek Polacek wrote: > On Sat, Nov 28, 2015 at 08:50:12AM +0100, Richard Biener wrote: > > Different approach: after the FE folds (unexpectedly?), scan the result for > > SAVE_EXPRs and if found, drop the folding. > > Neither this fixes this problem completely, because we sim

Re: [PATCH] Add save_expr langhook (PR c/68513)

2015-11-30 Thread Marek Polacek
On Sat, Nov 28, 2015 at 04:05:30PM +, Joseph Myers wrote: > On Sat, 28 Nov 2015, Richard Biener wrote: > > > Different approach: after the FE folds (unexpectedly?), scan the result > > for SAVE_EXPRs and if found, drop the folding. > > Or, if conversions are going to fold from language-indep

Re: [PATCH] Add save_expr langhook (PR c/68513)

2015-11-30 Thread Marek Polacek
On Sat, Nov 28, 2015 at 08:50:12AM +0100, Richard Biener wrote: > Different approach: after the FE folds (unexpectedly?), scan the result for > SAVE_EXPRs and if found, drop the folding. Neither this fixes this problem completely, because we simply don't know where those SAVE_EXPRs might be introd

Re: [PATCH] Add save_expr langhook (PR c/68513)

2015-11-30 Thread Marek Polacek
On Fri, Nov 27, 2015 at 10:43:42PM +, Joseph Myers wrote: > On Fri, 27 Nov 2015, Marek Polacek wrote: > > > I didn't know where to put setting of in_late_processing. With the current > > placement, we won't (for valid programs) call c_save_expr from c_genericize > > or c_gimplify_expr. > > W

Re: [PATCH] Add save_expr langhook (PR c/68513)

2015-11-28 Thread Joseph Myers
On Sat, 28 Nov 2015, Richard Biener wrote: > Different approach: after the FE folds (unexpectedly?), scan the result > for SAVE_EXPRs and if found, drop the folding. Or, if conversions are going to fold from language-independent code (which is the underlying problem here - a conversion without

Re: [PATCH] Add save_expr langhook (PR c/68513)

2015-11-27 Thread Richard Biener
On November 27, 2015 7:55:43 PM GMT+01:00, Marek Polacek wrote: >As suggested here > >and here , >this patch >adds a new langhook to distinguish whether to call c_save_expr or >save

Re: [PATCH] Add save_expr langhook (PR c/68513)

2015-11-27 Thread Joseph Myers
On Fri, 27 Nov 2015, Marek Polacek wrote: > I didn't know where to put setting of in_late_processing. With the current > placement, we won't (for valid programs) call c_save_expr from c_genericize > or c_gimplify_expr. Well, the placement in this patch (in c_parser_compound_statement) is certai

Re: [PATCH] Add save_expr langhook (PR c/68513)

2015-11-27 Thread Marek Polacek
On Fri, Nov 27, 2015 at 07:55:43PM +0100, Marek Polacek wrote: > +/* The C version of the save_expr langhook. Either call save_expr or > c_save_expr, > + depending on IN_LATE_PROCESSING. */ Consider this too long line fixed. Marek

[PATCH] Add save_expr langhook (PR c/68513)

2015-11-27 Thread Marek Polacek
As suggested here and here , this patch adds a new langhook to distinguish whether to call c_save_expr or save_expr from match.pd. Does this look reasonable? I didn't know where to