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
> 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
> 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
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
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
>
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
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
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
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 impos
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
===
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 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
13 matches
Mail list logo
