On 3/5/18 9:33 AM, Segher Boessenkool wrote:
> On Mon, Mar 05, 2018 at 08:01:14AM +0100, Eric Botcazou wrote:
>> Apparently the authors of the SPARC psABI thought that the last part of your
>> sentence is an interpolation and that the (historical) requirements were
>> vague
>> enough to allow
> Maybe we should have a target hook that says setjmp/longjmp are
> implemented by simple function calls (or as-if by function calls), so
> as not to penalize everyone who has an, erm, more conservative ABI?
Yes, that sounds a sensible compromise to me.
--
Eric Botcazou
On Mon, Mar 05, 2018 at 08:01:14AM +0100, Eric Botcazou wrote:
> > C11 says in 7.13.2.1/2
> > "The longjmp function restores the environment saved by the most recent
> > invocation of the setjmp macro in the same invocation of the program with
> > the corresponding jmp_buf argument."
> > where
> Apparently the authors of the SPARC psABI thought that the last part of your
> sentence is an interpolation and that the (historical) requirements were
> vague enough to allow their interpretation, IOW that the compiler can do
> the work.
And, as PR target/83368 showed, both the GNU and the
> C11 says in 7.13.2.1/2
> "The longjmp function restores the environment saved by the most recent
> invocation of the setjmp macro in the same invocation of the program with
> the corresponding jmp_buf argument."
> where "environment" is not really defined, but it includes all information
> a
On 03/04/2018 01:57 AM, Richard Biener wrote:
>
> I think posix says you have to mark such variables volatile. So I
> fully agree with your analysis of why setjmp isn't special for RA. It
> would be only making non-conforming code work by accident.
Note the code we're carrying around has its
On Sun, Mar 04, 2018 at 02:57:38PM +0100, Eric Botcazou wrote:
> > I can't argue with anything in that comment, other than the conclusion. :-)
> > It's not the compiler's job to implement the setjmp/longjmp save/restore.
> > Maybe Kenny was working around a problem with some target's buggy setjmp
On Mär 04 2018, Peter Bergner wrote:
> Clearly returning from the function that calls
> setjmp before calling longjmp must be illegal, since that would result
> in clobbering of the stack frame the longjmp would attempt to restore to.
> I don't know off hand who/what states
On 3/4/18 7:57 AM, Eric Botcazou wrote:
>> I can't argue with anything in that comment, other than the conclusion. :-)
>> It's not the compiler's job to implement the setjmp/longjmp save/restore.
>> Maybe Kenny was working around a problem with some target's buggy setjmp
>> and spilling everything
> I can't argue with anything in that comment, other than the conclusion. :-)
> It's not the compiler's job to implement the setjmp/longjmp save/restore.
> Maybe Kenny was working around a problem with some target's buggy setjmp
> and spilling everything "fixed" it?
What are the requirements
On Mär 04 2018, Richard Biener wrote:
> I think posix says you have to mark such variables volatile.
It's the C standard that does that:
7.13.2.1#3 All accessible objects have values, and all other components
of the abstract machine have state, as of the time the
On March 4, 2018 1:30:39 AM GMT+01:00, Peter Bergner
wrote:
>On 3/3/18 5:47 PM, Peter Bergner wrote:
>> On 3/3/18 10:29 AM, Jeff Law wrote:
>>> Here's the comment from regstat.c:
>>>
>>> /* We have a problem with any pseudoreg that lives
>>>
On 3/3/18 5:47 PM, Peter Bergner wrote:
> On 3/3/18 10:29 AM, Jeff Law wrote:
>> Here's the comment from regstat.c:
>>
>> /* We have a problem with any pseudoreg that lives
>> across the setjmp. ANSI says that if a user variable
>> does not change
On 3/3/18 10:29 AM, Jeff Law wrote:
> Here's the comment from regstat.c:
>
> /* We have a problem with any pseudoreg that lives
> across the setjmp. ANSI says that if a user variable
> does not change in value between the setjmp and the
>
On 03/02/2018 08:28 PM, Peter Bergner wrote:
> On 3/2/18 3:26 PM, Jeff Law wrote:
>> On 03/02/2018 12:45 PM, Peter Bergner wrote:
>>> ...which forces us to spill everything live across the setjmp by forcing
>>> the pseudos to interfere all hardregs. That can't be good for performance.
>>> What am
On 3/2/18 3:26 PM, Jeff Law wrote:
> On 03/02/2018 12:45 PM, Peter Bergner wrote:
>> ...which forces us to spill everything live across the setjmp by forcing
>> the pseudos to interfere all hardregs. That can't be good for performance.
>> What am I missing?
>
> You might want to hold off a bit.
On 03/02/2018 02:45 PM, Peter Bergner wrote:
While debugging the PR84264 ICE caused by the following test case:
void _setjmp ();
void a (unsigned long *);
void
b ()
{
for (;;)
{
_setjmp ();
unsigned long args[9]{};
a (args);
}
}
I
On 03/02/2018 12:45 PM, Peter Bergner wrote:
> While debugging the PR84264 ICE caused by the following test case:
>
> void _setjmp ();
> void a (unsigned long *);
> void
> b ()
> {
> for (;;)
> {
> _setjmp ();
> unsigned long args[9]{};
> a (args);
> }
On Fri, 2 Mar 2018, Peter Bergner wrote:
> But currently ira-lives.c:process_bb_node_lives() has:
>
> /* Don't allocate allocnos that cross setjmps or any
> call, if this function receives a nonlocal
> goto. */
> if (cfun->has_nonlocal_label
> || find_reg_note (insn,
While debugging the PR84264 ICE caused by the following test case:
void _setjmp ();
void a (unsigned long *);
void
b ()
{
for (;;)
{
_setjmp ();
unsigned long args[9]{};
a (args);
}
}
I noticed that IRA is spilling all pseudos that are live
20 matches
Mail list logo