Join GitHub today
GitHub is home to over 36 million developers working together to host and review code, manage projects, and build software together.Sign up
GHC-8 problems #39
Originally reported by David Duke.
While working with the Haskell Cuda library on OSX 10.11 I started getting a strange set of behaviours, and wondered if you had come anything similar? I recently updated both my GHC installation (to 8.0.1) and my CUDA toolkit (to 7.5). I therefore wanted to update Accelerate etc, but noted that your Cuda package was only noted up to 7.0. As I don't believe there are substantial changes from 7.0 -> 7.5 I thought it should still work (and I need to have the later CUDA for work not involving Haskell).
However I found that Haskell code that called the Cuda library was aborting, and tracked the failure down to the call to cuInit (made through "initialise" in your library) returning error code 2 (CUDA_DEVICE_OUT_OF_MEMORY). Its not clear why this should be happening, and to explore further I:
Given the simplicity of the two programs, I'm scratching my head for possible causes: when called from C, the wrapper is showing the correct arg and result; when called from Haskell it shows the correct arg but the wrong result! Here are the compiler invocations and runtime results (programs are attached):
I haven't had a chance to regress to ghc-7.10.3, and was also planning to try the code on linux once Cuda is reinstalled next week. Wondered if you had come across anything similar - or could check what happens on a different configuration?
Thanks for working on this Trevor. Not sure if its meant to be in a sufficiently stable state yet to build, so ignore if premature, but when I tried building on OSX10.11 with GHC 8.0.1 and gcc Apple LLVM version 7.3.0 (clang-703.0.31) I ran into problems apparently due to dynamic linking
ld: -rpath can only be used when creating a dynamic final linked image
for modules Foreign.CUDA.Analysis.Device and Foreign.CUDA.Types. Unclear if its an issue with the modified Setup.hs, OSX generally, or just my particular toolset.
referenced this issue
Sep 1, 2016
@alpmestan sorry, just got back from conference travel and am catching up with things. The main problem is that I didn't yet get this to work under ghci. I guess having compiled programs working at least is a big plus, so I'll finalise and throw it up on hackage shortly.
I'm still getting a build problem on OSX, however:
[29 of 37] Compiling Foreign.CUDA.Runtime ( Foreign/CUDA/Runtime.hs, dist/build/Foreign/CUDA/Runtime.o )
Foreign/CUDA/Internal/C2HS.hs:202:3: warning: [-Winline-rule-shadowing]
Foreign/CUDA/Internal/C2HS.hs:204:3: warning: [-Winline-rule-shadowing]
This was from a fresh clone of the cuda repo. Are you able to build under OSX, if so could you confirm compiler version, I'm using the following:
Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1
David Duke T: +44 113 3436800
@djduke working for me on OS X on both 7.10.3 and 8.0.1. I haven't upgraded to Sierra yet, I am still on El Capitan (10.11.6).
What is the
As far as I can see, my tool configuration matches yours. My c2hs was older (2015), I updated c2hs and tried again but the problem persists. Here is a log of building cuda from a fresh clone of your repo, along with version info for the tools. I also ran cabal build with verbose=3, and looked at the output of the final set of commands (output at the end).
Here is the most obviously relevant chunk of the output from cabal --verbose=3:
David Duke T: +44 113 3436800
Following up on my previous mail: I wonder if the problem is related to this issue with Cabal:
where dynamic linking was incorrectly turned on when executable profiling was selected. The issue was closed and the change was committed, but possibly masking a deeper inconsistency? I'm using Cabal-184.108.40.206, and suspect as you've been using ghc-8.0.1. you will be on the same version?
I just tried this with GHC HEAD and everything appears to work as expected in ghci.
The RTS automatically avoids the region needed by CUDA, no need to specify that through RTS flags or otherwise (although, I'm not sure how large a region it avoids... if your total GPU+system RAM is very high maybe you will still need to specify the offset manually.)