On Fri, Aug 09, 2019 at 04:19:38PM +0100, Richard Sandiford wrote:
> > Can't we have a CLOBBER also for the RESULT_DECL var in some cases and
> > on some paths and thus shouldn't we track the RESULT_DECL in
> > compute_live_vars/live_vars_at_stmt
> > in addition to the local vars (sure, tree-ssa-li
Jakub Jelinek writes:
> On Fri, Aug 09, 2019 at 11:28:32AM +0200, Richard Biener wrote:
>> > Tested on aarch64-linux-gnu and x86_64-linux-gnu. OK to install?
>>
>> OK.
>
> Can't we have a CLOBBER also for the RESULT_DECL var in some cases and
> on some paths and thus shouldn't we track the RESUL
On Fri, Aug 09, 2019 at 11:28:32AM +0200, Richard Biener wrote:
> > Tested on aarch64-linux-gnu and x86_64-linux-gnu. OK to install?
>
> OK.
Can't we have a CLOBBER also for the RESULT_DECL var in some cases and
on some paths and thus shouldn't we track the RESULT_DECL in
compute_live_vars/live_
On Fri, Aug 9, 2019 at 10:33 AM Richard Sandiford
wrote:
>
> In this PR we have two return paths from a function "map". The common
> code sets to the value returned by one path, while the other
> path does:
>
> = map (&, ...);
>
> We treated this call as tail recursion, losing the copy seman
In this PR we have two return paths from a function "map". The common
code sets to the value returned by one path, while the other
path does:
= map (&, ...);
We treated this call as tail recursion, losing the copy semantics
on the value returned by the recursive call.
We'd correctly reject
