March 2015 - ghc-tickets

Re: [GHC] #5376: Quotation in System.Process.system for Windows
by GHC 19 Mar '15

19 Mar '15

#5376: Quotation in System.Process.system for Windows -------------------------------------+------------------------------------- Reporter: simonpj | Owner: snoyberg Type: bug | Status: new Priority: low | Milestone: 7.12.1 Component: Core Libraries | Version: 7.0.4 Resolution: | Keywords: Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * os: Unknown/Multiple => Windows -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/5376#comment:11> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

Re: [GHC] #2725: Remove Hack in compiler/nativeGen/X86/CodeGen.hs
by GHC 19 Mar '15

19 Mar '15

#2725: Remove Hack in compiler/nativeGen/X86/CodeGen.hs -------------------------------------+------------------------------------- Reporter: clemens | Owner: Type: task | thoughtpolice Priority: low | Status: new Component: Compiler (NCG) | Milestone: 7.12.1 Resolution: | Version: 6.11 Operating System: Unknown/Multiple | Keywords: codegen Type of failure: None/Unknown | Architecture: Blocked By: | Unknown/Multiple Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * type: bug => task Comment: From Phab:D694: "If there still are broken binutils around, then maybe we should simply leave the current code (which works) in for another 10 years." -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/2725#comment:19> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #10165: Win32 broken with GHC 7.10 RC3
by GHC 19 Mar '15

19 Mar '15

#10165: Win32 broken with GHC 7.10 RC3 ---------------------------------------+---------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 7.10.1-rc3 Keywords: | Operating System: Windows Architecture: x86 | Type of failure: Runtime crash Test Case: | Blocked By: Blocking: | Related Tickets: Differential Revisions: | ---------------------------------------+---------------------------------- Using the 32bit Windows build of GHC 7.10 RC3 (ghc-7.10.0.20150316) I can't load the Win32 library. I get the problem: {{{ C:\Neil>ghci GHCi, version 7.10.0.20150316: http://www.haskell.org/ghc/ :? for help Prelude> import System.Win32 Prelude System.Win32> wRITE_DAC <interactive>: C:\ghc\ghc-7.10.0.20150316\lib\Win32_6dnIMpnCmqmCdDB983aKnr\HSWin 32-2.3.1.0-6dnIMpnCmqmCdDB983aKnr.o: unknown symbol `_SetWindowLongPtrW' ghc.exe: unable to load package `Win32-2.3.1.0' }}} This seems very serious, and breaks all packages that indirectly depend on the Win32 module (which on Windows is most of them). -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10165> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 8

Re: [GHC] #7191: hsc2hs can't treat absolute path correctly on Windows.
by GHC 19 Mar '15

19 Mar '15

#7191: hsc2hs can't treat absolute path correctly on Windows. -------------------------------------+------------------------------------- Reporter: shelarcy | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: hsc2hs | Version: 7.8.1-rc2 Resolution: worksforme | Keywords: Operating System: Windows | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Changes (by thomie): * status: infoneeded => closed * resolution: => worksforme Comment: Replying to [comment:12 gintas]: > No, I am sure I was using hsc2hs from Haskell Platform 2014.2.0.0. I just retested, it works perfectly fine. edwinhere: please reopen again if you're still having problems. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/7191#comment:15> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9572: nofib target for just building should be part of validate
by GHC 19 Mar '15

19 Mar '15

#9572: nofib target for just building should be part of validate -------------------------------------+------------------------------------- Reporter: ezyang | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: NoFib benchmark | Version: 7.8.2 suite | Operating System: Keywords: | Unknown/Multiple Architecture: Unknown/Multiple | Type of failure: Difficulty: Unknown | None/Unknown Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- nofib is never run during validates, which makes it easy to bitrot (c.f. AMP changes). It would be better if: 1. We had a build target for just building nofib tests, not running them, (maybe optionally with optimizations turned off, or just `-fno-code`) and 2. This build target was executed during validates This should strike a balance between wanting to avoid having to spend a lot of time running the benchmarks on validate, while still exercising the nofib tests to some degree. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9572> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9609: GHCi gives overly specific error message for unknown constructor
by GHC 19 Mar '15

19 Mar '15

#9609: GHCi gives overly specific error message for unknown constructor -------------------------------------+------------------------------------- Reporter: dfeuer | 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: -------------------------------------+------------------------------------- What happens: {{{ Prelude> :i Fish Top level: Not in scope: data constructor ‘Fish’ }}} This is potentially confusing because `:i` can be used for type constructors and classes, as well as data constructors. What I think should happen: {{{ Prelude> :i Fish Top level: Not in scope: constructor or class ‘Fish’ }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9609> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9956: Command line flag deprecated warning could be annoying for -Werror users
by GHC 19 Mar '15

19 Mar '15

#9956: Command line flag deprecated warning could be annoying for -Werror users -------------------------------------+------------------------------------- Reporter: ezyang | Owner: ezyang Type: bug | Status: new Priority: high | Milestone: 7.10.1 Component: Compiler | Version: 7.11 Keywords: | Operating System: Unknown/Multiple Architecture: | Type of failure: None/Unknown Unknown/Multiple | Blocked By: Test Case: | Related Tickets: Blocking: | Differential Revisions: | -------------------------------------+------------------------------------- In 7.10 we deprecated the poorly named `-package-name` for `-this-package- key`. However, I was working with GHC's validate script and I noticed that this behavior actually might be pretty annoying, because it causes GHC to fail on `-Werror`, and there doesn't seem to be any way of turning off this behavior. So maybe we should add a -fno-warn flag which controls flag warnings. But old GHCs wouldn't accept that flag, so it doesn't make it any more convenient for people to keep their old build scripts running while squelching the warning. Or we could drop the deprecation warning for now and start bleating about it next release. Setting priority high because whatever we decide to do, we need to decide it before 7.10 release. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9956> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 2

[GHC] #9392: "\n" is displayed weirdly in error messages
by GHC 19 Mar '15

19 Mar '15

#9392: "\n" is displayed weirdly in error messages -------------------------------------+------------------------------------- Reporter: Artyom.Kazak | Owner: Type: bug | Status: new Priority: low | Milestone: Component: Compiler | Version: 7.8.3 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Other Blocked By: | Test Case: Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Observe: {{{ Prelude> "a\nb" + () <interactive>:2:10: Couldn't match expected type ‘[Char]’ with actual type ‘()’ In the second argument of ‘(+)’, namely ‘()’ In the expression: "a\n\ \b" + () }}} Moreover, if “\n” is at the end of the string, it simply gets eaten: {{{ Prelude> "a\n" + () <interactive>:3:9: Couldn't match expected type ‘[Char]’ with actual type ‘()’ In the second argument of ‘(+)’, namely ‘()’ In the expression: "a" + () }}} It happens in GHC as well as GHCi. Tested on 7.8.3. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9392> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 5

Re: [GHC] #4436: Render multi-line strings more prettily in Template Haskell
by GHC 19 Mar '15

19 Mar '15

#4436: Render multi-line strings more prettily in Template Haskell -------------------------------------+------------------------------------- Reporter: simonpj | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.12.3 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: Type of failure: None/Unknown | Unknown/Multiple Blocked By: | Test Case: th/T4436 Related Tickets: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- Comment (by thomie): For later reference, the commit ids of the above 3 patches are: 98bef4db89b57b01c8f557a027dbeb8ae72407c9 4041be6185f6df8065b84ef10bb664715ca7745d f63a3ead88bc37f2105dcd1def902aef5a3d5944 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/4436#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 0

[GHC] #9873: Use CONF_GCC_LINKER_OPTS_STAGE2 only in stage2
by GHC 19 Mar '15

19 Mar '15

#9873: Use CONF_GCC_LINKER_OPTS_STAGE2 only in stage2 -------------------------------------+------------------------------------- Reporter: nomeata | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 7.9 Keywords: | Operating System: Architecture: Unknown/Multiple | Unknown/Multiple Difficulty: Unknown | Type of failure: Blocked By: | None/Unknown Related Tickets: | Test Case: | Blocking: | Differential Revisions: -------------------------------------+------------------------------------- On ARM, we want to make sure that GHC uses the gold linker. In order to achieve that, we need to get `-fuse-ld=gold` into SettingsCCompilerLinkFlags in the settings. This field is filled with only CONF_GCC_LINKER_OPTS_STAGE2. So we want that flag to show up there. But this variable is used in other places as well. For example, the configuration of tinfo fails: {{{ $ make libraries/terminfo/dist-boot/package-data.mk ===--- building phase 0 make -r --no-print-directory -f ghc.mk phase=0 phase_0_builds libraries/terminfo/ghc.mk:3: libraries/terminfo/dist-boot/package-data.mk: Datei oder Verzeichnis nicht gefunden "inplace/bin/ghc-cabal" configure libraries/terminfo dist-boot "" --with- ghc="/usr/bin/ghc" --with-ghc-pkg="/usr/bin/ghc-pkg" --package- db=/home/jojo/build/haskell/ghc/libraries/bootstrapping.conf --disable- library-for-ghci --enable-library-vanilla --disable-library-profiling --disable-shared --with-hscolour="/usr/bin/HsColour" --configure- option=CFLAGS=" -fno-stack-protector " --configure-option=LDFLAGS=" -fuse-ld=gold " --configure-option=CPPFLAGS=" " --gcc-options=" -fno- stack-protector -fuse-ld=gold " --constraint "binary == 0.7.1.0" --constraint "Cabal == 1.21.1.0" --constraint "hpc == 0.6.0.2" --constraint "bin-package-db == 0.0.0.0" --constraint "hoopl == 3.10.0.2" --constraint "transformers == 0.4.2.0" --constraint "terminfo == 0.4.0.0" --with-gcc="/usr/bin/gcc" --configure-option=--with- cc="/usr/bin/gcc" --with-ar="/usr/bin/ar" --with-alex="/usr/bin/alex" --with-happy="/usr/bin/happy" Configuring terminfo-0.4.0.0... configure: WARNING: unrecognized options: --with-compiler, --with-gcc checking for gcc... /usr/bin/gcc checking whether the C compiler works... yes checking for C compiler default output file name... a.out checking for suffix of executables... checking whether we are cross compiling... no checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /usr/bin/gcc accepts -g... yes checking for /usr/bin/gcc option to accept ISO C89... none needed checking how to run the C preprocessor... /usr/bin/gcc -E checking for grep that handles long lines and -e... /bin/grep checking for egrep... /bin/grep -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking ncurses.h usability... yes checking ncurses.h presence... yes checking for ncurses.h... yes checking for setupterm in -ltinfo... yes configure: creating ./config.status config.status: creating terminfo.buildinfo configure: WARNING: unrecognized options: --with-compiler, --with-gcc ghc-cabal: Missing dependency on a foreign library: * Missing C library: tinfo This problem can usually be solved by installing the system package that provides this library (you may need the "-dev" version). If the library is already installed but in a non-standard location then you can use the flags --extra-include-dirs= and --extra-lib-dirs= to specify where it is. libraries/terminfo/ghc.mk:3: recipe for target 'libraries/terminfo/dist- boot/package-data.mk' failed make[1]: *** [libraries/terminfo/dist-boot/package-data.mk] Error 1 Makefile:71: recipe for target 'libraries/terminfo/dist-boot/package- data.mk' failed make: *** [libraries/terminfo/dist-boot/package-data.mk] Error 2 }}} The problem (unfortunately, not very visible) is that `ghc-cabal` calls `gcc` to test if the C libaries are available. It uses the linker flags that it’s being told to use from the host GHC (here: 7.6.3), which contains the usual: {{{ $ ghc --info |fgrep 'C compiler flags' ,("C compiler flags"," -fno-stack-protector -Wl,--hash-size=31 -Wl ,--reduce-memory-overheads") }}} But to that it adds `-fuse-ld-gold` because `ghc-cabal` is gets `" --gcc- options=" -fno-stack-protector -fuse-ld=gold "` passed. So the build system should not pass flags from `CONF_GCC_LINKER_OPTS_STAGE2` anywhere besides gcc when used *by the stage 2 ghc* during linking. The chain of variables leading to this can be seen here: {{{ $ git grep CONFIGURE_LDFLAGS rules/build-package-data.mk:$1_$2_CONFIGURE_LDFLAGS = $$(SRC_LD_OPTS) $$(CONF_GCC_LINKER_OPTS_STAGE$3) $$($1_LD_OPTS) $$($1_$2_LD_OPTS) rules/build-package-data.mk:$1_$2_CONFIGURE_OPTS += --configure- option=LDFLAGS="$$($1_$2_CONFIGURE_LDFLAGS)" rules/build-package-data.mk:$1_$2_CONFIGURE_OPTS += --gcc- options="$$($1_$2_CONFIGURE_CFLAGS) $$($1_$2_CONFIGURE_LDFLAGS)" }}} I’m currently experimenting with a patch that simply does not use `CONF_GCC_LINKER_OPTS_STAGE` anywhere besides when defining `SettingsCCompilerLinkFlags`, but I’m afraid that this might introduce new unwanted behaviour. But since `ghc-cabal` reads gcc-flags from `ghc --info`, maybe that channel of information is sufficient. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/9873> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

1 11