- ghc-tickets - Haskell.org

[GHC] #12802: prototype mismatch with EFF_ from unregisterisered GHC when building ieee754
by GHC 30 Nov '16

30 Nov '16

#12802: prototype mismatch with EFF_ from unregisterisered GHC when building ieee754 -------------------------------------+------------------------------------- Reporter: clint | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 8.0.1 Keywords: | Operating System: Linux Architecture: | Type of failure: Incorrect result Unknown/Multiple | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Where building ieee754 succeeded with GHC 7.10, it fails with 8.0 on platforms without registerised builds, for example arm64: {{{ [1 of 2] Compiling Numeric.IEEE ( Numeric/IEEE.hs, dist- ghc/build/Numeric/IEEE.o ) In file included from /tmp/ghc8e40_0/ghc_2.hc:3:0: error: /tmp/ghc8e40_0/ghc_2.hc:2448:6: error: error: conflicting types for 'nextup' EFF_(nextup); ^ /usr/lib/ghc/include/Stg.h:228:24: error: note: in definition of macro 'EFF_' #define EFF_(f) void f() /* See Note [External function prototypes] */ ^ In file included from /usr/include/features.h:364:0: error: 0, from /usr/include/math.h:26, from /usr/lib/ghc/include/Stg.h:74, from /tmp/ghc8e40_0/ghc_2.hc:3: /usr/include/aarch64-linux-gnu/bits/mathcalls.h:301:1: error: note: previous declaration of 'nextup' was here __MATHCALL (nextup,, (_Mdouble_ __x)); ^ In file included from /tmp/ghc8e40_0/ghc_2.hc:3:0: error: /tmp/ghc8e40_0/ghc_2.hc:2501:6: error: error: conflicting types for 'nextup' EFF_(nextup); ^ /usr/lib/ghc/include/Stg.h:228:24: error: note: in definition of macro 'EFF_' #define EFF_(f) void f() /* See Note [External function prototypes] */ ^ In file included from /usr/include/features.h:364:0: error: 0, from /usr/include/math.h:26, from /usr/lib/ghc/include/Stg.h:74, from /tmp/ghc8e40_0/ghc_2.hc:3: /usr/include/aarch64-linux-gnu/bits/mathcalls.h:301:1: error: note: previous declaration of 'nextup' was here __MATHCALL (nextup,, (_Mdouble_ __x)); ^ In file included from /tmp/ghc8e40_0/ghc_2.hc:3:0: error: /tmp/ghc8e40_0/ghc_2.hc:2554:6: error: error: conflicting types for 'nextupf' EFF_(nextupf); ^ /usr/lib/ghc/include/Stg.h:228:24: error: note: in definition of macro 'EFF_' #define EFF_(f) void f() /* See Note [External function prototypes] */ ^ In file included from /usr/lib/ghc/include/Stg.h:74:0: error: 0, from /tmp/ghc8e40_0/ghc_2.hc:3: /usr/include/aarch64-linux-gnu/bits/mathcalls.h:301:1: error: note: previous declaration of 'nextupf' was here __MATHCALL (nextup,, (_Mdouble_ __x)); ^ In file included from /tmp/ghc8e40_0/ghc_2.hc:3:0: error: /tmp/ghc8e40_0/ghc_2.hc:2607:6: error: error: conflicting types for 'nextupf' EFF_(nextupf); ^ /usr/lib/ghc/include/Stg.h:228:24: error: note: in definition of macro 'EFF_' #define EFF_(f) void f() /* See Note [External function prototypes] */ ^ In file included from /usr/lib/ghc/include/Stg.h:74:0: error: 0, from /tmp/ghc8e40_0/ghc_2.hc:3: /usr/include/aarch64-linux-gnu/bits/mathcalls.h:301:1: error: note: previous declaration of 'nextupf' was here __MATHCALL (nextup,, (_Mdouble_ __x)); ^ In file included from /tmp/ghc8e40_0/ghc_2.hc:3:0: error: /tmp/ghc8e40_0/ghc_2.hc:2660:6: error: error: conflicting types for 'nextdown' EFF_(nextdown); ^ /usr/lib/ghc/include/Stg.h:228:24: error: note: in definition of macro 'EFF_' #define EFF_(f) void f() /* See Note [External function prototypes] */ ^ In file included from /usr/include/features.h:364:0: error: 0, from /usr/include/math.h:26, from /usr/lib/ghc/include/Stg.h:74, from /tmp/ghc8e40_0/ghc_2.hc:3: /usr/include/aarch64-linux-gnu/bits/mathcalls.h:299:1: error: note: previous declaration of 'nextdown' was here __MATHCALL (nextdown,, (_Mdouble_ __x)); ^ In file included from /tmp/ghc8e40_0/ghc_2.hc:3:0: error: /tmp/ghc8e40_0/ghc_2.hc:2713:6: error: error: conflicting types for 'nextdown' EFF_(nextdown); ^ /usr/lib/ghc/include/Stg.h:228:24: error: note: in definition of macro 'EFF_' #define EFF_(f) void f() /* See Note [External function prototypes] */ ^ In file included from /usr/include/features.h:364:0: error: 0, from /usr/include/math.h:26, from /usr/lib/ghc/include/Stg.h:74, from /tmp/ghc8e40_0/ghc_2.hc:3: /usr/include/aarch64-linux-gnu/bits/mathcalls.h:299:1: error: note: previous declaration of 'nextdown' was here __MATHCALL (nextdown,, (_Mdouble_ __x)); ^ In file included from /tmp/ghc8e40_0/ghc_2.hc:3:0: error: /tmp/ghc8e40_0/ghc_2.hc:2766:6: error: error: conflicting types for 'nextdownf' EFF_(nextdownf); ^ /usr/lib/ghc/include/Stg.h:228:24: error: note: in definition of macro 'EFF_' #define EFF_(f) void f() /* See Note [External function prototypes] */ ^ In file included from /usr/lib/ghc/include/Stg.h:74:0: error: 0, from /tmp/ghc8e40_0/ghc_2.hc:3: /usr/include/aarch64-linux-gnu/bits/mathcalls.h:299:1: error: note: previous declaration of 'nextdownf' was here __MATHCALL (nextdown,, (_Mdouble_ __x)); ^ In file included from /tmp/ghc8e40_0/ghc_2.hc:3:0: error: /tmp/ghc8e40_0/ghc_2.hc:2819:6: error: error: conflicting types for 'nextdownf' EFF_(nextdownf); ^ /usr/lib/ghc/include/Stg.h:228:24: error: note: in definition of macro 'EFF_' #define EFF_(f) void f() /* See Note [External function prototypes] */ ^ In file included from /usr/lib/ghc/include/Stg.h:74:0: error: 0, from /tmp/ghc8e40_0/ghc_2.hc:3: /usr/include/aarch64-linux-gnu/bits/mathcalls.h:299:1: error: note: previous declaration of 'nextdownf' was here __MATHCALL (nextdown,, (_Mdouble_ __x)); ^ `gcc' failed in phase `C Compiler'. (Exit code: 1) }}} {{{ [("Project name","The Glorious Glasgow Haskell Compilation System") ,("GCC extra via C opts"," -fwrapv -fno-builtin") ,("C compiler command","/usr/bin/gcc") ,("C compiler flags"," -fno-stack-protector") ,("C compiler link flags"," -fuse-ld=gold -Wl,-z,noexecstack") ,("Haskell CPP command","/usr/bin/gcc") ,("Haskell CPP flags","-E -undef -traditional") ,("ld command","/usr/bin/ld.gold") ,("ld flags"," -z noexecstack") ,("ld supports compact unwind","YES") ,("ld supports build-id","YES") ,("ld supports filelist","NO") ,("ld is GNU ld","YES") ,("ar command","/usr/bin/ar") ,("ar flags","q") ,("ar supports at file","YES") ,("touch command","touch") ,("dllwrap command","/bin/false") ,("windres command","/bin/false") ,("libtool command","libtool") ,("perl command","/usr/bin/perl") ,("cross compiling","NO") ,("target os","OSLinux") ,("target arch","ArchARM64") ,("target word size","8") ,("target has GNU nonexec stack","True") ,("target has .ident directive","True") ,("target has subsections via symbols","False") ,("Unregisterised","YES") ,("LLVM llc command","llc-3.7") ,("LLVM opt command","opt-3.7") ,("Project version","8.0.1") ,("Project Git commit id","4986837f8168cacf95c24fecc84d7b36c47f3c11") ,("Booter version","7.10.3") ,("Stage","2") ,("Build platform","aarch64-unknown-linux") ,("Host platform","aarch64-unknown-linux") ,("Target platform","aarch64-unknown-linux") ,("Have interpreter","YES") ,("Object splitting supported","NO") ,("Have native code generator","NO") ,("Support SMP","NO") ,("Tables next to code","YES") ,("RTS ways","l debug thr thr_debug thr_l thr_p dyn debug_dyn thr_dyn thr_debug_dyn l_dyn thr_l_dyn thr_debug_p") ,("RTS expects libdw","NO") ,("Support dynamic-too","YES") ,("Support parallel --make","YES") ,("Support reexported-modules","YES") ,("Support thinning and renaming package flags","YES") ,("Requires unified installed package IDs","YES") ,("Uses package keys","YES") ,("Uses unit IDs","YES") ,("Dynamic by default","NO") ,("GHC Dynamic","YES") ,("GHC Profiled","NO") ,("Leading underscore","NO") ,("Debug on","False") ,("LibDir","/usr/lib/ghc") ,("Global Package DB","/usr/lib/ghc/package.conf.d") ] }}} The same is true for mips64el, s390x, alpha, hppa, m68k, sh4, sparc64, and I imagine mips and mipsel as well. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12802> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 4

Re: [GHC] #2168: ghci should show haddock comments for identifier
by GHC 30 Nov '16

30 Nov '16

#2168: ghci should show haddock comments for identifier -------------------------------------+------------------------------------- Reporter: j.waldmann | Owner: Type: feature request | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.8.2 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by gershomb): Adamse: I think this would be great for haddock too, and am excited someone wants to proceed! I know that a number of people have an interest in this, and am trying to get some further eyes on the proposal to confirm it makes sense, but on first glance it looks like a reasonable approach. Even step 1 on its own would be great, as an opportunity for lots of tooling (ghci included) to start making use of the data. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2168#comment:26> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #12799: Itimer.c doesn't compile on iOS non-threaded RTS
by GHC 30 Nov '16

30 Nov '16

#12799: Itimer.c doesn't compile on iOS non-threaded RTS -------------------------------------+------------------------------------- Reporter: bgamari | Owner: Type: bug | Status: new Priority: high | Milestone: 8.2.1 Component: Runtime | Version: 8.0.1 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC Unknown/Multiple | failed Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The RTS uses the pthread-based `Itimer` implementation due to the bizarrely crippled timer mechanisms provided imposed by that platform. This broke in 999c464da36e925bd4ffea34c94d3a7b3ab0135c which fixed the pthreads implementation to correctly pause when unneeded. In doing this, however, it introduced a dependency on the RTS's synchronization primitives provided by `OSThreads.c` (e.g. `Condition`, `Mutex`). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12799> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12851: Regression: GHC doesn't show filepaths by default anymore
by GHC 30 Nov '16

30 Nov '16

#12851: Regression: GHC doesn't show filepaths by default anymore -------------------------------------+------------------------------------- Reporter: hvr | Owner: Type: bug | Status: new Priority: low | Milestone: 8.2.1 Component: Compiler | Version: 8.1 Keywords: regression | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Sorry for chiming in so late, I didn't notice #12807 and I didn't build GHC HEAD for several days, otherwise I would have cried out loud sooner. I'm deliberately declaring this a regression since I consider this a bad default. And not for the mere fact that change is bad ;-) Don't get me wrong, I can see usefulness in the `-fno-show-source-paths` feature (although I consider it inconsistent, see below), but it's a bad default because in my workflows I rely on seeing the source-path ''by default'', and I see no way to restore this as the default behaviour of GHC short of patching GHC. {{{ [1 of 1] Compiling Control.Concurrent.STMSupply (.hs -> .o) }}} First of all, if we drop filepaths, then please drop them completely, either I need more information about which `.hs` file was used as source, or I don't need it at all, so this ` (.hs -> .o)` suffix is just noise to me; not the least because the `-> .o` part carries almost no information for me. If the premise of `-fno-show-source-paths` is that we know how we called GHC and thereby know what is being compiled, showing `(.hs -> .o)` is pointless. Morever, `-f(no-)show-source-paths` is a lie/misnomer, as it doesn't only control the *source* path display, but *also* the *output* path display! Also, when invoking GHC, and pass it multiple include folders, sometimes GHC picks up the wrong module (or rather one I didn't intend), having it print the source file path by default has been a big timesaver to me, detecting when I was barking up the wrong source-file while figuring out why stuff didn't work. Finally, this also breaks my shell-based workflow because I'm used to copy'n'paste filepaths from GHC's output, especially for longer source- paths where tab-completing my way to the source path is too tedious. This is just the first impression I got while being exposed to this UI change today, there may be other regressions I'd notice when having to use this for longer. So, in summary I propose to - Make `-fshow-source-paths` the default again - drop the `(.hs->.o)` suffix in `-fno-show-show-source-paths` - consider a better name; actually, I can see cases where you want to omit only the output-path display (since it's imho often less interesting to know the output files names; even though sometimes you may want to know it since it can be affected in a non-obvious way by output-dir flags), e.g. maybe - Have `-f(no-)show-source-paths` control the source-path display - Have `-f(no-)show-output-paths` control the output-path display - As a compromise, consider `-fshow-source-paths -fno-show-output- paths` becoming the new default. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12851> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 13

[GHC] #11629: reify returns Dec that use ConT instead of PromotedT
by GHC 30 Nov '16

30 Nov '16

#11629: reify returns Dec that use ConT instead of PromotedT -------------------------------------+------------------------------------- Reporter: aavogt | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Template | Version: 7.10.2 Haskell | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11629> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 9

[GHC] #9007: relocation R_X86_64_32 against `stg_CHARLIKE_closure' can not be used when making a shared object
by GHC 30 Nov '16

30 Nov '16

#9007: relocation R_X86_64_32 against `stg_CHARLIKE_closure' can not be used when making a shared object ----------------------------------+---------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.9 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: Building GHC failed Unknown/Multiple | Test Case: Difficulty: Unknown | Blocking: Blocked By: | Related Tickets: | ----------------------------------+---------------------------------------- Building HEAD on Debian wheezy with the Debian packaging setup fails: {{{ configure: Building in-tree ghc-pwd /usr/bin/ld: utils/ghc-pwd/dist-boot/Main.o: relocation R_X86_64_32 against `stg_CHARLIKE_closure' can not be used when making a shared object; recompile with -fPIC utils/ghc-pwd/dist-boot/Main.o: could not read symbols: Bad value collect2: error: ld returned 1 exit status configure: error: Building ghc-pwd failed }}} http://deb.haskell.org/dailies/2014-04-16/ghc_7.9.20140416-0.daily_amd64.bu… This is possibly related to the Hardening flags added by Debian: {{{ ~ $ dpkg-buildflags --get LDFLAGS -Wl,-z,relro ~ $ dpkg-buildflags --get CFLAGS -g -O2 -fstack-protector --param=ssp-buffer-size=4 -Wformat -Werror =format-security }}} Other related bug might be #3668 and https://bugs.debian.org/712228 I’ll disable the hardening flags and see if it helps. The error first occurred 2014-03-27. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9007> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 24

[GHC] #11656: Alllow static pointers to local closed definitions
by GHC 29 Nov '16

29 Nov '16

#11656: Alllow static pointers to local closed definitions -------------------------------------+------------------------------------- Reporter: mboes | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.3 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- A limitation of the original patch implementing `-XStaticPointers` is that while the following all work, {{{#!hs t1 = static not t2 = static (\x -> case x of True -> False; False -> True) }}} the below does not: {{{#!hs t3 = static foo where foo True = False }}} Yet `foo` is perfectly "static": it's a closed expression that can readily be floated to top-level. So in short: `-XStaticPointers` should not consider only expressions with top-level identifiers, but in general any closed expression (which may involve local closed identifiers too). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/11656> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 21

[GHC] #12869: getChar doesn't work on a new Windows build
by GHC 29 Nov '16

29 Nov '16

#12869: getChar doesn't work on a new Windows build -------------------------------------+------------------------------------- Reporter: Darwin226 | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime | Version: 7.10.3 System | Keywords: | Operating System: Windows Architecture: x86_64 | Type of failure: Incorrect result (amd64) | at runtime Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Last night I updated my PC to the 14965 Windows insider build. Today I notice that `getLine` no longer terminates (pressing enter just goes to a new line), but I'm suspecting that the root cause it that `getChar` returns `'\NUL'` no mather what is input. I've tried this both GHCi and in a compiled program. This is only broken if I set my codepage to 65001 (UTF-8). If I set it to something like 850 it works as it should. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12869> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 3

[GHC] #12888: ‘Identity instance’: Outputable SDoc
by GHC 29 Nov '16

29 Nov '16

#12888: ‘Identity instance’: Outputable SDoc -------------------------------------+------------------------------------- Reporter: Iceland_jack | Owner: Type: feature | Status: new request | Priority: normal | Milestone: Component: GHC API | Version: 8.0.1 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- Is there reason why there isn't an ‘identity instance’¹ for `Outputable`? {{{#!hs class Outputable a where ppr :: a -> SDoc instance Outputabe SDoc where ppr :: SDoc -> SDoc ppr = id }}} A benefit: lets me always use `pprTraceIt :: Outputable a => String -> a -> a`, I know I can use `pprTrace` but I like not having to think about the type of what I'm tracing and neither functions work to debug something like `Either SDoc Name`. ---- ¹ For lack of a better term, something like {{{#!hs class Foo a where foo :: a -> A instance Foo A where foo :: A -> A foo = id @A }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12888> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #12892: Improve type safety in the RTS
by GHC 29 Nov '16

29 Nov '16

#12892: Improve type safety in the RTS -------------------------------------+------------------------------------- Reporter: dobenour | Owner: Type: task | Status: new Priority: normal | Milestone: Component: Runtime | Version: 8.0.1 System | Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Test Case: | Blocked By: Blocking: | Related Tickets: Differential Rev(s): | Wiki Page: -------------------------------------+------------------------------------- The RTS must (by virtue of its job) be type unsafe, but it doesn't need to be gratuitously so. Currently, there are a lot of dubious conversions, pointer casts that cast away `const`, and other questionable practices. This task covers improving the RTS's type safety. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/12892> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0