[GHC] #2015: SOE samples crash when running from ghci rather than compiling and running with ghc

[GHC]

#2015: SOE samples crash when running from ghci rather than compiling and 
running
with ghc
-+--
Reporter:  justinhj  |   Owner:  
Type:  bug   |  Status:  new 
Priority:  normal|   Milestone:  
   Component:  GHCi  | Version:  6.8.2   
Severity:  normal|Keywords:  SOE ghci
  Difficulty:  Unknown   |Testcase:  
Architecture:  Unknown   |  Os:  Windows 
-+--
 When running the SOE samples from http://haskell.org/soe/software1.htm
 I can compile and run at the command line fine, but if I use ghci instead
 of ghc I always get this error...

 {{{

 C:\cygwin\home\Justin\haskell\SOE\src>ghci
 GHCi, version 6.8.2: http://www.haskell.org/ghc/  :? for help
 Loading package base ... linking ... done.
 Prelude> :load test.hs
 Ok, modules loaded: Snowflake, Main, SOE.
 Prelude Main> main
 Loading package old-locale-1.0.0.0 ... linking ... done.
 Loading package old-time-1.0.0.0 ... linking ... done.
 Loading package OpenGL-2.2.1.1 ... linking ... done.
 Loading package GLFW-0.1 ... : Unknown PEi386 section name
 `.reloc'
  (while processing: C:\Program
 Files\Haskell\GLFW-0.1\ghc-6.8.2/HSGLFW-0.1.o)
 : panic! (the 'impossible' happened)
   (GHC version 6.8.2 for i386-unknown-mingw32):
 loadObj: failed

 Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

 }}}

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [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

[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
-+--
 Reporter:  thorkilnaur  |  Owner:  thorkilnaur
 Type:  bug  | Status:  new
 Priority:  high |  Milestone:  6.8.3  
Component:  Compiler |Version:  6.9
 Severity:  normal   | Resolution: 
 Keywords:   | Difficulty:  Unknown
 Testcase:   |   Architecture:  powerpc
   Os:  MacOS X  |  
-+--
Comment (by eelco):

 I haven't spent much time on this (because I compiling GHC wasn't the
 final goal ;), but the compiler built with 'quickest' gave some strange
 errors concerning interface files when trying to build HAppS.  So I tried
 building 6.8.2 again, again with ld_classic, but now with build flavor
 'quick'.  I had to restart the build 3 or 4 times, since it segfaulted on
 (seemingly) random files.  After that I tried building HAppS again.
 Unfortunately, I got stuck at the same point, this time with a panic.

 {{{
 [10 of 18] Compiling HAppS.State.Transaction (
 src/HAppS/State/Transaction.hs, dist/build/HAppS/State/Transaction.o )

 src/HAppS/State/Transaction.hs:264:42:
 Warning: Defined but not used: `logger'

 src/HAppS/State/Transaction.hs:264:52:
 Warning: Defined but not used: `ev'
 ghc-6.8.2: panic! (the 'impossible' happened)
   (GHC version 6.8.2 for powerpc-apple-darwin):
 splitFunTy
 base:GHC.Conc.STM{tc r2T} base:GHC.Base.(){(w) tc 40}
 }}}

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #1944: round function causes cblas NaNs

[GHC]

#1944: round function causes cblas NaNs
---+
 Reporter:  SevenThunders  |  Owner: 
 Type:  bug| Status:  new
 Priority:  normal |  Milestone:  6.8.3  
Component:  Compiler   |Version:  6.8.1  
 Severity:  critical   | Resolution: 
 Keywords: | Difficulty:  Unknown
 Testcase: |   Architecture:  x86
   Os:  Windows|  
---+
Comment (by SevenThunders):

 Replying to [comment:7 simonmar]:
 > Presumably something in the floating-point unit state is changing in a
 way that upsets the code in the cblas library.  I don't know of anything
 that could cause this; the native code generator does in one place
 generate code that saves and restores the FPU control word, but that was
 added in 6.8.2 (see #1910).
 >
 > To proceed we really need to know what is changing in the FPU state, so
 that we can trace it back to the point at which it changed.  At the very
 least, we need a reproducible test case.  I downloaded your files and
 tried it, but it looks like I have a DLL missing:

 > Using dependency walker it looks like I don't have "MSJAVA.DLL".
 Although why I need that, I have no idea.

 Hmmm, my dependency walker is not showing the same results.  I have no
 dependency on MSJAVA.dll.  The dependencies I show are MSVCRT.dll,
 KERNEL32.dll, NTDLL.dll.  This could be because of the C runtime libraries
 that you are linking  to on your system.  So this is what I did to try to
 remove any possible variation in results.

 First I recompiled my test case using GHC 6.8.2 on my intel core duo
 laptop running windows xp (32 bit).  It still shows the errant NaNs.  I
 then uploaded my atlas.dll file once again just in case.  (Although the
 size of the two files is identical). I then uploaded my C runtime DLLs and
 the system DLLs.  They should be virus free, if my virus protection
 software is any good.  These files are now in subdirectory CRunTime.  I
 suspect it's not entirely kosher to freely publish copyrighted MS software
 so if you can get these to work, let me know and I will delete the system
 files.  You will probably temporarily have to mess with your path or put
 all the DLL's in the same directory with the application to force it to
 pick up the C Runtime I've provided.

 The location of these binaries can be found in:
 http://home.earthlink.net/~mattcbro/Test2/

 Apparently igloo was able to run my test case with my binaries and
 obtained some odd results so I am not alone in this.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: http://www.haskell.org/ghc/dist/mac_frameworks/GNUreadline-framework.zip

[Thorkil Naur]

Hello,

Thanks everybody. However, I believe that using a modified readline library is 
debatable, mainly because it adds the burden of keeping this library 
up-to-date to the GHC maintenance process. Having a renamed library is one 
thing and it does not seem that also modifying the contents of the library is 
an improvement.  For me to consider this idea, it should be the very last 
solution, every other stone having been turned. And I certainly believe that 
stones remain to be turned in this case.

I would very much like to hear your comments to this.

In addition, if you must replace this framework with another with different 
contents, I would suggest the use of some versioning scheme. Otherwise is 
seems that a lot of confusion could result.

Thanks and best regards
Thorkil

On Thursday 03 January 2008 16:18, Ian Lynagh wrote:
> 
> Hi Christian,
> 
> On Thu, Jan 03, 2008 at 02:41:56PM +0100, Christian Maeder wrote:
> > 
> > Judah's framework (2342543 Bytes)
> > http://www.math.ucla.edu/~jjacobson/ghc/GNUreadline-framework.zip
> > 
> > should replace (my old one)
> > http://www.haskell.org/ghc/dist/mac_frameworks/GNUreadline-framework.zip
> 
> Done!
> 
> 
> Thanks
> Ian
> 
> 
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #1987: GHCi's config file in \ghc folder on Windows

[GHC]

#1987: GHCi's config file in \ghc folder on Windows
-+--
 Reporter:  felixmar |  Owner: 
 Type:  feature request  | Status:  new
 Priority:  low  |  Milestone:  6.10 branch
Component:  GHCi |Version:  6.9
 Severity:  normal   | Resolution: 
 Keywords:   | Difficulty:  Unknown
 Testcase:   |   Architecture:  Unknown
   Os:  Windows  |  
-+--
Changes (by ross):

  * type:  proposal => feature request

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #1395: let ./configure check for a GNUreadline framework

[GHC]

#1395: let ./configure check for a GNUreadline framework
-+--
 Reporter:  [EMAIL PROTECTED]|  Owner: 
 Type:  feature request  | Status:  reopened   
 Priority:  normal   |  Milestone:  6.8 branch 
Component:  Build System |Version:  6.8
 Severity:  normal   | Resolution: 
 Keywords:   | Difficulty:  Easy (1 hr)
 Testcase:   |   Architecture:  Multiple   
   Os:  MacOS X  |  
-+--
Comment (by guest):

 By the way; I wrote the previous comment while logged in as `guest`, but
 forgot to sign it.

 -Judah

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #1395: let ./configure check for a GNUreadline framework

[GHC]

#1395: let ./configure check for a GNUreadline framework
-+--
 Reporter:  [EMAIL PROTECTED]|  Owner: 
 Type:  feature request  | Status:  reopened   
 Priority:  normal   |  Milestone:  6.8 branch 
Component:  Build System |Version:  6.8
 Severity:  normal   | Resolution: 
 Keywords:   | Difficulty:  Easy (1 hr)
 Testcase:   |   Architecture:  Multiple   
   Os:  MacOS X  |  
-+--
Comment (by guest):

 Replying to [comment:25 maeder]:
 > My modification of `utils/hsc2hs/Main.hs` (probably) caused the problem
 reported in
 > http://article.gmane.org/gmane.comp.lang.haskell.cafe/34373

 Cabal already handles this type of problem by passing different flags
 based on whether `hsc2hs` is using `gcc` or `ghc`.  This is done in
 `Distribution.Simple.PreProcess.ppHsc2hs` and
 `Simple.Program.hsc2hsProgram`.

 Perhaps Cabal should add the `-F$HOME/Library/Frameworks` instead of
 `hsc2hs` itself?   See http://hackage.haskell.org/trac/hackage/ticket/189

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #793: Use gcc's libffi to replace Adjustor.c and ByteCodeFFI.hs?

[GHC]

#793: Use gcc's libffi to replace Adjustor.c and ByteCodeFFI.hs?
+---
 Reporter:  simonmar|  Owner:  simonmar
 Type:  task| Status:  new 
 Priority:  normal  |  Milestone:  6.8 branch  
Component:  Runtime System  |Version:  6.4.1   
 Severity:  normal  | Resolution:  
 Keywords:  | Difficulty:  Moderate (1 day)
 Testcase:  N/A |   Architecture:  Unknown 
   Os:  Unknown |  
+---
Comment (by igloo):

 I don't think we should bundle it. It's the sort of thing where more
 obscure platforms need the latest version, and we don't another thing we
 have to make sure we keep up-to-date. Also, for the common case (including
 Windows users) it isn't necessary to have it, as the existing code can be
 used instead.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #793: Use gcc's libffi to replace Adjustor.c and ByteCodeFFI.hs?

[GHC]

#793: Use gcc's libffi to replace Adjustor.c and ByteCodeFFI.hs?
+---
 Reporter:  simonmar|  Owner:  simonmar
 Type:  task| Status:  new 
 Priority:  normal  |  Milestone:  6.8 branch  
Component:  Runtime System  |Version:  6.4.1   
 Severity:  normal  | Resolution:  
 Keywords:  | Difficulty:  Moderate (1 day)
 Testcase:  N/A |   Architecture:  Unknown 
   Os:  Unknown |  
+---
Changes (by simonmar):

  * owner:  => simonmar

Comment:

 I have the `createAdjustor` part of this working, but it needs proper
 autoconf gubbins etc., and we need to decide whether to import `libffi`
 into our tree and hook it into the build system or not.  Right now I'm
 compiling against the `libffi` supplied by Debian/Ubuntu, which appears to
 be close to the version in the gcc SVN repository.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #2011: [6.8.1 regression] panic: lookupVers1 base:GHC.Prim sym{tc}

[GHC]

#2011: [6.8.1 regression] panic: lookupVers1 base:GHC.Prim sym{tc}
--+-
 Reporter:  simonmar  |  Owner:  igloo  
 Type:  merge | Status:  new
 Priority:  high  |  Milestone:  6.8.3  
Component:  Compiler  |Version:  6.8.2  
 Severity:  normal| Resolution: 
 Keywords:| Difficulty:  Unknown
 Testcase:|   Architecture:  Unknown
   Os:  Unknown   |  
--+-
Changes (by simonpj):

  * owner:  simonpj => igloo
  * type:  bug => merge

Comment:

 The patch is this one.  Ian, please merge to 6.8 branch.
 {{{
 Thu Dec 20 16:43:07 GMT 2007  [EMAIL PROTECTED]
   * Fix nasty recompilation bug in MkIface.computeChangedOccs

 MERGE to 6.8 branch

   In computeChangedOccs we look up the old version of a Name.
   But a WiredIn Name doesn't have an old version, because WiredIn things
   don't appear in interface files at all.

   Result: ghc-6.9: panic! (the 'impossible' happened)
 (GHC version 6.9 for x86_64-unknown-linux):
 lookupVers1 base:GHC.Prim chr#{v}

   This fixes the problem.  The patch should merge easily onto the branch.
 }}}

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #2000: -funfolding-update-in-place badly documented

[GHC]

#2000: -funfolding-update-in-place badly documented
--+-
 Reporter:  m4dc4p|  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):

  * type:  bug => merge

Comment:

 It's an obsolete flag that does nothing.  I'll remove the documentation:
 {{{
 Thu Jan  3 16:00:36 GMT 2008  [EMAIL PROTECTED]
   * Remove -funfolding-update-in-place flag documentation
 }}}
 Merge to 6.8 branch, pls.

 Simon

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #2006: unreachable GADT pattern clauses show up as warnings with -Wall

[GHC]

#2006: unreachable GADT pattern clauses show up as warnings with -Wall
--+-
 Reporter:  ryani |  Owner: 
 Type:  bug   | Status:  new
 Priority:  normal|  Milestone:  6.10 branch
Component:  Compiler  |Version:  6.8.1  
 Severity:  normal| Resolution: 
 Keywords:| Difficulty:  Unknown
 Testcase:|   Architecture:  Unknown
   Os:  Unknown   |  
--+-
Changes (by simonpj):

  * milestone:  6.8 branch => 6.10 branch

Comment:

 Quite right.  The "non-exhaustive pattern" warning comes from a part of
 the compiler that needs a serious overhaul.  See #595.  In particular,
 it's utterly unaware of GADTs, so it's going to produce spurious warnings,
 and will continue to do so until it is overhauled.

 We definitely won't fix this on the 6.8 branch.  Probably it needs a
 volunteer.

 Simon

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #595: Overhaul GHC's overlapping/non-exhaustive pattern checking

[GHC]

#595: Overhaul GHC's overlapping/non-exhaustive pattern checking
--+-
 Reporter:  simonmar  |  Owner:
 Type:  task  | Status:  new   
 Priority:  normal|  Milestone:  _|_   
Component:  Compiler  |Version:  None  
 Severity:  normal| Resolution:  None  
 Keywords:  warnings  | Difficulty:  Difficult (1 week)
 Testcase:  N/A   |   Architecture:  Unknown   
   Os:  Unknown   |  
--+-
Comment (by simonpj):

 And #2006

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: http://www.haskell.org/ghc/dist/mac_frameworks/GNUreadline-framework.zip

[Ian Lynagh]

Hi Christian,

On Thu, Jan 03, 2008 at 02:41:56PM +0100, Christian Maeder wrote:
> 
> Judah's framework (2342543 Bytes)
> http://www.math.ucla.edu/~jjacobson/ghc/GNUreadline-framework.zip
> 
> should replace (my old one)
> http://www.haskell.org/ghc/dist/mac_frameworks/GNUreadline-framework.zip

Done!


Thanks
Ian

___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #1898: segfault with +RTS -N2 (related to tryTakeMVar?)

[GHC]

#1898: segfault with +RTS -N2 (related to tryTakeMVar?)
+---
 Reporter:  j.waldmann  |  Owner:  igloo  
 Type:  merge   | Status:  new
 Priority:  high|  Milestone:  6.8.3  
Component:  Compiler|Version:  6.8.1  
 Severity:  normal  | Resolution: 
 Keywords:  | Difficulty:  Unknown
 Testcase:  |   Architecture:  x86
   Os:  Linux   |  
+---
Changes (by simonmar):

  * owner:  simonmar => igloo
  * type:  bug => merge

Comment:

 Fixed:
 {{{
 Thu Jan  3 03:27:17 PST 2008  Simon Marlow <[EMAIL PROTECTED]>
   * FIX #1898: add a missing UNTAG_CLOSURE() in checkBlackHoles
 }}}

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #1999: panic with GADT etc.

[GHC]

#1999: panic with GADT etc.
--+-
 Reporter:  jeltsch   |  Owner:  chak   
 Type:  bug   | Status:  new
 Priority:  normal|  Milestone:  6.10 branch
Component:  Compiler  |Version:  6.9
 Severity:  normal| Resolution: 
 Keywords:| Difficulty:  Unknown
 Testcase:|   Architecture:  x86
   Os:  Linux |  
--+-
Changes (by simonpj):

  * owner:  => chak

Comment:

 However, it may well not work in the HEAD, where Manuel is busy ripping
 out the old implementation of GADTs, in favour of the new type-function-
 based machinery.

 So I'm assigning this to Manuel; it'd be good to make a test case out of
 it too.

 Simon

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #2013: ghci crash on startup: R_X86_64_32S relocation out of range.

[GHC]

#2013: ghci crash on startup: R_X86_64_32S relocation out of range.
-+--
 Reporter:  mboes|  Owner:
 Type:  bug  | Status:  new   
 Priority:  normal   |  Milestone:  6.8.3 
Component:  GHCi |Version:  6.8.1 
 Severity:  normal   | Resolution:
 Keywords:   | Difficulty:  Unknown   
 Testcase:   |   Architecture:  x86_64 (amd64)
   Os:  FreeBSD  |  
-+--
Comment (by mboes):

 Debug output of
 {{{
 ./stage2/ghc-inplace --interactive +RTS -Dl 2>&1 | tee log
 }}}
 is at [http://code.haskell.org/~mboes/log.bz2] (log too big for attachment
 on trac).

 Note that FreeBSD, just like OpenBSD, does not define MAP_32BIT and
 MAP_ANONYMOUS. I see in Linker.c the following #define:
 {{{
 #if defined(x86_64_HOST_ARCH) && defined(MAP_32BIT)
 #define EXTRA_MAP_FLAGS MAP_32BIT
 #else
 #define EXTRA_MAP_FLAGS 0
 #endif
 }}}

 But then I see an attempt to resolve symbols allocated in high memory
 using a bounce sequence:
 {{{
 // On x86_64, 32-bit relocations are often used, which requires that
 // we can resolve a symbol to a 32-bit offset.  However, shared
 // libraries are placed outside the 2Gb area, which leaves us with a
 // problem when we need to give a 32-bit offset to a symbol in a
 // shared library.
 //
 // For a function symbol, we can allocate a bounce sequence inside the
 // 2Gb area and resolve the symbol to this.  The bounce sequence is
 // simply a long jump instruction to the real location of the symbol.
 //
 // For data references, we're screwed.
 //
 ...
 static void*
 x86_64_high_symbol( char *lbl, void *addr )
 {
 x86_64_bounce *bounce;

 if ( x86_64_bounce_buffer == NULL ||
  x86_64_bb_next_off >= X86_64_BB_SIZE ) {
 x86_64_bounce_buffer =
 mmap(NULL, X86_64_BB_SIZE * sizeof(x86_64_bounce),
  PROT_EXEC|PROT_READ|PROT_WRITE,
  MAP_PRIVATE|EXTRA_MAP_FLAGS|MAP_ANONYMOUS, -1, 0);
 if (x86_64_bounce_buffer == MAP_FAILED) {
 barf("x86_64_high_symbol: mmap failed");
 }
 x86_64_bb_next_off = 0;
 }
 ...
 }}}

 Since there is no MAP_32BIT on FreeBSD it would seem the above bounce
 sequence can get arbitrarily allocated in high memory. Could this be the
 problem? I'm way out of my depth here, so please forgive the daftness of
 this question, but on my system there are no 32bit libraries at all, only
 64bit ones. Hence, could we do away with 32bit relocations entirely?

 Hope this helps,

 Mathieu

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

http://www.haskell.org/ghc/dist/mac_frameworks/GNUreadline-framework.zip

[Christian Maeder]

Hi Ian,

Judah's framework (2342543 Bytes)
http://www.math.ucla.edu/~jjacobson/ghc/GNUreadline-framework.zip

should replace (my old one)
http://www.haskell.org/ghc/dist/mac_frameworks/GNUreadline-framework.zip

as described in http://hackage.haskell.org/trac/ghc/ticket/1931

I've also a copy at
http://www.informatik.uni-bremen.de/agbkb/forschung/formal_methods/CoFI/hets/mac/GNUreadline-framework.zip

Cheers Christian

(only the header files are different to allow inclusion via the -F flag
to gcc on Macs)
___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #1898: segfault with +RTS -N2 (related to tryTakeMVar?)

[GHC]

#1898: segfault with +RTS -N2 (related to tryTakeMVar?)
+---
 Reporter:  j.waldmann  |  Owner:  simonmar
 Type:  bug | Status:  new 
 Priority:  high|  Milestone:  6.8.3   
Component:  Compiler|Version:  6.8.1   
 Severity:  normal  | Resolution:  
 Keywords:  | Difficulty:  Unknown 
 Testcase:  |   Architecture:  x86 
   Os:  Linux   |  
+---
Changes (by simonmar):

  * owner:  => simonmar

Comment:

 I'm testing a fix for this.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #1944: round function causes cblas NaNs

[GHC]

#1944: round function causes cblas NaNs
---+
 Reporter:  SevenThunders  |  Owner: 
 Type:  bug| Status:  new
 Priority:  normal |  Milestone:  6.8.3  
Component:  Compiler   |Version:  6.8.1  
 Severity:  critical   | Resolution: 
 Keywords: | Difficulty:  Unknown
 Testcase: |   Architecture:  x86
   Os:  Windows|  
---+
Comment (by simonmar):

 Presumably something in the floating-point unit state is changing in a way
 that upsets the code in the cblas library.  I don't know of anything that
 could cause this; the native code generator does in one place generate
 code that saves and restores the FPU control word, but that was added in
 6.8.2 (see #1910).

 To proceed we really need to know what is changing in the FPU state, so
 that we can trace it back to the point at which it changed.  At the very
 least, we need a reproducible test case.  I downloaded your files and
 tried it, but it looks like I have a DLL missing:

 {{{
 c:\builds\atlas\Test2>maketest

 c:\builds\atlas\Test2>set CLIB=atlas

 c:\builds\atlas\Test2>set TopFile=Test2

 c:\builds\atlas\Test2>set csrc=ctest2.c

 c:\builds\atlas\Test2>set OutFile=Test2.exe

 c:\builds\atlas\Test2>dlltool.exe -D atlas.dll -l atlas.lib

 c:\builds\atlas\Test2>set XFLAGS=-threaded -O -XForeignFunctionInterface

 c:\builds\atlas\Test2>rem set XFLAGS=-threaded -O -fffi

 c:\builds\atlas\Test2>ghc -threaded -O -XForeignFunctionInterface -I.
 -I..\matri
 xstack --make Test2.hs ctest2.c -o Test2.exe -optl-latlas -optl-L"."
 [1 of 1] Compiling Main ( Test2.hs, Test2.o )
 Linking Test2.exe ...

 c:\builds\atlas\Test2>Test2

 c:\builds\atlas\Test2>dir
  Volume in drive C has no label.
  Volume Serial Number is 6041-4C23

  Directory of c:\builds\atlas\Test2

 03/01/2008  10:38  .
 03/01/2008  10:38  ..
 29/11/2007  02:28 5,485,456 atlas.dll
 03/01/2008  10:38 1,490 atlas.lib
 29/11/2007  02:28   547 ctest2.c
 29/11/2007  02:28   721 ctest2.h
 03/01/2008  10:38   849 ctest2.o
 03/01/2008  10:37   433 index.html
 29/11/2007  02:28   309 maketest.bat
 03/01/2008  10:38   687,370 Test2.exe
 03/01/2008  10:38   502 Test2.exe.manifest
 03/01/2008  10:38 1,913 Test2.hi
 29/11/2007  02:28   178 Test2.hs
 03/01/2008  10:38 4,920 Test2.o
   12 File(s)  6,184,688 bytes
2 Dir(s)  47,145,406,464 bytes free

 c:\builds\atlas\Test2>Test2.exe

 c:\builds\atlas\Test2>
 }}}

 Using dependency walker it looks like I don't have "MSJAVA.DLL".  Although
 why I need that, I have no idea.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #1012: ghc panic with mutually recursive modules and template haskell

[GHC]

#1012: ghc panic with mutually recursive modules and template haskell
--+-
 Reporter:  guest |  Owner:
 Type:  bug   | Status:  reopened  
 Priority:  normal|  Milestone:  6.8 branch
Component:  Template Haskell  |Version:  6.8.2 
 Severity:  normal| Resolution:
 Keywords:| Difficulty:  Unknown   
 Testcase:  TH_import_loop|   Architecture:  Multiple  
   Os:  Multiple  |  
--+-
Changes (by simonmar):

  * milestone:  _|_ => 6.8 branch

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #1012: ghc panic with mutually recursive modules and template haskell

[GHC]

#1012: ghc panic with mutually recursive modules and template haskell
--+-
 Reporter:  guest |  Owner:  
 Type:  bug   | Status:  reopened
 Priority:  normal|  Milestone:  _|_ 
Component:  Template Haskell  |Version:  6.8.2   
 Severity:  normal| Resolution:  
 Keywords:| Difficulty:  Unknown 
 Testcase:  TH_import_loop|   Architecture:  Multiple
   Os:  Multiple  |  
--+-
Comment (by simonmar):

 Since `ModuleB` is outside the `ModuleA/ModuleC` loop, it can import
 `ModuleA` without creating any new loops, and I bet this will work around
 the problem and get you unblocked.

 What's happening is that the dependency analysis isn't figuring out that
 the real `ModuleA` must be compiled before `ModuleB`.  I think the
 solution is something along the lines of: every module that depends on a
 module in a cycle, but is not a member of that cycle, should have an
 implicit dependency on each of the modules in the cycle.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs

Re: [GHC] #2013: ghci crash on startup: R_X86_64_32S relocation out of range.

[GHC]

#2013: ghci crash on startup: R_X86_64_32S relocation out of range.
-+--
 Reporter:  mboes|  Owner:
 Type:  bug  | Status:  new   
 Priority:  normal   |  Milestone:  6.8.3 
Component:  GHCi |Version:  6.8.1 
 Severity:  normal   | Resolution:
 Keywords:   | Difficulty:  Unknown   
 Testcase:   |   Architecture:  x86_64 (amd64)
   Os:  FreeBSD  |  
-+--
Changes (by simonmar):

  * milestone:  => 6.8.3

Comment:

 Could you link the stage 2 compiler with -debug:
 {{{
 $ cd compiler
 $ rm stage2/ghc-6.9*
 $ make stage=2 EXTRA_HC_OPTS=-debug
 }}}
 and then capture the linker debugging output:
 {{{
 $ ./stage2/ghc-inplace +RTS -Dl 2>&1 | tee log
 }}}

 this should help track down the problem.

-- 
Ticket URL: 
GHC 
The Glasgow Haskell Compiler___
Glasgow-haskell-bugs mailing list
Glasgow-haskell-bugs@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs