#7602: Threaded RTS performing badly on recent OS X (10.8?) -------------------------------+-------------------------------------------- Reporter: simonmar | Owner: thoughtpolice Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Runtime System | Version: 7.7 Keywords: | Os: MacOS X Architecture: x86_64 (amd64) | Failure: None/Unknown Difficulty: Unknown | Testcase: Blockedby: 7678 | Blocking: Related: | -------------------------------+-------------------------------------------- Comment(by thoughtpolice): Well, technically I think that under GCC's -traditional-cpp mode, clang SHOULD respect our code. The problem is I just don't think the "be insensitive to leading whitespace" rule is implemented. :( I don't think turning one or the other off is an option. Base in particular has a few modules with both CPP and Rules, but if you disable one or the other, things will break. Either the preprocessor directives become a syntax error, or you disable the RULES and they are ignored - but the preprocessor would error on them anyway because it runs first. There is another problem. We can change GHC and all of its dependent libraries to remove leading whitespace on lines that would be ambiguous to clang. Unfortunately, 3rd party libraries do this kind of formatting to, so this could break user programs for a very bizarre reason. I think it should be possible to fix this in a transparent way, but it won't be pretty. Basically, we'll need to preemptively strip out lines that begin with whitespace, where the first non whitespace character is #. Something like "s/^\s+\#(.*)/#$1/" or whatever in regex-ese. In the mean time I think it should be possible to get clang building by reformatting a few of libraries using RULES improperly, which should not be too much work I think. Finally, the various TLS models makes no difference on the example using __thread I posted above. I posit that TLS models are silently ignored on OS X, where Apple is free to do what they wish. -- Ticket URL: http://hackage.haskell.org/trac/ghc/ticket/7602#comment:22 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler