On Wed, Jul 18, 2012 at 7:46 PM, Steven Bosscher wrote:
> Hello,
>
> This is my proposed fix for PR53948. We don't want to put user
> variables in callee-clobbered registers, but obviously function
> arguments are OK there. REG_USERVAR_P is set on PARM_DECLs and on user
> variables, so it can't be
On Wed, Jul 18, 2012 at 08:55:17PM +0200, Jan Kratochvil wrote:
> On Wed, 18 Jul 2012 20:05:46 +0200, Steven Bosscher wrote:
> > I wouldn't know what to test for. Looking for a .loc marker seems a bit
> > fragile.
>
> What is fragile on
> // { dg-final { scan-assembler-times "\\.loc\t1 3 0\\r\\n\
On Wed, 18 Jul 2012 20:05:46 +0200, Steven Bosscher wrote:
> I wouldn't know what to test for. Looking for a .loc marker seems a bit
> fragile.
What is fragile on
// { dg-final { scan-assembler-times "\\.loc\t1 3 0\\r\\n\t\[^.\]" 6 } }
or something like that. Line numbers are constant for the t
On Wed, Jul 18, 2012 at 7:55 PM, Jan Kratochvil
wrote:
> Hello Steven,
>
> On Wed, 18 Jul 2012 19:46:16 +0200, Steven Bosscher wrote:
>> This is my proposed fix for PR53948.
>
> I can't speak for the GCC code but could it have a GCC testcase?
I wouldn't know what to test for. Looking for a .loc m
Hello Steven,
On Wed, 18 Jul 2012 19:46:16 +0200, Steven Bosscher wrote:
> This is my proposed fix for PR53948.
I can't speak for the GCC code but could it have a GCC testcase?
Thanks,
Jan
Hello,
This is my proposed fix for PR53948. We don't want to put user
variables in callee-clobbered registers, but obviously function
arguments are OK there. REG_USERVAR_P is set on PARM_DECLs and on user
variables, so it can't be used to distinguish between the two.
As it turns out, I can hi-jac
