March 2014 - ghc-tickets

[GHC] #8673: GHC could generate GADT record selectors in more cases
by GHC 17 May '14

17 May '14

#8673: GHC could generate GADT record selectors in more cases ------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Philip Holzenspies writes (in email to ghc-users): I was playing around with GADT-records again and ran into behaviour that I'm not sure is intentional. Given this program: {{{ {-#LANGUAGE GADTs #-} data FooBar x a where Foo :: { fooBar :: a } -> FooBar Char a Bar :: { fooBar :: a } -> FooBar Bool a }}} GHC tells me this: {{{ foo.hs:3:1: Constructors Foo and Bar have a common field `fooBar', but have different result types In the data declaration for `FooBar' Failed, modules loaded: none. }}} The user guide does say (section 7.4.7): "However, for GADTs there is the following additional constraint: every constructor that has a field f must have the same result type (modulo alpha conversion)." So this behaviour is documented in the user guide. However, it seems reasonable that in the case above, where all the relevant variables are exposed in the result type of both constructors, this should be perfectly typeable. In other words, shouldn't GHC be able to derive a type that is simply: {{{ fooBar :: FooBar x a -> a }}} ? Is this something that was simply never implemented, but could be, or is this not decidable or prohibitively computationally complex? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8673> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #8935: Obscure linker bug leads to crash in GHCi
by GHC 02 May '14

02 May '14

#8935: Obscure linker bug leads to crash in GHCi ------------------------------------+------------------------------------- Reporter: simonmar | Owner: simonmar Type: bug | Status: new Priority: high | Milestone: 7.8.2 Component: Runtime System | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: GHCi crash Difficulty: Rocket Science | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- I have a build of GHC (with `DYNAMIC_GHC_PROGRAMS=NO`) that exhibits the following crash: {{{ $ ghc -e 'System.Environment.getEnvironment' <segfault> }}} I tracked it down, eventually, to a bad reference to the symbol `environ` from `__hscore_environ` in `libraries/base/includes/HsBase.h`. Somehow, `environ` had got linked to the wrong address. Lots more investigation lead me to discover this: `internal_dlsym()` in `Linker.c` tries to look up a symbol in all the different shared libraries we have loaded so far, one by one. (see be497c202b790999c3fd0ddc4a4176b8cf6acf7e). Unfortunately, this seems to break things in my case. Here's a simple test program that works on Ubuntu 12.04: {{{ #include <dlfcn.h> #include <stdio.h> char *so = "/usr/lib/x86_64-linux-gnu/libgmp.so"; char *so2 = "/usr/lib/x86_64-linux-gnu/libpthread.so"; extern char**environ; int main(int argc, char *argv[]) { void *deflt, *hdl; deflt = dlopen(NULL, RTLD_LAZY | RTLD_GLOBAL); printf("environ = %p\n", &environ); printf("dlsym(deflt, \"environ\") = %p\n", dlsym(deflt,"environ")); hdl = dlopen(so, RTLD_LAZY); printf("dlsym(\"libgmp\", \"environ\") = %p\n", dlsym(hdl,"environ")); hdl = dlopen(so2, RTLD_LAZY); printf("dlsym(\"libpthread\", \"environ\") = %p\n", dlsym(hdl,"environ")); } }}} And the output: {{{ environ = 0x601040 dlsym(deflt, "environ") = 0x601040 dlsym("libgmp", "environ") = 0x2aaaab290568 dlsym("libpthread", "environ") = 0x601040 }}} Note that the value we get from looking up `environ` in `libgmp` is different to the others. The correct value is `0x601040`. gdb thinks that `0x2aaaab290568` is also `environ`: {{{ (gdb) p4 0x2aaaab290568 0x2aaaab290580 <buflen.9817>: 0x0 0x2aaaab290578: 0x0 0x2aaaab290570 <miss_F_GETOWN_EX>: 0x0 0x2aaaab290568 <environ>: 0x0 }}} but note that it contains zero. The real one is: {{{ (gdb) p4 0x601040 0x601058: 0x0 0x601050 <dtor_idx.6533>: 0x0 0x601048 <completed.6531>: 0x0 0x601040 <environ@@GLIBC_2.2.5>: 0x7fffffffe268 }}} In GHC we're loading `libgmp` when we load the `integer-gmp` package, and this causes future references to `environ` to go wrong. I've locally fixed this by changing `internal_dlsym` to `dlsym`, but since there was a reason to make this change in the first place I haven't pushed it to master. Suggestions welcome. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8935> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 64

[GHC] #8933: process007: internal error: checkStackFrame: weird activation record found on stack
by GHC 01 May '14

01 May '14

#8933: process007: internal error: checkStackFrame: weird activation record found on stack ------------------------------------+---------------------------------- Reporter: trommler | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Compiler | Version: 7.8.1-rc2 Keywords: | Operating System: Linux Architecture: Unknown/Multiple | Type of failure: Runtime crash Difficulty: Unknown | Test Case: process007 Blocked By: | Blocking: Related Tickets: | ------------------------------------+---------------------------------- On an unregisterised compiler process007 segfaults in all WAYS. Here is a stack trace from a run with {{{+RTS -DS}}} on an x86_64 machine: {{{ Starting program: /home/trp/research/ghc- unreg/ghc-7.8/libraries/process/tests/process007 +RTS -DS [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib64/libthread_db.so.1". cap 0: initialised process007: internal error: checkStackFrame: weird activation record found on stack (0x7ffff69050b8 281051976). (GHC version 7.8.0.20140324 for x86_64_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Program received signal SIGABRT, Aborted. 0x00007ffff6a95849 in raise () from /lib64/libc.so.6 (gdb) where #0 0x00007ffff6a95849 in raise () from /lib64/libc.so.6 #1 0x00007ffff6a96cd8 in abort () from /lib64/libc.so.6 #2 0x00000000008172af in rtsFatalInternalErrorFn ( s=0x894080 "checkStackFrame: weird activation record found on stack (%p %d).", ap=0x7fffffffd968) at rts/RtsMessages.c:170 #3 0x0000000000816ee7 in barf ( s=0x894080 "checkStackFrame: weird activation record found on stack (%p %d).") at rts/RtsMessages.c:42 #4 0x00000000008355e2 in checkStackFrame (c=0x7ffff69050b8) at rts/sm/Sanity.c:165 #5 0x000000000083560a in checkStackChunk (sp=0x7ffff69050b8, stack_end=0x7ffff6905390) at rts/sm/Sanity.c:177 #6 0x0000000000836100 in checkSTACK (stack=0x7ffff6905000) at rts/sm/Sanity.c:497 #7 0x0000000000836254 in checkTSO (tso=0x7ffff6905390) at rts/sm/Sanity.c:535 #8 0x000000000082625a in threadStackOverflow (cap=0xd79740 <MainCapability>, tso=0x7ffff6905390) at rts/Threads.c:500 #9 0x000000000082226a in schedule ( initialCapability=0xd79740 <MainCapability>, task=0xd9a4e0) at rts/Schedule.c:528 #10 0x00000000008236b3 in scheduleWaitThread (tso=0x7ffff6905390, ret=0x0, pcap=0x7fffffffdcc0) at rts/Schedule.c:2346 #11 0x0000000000824d63 in rts_evalLazyIO (cap=0x7fffffffdcc0, p=0xbd4da0 <ZCMain_main_closure>, ret=0x0) at rts/RtsAPI.c:500 #12 0x00000000008272de in real_main () at rts/RtsMain.c:63 #13 0x00000000008273d1 in hs_main (argc=3, argv=0x7fffffffde48, main_closure=0xbd4da0 <ZCMain_main_closure>, rts_config=...) at rts/RtsMain.c:114 #14 0x000000000040849f in main () }}} Running without the RTS flags: {{{ Program received signal SIGSEGV, Segmentation fault. 0x00000000008307ed in StgRun (f=0xd79758b8e5894855, basereg=0xd79758 <MainCapability+24>) at rts/StgCRun.c:81 81 f = (StgFunPtr) (f)(); (gdb) where #0 0x00000000008307ed in StgRun (f=0xd79758b8e5894855, basereg=0xd79758 <MainCapability+24>) at rts/StgCRun.c:81 #1 0x0000000000822022 in schedule ( initialCapability=0xd79740 <MainCapability>, task=0xd9a470) at rts/Schedule.c:463 #2 0x00000000008236b3 in scheduleWaitThread (tso=0x7ffff6905390, ret=0x0, pcap=0x7fffffffdcd0) at rts/Schedule.c:2346 #3 0x0000000000824d63 in rts_evalLazyIO (cap=0x7fffffffdcd0, p=0xbd4da0 <ZCMain_main_closure>, ret=0x0) at rts/RtsAPI.c:500 #4 0x00000000008272de in real_main () at rts/RtsMain.c:63 #5 0x00000000008273d1 in hs_main (argc=1, argv=0x7fffffffde58, main_closure=0xbd4da0 <ZCMain_main_closure>, rts_config=...) at rts/RtsMain.c:114 #6 0x000000000040849f in main () }}} The value of f in StgRun looks strange the first three bytes are the same as basereg {{{0xd79758}}}. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8933> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #8742: Reuse scavenge_small_bitmap
by GHC 29 Apr '14

29 Apr '14

#8742: Reuse scavenge_small_bitmap ------------------------------------+------------------------------------- Reporter: Tarrasch | Owner: simonmar Type: task | Status: new Priority: lowest | Milestone: Component: Runtime System | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- Hi, I've found that the `scavenge_small_bitmap` is in-lined at two places. I added this patch to remove code duplication. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8742> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 19

[GHC] #8866: scavenge_stack: weird activation record found on stack on "cabal install -j"
by GHC 29 Apr '14

29 Apr '14

#8866: scavenge_stack: weird activation record found on stack on "cabal install -j" ----------------------------------+---------------------------------- Reporter: adinapoli | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Build System | Version: 7.8.1-rc2 Keywords: | Operating System: MacOS X Architecture: x86_64 (amd64) | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ----------------------------------+---------------------------------- Hello everyone, sorry if this was reported somewhere else. I know that the dreadful "scavenge_stack" is nothing new, but it's the first time I see it on Mac OS X (I'm on Maverick, OS X 10.9.2). This is a "stacktrace" of the problem. It seems to happen almost consistently if I try to do a parallel installation: {{{ [hsenv]☁ ~HSENV cabal install -j snap Resolving dependencies... Configuring HUnit-1.2.5.2... Downloading MonadRandom-0.1.13... Downloading logict-0.6.0.2... cabal: internal error: scavenge_stack: weird activation record found on stack: 415597384 (GHC version 7.8.0.20140228 for x86_64_apple_darwin) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug [1] 2328 abort cabal install -j snap [hsenv]☁ ~HSENV }}} The concerning thing is that it doesn't seem to be deterministic. After issuing that command, I have tried again and it worked this time: {{{ [hsenv]☁ ~HSENV cabal install -j snap Resolving dependencies... Configuring HUnit-1.2.5.2... Downloading MonadRandom-0.1.13... Configuring SHA-1.6.4... Downloading logict-0.6.0.2... Downloading process-1.1.0.2... [...] }}} It seems to happen with every package and I have tried to install snap just for the sake of reproducing it. Thanks! ps. Cross-posted on Github into the cabal issue tracker: https://github.com/haskell/cabal/issues/1716 Alfredo -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8866> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #8121: Gitolite Migration
by GHC 28 Apr '14

28 Apr '14

#8121: Gitolite Migration ------------------------------------+------------------------------------- Reporter: hvr | Owner: hvr Type: task | Status: new Priority: normal | Milestone: Component: None | Version: Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- This ticket is for keeping track of the implementation of the [GitolitePlan Gitolite Migration Plan] See also the posting [http://permalink.gmane.org/gmane.comp.lang.haskell.ghc.devel/1618 "Proposal: Gitolite for repository management"] to ghc-devs(a)haskell.org -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8121> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 17

[GHC] #8498: gcc hardcoded in build scripts! (ignores the --with-gcc= flag in configure)
by GHC 28 Apr '14

28 Apr '14

#8498: gcc hardcoded in build scripts! (ignores the --with-gcc= flag in configure) ------------------------------------+--------------------------------- Reporter: carter | Owner: Type: bug | Status: new Priority: high | Milestone: 7.8.1 Component: Compiler | Version: 7.7 Keywords: | Operating System: MacOS X Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+--------------------------------- NB: this may be a dupe of another issue, but reporting is separately for now i'm on OS X 10.8 (mountain lion) with xcode 5, ghc comit 23fb7f3b7987d7b3fa445e54680a8a00a37e714d, I've got a gcc-4.8 installed, though gcc in my path is actually clang (as is typical for xcode 5), so I configured as {{{ ./configure --with-gcc=gcc-4.8 }}} and then I noticed as i'm building, some warnings that mean clang is being called rather than gcc! heres a relevant snippet of the build transcript {{{ cp" utils/hsc2hs/template-hsc.h inplace/lib/template-hsc.h "/usr/bin/ghc" -hisuf hi -osuf o -hcsuf hc -static -H64m -O -fasm -package process -package containers -package-db libraries/bootstrapping.conf -i -iutils/deriveConstants/. -iutils/deriveConstants/dist/build -iutils/deriveConstants/dist/build/autogen -Iutils/deriveConstants/dist/build -Iutils/deriveConstants/dist/build/autogen -no-user-package-db -rtsopts -odir utils/deriveConstants/dist/build -hidir utils/deriveConstants/dist/build -stubdir utils/deriveConstants/dist/build -c utils/deriveConstants/./DeriveConstants.hs -o utils/deriveConstants/dist/build/DeriveConstants.o "inplace/bin/mkdirhier" utils/deriveConstants/dist/build/tmp//. "inplace/bin/mkdirhier" rts/dist/build//. gcc -E -m64 -undef -traditional -P -Iincludes -Iincludes/dist -Iincludes /dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Icompiler/stage1 -x c compiler/prelude/primops.txt.pp | grep -v '^#pragma GCC' > compiler/stage1/build/primops.txt compiler/prelude/primops.txt.pp:35:55: warning: missing terminating ' character [-Winvalid-pp-token] -- The default attribute values which apply if you don't specify ^ compiler/prelude/primops.txt.pp:1310:19: warning: missing terminating ' character [-Winvalid-pp-token] difference doesn't fit in an {\tt Int\#}.} ^ compiler/prelude/primops.txt.pp:1591:41: warning: missing terminating ' character [-Winvalid-pp-token] -- not really the right type, but we don't know about pairs here. The ^ compiler/prelude/primops.txt.pp:1620:15: warning: missing terminating ' character [-Winvalid-pp-token] -- but we don't want to tell the strictness ^ compiler/prelude/primops.txt.pp:1634:30: warning: missing terminating ' character [-Winvalid-pp-token] -- must be *precise* - we don't want the strictness analyser turning ^ compiler/prelude/primops.txt.pp:1690:14: warning: missing terminating ' character [-Winvalid-pp-token] -- NB: retry#'s strictness information specifies it to return bottom. ^ compiler/prelude/primops.txt.pp:1811:47: warning: missing terminating ' character [-Winvalid-pp-token] Otherwise, store value arg as {\tt MVar\#}'s new contents, and return with integer 1.} ^ compiler/prelude/primops.txt.pp:1906:21: warning: missing terminating ' character [-Winvalid-pp-token] {\tt RealWorld}; it's only used in the type system, to parameterise {\tt State\#}. } ^ compiler/prelude/primops.txt.pp:2084:67: warning: missing terminating ' character [-Winvalid-pp-token] -- why return the value? So that we can control sharing of seq'd ^ compiler/prelude/primops.txt.pp:2087:13: warning: missing terminating ' character [-Winvalid-pp-token] -- we don't want to inline x, so better to represent it as ^ compiler/prelude/primops.txt.pp:2108:48: warning: missing terminating ' character [-Winvalid-pp-token] -- `the processor containing the expression v'; it is not evaluated ^ compiler/prelude/primops.txt.pp:2206:20: warning: missing terminating ' character [-Winvalid-pp-token] {These aren't nearly as wired in as Etc...} ^ compiler/prelude/primops.txt.pp:2236:57: warning: missing terminating ' character [-Winvalid-pp-token] * It does not claim to be a {\it data} type, and that's important for ^ compiler/prelude/primops.txt.pp:2240:4: warning: missing terminating ' character [-Winvalid-pp-token] It's also used to instantiate un-constrained type variables after type ^ compiler/prelude/primops.txt.pp:2278:86: warning: missing terminating ' character [-Winvalid-pp-token] used when you want to write a program that you know is well-typed, but where Haskell's ^ compiler/prelude/primops.txt.pp:2301:28: warning: missing terminating ' character [-Winvalid-pp-token] have to do with GHC's internal representation details (for the congnoscenti, data values ^ compiler/prelude/primops.txt.pp:2307:76: warning: missing terminating ' character [-Winvalid-pp-token] -- NB. It is tempting to think that casting a value to a type that it doesn't have is safe ^ compiler/prelude/primops.txt.pp:2308:22: warning: missing terminating ' character [-Winvalid-pp-token] -- as long as you don't "do anything" with the value in its cast form, such as seq on it. This ^ compiler/prelude/primops.txt.pp:2309:7: warning: missing terminating ' character [-Winvalid-pp-token] -- isn't the case: the compiler can insert seqs itself, and if these happen at the wrong type, ^ compiler/prelude/primops.txt.pp:2344:17: warning: missing terminating ' character [-Winvalid-pp-token] the newtype's concrete type to the abstract type. But it also works in ^ compiler/prelude/primops.txt.pp:2367:67: warning: missing terminating ' character [-Winvalid-pp-token] {\tt instance Coercible b b' => Coercible (D a b c) (D a b' c')} ^ compiler/prelude/primops.txt.pp:2389:43: warning: missing terminating ' character [-Winvalid-pp-token] you need to set the role of {\tt Set}'s type parameter to Nominal. }}} notice the hard coded gcc call {{{ gcc -E -m64 -undef -traditional -P -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist- ghcconstants/header -Icompiler/stage1 -x c compiler/prelude/primops.txt.pp | grep -v '^#pragma GCC' > compiler/stage1/build/primops.txt }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8498> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 15

[GHC] #8303: defer StackOverflow exceptions (rather than dropping them) when exceptions are masked
by GHC 28 Apr '14

28 Apr '14

#8303: defer StackOverflow exceptions (rather than dropping them) when exceptions are masked ------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: None/Unknown Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | ------------------------------------+------------------------------------- See http://www.reddit.com/r/haskell/comments/1luan1/strange_io_sequence_behavio… for a very simple program (`main'`) that accidentally evades the stack size limit, running to completion even though it has allocated hundreds of megabytes of stack chunks, and [http://www.reddit.com/r/haskell/comments/1luan1/strange_io_sequence_behavio… my comment] for an explanation of this behavior. ryani suggested that when a thread exceeds its stack limit but it is currently blocking exceptions, the RTS shouldn't simply drop the `StackOverflow` exception, but rather deliver it when the `mask` operation completes. That sounds sensible to me and it would give a nice guarantee that when any individual `mask` operation uses a small amount of stack, the stack size limit is approximately enforced. (I know that the default stack size limit may go away or essentially go away, but it can still be nice when developing to use a small stack size limit, so that one's system isn't run into the ground by infinite recursion quickly gobbling up tons of memory.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8303> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #8728: Segmentation fault in Cabal
by GHC 28 Apr '14

28 Apr '14

#8728: Segmentation fault in Cabal -------------------------------------+---------------------------------- Reporter: heatsink | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 7.8.1-rc1 Keywords: Cabal | Operating System: MacOS X Architecture: x86 | Type of failure: Runtime crash Difficulty: Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | -------------------------------------+---------------------------------- I get a segfault in the following program, compiled on OS X with the development version of GHC (last commit 50e4d40f88c3eee41384efacfd83f73305e2210d), run with the command `./Setup configure`. A `.cabal` file is not needed to produce the error. {{{ -- ghc --make Setup.hs import Distribution.Simple main = defaultMainWithHooks simpleUserHooks }}} I discovered the problem when installing `llvm-general-pure`. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8728> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #8676: RTS headers don't compile as C++
by GHC 28 Apr '14

28 Apr '14

#8676: RTS headers don't compile as C++ ----------------------------------+---------------------------------------- Reporter: blitzcode | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 7.8.1 Component: Runtime System | Version: 7.6.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC failed Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------------+---------------------------------------- GHC's RTS headers can't be included from C++, as they contain constructs like this {{{ dbl_link_replace(bdescr *new, bdescr *old, bdescr **list) }}} (notice the 'new'). This is the case for the headers shipped with 7.6.3 and still seems to be in the HEAD version. Since the code has the usual {{{ #ifdef __cplusplus extern "C" { #endif }}} all over the place, I assume the C++ incompatibility is simply an oversight? In any case, it would seem highly unusual to have a C interface that can't be consumed from C++. It seems all the incompatibilities could be removed with at worst a small amount of inconvenience, and automatic checking for C++ compatibility on each build could be added. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/8676> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3