[jhc] foreign ptr bugs

[John Meacham]

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 <korcan_h at hotmail.com> 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 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
>