[Bug target/9539] [Windows] builtin [long/set]jmp not working properly with signals

["ktietz at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9539

Kai Tietz <ktietz at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |ktietz at gcc dot gnu.org
         Resolution|                            |FIXED

--- Comment #9 from Kai Tietz <ktietz at gcc dot gnu.org> 2011-12-17 15:59:11 UTC ---
So, I took a closer look about this testcase.  Well, as observed test-case
doesn't fail for -O0. I doens't fails for higher optimizations, too, but for
them the exception simply won't be raised.  That's caused by read-access of a
address where result is never used.  This kind of statement simply gets
optimized away by optimization passes.  By modifying this test to write here
instead to the volatile address 0, the test has expected behavior, even for
optimized version.
  Beside that the calling-convention of the SEH-handler is wrong.  It has to be
WINAPI for 32-bit (and also for 64-bit, but here stdcall is actual no special
calling-convention and therefore doesn't produce additional failures).

So I close this bug, as it is obviously fixed for already some time AFAICS.