Building jhc from darcs repo I get a compile error: src/FrontEnd/Class.hs:643:12:     No instance for (Binary (Map.Map Name Class))       arising from a use of `get' at src/FrontEnd/Class.hs:643:12-26     Possible fix:       add an instance declaration for (Binary (Map.Map Name Class))     In a stmt of a 'do' expression: an <- get     In the expression:         do { ah <- get;              ai <- get;              aj <- get;              ak <- get;              .... }     In a case alternative:         1 -> do { ah <- get;                   ai <- get;                   aj <- get;                   .... } ghc version is 6.12.3 DrIFT Version is 2.2.3 ----------------------------------------

From: john@repetae.net Date: Wed, 29 Dec 2010 17:22:55 -0800 Subject: Re: [jhc] foreign ptr bugs To: korcan_h@hotmail.com CC: jhc@haskell.org

On Wed, Dec 29, 2010 at 4:45 PM, Korcan Hussein wrote:

...

Hi I mentioned this briefly in the past before, there is a bug when there are multiple foreign pointers in the same lexical scope obtained from (different) foreign binding functions. The pointer values end up having the same address this typically happens when GCC optimizations are enabled for which most of the time I can make code work correctly by adding -fdebug option to jhc.

Hmm... that is strange. I am actually working on the foreign pointer implementation at the moment in order to get them to play nicely with the new garbage collector. I'll have to see if I can reproduce this bug.

...

Another problem I've been having is erroneous C code generated with the same test code when I set the flag "-fno-global-optimize".

Hmm.. I have not tested that flag in a while, I'll check if it still should work and add it to the regression tests if it is something I intend to support going forward.

...

I'm using fedora, jhc-0.7.6

Have you tried with the latest darcs version of jhc? I fixed a couple bugs in the code generator, I don't think any would be causing this directly, but it is possible.

John

I have the same version of binrary in my user packages but I have two versions of containers, in system wide I have 0.3.0.0 and my user packages I have version 0.4.0.0

From: john@repetae.net Date: Thu, 30 Dec 2010 03:48:43 -0800 Subject: Re: [jhc] foreign ptr bugs To: korcan_h@hotmail.com CC: jhc@haskell.org

On Thu, Dec 30, 2010 at 2:54 AM, Korcan Hussein wrote:

...

Building jhc from darcs repo I get a compile error: ...

That is strange, I am compiling the darcs version with ghc 6.12 and it is working fine. What version of 'containers' and 'binary' do you have installed? I have

containers-0.3.0.0 binary-0.5.0.2

John

I have narrowed it down to the -fstrict-aliasing optimization pass that is causing the bug. So it is likely that I am accidentally aliasing some memory location via two different pointer types. hmm... not sure how to proceed debugging this other than manual inspection of the generated assembly. Has anyone out there dealt with aliasing issues before? I'd prefer to figure out the root cause than just disable the optimization without understanding why it is needed. John

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

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

On Sat, Jan 1, 2011 at 6:03 PM, Korcan Hussein wrote:

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!

It applies the brute force approach of never reclaiming anything, that isn't entirely true, it does some static analysis and a simple form of region inference so things won't blow up too fast, but programs will eventually run out of RAM. Basically, the reason for this was that I was experimenting with alternate garbage collectors and it wasn't clear which one would end up on top. jgc will probably be enabled by default in the next release. John