On 2013-09-18 09:26, Peter Maydell wrote: > On 18 September 2013 08:06, Jan Kiszka <jan.kis...@web.de> wrote: >> On 2013-09-17 23:24, Peter Maydell wrote: >>> On 17 September 2013 18:03, Stefan Weil <s...@weilnetz.de> wrote: >>>> could you please review this patch which removes code added by you earlier? >>>> I have run tests with the old code and assertions to see whether the values >>>> were really smashed. They never were, and from the documentation of setjmp >>>> I'd not expect that they ever might be. >>> >>> We had a discussion about this back in 2011. Any compiler which needs >>> these statements is definitely buggy -- the C standard mandates that >>> they're not needed. >> >> I'm not that sure about this. We have a no-return function involved >> between setjmp and the actual longjmp. Why should the compiler have to >> preserve local variables when entering cpu_loop_exit? > > Because the C standard specification for setjmp and longjmp > says it must (if they are not changed between the setjmp and > the longjmp call; locals which are changed need not be preserved). > I quoted the relevant section from C99 in the discussion I linked.
> And gcc's documentation of the 'noreturn' attribute specifically > says it does not affect the exceptional path where the function > returns via longjmp. OK, that is the clarifying bit of information. Now the question is if want to drop support for faulty compilers again, work around the false-positive warning, or avoid the issue differently than via reloading. Jan
signature.asc
Description: OpenPGP digital signature
