From trac at galois.com Sat Dec 1 03:45:26 2007 From: trac at galois.com (GHC) Date: Sat Dec 1 03:41:11 2007 Subject: [GHC] #1940: GHCi triggers firewall by sending unexpected packet In-Reply-To: <049.546c2ee041c20f9b1787468b8e40cdee@localhost> References: <049.546c2ee041c20f9b1787468b8e40cdee@localhost> Message-ID: <058.11f22902cfcb12c34a5e73fac4c502c5@localhost> #1940: GHCi triggers firewall by sending unexpected packet ------------------------+--------------------------------------------------- Reporter: TimAttwood | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.8.1 Severity: trivial | Resolution: Keywords: firewall | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ------------------------+--------------------------------------------------- Comment (by TimAttwood): Yes, it only happens in GHCi, I haven't seen any compiled programs trigger the firewall unexpectedly. I'll post the packet info again next time it happens. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 1 08:06:14 2007 From: trac at galois.com (GHC) Date: Sat Dec 1 08:02:53 2007 Subject: [GHC] #1843: ghc 6.8.1 broken on Mac OS X Leopard PPC In-Reply-To: <044.ed2a345fe747cd9c97e2c67af33b571b@localhost> References: <044.ed2a345fe747cd9c97e2c67af33b571b@localhost> Message-ID: <053.1df2f486c335e1c2946df41aafb6b613@localhost> #1843: ghc 6.8.1 broken on Mac OS X Leopard PPC ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: 6.8.2 Component: Compiler | Version: 6.8.1 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by fons): * cc: alfonso.acosta@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 1 09:29:06 2007 From: trac at galois.com (GHC) Date: Sat Dec 1 09:24:50 2007 Subject: [GHC] #1940: GHCi triggers firewall by sending unexpected packet In-Reply-To: <049.546c2ee041c20f9b1787468b8e40cdee@localhost> References: <049.546c2ee041c20f9b1787468b8e40cdee@localhost> Message-ID: <058.1ffa4467ba9d8777ac7c136ccb14fb0e@localhost> #1940: GHCi triggers firewall by sending unexpected packet ------------------------+--------------------------------------------------- Reporter: TimAttwood | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: GHCi | Version: 6.8.1 Severity: trivial | Resolution: Keywords: firewall | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ------------------------+--------------------------------------------------- Changes (by igloo): * milestone: => _|_ -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 1 09:38:48 2007 From: trac at galois.com (GHC) Date: Sat Dec 1 09:34:30 2007 Subject: [GHC] #1109: lockFile: fd out of range In-Reply-To: <044.93e67f25468eba0b175752293ec78378@localhost> References: <044.93e67f25468eba0b175752293ec78378@localhost> Message-ID: <053.0d29f01226d40652b736a2cf2ac3e99e@localhost> #1109: lockFile: fd out of range ----------------------------+----------------------------------------------- Reporter: guest | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8.3 Component: libraries/base | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Linux | ----------------------------+----------------------------------------------- Changes (by igloo): * owner: simonmar => igloo * type: bug => merge -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 1 10:29:06 2007 From: trac at galois.com (GHC) Date: Sat Dec 1 10:24:48 2007 Subject: [GHC] #1950: Should not register packages when installing with DESTDIR option Message-ID: <042.990e084170639a2a6f0be52d5f2d21ab@localhost> #1950: Should not register packages when installing with DESTDIR option --------------------------+------------------------------------------------- Reporter: ajd | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.8.1 Severity: minor | Keywords: Testcase: | Architecture: Unknown Os: Linux | --------------------------+------------------------------------------------- After compiling GHC 6.8.1 configured with --prefix=/usr --libdir=/usr/lib/haskell, I installed it with DESTDIR=/usr/pkg/ghc/6.8.1-swp . During the installation, Cabal emitted some (ignored) warnings like so: {{{ Registering parallel-1.0.0.0... Reading package info from "dist/installed-pkg-config" ... done. /usr/lib/haskell//ghc-6.8.1/lib/parallel-1.0.0.0 doesn't exist or isn't a directory (ignoring) /usr/lib/haskell//ghc-6.8.1/lib/parallel-1.0.0.0 doesn't exist or isn't a directory (ignoring) cannot find libHSparallel-1.0.0.0.a on library path (ignoring) }}} In other words, the build system didn't tell Cabal that the files were not yet in their final place. I'm not sure if this does any harm, but it seems like, if DESTDIR is set, GHC ought to use Cabal's "copy" instead of "install" and then provide a separate Makefile target for registering all the libraries. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 1 15:44:19 2007 From: trac at galois.com (GHC) Date: Sat Dec 1 15:40:01 2007 Subject: [GHC] #1365: -fbyte-code is ignored in a OPTIONS_GHC pragma In-Reply-To: <047.0b0f638b3610964bc1921eacae64b292@localhost> References: <047.0b0f638b3610964bc1921eacae64b292@localhost> Message-ID: <056.8b580ce39fb7adfee1b822e2f47dbbba@localhost> #1365: -fbyte-code is ignored in a OPTIONS_GHC pragma -----------------------------+---------------------------------------------- Reporter: mnislaih | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: GHCi | Version: 6.7 Severity: minor | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: MacOS X | -----------------------------+---------------------------------------------- Changes (by mnislaih): * cc: mnislaih@gmail.com (added) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 1 18:53:59 2007 From: trac at galois.com (GHC) Date: Sat Dec 1 18:49:39 2007 Subject: [GHC] #1914: Reload is reloading all modules In-Reply-To: <047.444d64a09201d639672cf8328463b1bd@localhost> References: <047.444d64a09201d639672cf8328463b1bd@localhost> Message-ID: <056.1c8474576367f1cd5c48aa2ebcec2bbf@localhost> #1914: Reload is reloading all modules ----------------------+----------------------------------------------------- Reporter: simonmar | Owner: igloo Type: merge | Status: closed Priority: high | Milestone: 6.8.2 Component: GHCi | Version: 6.8.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 1 18:54:32 2007 From: trac at galois.com (GHC) Date: Sat Dec 1 18:50:14 2007 Subject: [GHC] #1744: treat byte order mark as zero-width whitespace In-Reply-To: <044.80a63f9733be4ce7239a3d4908550ac5@localhost> References: <044.80a63f9733be4ce7239a3d4908550ac5@localhost> Message-ID: <053.03774ba0faf4277cd33a83b9ea9eb1da@localhost> #1744: treat byte order mark as zero-width whitespace -------------------------------+-------------------------------------------- Reporter: igloo | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.8.2 Component: Compiler (Parser) | Version: 6.8 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | -------------------------------+-------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 1 18:55:24 2007 From: trac at galois.com (GHC) Date: Sat Dec 1 18:51:04 2007 Subject: [GHC] #1109: lockFile: fd out of range In-Reply-To: <044.93e67f25468eba0b175752293ec78378@localhost> References: <044.93e67f25468eba0b175752293ec78378@localhost> Message-ID: <053.772e99b6483bb1d52c3a903716c00868@localhost> #1109: lockFile: fd out of range ----------------------------+----------------------------------------------- Reporter: guest | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.8.3 Component: libraries/base | Version: 6.6 Severity: normal | Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Linux | ----------------------------+----------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: All four merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 1 20:18:15 2007 From: trac at galois.com (GHC) Date: Sat Dec 1 20:14:54 2007 Subject: [GHC] #1843: ghc 6.8.1 broken on Mac OS X Leopard PPC In-Reply-To: <044.ed2a345fe747cd9c97e2c67af33b571b@localhost> References: <044.ed2a345fe747cd9c97e2c67af33b571b@localhost> Message-ID: <053.e46044e0c6de6692b8bfd8617086a1cd@localhost> #1843: ghc 6.8.1 broken on Mac OS X Leopard PPC ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: 6.8.2 Component: Compiler | Version: 6.8.1 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | ----------------------+----------------------------------------------------- Comment (by igloo): Thanks for all the investigative work, everyone! Replying to [comment:21 ChrisKuklewicz]: > Here is a patch to compiler/nativeGen/MachineCodeGen.hs to use the desired instructions: [...] > More testing is needed, but I think I have a working stage2 compiler from the above without having to use -fvia-C. 6.8.2 is just around the corner, so do we think this patch is right? Should I apply it? Thanks Ian -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 1 20:20:09 2007 From: trac at galois.com (GHC) Date: Sat Dec 1 20:15:51 2007 Subject: [GHC] #1902: Restrict the type of (^), (^^), and add genericPower, genericPower' In-Reply-To: <044.28ddc14112703dac9e2f7a74565fc0f2@localhost> References: <044.28ddc14112703dac9e2f7a74565fc0f2@localhost> Message-ID: <053.3f9f41e28d5f99950bfdfca9dd90f223@localhost> #1902: Restrict the type of (^), (^^), and add genericPower, genericPower' ----------------------------+----------------------------------------------- Reporter: igloo | Owner: Type: proposal | Status: closed Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.8.1 Severity: normal | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => wontfix Comment: No consensus for the change. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sat Dec 1 20:32:45 2007 From: trac at galois.com (GHC) Date: Sat Dec 1 20:28:25 2007 Subject: [GHC] #1950: Should not register packages when installing with DESTDIR option In-Reply-To: <042.990e084170639a2a6f0be52d5f2d21ab@localhost> References: <042.990e084170639a2a6f0be52d5f2d21ab@localhost> Message-ID: <051.496844e6ee44399d37256eecc35eeb14@localhost> #1950: Should not register packages when installing with DESTDIR option --------------------------+------------------------------------------------- Reporter: ajd | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.8.1 Severity: minor | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | --------------------------+------------------------------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => wontfix Comment: When making debs, rpms etc this is exactly what we want to happen. The libraries are installed under the DESTDIR, but registered as if they were outside it. Then the deb or rpm can be installed just by unpacking outside of the DESTDIR. If this is causing you problems then please reopen, with more details of what you are trying to do. Thanks Ian -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 2 00:06:00 2007 From: trac at galois.com (GHC) Date: Sun Dec 2 00:01:41 2007 Subject: [GHC] #1950: Should not register packages when installing with DESTDIR option In-Reply-To: <042.990e084170639a2a6f0be52d5f2d21ab@localhost> References: <042.990e084170639a2a6f0be52d5f2d21ab@localhost> Message-ID: <051.f809296557d5c795bafb41b44c2c8f53@localhost> #1950: Should not register packages when installing with DESTDIR option --------------------------+------------------------------------------------- Reporter: ajd | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Build System | Version: 6.8.1 Severity: minor | Resolution: wontfix Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Linux | --------------------------+------------------------------------------------- Comment (by ajd): Okay, I didn't realize the registration actually worked when the packages weren't there. (I interpreted the warning message as a failure to register the package.) I guess there isn't a problem then. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 2 12:23:47 2007 From: trac at galois.com (GHC) Date: Sun Dec 2 12:19:29 2007 Subject: [GHC] #1951: Add "writer" Monad instance (, ) o to Control.Monad.Instances Message-ID: <044.d983d9ad1795cf879541d88d3708e6e6@localhost> #1951: Add "writer" Monad instance (,) o to Control.Monad.Instances -------------------------------+-------------------------------------------- Reporter: conal | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.8.1 Severity: normal | Keywords: Difficulty: Easy (1 hr) | Testcase: Architecture: Unknown | Os: Unknown -------------------------------+-------------------------------------------- I'd like to have a (,)-style writer instance alongside the (->)-based reader instance for Monad in {{{Control.Monad.Instances}}}. Here's the current reader: {{{ instance Monad ((->) r) where return = const f >>= k = \ r -> k (f r) r }}} and my proposed writer: {{{ instance Monoid o => Monad ((,) o) where return = pure (o,a) >>= f = (o `mappend` o', a') where (o',a') = f a }}} where the {{{return}}} definition relies on the Applicative instance of {{{((,) o)}}}. Written out explicitly, {{{ return a = (mempty,a) }}} {{{Control.Monad.Instances}}} will also need two new imports: {{{ import Data.Monoid (Monoid(..)) import Control.Applicative (pure) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 2 12:54:41 2007 From: trac at galois.com (GHC) Date: Sun Dec 2 12:50:20 2007 Subject: [GHC] #1952: Max and Min for Monoid Message-ID: <044.1b83eeaeebb32eb932d16a30464c2990@localhost> #1952: Max and Min for Monoid -------------------------------+-------------------------------------------- Reporter: conal | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.8.1 Severity: normal | Keywords: Difficulty: Easy (1 hr) | Testcase: Architecture: Unknown | Os: Unknown -------------------------------+-------------------------------------------- I'd like to add two instances to {{{Data.Monoid}}}, alongside of All/Any, Sum/Product, and First/Last. Here's a current instance (as a style example): {{{ -- | Boolean monoid under conjunction. newtype All = All { getAll :: Bool } deriving (Eq, Ord, Read, Show, Bounded) instance Monoid All where mempty = All True All x `mappend` All y = All (x && y) }}} My proposed addition: {{{ -- | Ordered monoid under 'max'. newtype Max a = Max { getMax :: a } deriving (Eq, Ord, Read, Show, Bounded) instance (Ord a, Bounded a) => Monoid (Max a) where mempty = Max minBound Max a `mappend` Max b = Max (a `max` b) -- | Ordered monoid under 'min'. newtype Min a = Min { getMin :: a } deriving (Eq, Ord, Read, Show, Bounded) instance (Ord a, Bounded a) => Monoid (Min a) where mempty = Min minBound Min a `mappend` Min b = Min (a `min` b) }}} I have a niggling uncertainty about the Ord & Bounded instances for {{{Min a}}}? Is there a reason flip the {{{a}}} ordering instead of preserving it? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 2 14:20:16 2007 From: trac at galois.com (GHC) Date: Sun Dec 2 14:16:52 2007 Subject: [GHC] #1843: ghc 6.8.1 broken on Mac OS X Leopard PPC In-Reply-To: <044.ed2a345fe747cd9c97e2c67af33b571b@localhost> References: <044.ed2a345fe747cd9c97e2c67af33b571b@localhost> Message-ID: <053.05322ba8ab27c929a15fb72004d4f668@localhost> #1843: ghc 6.8.1 broken on Mac OS X Leopard PPC ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: 6.8.2 Component: Compiler | Version: 6.8.1 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | ----------------------+----------------------------------------------------- Comment (by guest): I tried applying ChrisKuklewicz's patch to a fresh ghc 6.8.1 source tree (from http://haskell.org/ghc/dist/6.8.1/ghc-6.8.1-src.tar.bz2) along with the extra libs, and the linker segfaults every time it tries to link one of the certain extra libs. So far, parsec, X11, and OpenGL cause it to die: {{{ ... == make way=p -f GNUmakefile all; == Finished recursively making `all' for ways: p ... Registering HGL-3.2.0.0... Reading package info from "dist/inplace-pkg-config" ... done. Saving old package config file... done. Writing new package config file... done. if ifBuildable/ifBuildable OpenGL; then \ cd OpenGL && \ make -r && \ setup/Setup register --inplace; \ fi ../../compiler/stage1/ghc-inplace -package-name OpenGL-2.2.1.1 -hide-all- packages -split-objs -i -idist/build/autogen -idist/build -i. -Idist/build -Iinclude -optc-DCALLCONV=ccall -#include "HsOpenGL.h" -odir dist/build -hidir dist/build -stubdir dist/build -package base-3.0.0.0 -O -DCALLCONV=ccall -XCPP -XForeignFunctionInterface -idist/build -H16m -O -O -Rghc-timing -fgenerics -c Graphics/Rendering/OpenGL/GL/Feedback.hs -o dist/build/Graphics/Rendering/OpenGL/GL/Feedback.o -ohi dist/build/Graphics/Rendering/OpenGL/GL/Feedback.hi collect2: ld terminated with signal 10 [Bus error] <> make[2]: *** [dist/build/Graphics/Rendering/OpenGL/GL/Feedback.o] Error 1 make[1]: *** [make.library.OpenGL] Error 2 make: *** [stage1] Error 2 }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 2 15:07:32 2007 From: trac at galois.com (GHC) Date: Sun Dec 2 15:03:13 2007 Subject: [GHC] #1952: Max and Min for Monoid In-Reply-To: <044.1b83eeaeebb32eb932d16a30464c2990@localhost> References: <044.1b83eeaeebb32eb932d16a30464c2990@localhost> Message-ID: <053.4afd8189658ea57db4fc06c35039841e@localhost> #1952: Max and Min for Monoid ----------------------------+----------------------------------------------- Reporter: conal | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Comment (by conal): Oops -- editing error. The Min instance should use maxBound: {{{ instance (Ord a, Bounded a) => Monoid (Min a) where mempty = Min maxBound Min a `mappend` Min b = Min (a `min` b) }}} Thanks, Ian. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 2 16:07:55 2007 From: trac at galois.com (GHC) Date: Sun Dec 2 16:04:28 2007 Subject: [GHC] #1843: ghc 6.8.1 broken on Mac OS X Leopard PPC In-Reply-To: <044.ed2a345fe747cd9c97e2c67af33b571b@localhost> References: <044.ed2a345fe747cd9c97e2c67af33b571b@localhost> Message-ID: <053.f88c8099e85cafce03ee5ee24d03f91a@localhost> #1843: ghc 6.8.1 broken on Mac OS X Leopard PPC ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: 6.8.2 Component: Compiler | Version: 6.8.1 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | ----------------------+----------------------------------------------------- Comment (by igloo): Replying to [comment:25 guest]: > I tried applying ChrisKuklewicz's patch to a fresh ghc 6.8.1 source tree (from http://haskell.org/ghc/dist/6.8.1/ghc-6.8.1-src.tar.bz2) along with the extra libs, and the linker segfaults every time it tries to link one of the certain extra libs. So far, parsec, X11, and OpenGL cause it to die: Thanks for the info! From comments 4 and 9 it sounds to me like that is a different problem, and not something caused by the patch. Does anyone disagree? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 2 17:09:35 2007 From: trac at galois.com (GHC) Date: Sun Dec 2 17:05:16 2007 Subject: [GHC] #1952: Max and Min for Monoid In-Reply-To: <044.1b83eeaeebb32eb932d16a30464c2990@localhost> References: <044.1b83eeaeebb32eb932d16a30464c2990@localhost> Message-ID: <053.56652e0dc153bce16adf7133b6215deb@localhost> #1952: Max and Min for Monoid ----------------------------+----------------------------------------------- Reporter: conal | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * milestone: => Not GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 2 17:09:43 2007 From: trac at galois.com (GHC) Date: Sun Dec 2 17:05:24 2007 Subject: [GHC] #1951: Add "writer" Monad instance (, ) o to Control.Monad.Instances In-Reply-To: <044.d983d9ad1795cf879541d88d3708e6e6@localhost> References: <044.d983d9ad1795cf879541d88d3708e6e6@localhost> Message-ID: <053.177e6b83d1da69f89a8076174804c2d5@localhost> #1951: Add "writer" Monad instance (,) o to Control.Monad.Instances ----------------------------+----------------------------------------------- Reporter: conal | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries/base | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Unknown Os: Unknown | ----------------------------+----------------------------------------------- Changes (by igloo): * milestone: => Not GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 2 17:12:43 2007 From: trac at galois.com (GHC) Date: Sun Dec 2 17:08:24 2007 Subject: [GHC] #1895: Allow aliases in GHCi module imports In-Reply-To: <044.6ecaa12d10d2acbb79232cbf02108989@localhost> References: <044.6ecaa12d10d2acbb79232cbf02108989@localhost> Message-ID: <053.a5a2ef604e8d06b0a462f434a95d7a35@localhost> #1895: Allow aliases in GHCi module imports -----------------------------+---------------------------------------------- Reporter: tibbe | Owner: Type: feature request | Status: new Priority: normal | Milestone: 6.8 branch Component: GHCi | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -----------------------------+---------------------------------------------- Changes (by igloo): * difficulty: => Unknown * milestone: => 6.8 branch Comment: This would also keep the prompt width down, which would be nice. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 2 17:17:32 2007 From: trac at galois.com (GHC) Date: Sun Dec 2 17:13:10 2007 Subject: [GHC] #1948: panic compiling associated type synonyms In-Reply-To: <044.901fcabfca30dda2950c2764ee7f0ad8@localhost> References: <044.901fcabfca30dda2950c2764ee7f0ad8@localhost> Message-ID: <053.36e96a1d8558a7b783eb85e5e65707f7@localhost> #1948: panic compiling associated type synonyms --------------------------------+------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: typefunction panic | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------------+------------------------------------------- Changes (by igloo): * difficulty: => Unknown * summary: panic compiling associated type synonims => panic compiling associated type synonyms * milestone: => 6.10 branch Comment: Thanks for the report. AT synonyms are known to be broken in the 6.8 branch, so I'm putting this in the 6.10 branch milestone. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 2 17:34:27 2007 From: trac at galois.com (GHC) Date: Sun Dec 2 17:30:05 2007 Subject: [GHC] #1934: Bad interplay between -O2 and -prof -auto-all in GHC-6.6.1 In-Reply-To: <056.9240df8333d09b5378a25d28d27c77ce@localhost> References: <056.9240df8333d09b5378a25d28d27c77ce@localhost> Message-ID: <065.fe0da2e2d94a1816e89e826693e8364f@localhost> #1934: Bad interplay between -O2 and -prof -auto-all in GHC-6.6.1 -------------------------------+-------------------------------------------- Reporter: daniel.is.fischer | Owner: Type: bug | Status: new Priority: low | Milestone: 6.8 branch Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -------------------------------+-------------------------------------------- Changes (by igloo): * priority: normal => low * milestone: => 6.8 branch Comment: Thanks for the report. I can reproduce this with 6.6, but not 6.8.1, so I think it's been fixed. I'll leave this bug open for now, in case we want to make sure the real bug has been fixed as well as this symptom, or to extract a testcase from it. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 2 18:23:34 2007 From: trac at galois.com (GHC) Date: Sun Dec 2 18:19:17 2007 Subject: [GHC] #1807: type equality coercions not symmetric + order dependent In-Reply-To: <044.45fcb8ad600f7cb654635a4f70a9b286@localhost> References: <044.45fcb8ad600f7cb654635a4f70a9b286@localhost> Message-ID: <053.9deabde25c69d04078bd56ca2a472cbe@localhost> #1807: type equality coercions not symmetric + order dependent ----------------------------------------------------------------+----------- Reporter: guest | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.8 Severity: normal | Resolution: Keywords: type equality coercions symmetry order constraints | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------------------------------------------+----------- Comment (by Remi): Not sure whether it's the same bug, but at least it looks very similiar. In ghc-6.9.20071105, x typechecks, but y doesn't. And the only difference is which side of the (a ~ b) the Eq constraint is on.. (there unfortunately are no newer binary linux i386 snapshots that actually install..) {{{ {-# LANGUAGE TypeFamilies, GADTs, KindSignatures, TypeOperators, RankNTypes, FlexibleContexts #-} module Foo where data Equal a b = (b ~ a) => Refl foo :: forall a b. ((a ~ b) => a -> b -> Bool) -> Equal a b -> a -> b -> Bool foo f Refl a b = f a b x :: Eq b => Equal a b -> a -> b -> Bool x = foo (==) -- Doesn't typecheck {- y :: Eq a => Equal a b -> a -> b -> Bool y = foo (==) -} }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 2 18:32:53 2007 From: trac at galois.com (GHC) Date: Sun Dec 2 18:28:31 2007 Subject: [GHC] #1953: Add Bounded instance for IntSet Message-ID: <047.7cdd2f7243fdf02fedceb5b12b5b50ce@localhost> #1953: Add Bounded instance for IntSet ----------------------------------+----------------------------------------- Reporter: dbenbenn | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 6.8.1 Severity: normal | Keywords: Difficulty: Easy (1 hr) | Testcase: Architecture: Multiple | Os: Multiple ----------------------------------+----------------------------------------- I propose to add a Bounded instance to !IntSet.hs. !IntSet is in Ord, and there are only finitely many instances of !IntSet. Therefore there is a min !IntSet and a max !IntSet. It turns out these bounds are very simple: {{{ instance Bounded IntSet where minBound = fromList [] maxBound = fromList [maxBound] }}} Suggested deadline: December 16, 2007. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 2 18:40:51 2007 From: trac at galois.com (GHC) Date: Sun Dec 2 18:36:30 2007 Subject: [GHC] #1944: round function causes cblas NaNs In-Reply-To: <052.7827d863c451a2b4d8c8af2c2416f81c@localhost> References: <052.7827d863c451a2b4d8c8af2c2416f81c@localhost> Message-ID: <061.d363d2966f09a98a82ab9bca374e607e@localhost> #1944: round function causes cblas NaNs ---------------------------+------------------------------------------------ Reporter: SevenThunders | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.2 Component: Compiler | Version: 6.8.1 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ---------------------------+------------------------------------------------ Changes (by igloo): * difficulty: => Unknown * milestone: => 6.8.2 Comment: Thanks for the testcase! What is the correct output, and what output do you get but not expect? With atlas321_WinNT_PII.zip from http://www.netlib.org/atlas/archives/windows/ I get: {{{ $ ghc --make Test2.hs ctest2.c -lcblas -latlas -threaded -O -fffi -Latlas/WinNT_PII/ Linking Test2.exe ... $ ./Test2 "rounded base = 0" C[0] = 2 C[1] = 2 C[2] = 2 C[3] = 2 }}} which I assume is correct, and with your atlas.dll I get: {{{ $ dlltool.exe -D atlas.dll -l atlas.lib $ ghc -threaded -O -fffi --make Test2.hs ctest2.c -o Test2.exe -optl- latlas -optl-L"." [1 of 1] Compiling Main ( Test2.hs, Test2.o ) Linking Test2.exe ... $ ./Test2 $ }}} which looks broken, but in a different way than you were expecting? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 2 18:44:44 2007 From: trac at galois.com (GHC) Date: Sun Dec 2 18:40:24 2007 Subject: [GHC] #1953: Add Bounded instance for IntSet In-Reply-To: <047.7cdd2f7243fdf02fedceb5b12b5b50ce@localhost> References: <047.7cdd2f7243fdf02fedceb5b12b5b50ce@localhost> Message-ID: <056.5638aa296fe086bb840ca14b717fc32e@localhost> #1953: Add Bounded instance for IntSet -------------------------------+-------------------------------------------- Reporter: dbenbenn | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: libraries (other) | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Multiple Os: Multiple | -------------------------------+-------------------------------------------- Comment (by dbenbenn): Actually, here's a slightly better way of writing the same code: {{{ instance Bounded IntSet where minBound = empty maxBound = singleton maxBound }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 2 18:52:18 2007 From: trac at galois.com (GHC) Date: Sun Dec 2 18:47:56 2007 Subject: [GHC] #1953: Add Bounded instance for IntSet In-Reply-To: <047.7cdd2f7243fdf02fedceb5b12b5b50ce@localhost> References: <047.7cdd2f7243fdf02fedceb5b12b5b50ce@localhost> Message-ID: <056.28099ee87d5a961ee0ccbeb3310d6f65@localhost> #1953: Add Bounded instance for IntSet -------------------------------+-------------------------------------------- Reporter: dbenbenn | Owner: Type: proposal | Status: new Priority: normal | Milestone: Not GHC Component: libraries (other) | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: Multiple Os: Multiple | -------------------------------+-------------------------------------------- Changes (by igloo): * milestone: => Not GHC -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Sun Dec 2 19:53:40 2007 From: trac at galois.com (GHC) Date: Sun Dec 2 19:49:18 2007 Subject: [GHC] #1946: Ctr-c doesn't work in ghci-6.8.1, probably related to #1922 In-Reply-To: <056.ebd4cb89de11dff2d57f274b1f985468@localhost> References: <056.ebd4cb89de11dff2d57f274b1f985468@localhost> Message-ID: <065.ebea604fea6654d119711c302e5b46ad@localhost> #1946: Ctr-c doesn't work in ghci-6.8.1, probably related to #1922 ----------------------------------+----------------------------------------- Reporter: daniel.is.fischer | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: GHCi | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Testcase: Architecture: x86 | Os: Linux ----------------------------------+----------------------------------------- Comment (by daniel.is.fischer): It does work with a newly built stage 3 ghc. The previous behaviour was with a stage 2 ghc. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 3 03:11:46 2007 From: trac at galois.com (GHC) Date: Mon Dec 3 03:07:24 2007 Subject: [GHC] #1936: When lazy IO blocks, it blocks the whole runtime In-Reply-To: <044.f29c60445787d8d1c724ac2871ace0b4@localhost> References: <044.f29c60445787d8d1c724ac2871ace0b4@localhost> Message-ID: <053.c1e42e4323690f582129abc37a3aea39@localhost> #1936: When lazy IO blocks, it blocks the whole runtime ------------------------------------------+--------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: None | Version: 6.8.1 Severity: normal | Resolution: Keywords: lazy IO getContents blocking | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Linux | ------------------------------------------+--------------------------------- Comment (by guest): Disregard that previous bit about the strace. It didn't happen, and the reason I thought it happened is stupider than I'm going to admit to publicly. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 3 03:46:39 2007 From: trac at galois.com (GHC) Date: Mon Dec 3 03:42:21 2007 Subject: [GHC] #1948: panic compiling associated type synonyms In-Reply-To: <044.901fcabfca30dda2950c2764ee7f0ad8@localhost> References: <044.901fcabfca30dda2950c2764ee7f0ad8@localhost> Message-ID: <053.4a61164e943212d74873fd8828fed8e9@localhost> #1948: panic compiling associated type synonyms --------------------------------+------------------------------------------- Reporter: guest | Owner: chak Type: bug | Status: new Priority: normal | Milestone: 6.10 branch Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: typefunction panic | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | --------------------------------+------------------------------------------- Changes (by simonpj): * owner: => chak -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 3 07:28:49 2007 From: trac at galois.com (GHC) Date: Mon Dec 3 07:24:29 2007 Subject: [GHC] #1919: GHC 6.8.1 panics with lookupRecBndr In-Reply-To: <054.e1ab90bcf781b85f82a9e40a92b5021d@localhost> References: <054.e1ab90bcf781b85f82a9e40a92b5021d@localhost> Message-ID: <063.83dafb389babb68344de956e28387619@localhost> #1919: GHC 6.8.1 panics with lookupRecBndr -----------------------------+---------------------------------------------- Reporter: BjornBuckwalter | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8.2 Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -----------------------------+---------------------------------------------- Changes (by simonpj): * owner: simonpj => igloo * type: bug => merge Comment: Fixed: {{{ Wed Nov 28 17:31:46 GMT 2007 simonpj@microsoft.com * Reorganise TcSimplify (again); FIX Trac #1919 }}} I ''hope'' this will merge smoothly to the 6.8 branch. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 3 09:18:54 2007 From: trac at galois.com (GHC) Date: Mon Dec 3 09:14:30 2007 Subject: [GHC] #1949: Build system destroys output In-Reply-To: <046.582359a2d327167afa37a4fee93cb241@localhost> References: <046.582359a2d327167afa37a4fee93cb241@localhost> Message-ID: <055.34c6d17439001d32cf330d40ce5bcc67@localhost> #1949: Build system destroys output --------------------------------------------------+------------------------- Reporter: mbaulch | Owner: Type: bug | Status: closed Priority: normal | Milestone: 6.8 branch Component: Build System | Version: 6.8.1 Severity: normal | Resolution: fixed Keywords: strip binaries install solaris build | Difficulty: Unknown Testcase: | Architecture: sparc Os: Solaris | --------------------------------------------------+------------------------- Changes (by igloo): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: Thanks for the report. Fixed in 6.8 branch and HEAD: {{{ Sun Dec 2 11:58:17 PST 2007 Ian Lynagh * Don't default to stripping binaries when installing }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 3 09:21:30 2007 From: trac at galois.com (GHC) Date: Mon Dec 3 09:17:07 2007 Subject: [GHC] #1940: GHCi triggers firewall by sending unexpected packet In-Reply-To: <049.546c2ee041c20f9b1787468b8e40cdee@localhost> References: <049.546c2ee041c20f9b1787468b8e40cdee@localhost> Message-ID: <058.3b639c491c1e5a221e78160498a0fd60@localhost> #1940: GHCi triggers firewall by sending unexpected packet ------------------------+--------------------------------------------------- Reporter: TimAttwood | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.8.1 Severity: trivial | Resolution: Keywords: firewall | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ------------------------+--------------------------------------------------- Changes (by igloo): * milestone: _|_ => 6.8.3 Comment: We should close this if we haven't got any further in the 6.8.3 timescale. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 3 10:24:59 2007 From: trac at galois.com (GHC) Date: Mon Dec 3 10:21:16 2007 Subject: [GHC] #1919: GHC 6.8.1 panics with lookupRecBndr In-Reply-To: <054.e1ab90bcf781b85f82a9e40a92b5021d@localhost> References: <054.e1ab90bcf781b85f82a9e40a92b5021d@localhost> Message-ID: <063.390517fe6d47e4300698980bd3979a75@localhost> #1919: GHC 6.8.1 panics with lookupRecBndr -----------------------------+---------------------------------------------- Reporter: BjornBuckwalter | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.8.2 Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Multiple | -----------------------------+---------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Mon Dec 3 18:11:13 2007 From: trac at galois.com (GHC) Date: Mon Dec 3 18:08:03 2007 Subject: [GHC] #1843: ghc 6.8.1 broken on Mac OS X Leopard PPC In-Reply-To: <044.ed2a345fe747cd9c97e2c67af33b571b@localhost> References: <044.ed2a345fe747cd9c97e2c67af33b571b@localhost> Message-ID: <053.c46e0f3a6d980a1bb8fd66776c2364d7@localhost> #1843: ghc 6.8.1 broken on Mac OS X Leopard PPC ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: 6.8.2 Component: Compiler | Version: 6.8.1 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | ----------------------+----------------------------------------------------- Comment (by thorkilnaur): I agree that the linker problem seems to be a separate issue. Using the !ChrisKuklewicz patch, a validate on a PPC Mac OS X 10.5. Leopard (without the extra libraries) concluded: {{{ OVERALL SUMMARY for test run started at Mon Dec 3 11:39:48 CET 2007 2001 total tests, which gave rise to 7595 test cases, of which 1 caused framework failures 5924 were skipped 1570 expected passes 75 expected failures 0 unexpected passes 26 unexpected failures Unexpected failures: Records(normal) arith011(normal) arr016(normal) cg034(normal) cg044(normal) cg059(normal) currentDirectory001(normal) directory001(normal) drv012(normal) drv013(normal) drv020(normal) ds059(normal) exceptions002(normal) freeNames(normal) ghci024(ghci) karl1(normal) nbe(normal) rebindable5(normal) red-black(normal) simpl007(normal) simplrun004(optc) tc(normal) tc088(normal) text001(normal) tup001(normal) unicode002(normal) }}} Proceeding with a more realistic build (mk/build.mk is mk/build.mk.sample with !BuildFlavour = perf) and extra libraries included, matters are brought to a halt at: {{{ ../../compiler/stage1/ghc-inplace -package-name parsec-2.0 -hide-all- packages -split-objs -i -idist/build/autogen -idist/build -i. -Idist/build -odir dist/build -hidir dist/build -stubdir dist/build -package base-3.0 -O -XExistentialQuantification -XPolymorphicComponents -idist/build -H32m -O2 -c Text/ParserCombinators/Parsec/Token.hs -o dist/build/Text/ParserCombinators/Parsec/Token.o -ohi dist/build/Text/ParserCombinators/Parsec/Token.hi collect2: ld terminated with signal 10 [Bus error] make[2]: *** [dist/build/Text/ParserCombinators/Parsec/Token.o] Error 1 make[1]: *** [make.library.parsec] Error 2 make: *** [stage1] Error 2 }}} which has been reported earlier on the glasgow-haskell-users mailing list, but as far as I can tell, not reported as a trac ticket. I will prepare a suitable trac ticket shortly, unless someone is kind enough to tell me that the issue has been reported already. Best regards Thorkil -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 4 00:55:00 2007 From: trac at galois.com (GHC) Date: Tue Dec 4 00:50:45 2007 Subject: [GHC] #1807: type equality coercions not symmetric + order dependent In-Reply-To: <044.45fcb8ad600f7cb654635a4f70a9b286@localhost> References: <044.45fcb8ad600f7cb654635a4f70a9b286@localhost> Message-ID: <053.3ea9d2c2b94d83a5cd13e281871d993b@localhost> #1807: type equality coercions not symmetric + order dependent ----------------------------------------------------------------+----------- Reporter: guest | Owner: chak Type: bug | Status: closed Priority: normal | Milestone: 6.10 branch Component: Compiler (Type checker) | Version: 6.8 Severity: normal | Resolution: duplicate Keywords: type equality coercions symmetry order constraints | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------------------------------------------------+----------- Changes (by chak): * status: new => closed * resolution: => duplicate Comment: This is a duplicate of #1919 combined with #1754. The former has been fixed by SimonPJ, so I am marking this as duplicate for #1754 now. (This applies to the original bug and Remi's example from two days ago.) -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 4 06:30:55 2007 From: trac at galois.com (GHC) Date: Tue Dec 4 06:26:29 2007 Subject: [GHC] #967: Simplifier in HEAD is iterating too much In-Reply-To: <047.1db23fa1dd4a7e0bb97d96b57c34f941@localhost> References: <047.1db23fa1dd4a7e0bb97d96b57c34f941@localhost> Message-ID: <056.77df67f45f664ad43d4471198441d23a@localhost> #967: Simplifier in HEAD is iterating too much ----------------------+----------------------------------------------------- Reporter: simonmar | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.7 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Unknown | ----------------------+----------------------------------------------------- Changes (by simonpj): * status: new => closed * resolution: => fixed Comment: This patch at least improves matters a lot {{{ Mon Dec 3 07:00:39 PST 2007 simonpj@microsoft.com * Improve eta reduction, to reduce Simplifier iterations }}} So I'm closing this bug fo rnow. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 4 07:32:50 2007 From: trac at galois.com (GHC) Date: Tue Dec 4 07:28:22 2007 Subject: [GHC] #1048: Add forkIO that starts in 'block' mode In-Reply-To: <053.3d943aa074476096db4463def1398273@localhost> References: <053.3d943aa074476096db4463def1398273@localhost> Message-ID: <062.7fa63073a0f97fc0a6ccfc49da3dcc25@localhost> #1048: Add forkIO that starts in 'block' mode -----------------------------+---------------------------------------------- Reporter: ChrisKuklewicz | Owner: simonmar Type: feature request | Status: new Priority: normal | Milestone: 6.10 branch Component: libraries/base | Version: 6.6 Severity: normal | Resolution: Keywords: concurrency | Difficulty: Easy (1 hr) Testcase: | Architecture: Multiple Os: Multiple | -----------------------------+---------------------------------------------- Comment (by simonmar): Partially done: {{{ Tue Dec 4 03:09:47 PST 2007 Simon Marlow * forkIO starts the new thread blocked if the parent is blocked (#1048) }}} I needed to fix various Ctrl-C problems in 6.8.1, and this seemed the least invasive way to do it. forkOS is not done, so leaving the ticket open for now. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 4 07:33:41 2007 From: trac at galois.com (GHC) Date: Tue Dec 4 07:29:15 2007 Subject: [GHC] #1583: GHCi + large Integer arithmetic + Ctrl-C = bad In-Reply-To: <051.781997f67aa02f9f839f9b3623a4da0b@localhost> References: <051.781997f67aa02f9f839f9b3623a4da0b@localhost> Message-ID: <060.b1e6ed22efc0481145fb866b9a5d1d52@localhost> #1583: GHCi + large Integer arithmetic + Ctrl-C = bad --------------------------+------------------------------------------------- Reporter: Isaac Dupree | Owner: simonmar Type: bug | Status: closed Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.6.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Multiple Os: Linux | --------------------------+------------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => fixed Comment: Fixed, I think. See also #1922 and #1946. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 4 10:04:36 2007 From: trac at galois.com (GHC) Date: Tue Dec 4 10:00:19 2007 Subject: [GHC] #1947: Segmentation fault/access violation in generated code In-Reply-To: <051.7113ffd85120a95cf3f282877a678b8a@localhost> References: <051.7113ffd85120a95cf3f282877a678b8a@localhost> Message-ID: <060.416e058f157a5da1a7aff4f9e9184098@localhost> #1947: Segmentation fault/access violation in generated code --------------------------+------------------------------------------------- Reporter: NeilMitchell | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | --------------------------+------------------------------------------------- Changes (by simonpj): * owner: => igloo * type: bug => merge Comment: Fixed, thank you. {{{ Tue Dec 4 14:58:03 GMT 2007 simonpj@microsoft.com * Make eta reduction check more carefully for bottoms (fix Trac #1947) }}} Ian: please merge. And could you make this program into a test? (Compile with -O2 and run as above.) Thanks Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 4 10:15:18 2007 From: trac at galois.com (GHC) Date: Tue Dec 4 10:10:53 2007 Subject: [GHC] #1547: Arity can decrease with -prof In-Reply-To: <044.c0c86188c91ab503a2f98a561709e8de@localhost> References: <044.c0c86188c91ab503a2f98a561709e8de@localhost> Message-ID: <053.f0981a7f1a7a4e3fc3a92fa3c659d6b4@localhost> #1547: Arity can decrease with -prof ---------------------------------------+------------------------------------ Reporter: igloo | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10 branch Component: Profiling | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: stm package/tests/conc052 | Architecture: Unknown Os: Unknown | ---------------------------------------+------------------------------------ Comment (by simonpj): I had a half-done change in `SimplUtils` which I'm just going to dump here for now. The actual code change (which I am not sure is right) is this: {{{ hunk ./compiler/simplCore/SimplUtils.lhs 827 - any isRuntimeVar bndrs + any isRuntimeVar bndrs || not (exprIsTrivial body) + -- Note [RHS eta expansion] }}} and the note is this: {{{ Note [RHS eta expansion] ~~~~~~~~~~~~~~~~~~~~~~~~ The basic idea is to transform f = \x1..xn -> N ==> f = \x1..xn y1..ym -> N y1..ym (n >= 0) where (in both cases) * The xi can include type variables * The yi are all value variables * N is a NORMAL FORM (i.e. no redexes anywhere) wanting a suitable number of extra args. This is OK even if n=0; for example: let g=\xs. x:xs in (\ys. map g ys) Here we can eta expand to \ys. let g=\xs. x:xs in map g ys You might think the f-binding woudl have floated, but it may not when we are profiling: f = scc "foo" (let g=\xs. x:xs in (\xs. map g ys)) Furthermore, f's arity might have been 1 before, if it originally looked like h g ys = map g ys f = scc "foo" (h (\xs. x:xs)) and we do not expect like the arity to decrease so that it now looks like zero (to the cheap-and-cheerful exprArity). However, we must be careful not to undo the effect of eta-reduction, hence the check for `(not (exprIsTrivial body))`. }}} I just want to capture the state of play because I can't finish this today. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 4 11:00:53 2007 From: trac at galois.com (GHC) Date: Tue Dec 4 10:56:31 2007 Subject: [GHC] #1110: Setting PATH needed in Windows Vista In-Reply-To: <058.e03ccf618ab5a7c0a2551f8b8f819c0f@localhost> References: <058.e03ccf618ab5a7c0a2551f8b8f819c0f@localhost> Message-ID: <067.4f9a921345e89fc93734c032698e58d5@localhost> #1110: Setting PATH needed in Windows Vista ---------------------------------+------------------------------------------ Reporter: br1@internet.com.uy | Owner: simonmar Type: bug | Status: reopened Priority: high | Milestone: 6.8.1 Component: Driver | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: x86_64 (amd64) Os: Windows | ---------------------------------+------------------------------------------ Changes (by bchallenor): * status: closed => reopened * version: 6.6 => 6.8.1 * resolution: fixed => Comment: I'm seeing this bug in Vista using "Version 6.8.1, for Haskell 98, stage 3 booted by GHC version 6.6". I try to compile a file generated using Alex that needs the preprocessor and get the following error: "gcc: installation problem, cannot exec `cc1': No such file or directory". As suggested, adding gcc-lib to the Path fixes it, but that's a bad hack. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 4 11:01:57 2007 From: trac at galois.com (GHC) Date: Tue Dec 4 10:57:33 2007 Subject: [GHC] #1110: Setting PATH needed in Windows Vista In-Reply-To: <058.e03ccf618ab5a7c0a2551f8b8f819c0f@localhost> References: <058.e03ccf618ab5a7c0a2551f8b8f819c0f@localhost> Message-ID: <067.fa7c399d5cfb413ddb88e7bee5788575@localhost> #1110: Setting PATH needed in Windows Vista ---------------------------------+------------------------------------------ Reporter: br1@internet.com.uy | Owner: simonmar Type: bug | Status: reopened Priority: high | Milestone: 6.8.1 Component: Driver | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: x86_64 (amd64) Os: Windows | ---------------------------------+------------------------------------------ Comment (by bchallenor): Sorry, I should have mentioned that this is on x86 (Intel). I hope this is a good place to file the bug. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 4 11:14:50 2007 From: trac at galois.com (GHC) Date: Tue Dec 4 11:10:23 2007 Subject: [GHC] #1922: getChar + Ctrl-C on Windows in GHCi breaks In-Reply-To: <044.ef42583e0338257216434a143829cc5f@localhost> References: <044.ef42583e0338257216434a143829cc5f@localhost> Message-ID: <053.225b4dcee98493b7ac5988af0592d1a3@localhost> #1922: getChar + Ctrl-C on Windows in GHCi breaks ---------------------+------------------------------------------------------ Reporter: guest | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | ---------------------+------------------------------------------------------ Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: Ok, several issues here. 1) happens because when you hit `^C` in a console, Windows apprently causes a blocked `read()` on `stdin` to return 0, which the runtime interprets as EOF. I haven't done anything about this yet, it seems fairly harmless. 2) is the same as (1), just that the real `^C` exception gets delivered during the reporting of the EOF. 3) happens due to a race condition in GHCi, which I've fixed. Interestingly, the fix required also fixing #1048 (make `forkIO` inherit `block` from the parent). 4) happens due to another race condition, this time on the console handler, which is a global pointer to a `StablePtr`. Under the right (wrong?) conditions, someone could free the `StablePtr` before it was dereferenced, leading to a crash. I've fixed this. To merge, in GHC: {{{ Tue Dec 4 03:09:47 PST 2007 Simon Marlow * forkIO starts the new thread blocked if the parent is blocked (#1048) Tue Dec 4 03:44:44 PST 2007 Simon Marlow * fix race conditions in sandboxIO (#1583, #1922, #1946) Tue Dec 4 07:39:18 PST 2007 Simon Marlow * protect console handler against concurrent access (#1922) }}} (note the first change needs documenting in the release notes, and I need in `libraries/base`: {{{ Tue Dec 4 03:08:17 PST 2007 Simon Marlow * protect against concurrent access to the signal handlers (#1922) Tue Dec 4 07:39:40 PST 2007 Simon Marlow * protect console handler against concurrent access (#1922) }}} in `libraries/unix`: {{{ Tue Dec 4 03:08:39 PST 2007 Simon Marlow * protect against concurrent access to the signal handlers (#1922) }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 4 11:17:34 2007 From: trac at galois.com (GHC) Date: Tue Dec 4 11:13:08 2007 Subject: [GHC] #1946: Ctr-c doesn't work in ghci-6.8.1, probably related to #1922 In-Reply-To: <056.ebd4cb89de11dff2d57f274b1f985468@localhost> References: <056.ebd4cb89de11dff2d57f274b1f985468@localhost> Message-ID: <065.f4b89d9571bed4c5160854d4f4c35e1f@localhost> #1946: Ctr-c doesn't work in ghci-6.8.1, probably related to #1922 -------------------------------+-------------------------------------------- Reporter: daniel.is.fischer | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: GHCi | Version: 6.8.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | -------------------------------+-------------------------------------------- Changes (by simonmar): * status: new => closed * difficulty: => Unknown * resolution: => fixed Comment: believe the crash is fixed, see #1922. The fact that Ctrl-C is unresponsive in some cases is an instance of #367. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 4 11:30:25 2007 From: trac at galois.com (GHC) Date: Tue Dec 4 11:26:01 2007 Subject: [GHC] #1110: Setting PATH needed in Windows Vista In-Reply-To: <058.e03ccf618ab5a7c0a2551f8b8f819c0f@localhost> References: <058.e03ccf618ab5a7c0a2551f8b8f819c0f@localhost> Message-ID: <067.0fa0b3e6dede847667421526f42dc1f8@localhost> #1110: Setting PATH needed in Windows Vista ---------------------------------+------------------------------------------ Reporter: br1@internet.com.uy | Owner: simonmar Type: bug | Status: reopened Priority: high | Milestone: 6.8.1 Component: Driver | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: x86_64 (amd64) Os: Windows | ---------------------------------+------------------------------------------ Comment (by simonmar): urgh, I think I know what the problem is. Can you confirm that using the `-cpp` option causes the failure? Try compiling a small source file with and without `-cpp`. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 4 11:30:36 2007 From: trac at galois.com (GHC) Date: Tue Dec 4 11:26:12 2007 Subject: [GHC] #1110: Setting PATH needed in Windows Vista In-Reply-To: <058.e03ccf618ab5a7c0a2551f8b8f819c0f@localhost> References: <058.e03ccf618ab5a7c0a2551f8b8f819c0f@localhost> Message-ID: <067.81b14510eaf9834e697c0114beb8f267@localhost> #1110: Setting PATH needed in Windows Vista ---------------------------------+------------------------------------------ Reporter: br1@internet.com.uy | Owner: simonmar Type: bug | Status: reopened Priority: high | Milestone: 6.8.3 Component: Driver | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: x86_64 (amd64) Os: Windows | ---------------------------------+------------------------------------------ Changes (by simonmar): * milestone: 6.8.1 => 6.8.3 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 4 16:19:26 2007 From: trac at galois.com (GHC) Date: Tue Dec 4 16:15:07 2007 Subject: [GHC] #1853: hpc mix files for Main modules overwrite each other In-Reply-To: <044.9b946ad54a9a35d3915c7a74c107b816@localhost> References: <044.9b946ad54a9a35d3915c7a74c107b816@localhost> Message-ID: <053.3df5a52ad4c19deeb6b0bf80fb04363e@localhost> #1853: hpc mix files for Main modules overwrite each other ---------------------------+------------------------------------------------ Reporter: guest | Owner: AndyGill Type: bug | Status: assigned Priority: normal | Milestone: 6.10 branch Component: Code Coverage | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ---------------------------+------------------------------------------------ Changes (by AndyGill): * status: new => assigned * owner: andy@galois.com => AndyGill -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 4 17:05:18 2007 From: trac at galois.com (GHC) Date: Tue Dec 4 17:00:56 2007 Subject: [GHC] #1954: Incorrect "Defined but not used" warning when using GeneralizedNewtypeDeriving Message-ID: <045.e561f4751fbf1f20f885ac5cefecdcbb@localhost> #1954: Incorrect "Defined but not used" warning when using GeneralizedNewtypeDeriving -------------------------+-------------------------------------------------- Reporter: magnus | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.1 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- When compiling {{{ {-# LANGUAGE GeneralizedNewtypeDeriving #-} {-# OPTIONS_GHC -Wall -Werror #-} module Bug(P, runP) where import Control.Monad.Identity(Identity, runIdentity) newtype P a = P { unP :: Identity a } deriving Monad runP :: P a -> a runP = runIdentity . unP }}} I get {{{ Bug.hs:7:14: Warning: Defined but not used: data constructor `P' }}} although the constructor is used in the derived Monad instance. This is obviously not a show stopper, but it forces me to rewrite what to me looks like an OK program if I want to stick to the given OPTIONS_GHC. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 4 17:56:33 2007 From: trac at galois.com (GHC) Date: Tue Dec 4 17:52:17 2007 Subject: [GHC] #1955: Heap profiling on Windows doesn't work Message-ID: <051.41700a7931b75f5016d260a75d133aed@localhost> #1955: Heap profiling on Windows doesn't work -------------------------------+-------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Runtime System | Version: 6.8.1 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Windows -------------------------------+-------------------------------------------- {{{ C:\Temp>type Main.hs main = print "neil" C:\Temp>ghc --make -prof -auto-all Main.hs [1 of 1] Compiling Main ( Main.hs, Main.o ) Linking Main.exe ... C:\Temp>main +RTS -hc "neil" C:\Temp>hp2ps main hp2ps: cannot open main.exe.hp }}} This can be fixed by either renaming the generated main.hp to main.exe.hp, or running "main.exe +RTS -hc" in the first place. I guess you are using argv [0]as the basis of where to put the heap profiling information, and using the executable name as the basis of where to find it. My suggestion would be that heap profiling information should always go at basename.hp (so main.hp), ignoring any extension. This would require fixing up both the RTS and the hp2ps utility. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 4 19:28:54 2007 From: trac at galois.com (GHC) Date: Tue Dec 4 19:24:31 2007 Subject: [GHC] #1944: round function causes cblas NaNs In-Reply-To: <052.7827d863c451a2b4d8c8af2c2416f81c@localhost> References: <052.7827d863c451a2b4d8c8af2c2416f81c@localhost> Message-ID: <061.6f5e3db97558f69cbb7e0353bec0fdda@localhost> #1944: round function causes cblas NaNs ---------------------------+------------------------------------------------ Reporter: SevenThunders | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.2 Component: Compiler | Version: 6.8.1 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | ---------------------------+------------------------------------------------ Comment (by SevenThunders): Replying to [comment:2 igloo]: I thought I had replied to this, but I will do so again. Here is what I get using my binary atlas cblas {{{ "rounded base = 0" C[0] = -1.#IND C[1] = 2 C[2] = 2 C[3] = -1.#IND }}} This is on my AMD athlon x2 processor running windows xp 64 (the library is still 32 bit). I get similar results running it on an Intel core duo processor with a different atlas compiled blas. Both blas's were compiled with threads turned on so in theory they are multi-threaded if that makes any difference. One question I have is does the code works correctly on your box if you compile it using the older ghc, but with my supplied atlas.dll binary, say ghc 6.6.1? On my box it runs just fine with the older ghc. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 4 19:54:21 2007 From: trac at galois.com (GHC) Date: Tue Dec 4 19:49:59 2007 Subject: [GHC] #1956: panic on runhaskell Setup configure on base Message-ID: <051.ef75b234a372362002a1e8acca106578@localhost> #1956: panic on runhaskell Setup configure on base -----------------------------+---------------------------------------------- Reporter: NeilMitchell | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.1 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Windows -----------------------------+---------------------------------------------- {{{ C:\Documents\Uni\contrib\base>darcs pull Pulling from "http://darcs.haskell.org/packages/base"... No remote changes to pull in! C:\Documents\Uni\contrib\base>runhaskell Setup configure :1:22: attempting to use module `System.IO' (System/IO.hs) which is not loaded :1:22: Not in scope: `System.IO.stderr' :1:22: Not in scope: `System.IO.stdin' ghc.exe: panic! (the 'impossible' happened) (GHC version 6.8.1 for i386-unknown-mingw32): interactiveUI:setBuffering Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug }}} Not sure what this should do, but it shouldn't panic. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 4 20:20:21 2007 From: trac at galois.com (GHC) Date: Tue Dec 4 20:16:07 2007 Subject: [GHC] #1957: Program that runs slower with optimizations on Message-ID: <047.0c19d2d6de54af50ee66a95834667ba4@localhost> #1957: Program that runs slower with optimizations on -------------------------+-------------------------------------------------- Reporter: clanehin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.1 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: x86 | Os: Linux -------------------------+-------------------------------------------------- This program runs significantly slower with optimization than without. I need two modules to manifest this bug. Is this a duplicate of 917/1945? Using -fno-full-laziness does not mitigate the problem. This seems to be the opposite of 1945. Without optimizations, there is a long delay and then all 10 results print at once. With optimizations, there is a shorter delay between each print statement. module Main (main) where import NaiveFib import Control.Monad main :: IO () main = replicateM_ 10 (printFib 37) module NaiveFib (printFib,naiveFib) where printFib :: Integer -> IO () printFib = print . naiveFib naiveFib :: Integer -> Integer naiveFib 0 = 0 naiveFib 1 = 1 naiveFib n = naiveFib (n-1) + naiveFib (n-2) lane@wired:~/test/optimizer-bug$ make main-O0 ghc-6.8.1 -O0 --make Main.hs -o main-O0 [1 of 2] Compiling NaiveFib ( NaiveFib.hs, NaiveFib.o ) [2 of 2] Compiling Main ( Main.hs, Main.o ) Linking main-O0 ... lane@wired:~/test/optimizer-bug$ time ./main-O0 24157817 24157817 24157817 24157817 24157817 24157817 24157817 24157817 24157817 24157817 real 0m34.491s user 0m25.982s sys 0m0.564s lane@wired:~/test/optimizer-bug$ make main-O2 ghc-6.8.1 -O2 --make Main.hs -o main-O2 [1 of 2] Compiling NaiveFib ( NaiveFib.hs, NaiveFib.o ) [2 of 2] Compiling Main ( Main.hs, Main.o ) Linking main-O2 ... lane@wired:~/test/optimizer-bug$ time ./main-O2 24157817 24157817 24157817 24157817 24157817 24157817 24157817 24157817 24157817 24157817 real 1m50.331s user 1m23.641s sys 0m1.008s -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 4 20:26:06 2007 From: trac at galois.com (GHC) Date: Tue Dec 4 20:21:49 2007 Subject: [GHC] #1957: Program that runs slower with optimizations on In-Reply-To: <047.0c19d2d6de54af50ee66a95834667ba4@localhost> References: <047.0c19d2d6de54af50ee66a95834667ba4@localhost> Message-ID: <056.4160c49308b37e22db82800120566181@localhost> #1957: Program that runs slower with optimizations on ----------------------+----------------------------------------------------- Reporter: clanehin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------+----------------------------------------------------- Comment (by clanehin): Forgot to preview. Sorry. {{{ lane@wired:~/test/optimizer-bug$ more Main.hs NaiveFib.hs :::::::::::::: Main.hs :::::::::::::: module Main (main) where import NaiveFib import Control.Monad main :: IO () main = replicateM_ 10 (printFib 37) :::::::::::::: NaiveFib.hs :::::::::::::: module NaiveFib (printFib,naiveFib) where printFib :: Integer -> IO () printFib = print . naiveFib naiveFib :: Integer -> Integer naiveFib 0 = 0 naiveFib 1 = 1 naiveFib n = naiveFib (n-1) + naiveFib (n-2) lane@wired:~/test/optimizer-bug$ make main-O0 ghc-6.8.1 -O0 --make Main.hs -o main-O0 [1 of 2] Compiling NaiveFib ( NaiveFib.hs, NaiveFib.o ) [2 of 2] Compiling Main ( Main.hs, Main.o ) Linking main-O0 ... lane@wired:~/test/optimizer-bug$ time ./main-O0 24157817 24157817 24157817 24157817 24157817 24157817 24157817 24157817 24157817 24157817 real 0m34.491s user 0m25.982s sys 0m0.564s lane@wired:~/test/optimizer-bug$ make clean rm -f *.hi rm -f *.o rm -f main-O2 rm -f main-O0 lane@wired:~/test/optimizer-bug$ make main-O2 ghc-6.8.1 -O2 --make Main.hs -o main-O2 [1 of 2] Compiling NaiveFib ( NaiveFib.hs, NaiveFib.o ) [2 of 2] Compiling Main ( Main.hs, Main.o ) Linking main-O2 ... lane@wired:~/test/optimizer-bug$ time ./main-O2 24157817 24157817 24157817 24157817 24157817 24157817 24157817 24157817 24157817 24157817 real 1m50.331s user 1m23.641s sys 0m1.008s }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Tue Dec 4 20:43:40 2007 From: trac at galois.com (GHC) Date: Tue Dec 4 20:39:24 2007 Subject: [GHC] #1957: Program that runs slower with optimizations on In-Reply-To: <047.0c19d2d6de54af50ee66a95834667ba4@localhost> References: <047.0c19d2d6de54af50ee66a95834667ba4@localhost> Message-ID: <056.af65a6e13ba7959461ceef7cff70bb03@localhost> #1957: Program that runs slower with optimizations on ----------------------+----------------------------------------------------- Reporter: clanehin | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------+----------------------------------------------------- Comment (by dons): Looks like the printFib is messing with the inlining: Across 2 modules, -O2 and -O are 5x slower than -Onot. In a single module, -O2 wins easily. Something fishy going on. Looking at the unfolding in the .hi file for NaiveFib.hs: {{{ interface main:NaiveFib 3 608120071117 where export main:NaiveFib naiveFib printFib module dependencies: package dependencies: base orphans: base:GHC.Base family instance modules: 3 printFib :: GHC.Num.Integer -> GHC.IOBase.IO () {- Arity: 2 Strictness: LL Unfolding: (NaiveFib.a `cast` (GHC.Num.Integer -> sym ((GHC.IOBase.:CoIO) ()))) -} 3 naiveFib :: GHC.Num.Integer -> GHC.Num.Integer {- Arity: 1 HasNoCafRefs Strictness: S -} 3 a :: GHC.Num.Integer -> GHC.Prim.State# GHC.Prim.RealWorld -> (# GHC.Prim.State# GHC.Prim.RealWorld, () #) {- Arity: 2 Strictness: LL Unfolding: (\ x :: GHC.Num.Integer eta :: GHC.Prim.State# GHC.Prim.RealWorld -> case @ (# GHC.Prim.State# GHC.Prim.RealWorld, () #) GHC.IO.a24 GHC.Handle.stdout (GHC.Num.$wshowsPrec 0 (NaiveFib.naiveFib x) (GHC.Base.[] @ GHC.Base.Char)) eta of wild { (# new_s, a59 #) -> GHC.IO.$wa9 GHC.Handle.stdout '\n' new_s }) -} vectorised variables: vectorised tycons: vectorised reused tycons: }}} Looks like the print is mucking up the optimiser a bit? Let's try moving the printFib line into Main.hs: {{{ $ time ./Main-O2 24157817 24157817 24157817 24157817 24157817 24157817 24157817 24157817 24157817 24157817 ./Main-O2 2.99s user 0.01s system 99% cpu 3.028 total }}} And, its fixed if we inline printFib too: {{{ printFib = print . naiveFib {-# INLINE printFib #-} }}} Simon, what's going on with the optimiser here? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 5 04:26:10 2007 From: trac at galois.com (GHC) Date: Wed Dec 5 04:21:43 2007 Subject: [GHC] #1110: Setting PATH needed in Windows Vista In-Reply-To: <058.e03ccf618ab5a7c0a2551f8b8f819c0f@localhost> References: <058.e03ccf618ab5a7c0a2551f8b8f819c0f@localhost> Message-ID: <067.ef8929d04d8c0fada806fc3abc16bcde@localhost> #1110: Setting PATH needed in Windows Vista ---------------------------------+------------------------------------------ Reporter: br1@internet.com.uy | Owner: simonmar Type: bug | Status: reopened Priority: high | Milestone: 6.8.3 Component: Driver | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: x86_64 (amd64) Os: Windows | ---------------------------------+------------------------------------------ Comment (by bchallenor): I can confirm that without gcc-lib on the command line, the file "main = return 42" compiles fine without any switches, but dies immediately with the -cpp switch. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 5 04:26:39 2007 From: trac at galois.com (GHC) Date: Wed Dec 5 04:22:10 2007 Subject: [GHC] #1110: Setting PATH needed in Windows Vista In-Reply-To: <058.e03ccf618ab5a7c0a2551f8b8f819c0f@localhost> References: <058.e03ccf618ab5a7c0a2551f8b8f819c0f@localhost> Message-ID: <067.4324254e7abd0b4caede0dcfb674a8ec@localhost> #1110: Setting PATH needed in Windows Vista ---------------------------------+------------------------------------------ Reporter: br1@internet.com.uy | Owner: simonmar Type: bug | Status: reopened Priority: high | Milestone: 6.8.3 Component: Driver | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: x86_64 (amd64) Os: Windows | ---------------------------------+------------------------------------------ Comment (by bchallenor): Oops, I meant Path. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 5 04:36:38 2007 From: trac at galois.com (GHC) Date: Wed Dec 5 04:32:09 2007 Subject: [GHC] #1958: collect2: ld terminated with signal 10 [Bus error]: Building parsec on a PPC Mac OS X 10.5 Leopard as part of GHC 6.9 Message-ID: <050.c31695132cb1b93380c95a8b6c208782@localhost> #1958: collect2: ld terminated with signal 10 [Bus error]: Building parsec on a PPC Mac OS X 10.5 Leopard as part of GHC 6.9 ----------------------------+----------------------------------------------- Reporter: thorkilnaur | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Compiler | Version: 6.9 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: powerpc | Os: MacOS X ----------------------------+----------------------------------------------- On a PPC Mac OS X 10.5 Leopard, building GHC 6.9 with mk/build.mk set to mk/build.mk.sample with !BuildFlavour = perf and extra libraries included, matters are brought to a halt at: {{{ ../../compiler/stage1/ghc-inplace -package-name parsec-2.0 -hide-all- packages -split-objs -i -idist/build/autogen -idist/build -i. -Idist/build -odir dist/build -hidir dist/build -stubdir dist/build -package base-3.0 -O -XExistentialQuantification -XPolymorphicComponents -idist/build -H32m -O2 -c Text/ParserCombinators/Parsec/Token.hs -o dist/build/Text/ParserCombinators/Parsec/Token.o -ohi dist/build/Text/ParserCombinators/Parsec/Token.hi collect2: ld terminated with signal 10 [Bus error] make[2]: *** [dist/build/Text/ParserCombinators/Parsec/Token.o] Error 1 make[1]: *** [make.library.parsec] Error 2 make: *** [stage1] Error 2 }}} This has been reported earlier: See http://www.haskell.org/pipermail /glasgow-haskell-users/2007-November/013407.html and perhaps elsewhere. I have currently isolated the problem to a single .s file, part of object- splitting the code generated for Token.hs, for which assembling using gcc followed by linking with ld -r provokes the bus error. The case is still rather large, however, and I will reduce some more before reporting the details. I currently suspect a problem in the Mac 10.5 Leopard linker, in addition to the problem reported in #1843. The problem does not occur on 10.4 Tiger. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 5 04:39:05 2007 From: trac at galois.com (GHC) Date: Wed Dec 5 04:35:32 2007 Subject: [GHC] #1843: ghc 6.8.1 broken on Mac OS X Leopard PPC In-Reply-To: <044.ed2a345fe747cd9c97e2c67af33b571b@localhost> References: <044.ed2a345fe747cd9c97e2c67af33b571b@localhost> Message-ID: <053.c90ecca321498ba0c68116a34081def3@localhost> #1843: ghc 6.8.1 broken on Mac OS X Leopard PPC ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: new Priority: high | Milestone: 6.8.2 Component: Compiler | Version: 6.8.1 Severity: critical | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | ----------------------+----------------------------------------------------- Comment (by thorkilnaur): The {{{collect2: ld terminated with signal 10 [Bus error]}}} matter has been reported as #1958. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 5 05:12:45 2007 From: trac at galois.com (GHC) Date: Wed Dec 5 05:08:14 2007 Subject: [GHC] #1168: nofib/spectral/calendar is mis-optimised In-Reply-To: <047.1e9bce153303809272446b6c0aede02d@localhost> References: <047.1e9bce153303809272446b6c0aede02d@localhost> Message-ID: <056.26a038b0397206ac0840b280655b4787@localhost> #1168: nofib/spectral/calendar is mis-optimised -------------------------------------+-------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: nofib/spectral/calendar | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Comment (by simonmar): See also #1957. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 5 05:12:36 2007 From: trac at galois.com (GHC) Date: Wed Dec 5 05:08:18 2007 Subject: [GHC] #1957: Program that runs slower with optimizations on In-Reply-To: <047.0c19d2d6de54af50ee66a95834667ba4@localhost> References: <047.0c19d2d6de54af50ee66a95834667ba4@localhost> Message-ID: <056.bfdcfe76d254ae9e019b5d349e4e8f07@localhost> #1957: Program that runs slower with optimizations on ----------------------+----------------------------------------------------- Reporter: clanehin | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------+----------------------------------------------------- Changes (by simonmar): * status: new => closed * resolution: => duplicate Comment: This is the same as #1168 (but I'll add an xref from there, more examples are always useful). -- Ticket URL: GHC The Glasgow Haskell Compiler From simonmarhaskell at gmail.com Wed Dec 5 05:18:28 2007 From: simonmarhaskell at gmail.com (Simon Marlow) Date: Wed Dec 5 05:14:02 2007 Subject: compiling ghc w/o ghc In-Reply-To: <1171161794.20071122171046@gmail.com> References: <1171161794.20071122171046@gmail.com> Message-ID: <47567AF4.4090307@gmail.com> Bulat Ziganshin wrote: > i've seen the following report from a man who tried to compile 6.8.1 > under linux without having any ghc installed: > > > checking for ghc... no > checking for path to top of build tree... > ./configure: line 2724: -v0: command not found > ./configure: line 2728: utils/pwd/pwd: No such file or directory > > line 2724: > $WithGhc -v0 --make pwd -o pwd > > the $WithGhc variable is empty > > > > afaiu, configure should stop at the moment when previous ghc isn't > found > > (he was extracted ghc-6.8.1-src-extralibs.tar.bz2 and ghc-6.8.1-src.tar.bz2 > if that matter) Thanks, I'm validating a fix for this. Cheers, Simon From trac at galois.com Wed Dec 5 05:22:00 2007 From: trac at galois.com (GHC) Date: Wed Dec 5 05:17:31 2007 Subject: [GHC] #1168: Optimisation sometimes decreases sharing in IO code In-Reply-To: <047.1e9bce153303809272446b6c0aede02d@localhost> References: <047.1e9bce153303809272446b6c0aede02d@localhost> Message-ID: <056.f3b61950582659a4449e5e9f2590b648@localhost> #1168: Optimisation sometimes decreases sharing in IO code -------------------------------------+-------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: _|_ Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: nofib/spectral/calendar | Architecture: Unknown Os: Unknown | -------------------------------------+-------------------------------------- Changes (by simonmar): * summary: nofib/spectral/calendar is mis-optimised => Optimisation sometimes decreases sharing in IO code Comment: Changing the subject to indicate the real cause of the problem. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 5 05:38:52 2007 From: trac at galois.com (GHC) Date: Wed Dec 5 05:34:23 2007 Subject: [GHC] #1887: internal error while running parallel program In-Reply-To: <042.6e0c34c36411842a56980d14ccd17967@localhost> References: <042.6e0c34c36411842a56980d14ccd17967@localhost> Message-ID: <051.f771be3783bd1af0014f7718e19598c4@localhost> #1887: internal error while running parallel program ----------------------------------+----------------------------------------- Reporter: mrd | Owner: simonmar Type: bug | Status: new Priority: normal | Milestone: 6.8.3 Component: Runtime System | Version: 6.9 Severity: normal | Resolution: Keywords: sanity error threads | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Linux | ----------------------------------+----------------------------------------- Comment (by simonmar): Tried to repro this without success so far. I couldn't build ndp with 6.8.1 due to this: {{{ ccTyCon: base:GHC.Base.Bool{(w) tc 3c} ccTyCon: base:GHC.Base.Bool{(w) tc 3c} ccTyCon: base:GHC.Base.Bool{(w) tc 3c} ccTyCon: base:GHC.Base.Bool{(w) tc 3c} ccTyCon: base:GHC.Base.Bool{(w) tc 3c} ghc-6.8.1: panic! (the 'impossible' happened) (GHC version 6.8.1 for x86_64-unknown-linux): vectorise/Vectorise.hs:(303,0)-(327,78): Non-exhaustive patterns in function vectAlgCase }}} which I presume is not a bug. With the HEAD I build ndp and ran the test program on 2 processors many times (20+) successfully. Tried also with -N4, also this machine only has two cores. I'll try next on an 8-proc Windows box, but if you have any more hints as to how to reproduce this I'd be grateful. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 5 10:08:17 2007 From: trac at galois.com (GHC) Date: Wed Dec 5 10:03:47 2007 Subject: [GHC] #1959: Recompilation bug Message-ID: <047.d023c0f6cd4f6961124bab5854dd4844@localhost> #1959: Recompilation bug -------------------------+-------------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 branch Component: Compiler | Version: 6.8.1 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: Unknown | Os: Unknown -------------------------+-------------------------------------------------- I found this bug while researching [wiki:Commentary/Compiler/RecompilationAvoidance]. In some cases the compiler will not recompile when it should. This is a long-standing, albeit serious, bug. Since the reproduction steps are quite intricate, I'll create a test case and then point to it from this ticket. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 5 10:20:41 2007 From: trac at galois.com (GHC) Date: Wed Dec 5 10:16:10 2007 Subject: [GHC] #1959: Recompilation bug In-Reply-To: <047.d023c0f6cd4f6961124bab5854dd4844@localhost> References: <047.d023c0f6cd4f6961124bab5854dd4844@localhost> Message-ID: <056.e3be56fbefbcc3934ad003bd6eaa4205@localhost> #1959: Recompilation bug -------------------------+-------------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8 branch Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: driver/1959 | Architecture: Unknown Os: Unknown | -------------------------+-------------------------------------------------- Changes (by simonmar): * testcase: => driver/1959 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 5 10:22:31 2007 From: trac at galois.com (GHC) Date: Wed Dec 5 10:18:03 2007 Subject: [GHC] #1110: Setting PATH needed in Windows Vista In-Reply-To: <058.e03ccf618ab5a7c0a2551f8b8f819c0f@localhost> References: <058.e03ccf618ab5a7c0a2551f8b8f819c0f@localhost> Message-ID: <067.9e9929a44ced1bd16488cf3faaf328b4@localhost> #1110: Setting PATH needed in Windows Vista ---------------------------------+------------------------------------------ Reporter: br1@internet.com.uy | Owner: igloo Type: merge | Status: new Priority: high | Milestone: 6.8.3 Component: Driver | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: x86_64 (amd64) Os: Windows | ---------------------------------+------------------------------------------ Changes (by simonmar): * status: reopened => new * owner: simonmar => igloo * type: bug => merge Comment: Fixed, to merge: {{{ Wed Dec 5 07:02:30 PST 2007 Simon Marlow * FIX #1110: hackery also needed when running gcc for CPP }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 5 11:41:21 2007 From: trac at galois.com (GHC) Date: Wed Dec 5 11:36:51 2007 Subject: [GHC] #1621: GHCi wrong execution time report In-Reply-To: <044.547081dc40bbb750c3a7c7bbe4e4a502@localhost> References: <044.547081dc40bbb750c3a7c7bbe4e4a502@localhost> Message-ID: <053.770217c390cace00cdee28bdcd069235@localhost> #1621: GHCi wrong execution time report ---------------------+------------------------------------------------------ Reporter: guest | Owner: igloo Type: merge | Status: new Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.6.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Windows | ---------------------+------------------------------------------------------ Changes (by simonmar): * owner: simonmar => igloo * type: bug => merge Comment: Fixed: {{{ Wed Dec 5 04:01:18 PST 2007 Simon Marlow * FIX #1621: bug in Windows code for getCPUTime }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 5 17:57:15 2007 From: trac at galois.com (GHC) Date: Wed Dec 5 17:52:43 2007 Subject: [GHC] #1960: Add Applicative and Monoid instances for STM Message-ID: <044.27a2327a98dc1a1cd8d85ed41bd79a60@localhost> #1960: Add Applicative and Monoid instances for STM -------------------------------+-------------------------------------------- Reporter: conal | Owner: Type: proposal | Status: new Priority: normal | Milestone: Component: libraries/base | Version: 6.8.1 Severity: normal | Keywords: Difficulty: Easy (1 hr) | Testcase: Architecture: Unknown | Os: Unknown -------------------------------+-------------------------------------------- {{{ instance Applicative STM where { pure = return; (<*>) = ap } instance Monoid (STM a) where { mempty = retry; mappend = orElse } }}} I don't know where these instances would go. Nor whether this is a libraries or GHC proposal. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Wed Dec 5 21:34:41 2007 From: trac at galois.com (GHC) Date: Wed Dec 5 21:30:47 2007 Subject: [GHC] #1171: GHC doesn't respect the imprecise exceptions semantics In-Reply-To: <043.e34c647eb7853d1bfa5f9e817d95be19@localhost> References: <043.e34c647eb7853d1bfa5f9e817d95be19@localhost> Message-ID: <052.ae9fc27680b40791777f5266d1fed9ff@localhost> #1171: GHC doesn't respect the imprecise exceptions semantics ----------------------+----------------------------------------------------- Reporter: neil | Owner: Type: bug | Status: reopened Priority: low | Milestone: _|_ Component: Compiler | Version: 6.6 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: cg059 | Architecture: Multiple Os: Multiple | ----------------------+----------------------------------------------------- Comment (by Isaac Dupree): Stefan O'Rear happened to write in haskell-cafe a performance reason for allowing non-termination to throw any exception: "When you see an expression of the form: f a you generally want to evaluate a before applying; but if a is _|_, this will only give the correct result if f a = _|_. Merely 'guaranteed to evaluate' misses out on some common cases, for instance ifac: {{{ ifac 0 a = a ifac n a = ifac (n - 1) (a * n) }}} ifac is guaranteed to either evaluate a, or go into an infinite loop - so it can be found strict, and unboxed. Whereas 'ifac -1 (error "moo")' is an infinite loop, so using a definition based on evaluation misses this case." -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 6 04:32:51 2007 From: trac at galois.com (GHC) Date: Thu Dec 6 04:28:33 2007 Subject: [GHC] #1957: Program that runs slower with optimizations on In-Reply-To: <047.0c19d2d6de54af50ee66a95834667ba4@localhost> References: <047.0c19d2d6de54af50ee66a95834667ba4@localhost> Message-ID: <056.1494ad141e4a0c05f6240195b8777d1d@localhost> #1957: Program that runs slower with optimizations on ----------------------+----------------------------------------------------- Reporter: clanehin | Owner: Type: bug | Status: closed Priority: normal | Milestone: Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: duplicate Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Linux | ----------------------+----------------------------------------------------- Comment (by simonpj): Trying with `-fno-state-hack` (a static flag) would tell you if this was the same as #1168. Does that cure it? Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 6 06:59:02 2007 From: trac at galois.com (GHC) Date: Thu Dec 6 06:54:30 2007 Subject: [GHC] #1959: Recompilation bug In-Reply-To: <047.d023c0f6cd4f6961124bab5854dd4844@localhost> References: <047.d023c0f6cd4f6961124bab5854dd4844@localhost> Message-ID: <056.3bfc1d2855cbd9d4b71d090fe5796fe2@localhost> #1959: Recompilation bug -------------------------+-------------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 6.8.2 Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: driver/1959 | Architecture: Unknown Os: Unknown | -------------------------+-------------------------------------------------- Changes (by igloo): * priority: normal => high * milestone: 6.8 branch => 6.8.2 -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Thu Dec 6 08:21:39 2007 From: trac at galois.com (GHC) Date: Thu Dec 6 08:17:05 2007 Subject: [GHC] #1959: Recompilation bug In-Reply-To: <047.d023c0f6cd4f6961124bab5854dd4844@localhost> References: <047.d023c0f6cd4f6961124bab5854dd4844@localhost> Message-ID: <056.489abcf118381da6a0af548b7886f83f@localhost> #1959: Recompilation bug -------------------------+-------------------------------------------------- Reporter: simonmar | Owner: igloo Type: merge | Status: new Priority: high | Milestone: 6.8.2 Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: driver/1959 | Architecture: Unknown Os: Unknown | -------------------------+-------------------------------------------------- Changes (by simonmar): * owner: => igloo * type: bug => merge Comment: Workaround applied, plesae merge and then re-milestone for 6.10: {{{ Thu Dec 6 00:45:56 PST 2007 Simon Marlow * FIX part of #1959: declaration versions were not being incremented correctly Thu Dec 6 09:23:49 GMT 2007 Simon Marlow * Workaround for #1959: assume untracked names have changed }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 7 09:16:51 2007 From: trac at galois.com (GHC) Date: Fri Dec 7 09:12:23 2007 Subject: [GHC] #1110: Setting PATH needed in Windows Vista In-Reply-To: <058.e03ccf618ab5a7c0a2551f8b8f819c0f@localhost> References: <058.e03ccf618ab5a7c0a2551f8b8f819c0f@localhost> Message-ID: <067.da4489f4e16168611d3470639d710685@localhost> #1110: Setting PATH needed in Windows Vista ---------------------------------+------------------------------------------ Reporter: br1@internet.com.uy | Owner: igloo Type: merge | Status: closed Priority: high | Milestone: 6.8.3 Component: Driver | Version: 6.8.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Easy (1 hr) Testcase: | Architecture: x86_64 (amd64) Os: Windows | ---------------------------------+------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 7 09:18:36 2007 From: trac at galois.com (GHC) Date: Fri Dec 7 09:13:59 2007 Subject: [GHC] #1959: Recompilation bug In-Reply-To: <047.d023c0f6cd4f6961124bab5854dd4844@localhost> References: <047.d023c0f6cd4f6961124bab5854dd4844@localhost> Message-ID: <056.ade06224f872b9c3019d9bfc69ce7784@localhost> #1959: Recompilation bug -------------------------+-------------------------------------------------- Reporter: simonmar | Owner: Type: bug | Status: new Priority: high | Milestone: 6.10 branch Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: driver/1959 | Architecture: Unknown Os: Unknown | -------------------------+-------------------------------------------------- Changes (by igloo): * owner: igloo => * type: merge => bug * milestone: 6.8.2 => 6.10 branch Comment: Both merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 7 09:22:00 2007 From: trac at galois.com (GHC) Date: Fri Dec 7 09:17:25 2007 Subject: [GHC] #1947: Segmentation fault/access violation in generated code In-Reply-To: <051.7113ffd85120a95cf3f282877a678b8a@localhost> References: <051.7113ffd85120a95cf3f282877a678b8a@localhost> Message-ID: <060.6d31a37d7aed2af77a3a3275782cea4e@localhost> #1947: Segmentation fault/access violation in generated code --------------------------+------------------------------------------------- Reporter: NeilMitchell | Owner: igloo Type: task | Status: new Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Windows | --------------------------+------------------------------------------------- Changes (by igloo): * type: merge => task Comment: Merged. Still need to make the test. -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 7 09:26:10 2007 From: trac at galois.com (GHC) Date: Fri Dec 7 09:21:33 2007 Subject: [GHC] #1922: getChar + Ctrl-C on Windows in GHCi breaks In-Reply-To: <044.ef42583e0338257216434a143829cc5f@localhost> References: <044.ef42583e0338257216434a143829cc5f@localhost> Message-ID: <053.f3d30ab823d0a118c94b78ad4a598438@localhost> #1922: getChar + Ctrl-C on Windows in GHCi breaks ---------------------+------------------------------------------------------ Reporter: guest | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.8.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: Unknown Os: Windows | ---------------------+------------------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 7 09:30:49 2007 From: trac at galois.com (GHC) Date: Fri Dec 7 09:26:13 2007 Subject: [GHC] #1621: GHCi wrong execution time report In-Reply-To: <044.547081dc40bbb750c3a7c7bbe4e4a502@localhost> References: <044.547081dc40bbb750c3a7c7bbe4e4a502@localhost> Message-ID: <053.e3ad48f9c6d3a60b88d191e8dfce43a4@localhost> #1621: GHCi wrong execution time report ---------------------+------------------------------------------------------ Reporter: guest | Owner: igloo Type: merge | Status: closed Priority: normal | Milestone: 6.8.3 Component: GHCi | Version: 6.6.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: x86_64 (amd64) Os: Windows | ---------------------+------------------------------------------------------ Changes (by igloo): * status: new => closed * resolution: => fixed Comment: Merged -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 7 12:07:19 2007 From: trac at galois.com (GHC) Date: Fri Dec 7 12:02:52 2007 Subject: [GHC] #1961: sh gen_contents_index --inplace does not work under Solaris Message-ID: <045.116ad859f0d7bf3b95047df75fdbabc3@localhost> #1961: sh gen_contents_index --inplace does not work under Solaris -----------------------------+---------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.8.1 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: x86 | Os: Solaris -----------------------------+---------------------------------------------- when bootstrapping ghc-6.8.1.20071206 under Solaris building failed with: {{{ sh gen_contents_index --inplace haddock: */dist/doc/html/*/*.haddock: openBinaryFile: does not exist (No such file or directory) gmake[1]: *** [doc] Error 1 }}} replacing sh with bash in libraries/Makefile fixed the problem -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 7 12:07:57 2007 From: trac at galois.com (GHC) Date: Fri Dec 7 12:03:20 2007 Subject: [GHC] #1370: Obscure loop in interaction between arity and case-of-bottom In-Reply-To: <046.0bc488ee18ee04e9eecbe565c20a4e89@localhost> References: <046.0bc488ee18ee04e9eecbe565c20a4e89@localhost> Message-ID: <055.6288a14aadd00187eba82925979bc77e@localhost> #1370: Obscure loop in interaction between arity and case-of-bottom -------------------------+-------------------------------------------------- Reporter: simonpj | Owner: simonpj Type: bug | Status: closed Priority: normal | Milestone: 6.8.3 Component: Compiler | Version: 6.6.1 Severity: normal | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: simpl-T1370 | Architecture: Unknown Os: Unknown | -------------------------+-------------------------------------------------- Changes (by simonpj): * testcase: => simpl-T1370 * status: new => closed * resolution: => fixed Comment: Actually this is fixed by the same patch as #1947, namely: {{{ Tue Dec 4 14:58:03 GMT 2007 simonpj@microsoft.com * Make eta reduction check more carefully for bottoms (fix Trac #1947) }}} I added a test case `simpl-T1370` to make sure it stays fixed. Simon -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 7 12:34:33 2007 From: trac at galois.com (GHC) Date: Fri Dec 7 12:30:08 2007 Subject: [GHC] #1961: sh gen_contents_index --inplace does not work under Solaris In-Reply-To: <045.116ad859f0d7bf3b95047df75fdbabc3@localhost> References: <045.116ad859f0d7bf3b95047df75fdbabc3@localhost> Message-ID: <054.d9dd93aa928a320e4d92a0a8c4402963@localhost> #1961: sh gen_contents_index --inplace does not work under Solaris --------------------------+------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.2 Component: Build System | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Solaris | --------------------------+------------------------------------------------- Changes (by igloo): * milestone: => 6.8.2 Comment: Thanks Christian; does the replacement I've attached to this bug report work for you with sh? -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 7 12:50:03 2007 From: trac at galois.com (GHC) Date: Fri Dec 7 12:45:34 2007 Subject: [GHC] #1961: sh gen_contents_index --inplace does not work under Solaris In-Reply-To: <045.116ad859f0d7bf3b95047df75fdbabc3@localhost> References: <045.116ad859f0d7bf3b95047df75fdbabc3@localhost> Message-ID: <054.44b853af7596d2e1495206dc517c3688@localhost> #1961: sh gen_contents_index --inplace does not work under Solaris --------------------------+------------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: 6.8.2 Component: Build System | Version: 6.8.1 Severity: normal | Resolution: Keywords: | Difficulty: Unknown Testcase: | Architecture: x86 Os: Solaris | --------------------------+------------------------------------------------- Comment (by maeder): yes, works, thanks! -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 7 13:19:40 2007 From: trac at galois.com (GHC) Date: Fri Dec 7 13:15:14 2007 Subject: [GHC] #1962: make binary-dist creates nested directories under solaris Message-ID: <045.1c0f16657d83ea78ed7447a0378acec8@localhost> #1962: make binary-dist creates nested directories under solaris -----------------------------+---------------------------------------------- Reporter: maeder | Owner: Type: bug | Status: new Priority: normal | Milestone: Component: Build System | Version: 6.8.1 Severity: normal | Keywords: Difficulty: Unknown | Testcase: Architecture: x86 | Os: Solaris -----------------------------+---------------------------------------------- {{{ cat Makefile >> /home/maeder/haskell/pc- solaris/ghc-6.8.1 .20071206/ghc-6.8.1.20071206/compiler/Makefile /home/maeder/haskell/pc-solaris/ghc-6.8.1.20071206/install-sh -c -m 644 packa ge.conf.in /home/maeder/haskell/pc- solaris/ghc-6.8.1.20071206/ghc-6.8.1.2007 1206/compiler/ set -e; for d in stage2/*/; do ../utils/mkdirhier/mkdirhier /home/maeder/haskell /pc-solaris/ghc-6.8.1.20071206/ghc-6.8.1.20071206/compiler/$d; done mkdir /home/maeder/haskell/pc- solaris/ghc-6.8.1.20071206/ghc-6.8.1.20071206/comp iler/stage2/DEPEND-NOTES mkdir /home/maeder/haskell/pc- solaris/ghc-6.8.1.20071206/ghc-6.8.1.20071206/comp iler/stage2/DEPEND-NOTES/DLL-NOTES mkdir /home/maeder/haskell/pc- solaris/ghc-6.8.1.20071206/ghc-6.8.1.20071206/comp iler/stage2/DEPEND-NOTES/DLL-NOTES/HSghc.o mkdir /home/maeder/haskell/pc- solaris/ghc-6.8.1.20071206/ghc-6.8.1.20071206/comp iler/stage2/DEPEND-NOTES/DLL-NOTES/HSghc.o/HsVersions.h mkdir /home/maeder/haskell/pc- solaris/ghc-6.8.1.20071206/ghc-6.8.1.20071206/comp iler/stage2/DEPEND-NOTES/DLL-NOTES/HSghc.o/HsVersions.h/Makefile mkdir /home/maeder/haskell/pc- solaris/ghc-6.8.1.20071206/ghc-6.8.1.20071206/comp iler/stage2/DEPEND-NOTES/DLL- NOTES/HSghc.o/HsVersions.h/Makefile/Makefile.ghcbin mkdir /home/maeder/haskell/pc- solaris/ghc-6.8.1.20071206/ghc-6.8.1.20071206/comp iler/stage2/DEPEND-NOTES/DLL- NOTES/HSghc.o/HsVersions.h/Makefile/Makefile.ghcbin /NOTES }}} -- Ticket URL: GHC The Glasgow Haskell Compiler From trac at galois.com Fri Dec 7 18:58:02 2007 From: trac at galois.com (GHC) Date: Fri Dec 7 18:54:19 2007 Subject: [GHC] #1843: ghc 6.8.1 broken on Mac OS X Leopard PPC In-Reply-To: <044.ed2a345fe747cd9c97e2c67af33b571b@localhost> References: <044.ed2a345fe747cd9c97e2c67af33b571b@localhost> Message-ID: <053.af0ae9b1e7ee073a6a3e2d68042fb7f8@localhost> #1843: ghc 6.8.1 broken on Mac OS X Leopard PPC ----------------------+----------------------------------------------------- Reporter: guest | Owner: Type: bug | Status: closed Priority: high | Milestone: 6.8.2 Component: Compiler | Version: 6.8.1 Severity: critical | Resolution: fixed Keywords: | Difficulty: Unknown Testcase: | Architecture: powerpc Os: MacOS X | ----------------------+----------------------------------------------------- Changes (by igloo): * status: new => closed * resolution: => fixed Comment: I've applied the patch to HEAD and 6.8 branch, so this bug is now fixed I believe. -- Ticket URL: GHC The Glasgow Haskell Com