On Thu, Oct 16, 2014 at 11:03 AM, Marc Glisse wrote:
> On Thu, 16 Oct 2014, Richard Biener wrote:
>
>> Does this fix PR63537?
>
>
> PR63537 is already fine for me with trunk, NRV replaces ret with retval
> everywhere. It does so even if I add f(&ret); in the function with void
> f(vec*);
>
>>> I'd
On Thu, 16 Oct 2014, Richard Biener wrote:
Does this fix PR63537?
PR63537 is already fine for me with trunk, NRV replaces ret with retval
everywhere. It does so even if I add f(&ret); in the function with void
f(vec*);
I'd worry if both result and found are address taken before the pass,
On Thu, Oct 16, 2014 at 9:31 AM, Jakub Jelinek wrote:
> On Thu, Oct 16, 2014 at 07:37:18AM +0200, Marc Glisse wrote:
>> Hello,
>>
>> the attached one-liner passed bootstrap+testsuite (really all languages) on
>> x86_64-linux-gnu (I got an extra pass of unix/-m32: os but I assume that the
>> failur
On Thu, Oct 16, 2014 at 07:37:18AM +0200, Marc Glisse wrote:
> Hello,
>
> the attached one-liner passed bootstrap+testsuite (really all languages) on
> x86_64-linux-gnu (I got an extra pass of unix/-m32: os but I assume that the
> failure with trunk was random).
>
> The current code is a bit weir
Hello,
the attached one-liner passed bootstrap+testsuite (really all languages)
on x86_64-linux-gnu (I got an extra pass of unix/-m32: os but I assume
that the failure with trunk was random).
The current code is a bit weird: we bail out if either result or found is
TREE_ADDRESSABLE, but then
