date:20080514

Re: [GHC] #2279: Include library source code in distribution

2008-05-14 Thread GHC

#2279: Include library source code in distribution
-+--
 Reporter:  guest|  Owner:
 Type:  feature request  | Status:  closed
 Priority:  normal   |  Milestone:
Component:  Documentation|Version:  6.8.2 
 Severity:  normal   | Resolution:  worksforme
 Keywords:   | Difficulty:  Unknown   
 Testcase:   |   Architecture:  Multiple  
   Os:  Multiple |  
-+--
Changes (by igloo):

  * status:  new => closed
  * difficulty:  => Unknown
  * resolution:  => worksforme

Comment:

 Thanks for the suggestion. Happily, the docs already include the source
 code, e.g.: http://www.haskell.org/ghc/docs/latest/html/libraries/base/src
 /Control-Concurrent.html

-- 
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] #2148: x86_64 code use several GiB of memory generates: internal error: ASSERTION FAILED: file sm/Storage.c, line 1126

2008-05-14 Thread GHC

#2148: x86_64 code use several GiB of memory generates: internal error: 
ASSERTION
FAILED: file sm/Storage.c, line 1126
+---
 Reporter:  twhitehead  |  Owner:  simonmar  
 Type:  bug | Status:  new   
 Priority:  high|  Milestone:  6.8.3 
Component:  Runtime System  |Version:  6.8.2 
 Severity:  normal  | Resolution:
 Keywords:  | Difficulty:  Unknown   
 Testcase:  |   Architecture:  x86_64 (amd64)
   Os:  Linux   |  
+---
Comment (by twhitehead):

 Bug2.hs is the 1hr-42min-to-crash code, I just made a mistake when quoting
 its runtime in the fastest-to-crash-code note above (I also made it
 somewhat confusing in the detailed messages above by always just refering
 to Bug.hs as I didn't actually add the extensions until I went to upload
 them).

 With regard to not having a machine with enough memory, I can get you
 access to our 32GiB-per-node cluster if that would help.

-- 
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] #1886: GHC API should preserve and provide access to comments

2008-05-14 Thread GHC

#1886: GHC API should preserve and provide access to comments
---+
 Reporter:  claus  |  
Owner: 
 Type:  bug| 
Status:  new
 Priority:  normal |  
Milestone:  6.10 branch
Component:  GHC API|
Version:  6.9
 Severity:  normal | 
Resolution: 
 Keywords:  GHC API, comments, program transformation, layout  | 
Difficulty:  Unknown
 Testcase: |   
Architecture:  Unknown
   Os:  Unknown|  
---+
Comment (by claus):

 see also this thread for a simpler breakdown of what is needed, and how it
 might be achieved:

 http://www.haskell.org/pipermail/haskell-cafe/2008-May/042671.html

-- 
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] #2257: validate hangs in configure

2008-05-14 Thread Norman Ramsey

 > #2257: validate hangs in configure
 > --+-
 >  Reporter:  nr|  Owner: 
 >  Type:  bug   | Status:  new
 >  Priority:  highest   |  Milestone:  6.8.3  
 > Component:  Build System  |Version:  6.8.2  
 >  Severity:  major | Resolution: 
 >  Keywords:| Difficulty:  Unknown
 >  Testcase:|   Architecture:  x86
 >Os:  Linux |  
 > --+-
 > Comment (by simonmar):
 > 
 >  I don't have any machines that exhibit this behaviour.  Can anyone help?

Send me an ssh public key and I'll give you a login on the offending machine.



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

Re: [GHC] #2284: Stack-hack optimization causes much re-computation in GUI callbacks

2008-05-14 Thread GHC

#2284: Stack-hack optimization causes much re-computation in GUI callbacks
--+-
Reporter:  sedillard  |Owner:  
Type:  bug|   Status:  new 
Priority:  normal |Milestone:  
   Component:  Compiler   |  Version:  6.8.2   
Severity:  normal |   Resolution:  
Keywords: | Testcase:  
Architecture:  Unknown|   Os:  Multiple
--+-
Comment (by sedillard):

 Oops the big test file is too big. You can download it here:

 http://graphics.cs.ucdavis.edu/~sdillard/horse.obj.gz

 With -O2 and -fno-state-hack it actually does quite well on my 2.1Ghz
 machine.

 Scott

-- 
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

[GHC] #2285: Solaris 9 build fails at stage2 with undefined symbol errors (for libm symbols)

2008-05-14 Thread GHC

#2285: Solaris 9 build fails at stage2 with undefined symbol errors (for libm
symbols)
--+-
Reporter:  TimBishop  |   Owner:  
Type:  bug|  Status:  new 
Priority:  normal |   Component:  Compiler
 Version:  6.8.2  |Severity:  normal  
Keywords: |Testcase:  
Architecture:  sparc  |  Os:  Solaris 
--+-
 (A copy of the pasted errors is attached to the ticket)

 I'm having a problem building ghc 6.8.2 using gcc 4.2.3 on Solaris 9. The
 problem occurs during the linking of stage2/ghc-inplace. Here is the
 error:

 {{{
 make[3]: Entering directory
 `/u1/src/garstow/devel/ghc/work/ghc-6.8.2/compiler'
 ../compiler/stage1/ghc-inplace -cpp  stage2/ghc-inplace.c -o stage2/ghc-
 inplace
 Undefined   first referenced
  symbol in file
  cosf
 
/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build/libHSbase-3.0.1.0.a(Float__1.o)
  expf
 
/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build/libHSbase-3.0.1.0.a(Float__1.o)
  logf
 
/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build/libHSbase-3.0.1.0.a(Float__1.o)
  powf
 
/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build/libHSbase-3.0.1.0.a(Float__1.o)
  sinf
 
/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build/libHSbase-3.0.1.0.a(Float__1.o)
  tanf
 
/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build/libHSbase-3.0.1.0.a(Float__1.o)
  acosf
 
/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build/libHSbase-3.0.1.0.a(Float__1.o)
  asinf
 
/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build/libHSbase-3.0.1.0.a(Float__1.o)
  atanf
 
/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build/libHSbase-3.0.1.0.a(Float__1.o)
  coshf
 
/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build/libHSbase-3.0.1.0.a(Float__1.o)
  sinhf
 
/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build/libHSbase-3.0.1.0.a(Float__1.o)
  tanhf
 
/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build/libHSbase-3.0.1.0.a(Float__1.o)
  sqrtf
 
/u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/dist/build/libHSbase-3.0.1.0.a(Float__1.o)
  ld: fatal: Symbol referencing errors. No output written to stage2/ghc-
 inplace
  collect2: ld returned 1 exit status
  make[3]: *** [stage2/ghc-inplace] Error 1
  make[3]: Leaving directory
 `/u1/src/garstow/devel/ghc/work/ghc-6.8.2/compiler'
  make[2]: *** [stage2] Error 2
  make[2]: Leaving directory `/u1/src/garstow/devel/ghc/work/ghc-6.8.2'
  make[1]: *** [bootstrap2] Error 2
  make[1]: Leaving directory `/u1/src/garstow/devel/ghc/work/ghc-6.8.2'
  make: *** [build-work/ghc-6.8.2/Makefile] Error 2
 }}}

 It was fairly obvious those symbols were provided by libm, so I did a
 little digging to check if it was trying to link -lm, and it was:

 {{{
 [EMAIL PROTECTED] [/u1/src/garstow/devel/ghc/work/ghc-6.8.2/compiler] %
 ../compiler/stage1/ghc-inplace -v -cpp stage2/ghc-inplace.c -o stage2/ghc-
 inplace
 Using /u1/src/garstow/devel/ghc/work/ghc-6.8.2/compiler/stage1/ghc-6.8.2
 -B/u1/src/garstow/devel/ghc/work/ghc-6.8.2 -fhardwire-lib-paths
 Glasgow Haskell Compiler, Version 6.8.2, for Haskell 98, stage 1 booted by
 GHC version 6.4.1
 Using package config file:
 /u1/src/garstow/devel/ghc/work/ghc-6.8.2/driver/package.conf.inplace
 wired-in package base mapped to base-3.0.1.0
 wired-in package rts mapped to rts-1.0
 wired-in package haskell98 mapped to haskell98-1.0.1.0
 wired-in package template-haskell mapped to template-haskell-2.2.0.0
 wired-in package ndp not found.
 Hsc static flags: -fhardwire-lib-paths -static
 Created temporary directory: /tmp/ghc6599_0
 *** C Compiler:
 gcc -x c stage2/ghc-inplace.c -o /tmp/ghc6599_0/ghc6599_0.s -mcpu=v9 -v -S
 -Wimplicit -O -D__GLASGOW_HASKELL__=608 -DTABLES_NEXT_TO_CODE -I
 /u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/include -I
 /u1/src/garstow/devel/ghc/work/ghc-6.8.2/includes -I
 /u1/src/garstow/devel/ghc/work/ghc-6.8.2/rts -I
 /u1/src/garstow/devel/ghc/work/ghc-6.8.2/gmp/gmpbuild
 Using built-in specs.
 Target: sparc-sun-solaris2.9
 Configured with: ../../work/gcc-4.2.3/configure --enable-threads --enable-
 shared=libstdc++ --enable-
 languages=ada,c,c++,fortran,java,objc,obj-c++,treelang --with-
 as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld
 Thread model: posix
 gcc version 4.2.3
  /usr/local/packages/gcc-4.2.3/bin/../libexec/gcc/sparc-sun-
 solaris2.9/4.2.3/cc1 -quiet -v -I
 /u1/src/garstow/devel/ghc/work/ghc-6.8.2/libraries/base/include -I
 /u1/src/garstow/devel/ghc/work/ghc-6.8.2/includes -I
 /u1/src/garstow/devel/ghc/work/ghc-6.8.2/rts -I
 /u1/src/garstow/devel/ghc/work/ghc-6.8.2/gmp/gmpbuild -iprefix
 /usr/local/packages/gcc-4.2.3/bin/../lib/gcc/sparc-

[GHC] #2284: Stack-hack optimization causes much re-computation in GUI callbacks

2008-05-14 Thread GHC

#2284: Stack-hack optimization causes much re-computation in GUI callbacks
--+-
Reporter:  sedillard  |   Owner:  
Type:  bug|  Status:  new 
Priority:  normal |   Component:  Compiler
 Version:  6.8.2  |Severity:  normal  
Keywords: |Testcase:  
Architecture:  Unknown|  Os:  Multiple
--+-
 This is a duplicate of #1168, recorded for posterity here, at the request
 of Simon PJ,

 http://www.haskell.org/pipermail/glasgow-haskell-
 users/2008-May/014739.html

 An IO lambda is created within main's scope, and this is given to the GLUT
 GUI library (or it could be GTK or wxHaskell) as a callback to draw the
 contents of the window. The callback lambda captures a value from the
 outer scope, but the state-hack inlines the value's defining expression
 into the callback. Thus, the value is re-computed every time the callback
 is called.

 -fno-state-hack fixes it.

 The attached program is a 3D model viewer. I've attached two models, one
 is small, the other larger. The performance hit is quite noticeable on the
 large one. The models need to be unzipped before running.

 {{{
 gunzip torus.obj.gz
 ./ObjView torus.obj
 }}}

 use x y z to rotate and force a redraw. When compiled with -O0 or -fno-
 state-hack, you'll see "BUILDING MESH" output once, otherwise it will be
 output on every redraw.

-- 
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] #2275: Poor indication of type error location

2008-05-14 Thread GHC

#2275: Poor indication of type error location
-+--
 Reporter:  guest|  Owner: 
 Type:  bug  | Status:  new
 Priority:  normal   |  Milestone: 
Component:  Compiler (Type checker)  |Version:  6.8.2  
 Severity:  normal   | Resolution: 
 Keywords:   | Difficulty:  Unknown
 Testcase:   |   Architecture:  Unknown
   Os:  Unknown  |  
-+--
Comment (by simonpj):

 I can't say I understand just what's going on here.  It's difficult to fix
 this unless we can reproduce it, but you don't give enough information to
 do that.  If you have enough time to upload a reproducible test case,
 that'd be great.

 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] #2276: foreign import stdcall "&foo" doesn't work

2008-05-14 Thread GHC

#2276: foreign import stdcall "&foo" doesn't work
--+-
 Reporter:  simonmar  |  Owner:  igloo  
 Type:  merge | Status:  new
 Priority:  normal|  Milestone:  6.8.3  
Component:  Compiler  |Version:  6.8.2  
 Severity:  normal| Resolution: 
 Keywords:| Difficulty:  Unknown
 Testcase:|   Architecture:  x86
   Os:  Windows   |  
--+-
Changes (by simonmar):

  * owner:  => igloo
  * type:  bug => merge
  * milestone:  _|_ => 6.8.3

Comment:

 Fixed.  This can be merged, but omitting the changes to PprC and CLabel
 which aren't necessary on the stable branch.

 {{{
 Wed May 14 01:24:22 PDT 2008  Simon Marlow <[EMAIL PROTECTED]>
   * FIX #2276: foreign import stdcall "&foo" doesn't work
 }}}

-- 
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] #1288: ghci 6.6 foreign import stdcall broken, panic, panic!!!!

2008-05-14 Thread GHC

#1288: ghci 6.6 foreign import stdcall broken, panic, panic
-+--
 Reporter:  [EMAIL PROTECTED]   |  Owner:  igloo
   
 Type:  merge| Status:  new 

 Priority:  normal   |  Milestone:  6.8.3   

Component:  GHCi |Version:  6.6 

 Severity:  critical | Resolution:  

 Keywords:  ghci foreign ffi dll import stdcall  | Difficulty:  Moderate (1 
day)
 Testcase:   |   Architecture:  x86 

   Os:  Windows  |  
-+--
Changes (by simonmar):

  * milestone:  6.10 branch => 6.8.3

-- 
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] #1288: ghci 6.6 foreign import stdcall broken, panic, panic!!!!

2008-05-14 Thread GHC

#1288: ghci 6.6 foreign import stdcall broken, panic, panic
-+--
 Reporter:  [EMAIL PROTECTED]   |  Owner:  igloo
   
 Type:  merge| Status:  new 

 Priority:  normal   |  Milestone:  6.10 branch 

Component:  GHCi |Version:  6.6 

 Severity:  critical | Resolution:  

 Keywords:  ghci foreign ffi dll import stdcall  | Difficulty:  Moderate (1 
day)
 Testcase:   |   Architecture:  x86 

   Os:  Windows  |  
-+--
Changes (by simonmar):

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

Comment:

 One bug fixed, remaining bug moved to #2283

 To merge:

 {{{
 Wed May 14 02:27:42 PDT 2008  Simon Marlow <[EMAIL PROTECTED]>
   * FIX #1288: GHCi wasn't adding the @n suffix to stdcalls on Windows
 }}}

-- 
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] #2038: System.Posix.Resource.setResourceLimit gives "setResourceLimit: invalid argument (Invalid argument)"

2008-05-14 Thread GHC

#2038: System.Posix.Resource.setResourceLimit gives "setResourceLimit: invalid
argument (Invalid argument)"
---+
 Reporter:  slyfox |  Owner:  igloo  
 Type:  bug| Status:  new
 Priority:  high   |  Milestone:  6.8.3  
Component:  libraries/unix |Version:  6.8.2  
 Severity:  major  | Resolution: 
 Keywords:  regression, ffi, unix  | Difficulty:  Unknown
 Testcase: |   Architecture:  x86
   Os:  Linux  |  
---+
Changes (by igloo):

  * owner:  => igloo

-- 
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] #2148: x86_64 code use several GiB of memory generates: internal error: ASSERTION FAILED: file sm/Storage.c, line 1126

2008-05-14 Thread GHC

#2148: x86_64 code use several GiB of memory generates: internal error: 
ASSERTION
FAILED: file sm/Storage.c, line 1126
+---
 Reporter:  twhitehead  |  Owner:  simonmar  
 Type:  bug | Status:  new   
 Priority:  high|  Milestone:  6.8.3 
Component:  Runtime System  |Version:  6.8.2 
 Severity:  normal  | Resolution:
 Keywords:  | Difficulty:  Unknown   
 Testcase:  |   Architecture:  x86_64 (amd64)
   Os:  Linux   |  
+---
Comment (by simonmar):

 Sadly I have no machines with enough memory to run this program.

 Also, reading back through the comments apparently `Bug.hs` crashed in "an
 hour and three quarters", which would make it quicker than the 3hrs 10min
 for `Bug2.hs`, right?  Unfortunately from the memory leak message, it
 seems like the RTS had been using around 13Gb at the time, which is way
 more than I have in any of my machines.  I'll look into getting a new
 machine, or some more memory.

-- 
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] #2282: threaded runtime system crashes on powerpc with -N2

2008-05-14 Thread GHC

#2282: threaded runtime system crashes on powerpc with -N2
---+
 Reporter:  [EMAIL PROTECTED]  |  Owner: 
 Type:  bug| Status:  new
 Priority:  normal |  Milestone: 
Component:  Runtime System |Version:  6.8.2  
 Severity:  normal | Resolution: 
 Keywords: | Difficulty:  Unknown
 Testcase: |   Architecture:  powerpc
   Os:  MacOS X|  
---+
Comment (by [EMAIL PROTECTED]):

 Source code attached in a tarfile.  The test data must still be downloaded
 separately, since it is too large to attach to the ticket.

-- 
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] #2257: validate hangs in configure

2008-05-14 Thread GHC

#2257: validate hangs in configure
--+-
 Reporter:  nr|  Owner: 
 Type:  bug   | Status:  new
 Priority:  highest   |  Milestone:  6.8.3  
Component:  Build System  |Version:  6.8.2  
 Severity:  major | Resolution: 
 Keywords:| Difficulty:  Unknown
 Testcase:|   Architecture:  x86
   Os:  Linux |  
--+-
Comment (by simonmar):

 I don't have any machines that exhibit this behaviour.  Can anyone help?

-- 
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] #2282: threaded runtime system crashes on powerpc with -N2

2008-05-14 Thread GHC

#2282: threaded runtime system crashes on powerpc with -N2
---+
 Reporter:  [EMAIL PROTECTED]  |  Owner: 
 Type:  bug| Status:  new
 Priority:  normal |  Milestone: 
Component:  Runtime System |Version:  6.8.2  
 Severity:  normal | Resolution: 
 Keywords: | Difficulty:  Unknown
 Testcase: |   Architecture:  powerpc
   Os:  MacOS X|  
---+
Changes (by simonmar):

  * difficulty:  => Unknown

Comment:

 It might be a while before we can track down this bug, and I assume that
 the darcs repository will change in the future.  Malcolm, could you tar up
 the exact source tree used to reproduce the bug and attach it to this
 ticket?  Thanks.

-- 
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

[GHC] #2283: WIndows: loading objects that refer to DLL symbols

2008-05-14 Thread GHC

#2283: WIndows: loading objects that refer to DLL symbols
-+--
Reporter:  simonmar  |   Owner: 
Type:  bug   |  Status:  new
Priority:  normal|   Milestone:  _|_
   Component:  GHCi  | Version:  6.8.2  
Severity:  normal|Keywords: 
  Difficulty:  Unknown   |Testcase: 
Architecture:  x86   |  Os:  Windows
-+--
 This is a test case from #1288, distilled into a separate report so I can
 close #1288:

 `test3b.c`:
 {{{
 #include 

 __declspec(dllexport) void _stdcall test(int arg)
 {
printf("The argument passed was %i\n", arg );
 }
 }}}

 `test_proxy_5a.c`:
 {{{
 __declspec(dllimport) void _stdcall test(int arg);

 void test_proxy(int arg)
 {
test(arg);
 }
 }}}

 To reproduce:
 {{{
 gcc -c test3b.c
 ar -rv test3b.a test3b.o
 c:/mingw/bin/dllwrap --export-all-symbols --output-lib test3b.dll.a -o
 test3b.dll test3b.a
 gcc -c test_proxy_5a.c
 ghci -ltest3b test_proxy_5a.o
 }}}

 the error message we get:

 {{{
 GHCi, version 6.9.20080512: http://www.haskell.org/ghc/  :? for help
 Loading package ghc-prim ... linking ... done.
 Loading package integer ... linking ... done.
 Loading package base ... linking ... done.
 Loading object (static) test_proxy_5a.o ... done
 Loading object (dynamic) test3b ... done
 ghc.exe:
 test_proxy_5a.o: unknown symbol `__imp__test'
 final link ... ghc.exe: linking extra libraries/objects failed
 }}}

 I'm not sure to what extent we need to support this, it's possible to link
 to the DLL by omitting the dllimport declaration.

-- 
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] #2273: inlining defeats seq

2008-05-14 Thread GHC

#2273: inlining defeats seq
--+-
 Reporter:  igloo |  Owner: 
 Type:  bug   | Status:  new
 Priority:  normal|  Milestone: 
Component:  Compiler  |Version:  6.9
 Severity:  normal| Resolution: 
 Keywords:| Difficulty:  Unknown
 Testcase:|   Architecture:  Unknown
   Os:  Unknown   |  
--+-
Comment (by simonpj):

 Thanks Ian -- nice report.  What is happening is this.  After inlining seq
 we get something like this:
 {{{
   let level = case x of { A -> 1; B -> 2 }
   in case level of { _ -> ...level... }
 }}}
 Now GHC thinks that the case-expression for `level` is cheap (which it
 is), and therefore ok to duplicate, so it inlines it
 {{{
   let level = case x of { A -> 1; B -> 2 }
   in case (case x of { A -> 1; B -> 2 }) of { _ -> ...level... }
 }}}
 Now there's only one remaining occurrence of `level` so that gets inlined
 too.  Disaster.

 This example has made me realise that what is ''really'' wrong here is
 that `seq` should really have a type more like
 {{{
   fseq :: a -> (a -> b) -> b
 }}}
 Then we'd have
 {{{
   level `fseq` (\level -> ...level...)
 }}}
 Now the inner `level` is nothing to do with the outer `level` and all will
 be well. So here we are saying what we mean: "evaluate `level` and use the
 evaluated version inside here".

 This version of `seq` is just reversed strict function application, of
 course.  Which is very like strict `let`.  So with bang patterns we could
 also write
 {{{
   let !level2 = level in ...level2...
 }}}
 This is satisfactorily explicit, but we must use a new name (`level2`).
 Perhaps that's not unreasonable.

 Both `fseq` and a strict let could desugar to
 {{{
case level of level2 { _ -> ...level2... }
 }}}
 Meanwhile I think a good fix will be to change the desugarer to desugar
 saturated applications of `seq` to this same form.  Not very robust to
 abstraction, but better than what we have now.

 `seq` is subtler than it looks.

-- 
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] #2279: Include library source code in distribution

Re: [GHC] #2148: x86_64 code use several GiB of memory generates: internal error: ASSERTION FAILED: file sm/Storage.c, line 1126

Re: [GHC] #1886: GHC API should preserve and provide access to comments

Re: [GHC] #2257: validate hangs in configure

Re: [GHC] #2284: Stack-hack optimization causes much re-computation in GUI callbacks

[GHC] #2285: Solaris 9 build fails at stage2 with undefined symbol errors (for libm symbols)

[GHC] #2284: Stack-hack optimization causes much re-computation in GUI callbacks

Re: [GHC] #2275: Poor indication of type error location

Re: [GHC] #2276: foreign import stdcall "&foo" doesn't work

Re: [GHC] #1288: ghci 6.6 foreign import stdcall broken, panic, panic!!!!

Re: [GHC] #1288: ghci 6.6 foreign import stdcall broken, panic, panic!!!!

Re: [GHC] #2038: System.Posix.Resource.setResourceLimit gives "setResourceLimit: invalid argument (Invalid argument)"

Re: [GHC] #2148: x86_64 code use several GiB of memory generates: internal error: ASSERTION FAILED: file sm/Storage.c, line 1126

Re: [GHC] #2282: threaded runtime system crashes on powerpc with -N2

Re: [GHC] #2257: validate hangs in configure

Re: [GHC] #2282: threaded runtime system crashes on powerpc with -N2

[GHC] #2283: WIndows: loading objects that refer to DLL symbols

Re: [GHC] #2273: inlining defeats seq

18 matches

Site Navigation

Mail list logo

Footer information