Re: Why does IRA force all pseudos live across a setjmp call to be spilled?

[Richard Biener]

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
>>>  across the setjmp.  ANSI says that if a user
>variable
>>>  does not change in value between the setjmp and the
>>>  longjmp, then the longjmp preserves it.  This
>>>  includes longjmp from a place where the pseudo
>>>  appears dead.  (In principle, the value still
>exists
>>>  if it is in scope.)  If the pseudo goes in a hard
>>>  reg, some other value may occupy that hard reg
>where
>>>  this pseudo is dead, thus clobbering the pseudo.
>>>  Conclusion: such a pseudo must not go in a hard
>>>  reg.  */
>> 
>> 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?
>
>The only observable difference I can see between a variable that has
>been
>spilled to memory versus one that is assigned to a non-volatile hard
>reg
>is if it is modified between the setjmp and the longjmp.  In the case
>where the variable is spilled to memory, the "new" updated value is the
>value you _may_ see on the return from setjmp (the return caused by the
>call to longjmp), whereas if it is assigned to a non-volatile register,
>then you _will_ see the "old" value that was saved by the setjmp call.
>I say _may_ see above, because there are cases were we might not store
>the "new" updated value to memory, even if we've spilled the pseudo.
>Examples would be spill code optimization, or the variable has been
>broken into separate live ranges/pseudos. etc. etc.  I guess I can even
>think of cases where we could see both "old" and "new" values of a
>variable.  Think of a variable that has been spilled/split like below:
>
>  a =  [start of live range, a assigned to non-volatile reg]
>spill store a
>...
>setjmp()
>...
>1)  ... = ... a ... [end of live range]
>... [a not assigned to a reg in this region]
>spill load a[start of live range]
>2)  ... = ... a ... [end of live range]
>...
>if (...)
>   a =   [start of live range]
>3) spill store a[end of live range]
>... [a not assigned to a reg in this region]
>longjmp()
>
>
>On return from setjmp (the return caused by the call to longjmp),
>the use of "a" at "1)" will use the non-volatile hard register
>that was saved by the initial call to setjmp, so it will see the
>"old" value of "a".  However, since the use of "a" at "2)" loads
>the value from memory, it will use the "new" value stored by
>the spill load at "3)"!
>
>That said, the comment above only talks about variables that do not
>change between the setjmp and the longjmp and in that case, you will
>see the same "old" value (which is the only value, since it wasn't
>modified) regardless of whether it was spilled or not.
>
>What does ANSI (or any spec) say about what should happen to variables
>that are modified between the setjmp and longjmp calls?  Maybe all bets
>are off, given the example above, since even spilling a variable live
>across a setjmp can still lead to strange behavior unless you don't
>allow spill/split optimization and I don't think we'd want that at all.

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. 

Richard. 


>Peter

Re: Why does IRA force all pseudos live across a setjmp call to be spilled?

[Andreas Schwab]

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 longjmp function
was called, except that the values of objects of automatic storage
duration that are local to the function containing the invocation of the
corresponding setjmp macro that do not have volatile-qualified type and
have been changed between the setjmp invocation and longjmp call are
indeterminate.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

[wwwdocs] PATCH for Re: Create a new mirror

[Gerald Pfeifer]

On Wed, 28 Feb 2018, KoDDoS Mirror wrote:
> We added missing cronjob to update it. It should be updated in 
> less than 6 hours.

Yep, it did.  I just applied the patch below.

Thank you for mirroring and letting us know!

Gerald


Index: mirrors.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/mirrors.html,v
retrieving revision 1.246
diff -u -r1.246 mirrors.html
--- mirrors.html22 Oct 2017 11:46:12 -  1.246
+++ mirrors.html4 Mar 2018 09:52:45 -
@@ -40,6 +40,10 @@
   ftp://nl.mirror.babylon.network/gcc/";>ftp://nl.mirror.babylon.network/gcc/
 |
   rsync://nl.mirror.babylon.network/gcc/,
   thanks to Tim Semeijn (noc@babylon.network) at Babylon Network.
+The Netherlands, Dronten:
+  http://mirror.koddos.net/gcc/";>http://mirror.koddos.net/gcc/ |
+  rsync://mirror.koddos.net/gcc/,
+  thanks to Martin (mir...@koddos.net) at KoDDoS.
 The Netherlands, Nijmegen: ftp://ftp.nluug.nl/mirror/languages/gcc";>ftp.nluug.nl, thanks to Jan 
Cristiaan van Winkel (jc at ATComputing.nl)
 Russia, Novosibirsk: http://mirror.linux-ia64.org/gnu/gcc/";>http://mirror.linux-ia64.org/gnu/gcc/,
 thanks to Daniel Volchixin 
 Slovakia, Bratislava: http://gcc.fyxm.net/";>gcc.fyxm.net, 
thanks to Jan Teluch (admin at 2600.sk)

Re: Why does IRA force all pseudos live across a setjmp call to be spilled?

[Eric Botcazou]

> 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 imposed on setjmp exactly and by whom?  The psABI on 
SPARC (the SCD) has an explicit note saying that setjmp/sigsetjmp/vfork don't 
(have to) preserve the usual non-volatile registers.

-- 
Eric Botcazou

Re: Why does IRA force all pseudos live across a setjmp call to be spilled?

[Peter Bergner]

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 "fixed" it?
> 
> What are the requirements imposed on setjmp exactly and by whom?  The psABI 
> on 
> SPARC (the SCD) has an explicit note saying that setjmp/sigsetjmp/vfork don't 
> (have to) preserve the usual non-volatile registers.

I'm not a language lawyer and I don't play one on TV either, but I believe
the requirements come from multiple sources.  You've pointed out your ABI
and Andreas pointed out the C standard also places requirements:

https://gcc.gnu.org/ml/gcc/2018-03/msg00030.html

I wouldn't be surprised if there are more specs/standards that place
restrictions too.  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 that restriction.

Peter

Re: Why does IRA force all pseudos live across a setjmp call to be spilled?

[Andreas Schwab]

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 that restriction.

7.13.2.1#2 ... if the function containing the invocation of the setjmp
macro has terminated execution in the interim, ... the behavior is
undefined.

Andreas.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Interested to contribute in gsoc project

[shreya pohekar]

Hello ,
I am Shreya Pohekar, 2nd year student of University Institute of Technology 
,RGPV ,Bhopal, India. I am interested in applying in GSoC 2018, and would like 
to contribute to the project : Parallelize the compilation using threads.

I am working with c/c++ for a long time and would be an appropriate candidate 
for this project. I have worked a bit on GCC as well , when I was learning ARM 
exploitation.

Can you guide me from where to get started? Or anything additional that I need 
to study.

Thanks

Regards,
Shreya 
Sent from Mail for Windows 10

gcc-8-20180304 is now available

[gccadmin]

Snapshot gcc-8-20180304 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/8-20180304/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk revision 258235

You'll find:

 gcc-8-20180304.tar.xzComplete GCC

  SHA256=b58da867d558bf83fd0c910d74ce471fc1a8417bffb4b7957c1bc8d660956e74
  SHA1=5f1ede092b90b7b3ad011b57311180d9f16fda22

Diffs from 8-20180225 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-8
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: Why does IRA force all pseudos live across a setjmp call to be spilled?

[Segher Boessenkool]

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
> > and spilling everything "fixed" it?
> 
> What are the requirements imposed on setjmp exactly and by whom?  The psABI 
> on 
> SPARC (the SCD) has an explicit note saying that setjmp/sigsetjmp/vfork don't 
> (have to) preserve the usual non-volatile registers.

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 program will need to return to its caller (so it has to restore the
non-volatile registers, set stack pointers correctly, that kind of thing).

But there is 7.13.2.1/3 as well:
"All accessible objects have values, and all other components of the
abstract machine have state, as of the time the longjmp function was
called, except that the values of objects of automatic storage duration
that are local to the function containing the invocation of the
corresponding setjmp macro that do not have volatile-qualified type and
have been changed between the setjmp invocation and longjmp call are
indeterminate."

So, an auto var that is *not* changed between setjmp and longjmp has
to keep its value.  If the auto var lives in memory that works out fine;
if it lives in a non-volatile reg and setjmp saves those, that works as
well; but if it lives in a *volatile* register it does not (because it
might be moved to some other reg for example; in the abstract machine
that did not change anything, but in the real machine it does).

If setjmp clobbers everything a function call does, this still works
fine as far as I see.  And GCC gives warnings if not (not that that
makes things compliant).


Segher

Re: Why does IRA force all pseudos live across a setjmp call to be spilled?

[Jeff Law]

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 origins prior to the
introduction of volatile into the C standard.  It may be the case that
we can and should rethink all this behavior in a modern world where
setjmp/longjmp semantics are better refined and programmers are expected
to use volatile to indicate the behavior they want.

I'm not sure I'd want to do that during stage4 though.  Seems like a
gcc-9 kind of thing.

jeff

Re: Why does IRA force all pseudos live across a setjmp call to be spilled?

[Eric Botcazou]

> 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 program will need to return to its caller (so it has to restore the
> non-volatile registers, set stack pointers correctly, that kind of thing).

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.

-- 
Eric Botcazou

Re: Why does IRA force all pseudos live across a setjmp call to be spilled?

[Eric Botcazou]

> 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 Solaris libc make use of 
the leeway given by the psABI for setjmp at least in some cases.

-- 
Eric Botcazou

C++ - compilation error for all implicit conversion

[Satya Prakash Prasad]

Is there a compiler flag that logs warning / error in case of any implicit
conversions - like int32_t to uint32_t.

#include 
#include 

using ::std::int32_t;
using ::std::uint32_t;

int main(int argc, char *argv[])
{
   int32_t x = 9;
uint32_t i = x;
   uint32_t i1 = socketread(...); // returns  int32_t  -1 on error and >0
on success
std::cout << " " << x << " " << i << std::flush << std::endl;
return 0;
}
c++ -std=c++11 -Wall -Wconversion -Wpedantic cast.cpp

I get no issues / warning / error during compilation - is there a way it
can achieved.