public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug target/9539] [Windows] builtin [long/set]jmp not working properly with signals
       [not found] <bug-9539-5367@http.gcc.gnu.org/bugzilla/>
@ 2006-09-20  8:05 ` fxcoudert at gcc dot gnu dot org
  2006-09-20  9:52 ` dannysmith at users dot sourceforge dot net
                   ` (2 subsequent siblings)
  3 siblings, 0 replies; 6+ messages in thread
From: fxcoudert at gcc dot gnu dot org @ 2006-09-20  8:05 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #6 from fxcoudert at gcc dot gnu dot org  2006-09-20 08:05 -------
I think this is fixed on 4.2:

$ gcc a.c
a.c:16:1: warning: "setjmp" redefined
In file included from a.c:7:
c:/MinGW/bin/../lib/gcc/mingw32/3.4.5/../../../../include/setjmp.h:41:1:
warning: this is the location of the previous definition
a.c: In function `main':
a.c:56: warning: passing arg 1 of `SetUnhandledExceptionFilter' from
incompatible pointer type

$ ./a.exe 
Install error handler
let's go
Error Handler
let's go


Can we close this bug?


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fxcoudert at gcc dot gnu dot
                   |                            |org
             Status|NEW                         |WAITING


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


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug target/9539] [Windows] builtin [long/set]jmp not working properly with signals
       [not found] <bug-9539-5367@http.gcc.gnu.org/bugzilla/>
  2006-09-20  8:05 ` [Bug target/9539] [Windows] builtin [long/set]jmp not working properly with signals fxcoudert at gcc dot gnu dot org
@ 2006-09-20  9:52 ` dannysmith at users dot sourceforge dot net
  2006-09-22 16:21 ` pascal dot obry at wanadoo dot fr
  2006-12-22  9:20 ` pinskia at gcc dot gnu dot org
  3 siblings, 0 replies; 6+ messages in thread
From: dannysmith at users dot sourceforge dot net @ 2006-09-20  9:52 UTC (permalink / raw)
  To: gcc-bugs



------- Comment #7 from dannysmith at users dot sourceforge dot net  2006-09-20 09:52 -------
(In reply to comment #6)
> I think this is fixed on 4.2:

Its still broken on my machine 
Try after compiling the testcase with optimization turned on.

Danny 


-- 


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


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug target/9539] [Windows] builtin [long/set]jmp not working properly with signals
       [not found] <bug-9539-5367@http.gcc.gnu.org/bugzilla/>
  2006-09-20  8:05 ` [Bug target/9539] [Windows] builtin [long/set]jmp not working properly with signals fxcoudert at gcc dot gnu dot org
  2006-09-20  9:52 ` dannysmith at users dot sourceforge dot net
@ 2006-09-22 16:21 ` pascal dot obry at wanadoo dot fr
  2006-12-22  9:20 ` pinskia at gcc dot gnu dot org
  3 siblings, 0 replies; 6+ messages in thread
From: pascal dot obry at wanadoo dot fr @ 2006-09-22 16:21 UTC (permalink / raw)
  To: gcc-bugs

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 627 bytes --]



------- Comment #8 from pascal dot obry at wanadoo dot fr  2006-09-22 16:21 -------
Subject: Re:  [Windows] builtin [long/set]jmp not working
 properly with signals

dannysmith at users dot sourceforge dot net a écrit :
> ------- Comment #7 from dannysmith at users dot sourceforge dot net  2006-09-20 09:52 -------
> (In reply to comment #6)
>> I think this is fixed on 4.2:
> 
> Its still broken on my machine 
> Try after compiling the testcase with optimization turned on.

Thanks Danny for the testing, I'm not myself setup to build 4.2 at the
moment.

Pascal.


-- 


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


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug target/9539] [Windows] builtin [long/set]jmp not working properly with signals
       [not found] <bug-9539-5367@http.gcc.gnu.org/bugzilla/>
                   ` (2 preceding siblings ...)
  2006-09-22 16:21 ` pascal dot obry at wanadoo dot fr
@ 2006-12-22  9:20 ` pinskia at gcc dot gnu dot org
  3 siblings, 0 replies; 6+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2006-12-22  9:20 UTC (permalink / raw)
  To: gcc-bugs



-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW
   Last reconfirmed|2005-09-24 17:04:36         |2006-12-22 09:20:06
               date|                            |


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


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug target/9539] [Windows] builtin [long/set]jmp not working properly with signals
       [not found] <bug-9539-4@http.gcc.gnu.org/bugzilla/>
@ 2011-12-17 16:04 ` ktietz at gcc dot gnu.org
  0 siblings, 0 replies; 6+ messages in thread
From: ktietz at gcc dot gnu.org @ 2011-12-17 16:04 UTC (permalink / raw)
  To: gcc-bugs

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.


^ permalink raw reply	[flat|nested] 6+ messages in thread

* [Bug target/9539] [Windows] builtin [long/set]jmp not working properly with signals
       [not found] <20030202182600.9539.obry@gnat.com>
@ 2004-01-15  1:55 ` pinskia at gcc dot gnu dot org
  0 siblings, 0 replies; 6+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2004-01-15  1:55 UTC (permalink / raw)
  To: gcc-bugs



-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement
          Component|c                           |target
   Last reconfirmed|0000-00-00 00:00:00         |2004-01-15 01:55:48
               date|                            |


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


^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2011-12-17 16:00 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
     [not found] <bug-9539-5367@http.gcc.gnu.org/bugzilla/>
2006-09-20  8:05 ` [Bug target/9539] [Windows] builtin [long/set]jmp not working properly with signals fxcoudert at gcc dot gnu dot org
2006-09-20  9:52 ` dannysmith at users dot sourceforge dot net
2006-09-22 16:21 ` pascal dot obry at wanadoo dot fr
2006-12-22  9:20 ` pinskia at gcc dot gnu dot org
     [not found] <bug-9539-4@http.gcc.gnu.org/bugzilla/>
2011-12-17 16:04 ` ktietz at gcc dot gnu.org
     [not found] <20030202182600.9539.obry@gnat.com>
2004-01-15  1:55 ` pinskia at gcc dot gnu dot org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).