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
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, ex
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
===
> 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 impos
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
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.1
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 ap
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
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 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 origi
> 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 prog
> 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 Sola
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(...); // return
13 matches
Mail list logo
