March 2015 - ghc-tickets

[GHC] #9348: "Symbol not found" when using a shared library
by GHC 15 Dec '15

15 Dec '15

#9348: "Symbol not found" when using a shared library -----------------------------------+----------------------------------- Reporter: alex.davis | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 7.8.3 Keywords: | Differential Revisions: Operating System: MacOS X | Architecture: x86 Type of failure: None/Unknown | Difficulty: Unknown Test Case: | Blocked By: Blocking: | Related Tickets: -----------------------------------+----------------------------------- I'm trying to make a shared library from a simple program. It works fine on my Windows box, but gives an error on Mac OS X. Furthermore, the error seems to be generated from one of GHC's shared libraries. What happens is this. I compile my shared library with GHC, which works fine. But when I try to use it from another program (specifically, R), I get an error message containing the following: Symbol not found: _stg_IND_STATIC_info Referenced from: /usr/local/lib/ghc-7.8.3/ghc-prim-0.3.1.0/libHSghc- prim-0.3.1.0-ghc7.8.3.dylib Expected in: flat namespace in /usr/local/lib/ghc-7.8.3/ghc-prim-0.3.1.0/libHSghc- prim-0.3.1.0-ghc7.8.3.dylib More details: The program I'm trying to use is R. In R, you load a shared library with the command "dyn.load". When I try this, the command I use is "dyn.load('final.dylib')", and the full error message is what follows: --- Error in dyn.load("final.dylib") : unable to load shared object '/Users/alexanderdavis/Desktop/illustrate bug copy/final.dylib': dlopen(/Users/alexanderdavis/Desktop/illustrate bug copy/final.dylib, 6): Symbol not found: _stg_IND_STATIC_info Referenced from: /usr/local/lib/ghc-7.8.3/ghc-prim-0.3.1.0/libHSghc- prim-0.3.1.0-ghc7.8.3.dylib Expected in: flat namespace in /usr/local/lib/ghc-7.8.3/ghc-prim-0.3.1.0/libHSghc- prim-0.3.1.0-ghc7.8.3.dylib --- As I said, I have done all of this with no trouble on Windows. I compiled into a DLL, loaded the program into R, and was able to use the functions in it. My Mac OS version is 10.9.4. My R version is 3.0.2. When loaded, it displays "Platform: x86_64-apple- darwin10.8.0 (64-bit)", but Sys.getev("R_ARCH") returns the empty string. Command used for compiler: ghc --make -dynamic -fPIC -shared SumRoots.hs StartEnd.c -o final.dylib The code is attached. It is from a blog post by Neil Mitchelll (author of HLint) about calling Haskell from R: http://neilmitchell.blogspot.com/2011/10/calling-haskell-from-r.html -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9348> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

[GHC] #9378: Make unknown LANGUAGE pragmas a warning, not an error
by GHC 15 Dec '15

15 Dec '15

#9378: Make unknown LANGUAGE pragmas a warning, not an error -------------------------------------+------------------------------------- Reporter: goldfire | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.2 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Currently, if I say `{-# LANGUAGE Foo #-}` at the top of my file, it fails to compile. This failure seems unnecessary, especially because any new language feature `Foo` enables will fail to compile later on down the file. Is it possible to have a "stern warning" that is produced even when other parts of the file produce errors? The reason I'm bringing this up is that, when 7.8 came out with its role annotations, users needed CPP in two different places: both to protect the `RoleAnnotations` pragma and to protect the role annotations themselves. This may be unavoidable on the role annotations directly, but I think we can improve the situation around `LANGUAGE` pragmas. Is there a downside to this? -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9378> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 7

[GHC] #10029: unit-tests: internal error: evacuate(static): strange closure type 62744
by GHC 15 Dec '15

15 Dec '15

#10029: unit-tests: internal error: evacuate(static): strange closure type 62744 -------------------------------------+------------------------------------- Reporter: | Owner: juhpetersen | Status: new Type: bug | Milestone: Priority: normal | Version: 7.8.4 Component: Compiler | Operating System: Linux Keywords: | Type of failure: Compile-time Architecture: arm | crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | -------------------------------------+------------------------------------- The syb-0.4.1 testsuite fails on ARMv7 Linux (Fedora 22 devel) with ghc-7.8.4: {{{ + ./Setup test Running 1 test suites... Test suite unit-tests: RUNNING... Cases: 29 Tried: 0 Errors: 0 Failures: 0 Cases: 29 Tried: 1 Errors: 0 Failures: 0 Cases: 29 Tried: 2 Errors: 0 Failures: 0 Cases: 29 Tried: 3 Errors: 0 Failures: 0 Cases: 29 Tried: 4 Errors: 0 Failures: 0 Cases: 29 Tried: 5 Errors: 0 Failures: 0 Cases: 29 Tried: 6 Errors: 0 Failures: 0 Cases: 29 Tried: 7 Errors: 0 Failures: 0 Cases: 29 Tried: 8 Errors: 0 Failures: 0 Cases: 29 Tried: 9 Errors: 0 Failures: 0 Cases: 29 Tried: 10 Errors: 0 Failures: 0 Cases: 29 Tried: 11 Errors: 0 Failures: 0 Cases: 29 Tried: 12 Errors: 0 Failures: 0 Cases: 29 Tried: 13 Errors: 0 Failures: 0 Cases: 29 Tried: 14 Errors: 0 Failures: 0 Cases: 29 Tried: 15 Errors: 0 Failures: 0 Cases: 29 Tried: 16 Errors: 0 Failures: 0 Cases: 29 Tried: 17 Errors: 0 Failures: 0 Cases: 29 Tried: 18 Errors: 0 Failures: 0unit-tests: internal error: evacuate(static): strange closure type 62744 (GHC version 7.8.4 for arm_unknown_linux) Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug Test suite unit-tests: FAIL Test suite logged to: dist/test/syb-0.4.1-unit-tests.log 0 of 1 test suites (0 of 1 test cases) passed. }}} Let me know if I can provide any more details. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10029> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9952: Add -g<level>
by GHC 15 Dec '15

15 Dec '15

#9952: Add -g<level> -------------------------------------+------------------------------------- Reporter: tibbe | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.4 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- We should add debug info levels, just like GCC and LLVM has. In particular, I'd like to have -g1 which has (from https://gcc.gnu.org/onlinedocs/gcc/Debugging-Options.html) > minimal information, enough for making backtraces in parts of the program that you don't plan to debug. This includes descriptions of functions and external variables, and line number tables, but no information about local variables. This should let us have -g1 turned on even in production code, as it should grow binary sizes by much. This in turn should be a boon for debugability of programs. It should also allow us to offer some for of stack traces without any runtime cost (except when an exception with a stack trace is actually raised.) -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9952> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #9499: Add -prelude-is flag
by GHC 15 Dec '15

15 Dec '15

#9499: Add -prelude-is flag -------------------------------------+------------------------------------- Reporter: agibiansky | Owner: agibiansky Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: flag | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Easy (less than 1 | Type of failure: hour) | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- I would like GHC to have a `-prelude-is` flag, which would specify an alternate Prelude to use instead of the default Haskell prelude. The benefit this would have is that this would give alternate preludes a more first-class status. Instead of having to import an alternative prelude everywhere, you could just have a ghc-options: -prelude-is=... flag in your *.cabal file, and have a different prelude be used. This is important for my own work, as I highly prefer other preludes for my non- library development; I think this is a feature which will be very useful as Haskell develops and we try to figure out how to get rid of the warts in the current Prelude. Additional discussion here: https://groups.google.com/forum/#!topic /haskell-cafe/NCVzXZcxNmQ -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9499> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 10

[GHC] #9573: Add warning for invalid digits in integer literals
by GHC 15 Dec '15

15 Dec '15

#9573: Add warning for invalid digits in integer literals -------------------------------------+------------------------------------- Reporter: vlopez | Owner: Type: bug | Status: new Priority: normal | Milestone: 7.10.1 Component: Compiler (Parser) | Version: 7.9 Keywords: parsing, integer, | Operating System: octal, binary, hexadecimal, | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Difficult (2-5 | None/Unknown days) | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: -------------------------------------+------------------------------------- In its latest version, GHC can parse binary (with `-XBinaryLiterals`), octal and hexadecimal literals: {{{#!hs > 0b101010 > 0o52 > 0x2A }}} Currently, the parser/lexer reads digits from the input as long as they are valid for the specified radix. All subsequent digits are interpreted as a new, separate token. If the user uses a digit which isn't valid for the radix, it may be reported with a non-obvious error message, or interpreted in surprising ways: {{{#!hs > :t 0o567 0o576 :: Num a => a > :t 0o5678 0o5678 :: (Num (a -> t), Num a) => t Prelude> :t 0x1bfah <interactive>:1:7: Not in scope: ‘h’ > replicate 0o5678 [8,8,8,8,8,8,8... }}} We suggest warning the user when a literal of this sort is written, while respecting any other error messages and the original behaviour. More specifically, the parser or lexer would give a warning if a token starting with an alphanumeric character is found immediately after a numeric literal, without a blank between them. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9573> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 6

[GHC] #9613: when giving an error "No instance for C (a -> b)", suggest that a function may be underapplied
by GHC 15 Dec '15

15 Dec '15

#9613: when giving an error "No instance for C (a -> b)", suggest that a function may be underapplied -------------------------------------+------------------------------------- Reporter: rwbarton | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: Compiler (Type | Version: 7.8.3 checker) | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Suggestion of ibotty here: http://www.reddit.com/r/haskell/comments/2go92u/beginner_error_messages_in_… {{{ Prelude> print length <interactive>:2:1: No instance for (Show ([a0] -> Int)) arising from a use of ‘print’ but there is an instance for (Show Int); maybe you omitted an argument to ‘length’ of type [a0]? In the expression: print length In an equation for ‘it’: it = print length }}} I guess the trickiest part will be figuring out what function is underapplied. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9613> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

[GHC] #9677: "operation not permitted" when running tests on Windows
by GHC 15 Dec '15

15 Dec '15

#9677: "operation not permitted" when running tests on Windows -------------------------------------+------------------------------------- Reporter: gintas | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Windows Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- When I run ghc tests on windows using "make test", I see instances of the following: =====> T5442d(normal) 86 of 4093 [0, 1, 0] cd ./cabal && $MAKE -s --no-print-directory T5442d </dev/null >T5442d.run.stdout 2>T5442d.run.stderr [Errno 1] Operation not permitted: './cabal/package.conf.T5442d.global' [Errno 90] Directory not empty: './cabal/package.conf.T5442d.global' [Errno 1] Operation not permitted: './cabal/package.conf.T5442d.user' [Errno 90] Directory not empty: './cabal/package.conf.T5442d.user' [Errno 1] Operation not permitted: './cabal/package.conf.T5442d.extra' Not sure if these are legitimately harmful, but something is going wrong. I am running ghc head on latest msys2. I also tried running the process as administrator to rule out permission issues due to handling symlinks. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9677> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 1

[GHC] #9687: Missing Typeable instances for built-in types
by GHC 15 Dec '15

15 Dec '15

#9687: Missing Typeable instances for built-in types -------------------------------------+------------------------------------- Reporter: selinger | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- According to the PolyTypeable wiki, https://ghc.haskell.org/trac/ghc/wiki/GhcKinds/PolyTypeable, "Users can no longer giving manual instances of `Typeable`; they must be derived." I cannot figure out how to do this for built-in types with missing `Typeable` instances. For example, my code requires a `Typeable` instance for 8-tuples. However, `Typeable` instances are natively only defined for 2- to 7-tuples: {{{ Prelude> :m Data.Typeable Prelude Data.Typeable> typeOf (1) Integer Prelude Data.Typeable> typeOf (1,2) (Integer,Integer) Prelude Data.Typeable> typeOf (1,2,3) (Integer,Integer,Integer) Prelude Data.Typeable> typeOf (1,2,3,4) (Integer,Integer,Integer,Integer) Prelude Data.Typeable> typeOf (1,2,3,4,5) (Integer,Integer,Integer,Integer,Integer) Prelude Data.Typeable> typeOf (1,2,3,4,5,6) (Integer,Integer,Integer,Integer,Integer,Integer) Prelude Data.Typeable> typeOf (1,2,3,4,5,6,7) (Integer,Integer,Integer,Integer,Integer,Integer,Integer) Prelude Data.Typeable> typeOf (1,2,3,4,5,6,7,8) <interactive>:10:1: No instance for (Typeable (,,,,,,,)) arising from a use of ‘typeOf’ In the expression: typeOf (1, 2, 3, 4, 5, 6, 7, 8) In an equation for ‘it’: it = typeOf (1, 2, 3, 4, 5, 6, 7, 8) Prelude Data.Typeable> }}} Since my code does not define the type of 8-tuples (it is defined in the Prelude, or even in the compiler), it is not possible to "derive" a Typeable instance for it. With the old Typeable class, I could just define it myself: {{{ instance (Typeable a, Typeable b, Typeable c, Typeable d, Typeable e, Typeable f, Typeable g, Typeable h) => Typeable (a,b,c,d,e,f,g,h) where typeOf _ = typerep where typerep = mkTyCon3 "GHC" "Tuple" "(,,,,,,,)" `mkTyConApp` [ typeOf (undefined :: a), typeOf (undefined :: b), typeOf (undefined :: c), typeOf (undefined :: d), typeOf (undefined :: e), typeOf (undefined :: f), typeOf (undefined :: g), typeOf (undefined :: h) ] }}} With the new `Typeable` class, I am completely stumped. How can I "derive" an instance for a pre-defined type? I think this is a bug. `Typeable` instances should be pre-defined for all pre-defined types, including //n//-tuples for all //n//. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9687> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9983: configure script invokes ghc with LDFLAGS during cross-builds
by GHC 15 Dec '15

15 Dec '15

#9983: configure script invokes ghc with LDFLAGS during cross-builds -------------------------------------+------------------------------------- Reporter: newsham | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build | Version: 7.8.4 System | Operating System: Unknown/Multiple Keywords: | Type of failure: Building GHC Architecture: | failed Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- When building ghc, the aclocal.m4 settings direct "configure" to use the provided LDFLAGS as GHC_LDFLAGS, which are later used to invoke the host's GHC: https://github.com/ghc/ghc/blob/ghc-7.8/aclocal.m4#L1820 This is undesirable when performing a cross-build, in which case the LDFLAGS are used to specify the flags for use when linking for the target and not when linking on the build host. rwbarton@freenode believes that the normal CFLAGS, LDFLAGS, LIBS, etc. should never have an affect on the build host behavior. Either this policy needs to be enforced or a separate set of flags needs to be introduced to allow setting the target flags separately from the build host flags. To reproduce, "./configure LDFLAGS=bogus" and observe the failure in ghc- pwd, which is used on the build host. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9983> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2