[jhc] foreign ptr bugs

[Korcan Hussein]

Hello, I've modified the example (attached to this email) to: writing back out the loaded image (1 binding function), drawing a horizontal line with set-pixel action I wrote, and using the fill rect routine (1 binding function). Each one is commented out except for drawing a line.

In all cases I'm getting incorrect behaviour and/or seg faults when (gcc) optimizations are enabled (with -fno-strict-aliasing set), if I use -fdebug all cases work correctly and no seg faults.

When saving out the buffer with optimizations turned on the image is loaded and does get saved out but once the operation completes (or when the program exits) I get a seg fault.

When drawing a line to the screen with optimizations turned on as soon the code tries to set the first pixel the program crashes with a seg fault but with -fdebug it works perfectly.

-fno-strict-aliasing fixes the issue with pointer values being the same but there is still something weird going on.

> From: john at repetae.net
> Date: Thu, 30 Dec 2010 15:42:54 -0800
> Subject: Re: [jhc] foreign ptr bugs
> To: korcan_h at hotmail.com
> CC: jhc at haskell.org
> 
> On Thu, Dec 30, 2010 at 12:13 PM, Korcan Hussein <korcan_h at hotmail.com> wrote:
> > I've never had to deal with aliasing bugs before fortunately but I did come across an article about getting warning messages from gcc for code not adhering to strict-aliasing rules which is -Wstrict-aliasing=2 apparently this warning is not enabled by -Wall by default, I've tried this with the test code I attached earlier and I do get many of these type of messages:
> >
> > "warning: dereferencing type-punned pointer will break strict-aliasing rules
> > warning: initialization from incompatible pointer type
> > warning: assignment from incompatible pointer type"
> >
> > There is also the attribute __may_alias__ for structs.
> 
> Yeah, I have played with those, almost all the warnings seem to be false
> positives due to the way I handle pointers and their conversion to uintptr_t. I
> am not sure there is going to be a good fix without non-trivial changes to the
> code generator. I think compiling with -fno-strict-aliasing is the best
> solution at the moment.
> 
> > I've also tried -fno-strict-aliasing without -fdebug and I do get different
> > pointer values this time but the program does not work correctly, the image
> > doesn't appear to get blitted to the screen buffer so I get a black window
> > which means it is either a plain bug with generated code or another
> > optimizations related to (strict-)aliasing messing things up or combination
> > of both.
> 
> I am tempted to think that this is an independent bug. It doesn't feel like it
> is related at least. Is there any way you can come up with a smaller test case,
> like trying to dump the buffer to see if the bmp is even being loaded, or
> seeing if you can plot something simple like a line? I don't have much
> experience with the SDL libraries.
> 
>         John
 		 	   		  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.hs
Type: application/octet-stream
Size: 1827 bytes
Desc: not available
URL: <http://www.haskell.org/pipermail/jhc/attachments/20110101/87c5ac2c/attachment.obj>