[jhc] foreign ptr bugs

[Korcan Hussein]

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 at repetae.net
> Date: Sat, 1 Jan 2011 17:16:10 -0800
> Subject: Re: [jhc] foreign ptr bugs
> To: korcan_h at hotmail.com
> CC: jhc at 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 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  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
> >