January 2014 - Glasgow-haskell-users

Problem with the object file name of the Main module.
by Christian Brolin 14 Jan '14

14 Jan '14

H. The documentation (version 7.6.3) section 7.7.2 Output files says that the source file name of the Main module does not have to be Main.hs making it "possible to have several Main modules in separate source files in the same directory". While this is true and promising it is seems to be unusable since GHC always compiles the main source file into an object file called Main.o.

4 7

Mips64el Linux Build
by cherry 04 Jan '14

04 Jan '14

Hello, I am new to the list, though I have been using GHC for a long time. Just say Hello. I would like to share my experience about building GHC (7.7.20131112) on/for mips64el linux, just in case anybody is interested, as it seems not documented (on Wiki pages of Platforms, CrossCompiling, or Porting). Ignore this email if it is not interesting or too trivial. It bootstrapped by cross compiling on x86_64 linux, with some tweaking on mk/build.mk and the build process. In particular, I needed to specify export CPP="mips64el-unknown-linux-gnu-gcc -E" otherwise the configure script just found to use the native "gcc -E" and it failed in preprocessing rts C files. Also in mk/build.mk I forced GhcThreaded = NO GhcWithInterpreter = YES # so, it can use TH and build happy The make process failed when trying to use ghc-stage2, but at that point the stage 2 compiler is already built, that's enough. With this cross-compiled ghc-stage2, the native build on mips64el machine was done without much interleaving. inplace/lib/unlit was x86_64 binary, and needed to be rebuild. Also manually built alex and happy (and their dependencies). Then it just went through. So, the new way of porting seems just cross compiling followed by native compiling? Somewhat surprisingly, GHCi is also working (forced it to be built), with system's dynamic linker. Is there need to write/update a wiki page for this? Thanks, cherry

2 1

memory ordering
by John Lato 01 Jan '14

01 Jan '14

Hello, I'm working on a lock-free algorithm that's meant to be used in a concurrent setting, and I've run into a possible issue. The crux of the matter is that a particular function needs to perform the following: > x <- MVector.read vec ix > position <- readIORef posRef and the algorithm is only safe if these two reads are not reordered (both the vector and IORef are written to by other threads). My concern is, according to standard Haskell semantics this should be safe, as IO sequencing should guarantee that the reads happen in-order. Of course this also relies upon the architecture's memory model, but x86 also guarantees that reads happen in order. However doubts remain; I do not have confidence that the code generator will handle this properly. In particular, LLVM may freely re-order loads of NotAtomic and Unordered values. The one hope I have is that ghc will preserve IO semantics through the entire pipeline. This seems like it would be necessary for proper handling of exceptions, for example. So, can anyone tell me if my worries are unfounded, or if there's any way to ensure the behavior I want? I could change the readIORef to an atomicModifyIORef, which should issue an mfence, but that seems a bit heavy-handed as just a read fence would be sufficient (although even that seems more than necessary). Thanks, John L.

4 10