On Fri, May 12, 2017 at 6:09 AM, Marek Polacek wrote:
> On Fri, May 12, 2017 at 09:32:48AM +0200, Richard Biener wrote:
>> On Thu, May 11, 2017 at 3:49 PM, Marek Polacek wrote:
>> > I had an interesting time coming to grips with these two PRs. But it
>> > essentially comes down to the fold call
On Fri, 12 May 2017, Marek Polacek wrote:
> > Otherwise the tree.c change is ok.
>
> Thanks. Jason/Joseph, any comments?
I don't have any comments on this. (c_save_expr folds to avoid
c_fully_fold needing to go inside SAVE_EXPRs.)
--
Joseph S. Myers
jos...@codesourcery.com
On Fri, May 12, 2017 at 12:09 PM, Marek Polacek wrote:
> On Fri, May 12, 2017 at 09:32:48AM +0200, Richard Biener wrote:
>> On Thu, May 11, 2017 at 3:49 PM, Marek Polacek wrote:
>> > I had an interesting time coming to grips with these two PRs. But it
>> > essentially comes down to the fold call
On Fri, May 12, 2017 at 09:32:48AM +0200, Richard Biener wrote:
> On Thu, May 11, 2017 at 3:49 PM, Marek Polacek wrote:
> > I had an interesting time coming to grips with these two PRs. But it
> > essentially comes down to the fold call in save_expr. With that, we can
> > call
> > fold() on an
On Thu, May 11, 2017 at 3:49 PM, Marek Polacek wrote:
> I had an interesting time coming to grips with these two PRs. But it
> essentially comes down to the fold call in save_expr. With that, we can call
> fold() on an expression whose operands weren't folded yet, but that is what
> code in fold
I had an interesting time coming to grips with these two PRs. But it
essentially comes down to the fold call in save_expr. With that, we can call
fold() on an expression whose operands weren't folded yet, but that is what
code in fold_binary_loc assumes. Since fold() is not recursive, we could e
