Yeah it works for me too, I didn't know that GC isn't enabled by default? how does memory management work without a garbage collector? malloc/free and static reference counts (linear types)? anyway thanks for the help! ----------------------------------------
From: john@repetae.net Date: Sat, 1 Jan 2011 17:16:10 -0800 Subject: Re: [jhc] foreign ptr bugs To: korcan_h@hotmail.com CC: jhc@haskell.org
They appear to work for me when I compile with the -fjgc option to jhc and -fno-strict-aliasing option to gcc. I am not sure why the non garbage collected version isn't working at the moment.
John
On Sat, Jan 1, 2011 at 3:47 PM, Korcan Hussein wrote:
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@repetae.net Date: Thu, 30 Dec 2010 15:42:54 -0800 Subject: Re: [jhc] foreign ptr bugs To: korcan_h@hotmail.com CC: jhc@haskell.org
On Thu, Dec 30, 2010 at 12:13 PM, Korcan Hussein 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