[GHC] #1949: Build system destroys output

[GHC]

#1949: Build system destroys output
--+-
 Reporter:  mbaulch   |  Owner: 
 
 Type:  bug   | Status:  new
 
 Priority:  normal|  Milestone:  6.8 branch 
 
Component:  Build System  |Version:  6.8.1  
 
 Severity:  normal|   Keywords:  strip binaries install solaris 
build
 Testcase:|   Architecture:  sparc  
 
   Os:  Solaris   |  
--+-
 It seems that the binaries left in the source directories after
 a 'gmake' are stripped before installation when 'gmake install'
 is called. The stripping butchers them such that they output
 'Killed' when executed.

 By manually installing these binaries by hand, the build works
 perfectly however.

 I have:
  - GNU strip version 2.17.
  - GCC 4.0.2 (from Blastwave)

 GHC was built from vanilla sources with -O2.

 NOTE: This problem existed for me with GHC 6.6.x also.

-- 
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] #1948: panic compiling associated type synonims

[GHC]

#1948: panic compiling associated type synonims
--+-
 Reporter:  guest |  Owner:
 Type:  bug   | Status:  new   
 Priority:  normal|  Milestone:
Component:  Compiler  |Version:  6.8.1 
 Severity:  normal|   Keywords:  typefunction panic
 Testcase:|   Architecture:  Unknown   
   Os:  Unknown   |  
--+-
 Trying to compile this:

 {{{
 {-# OPTIONS -fglasgow-exts #-}
 data Cons a b
 data Nil
 data Foo a = Foo
 class (Appendt l0 l1 ~ l2) => Append l0 l1 l2 where
 type Appendt l0 l1 :: *
 append :: Foo l0 -> Foo l1 -> Foo l2
 instance (Appendt b l1 ~ l2) => Append (Cons a b) l1 (Cons c l2) where
 type Appendt (Cons a b) l1 = Cons a (Appendt b l1)
 }}}

 gives this error:

 {{{
 ghc-6.8.1: panic! (the 'impossible' happened)
   (GHC version 6.8.1 for i386-unknown-linux):
 Coercion.splitCoercionKindOf
 base:GHC.Prim.trans{(w) tc 34y}
   (base:GHC.Prim.sym{(w) tc 34v}
  ((main:Main.:CoF:R1Appendt{tc roB})
 a{tv aph} [sk] b{tv ape} [sk] l1{tv apf} [sk]))
   t_apM{tv} [tau]
 (main:Main.:R1Appendt{tc ros})
 a{tv aph} [sk] b{tv ape} [sk] l1{tv apf} [sk]
 ~
   t_apM{tv} [tau]

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

 }}}

 i've tried to reduce the code to the minimum that will trigger the panic.

-- 
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] #1947: Segmentation fault/access violation in generated code

[GHC]

#1947: Segmentation fault/access violation in generated code
-+--
Reporter:  NeilMitchell  |Owner: 
Type:  bug   |   Status:  new
Priority:  normal|Milestone: 
   Component:  Compiler  |  Version:  6.8.1  
Severity:  normal|   Resolution: 
Keywords:| Testcase: 
Architecture:  x86   |   Os:  Windows
-+--
Comment (by NeilMitchell):

 I should point out that I'm fairly certain that this code doesn't do what
 it was intended to (the tak benchmark), but it still shouldn't segfault.

-- 
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] #1947: Segmentation fault/access violation in generated code

[GHC]

#1947: Segmentation fault/access violation in generated code
--+-
 Reporter:  NeilMitchell  |  Owner:   
 Type:  bug   | Status:  new  
 Priority:  normal|  Milestone:   
Component:  Compiler  |Version:  6.8.1
 Severity:  normal|   Keywords:   
 Testcase:|   Architecture:  x86  
   Os:  Windows   |  
--+-
 {{{
 F:\Temp\supero\supero-msg\tak>ghc --make Main_.hs -o foo -O2
 [1 of 1] Compiling Main ( Main_.hs, Main_.o )
 Linking foo.exe ...

 F:\Temp\supero\supero-msg\tak>foo 24 16 8
 Segmentation fault/access violation in generated code

 F:\Temp\supero\supero-msg\tak>ghc --version
 The Glorious Glasgow Haskell Compilation System, version 6.8.1
 }}}

 Windows XP. The test case is rather big, and needs reducing - I'll come
 back and do that in a few days time unless anyone beats me to it (I have a
 paper deadline in 23 hours...)

-- 
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] #1843: ghc 6.8.1 broken on Mac OS X Leopard PPC

[GHC]

#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 have investigated further and now have definite evidence that the
 sequence
 {{{
   lis r,hi16(s+k)
   ori r,r,lo16(s+k)
 }}}
 (where s is a symbol and k is a literate constant) used to bring the value
 s+k into register r is sometimes handled errorneously by (the Xcode 3.0
 coming with) Mac OS X 10.5 Leopard. In contrast to (the Xcode 2 that comes
 with) 10.4 Tiger that doesn't have this problem.

 The evidence indicates that the object code is produced correctly by
 Leopard (or at least in consistence with the object code produced by
 Tiger), but that the linker fails to process the relocation related to
 hi16(s+k) correctly, not only producing the confusing "unknown scattered
 relocation type 4" message, but also, in fact, generating incorrect code.
 Thus explaining the failure to run any amount of code that has been
 prepared in this manner.

 I intend to report this problem to Apple. In the meantime, there are
 fortunately some work-arounds:

  1. Use the sequence
 {{{
   lis r,ha16(s+k)
   la r,lo16(s+k)(r)
 }}}
  suggested by !ChrisKuklewicz above
  17. To retain the lis hi16 + ori lo16 combination, use
 {{{
 t = s+k
   lis r,hi16(t)
   ori r,r,lo16(t)
 }}}
  defining a new symbol t to hold the desired value for hi16.

 Both of these methods work, as far as I can tell.

 Best regards
 Thorkil

-- 
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] #1744: treat byte order mark as zero-width whitespace

[GHC]

#1744: treat byte order mark as zero-width whitespace
---+
 Reporter:  igloo  |  Owner: 
 Type:  feature request| Status:  new
 Priority:  normal |  Milestone:  6.10 branch
Component:  Compiler (Parser)  |Version:  6.8
 Severity:  normal | Resolution: 
 Keywords: | Difficulty:  Unknown
 Testcase: |   Architecture:  Unknown
   Os:  Unknown|  
---+
Comment (by Porges):

 Can I vote for this also? Some editors insist upon inserting the BOM when
 working with UTF-8 source, and this bug is ''highly'' annoying.

-- 
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] #1911: -w doesn't turn off nullModuleExport

[GHC]

#1911: -w doesn't turn off nullModuleExport
---+
 Reporter:  AndreaRossato  |  Owner:  AndreaRossato
 Type:  bug| Status:  assigned 
 Priority:  normal |  Milestone:  6.10 branch  
Component:  Compiler   |Version:  6.8.1
 Severity:  minor  | Resolution:   
 Keywords: | Difficulty:  Easy (1 hr)  
 Testcase: |   Architecture:  Multiple 
   Os:  Multiple   |  
---+
Comment (by AndreaRossato):

 Maybe you have noticed that I still lack that sort of confidence with the
 code that would refrain me from asking some of the questions I'm asking: I
 must admit I feel some sort of embarrassment in dealing with the Beast.

 So I'm attaching a new patch, which correctly deals with the second issue.

 I also want to rephrase my other question about the possibility of adding
 more specific warnings instead of a general wanr-misc: the warning about
 exporting T(..) when T is a synonym is treated similarly to the warning
 for importing T(..) when T is exported abstractly. For this second case
 there is a flag: -fwarn-dodgy-imports. Shouldn't we add a corresponding
 -fwarn-dodgy-exports?

 This second was seems more consistent to me (obviously the patch will
 include all the needed documentation update too).

 Sorry for the noise: I'm learning.

 Andrea

-- 
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] #1911: -w doesn't turn off nullModuleExport

[GHC]

#1911: -w doesn't turn off nullModuleExport
---+
 Reporter:  AndreaRossato  |  Owner:  AndreaRossato
 Type:  bug| Status:  assigned 
 Priority:  normal |  Milestone:  6.10 branch  
Component:  Compiler   |Version:  6.8.1
 Severity:  minor  | Resolution:   
 Keywords: | Difficulty:  Easy (1 hr)  
 Testcase: |   Architecture:  Multiple 
   Os:  Multiple   |  
---+
Comment (by AndreaRossato):

 I've just attached a patch, which is just a proof of concept... that I can
 actually take care of this ticket...;)

 This is just a start, since I think I need some directions here.

 I added the new warn-misc option, and I added it to the list of
 standardWarnings.

 I changed RnNames.lhs to use it and the bug in the title of this ticket is
 gone. I've also applied the same approach to the problem Simon reported
 above. This way the warning has been eliminated but an error is reported
 instead. Indeed if the exported element has the form of a type constructor
 (isTyConName), a warning is reported, otherwise an exportItemErr is
 emitted.

 So, I think I need, in such a case, a more sophisticated approach, which
 may be more invasive in the code. This is the reason why I included that
 change, in order to have some comments on how to deal with this kind of
 warnings.

 Another question: wouldn't it be better to add a specific warning for each
 of those cases? Since I'm going to do this work for (possibly) all those
 unflagged warnings, adding a specific flag for each of them is not going
 to be more burdensome.

 Finally, I want to investigate a bit more those strange flag interactions
 we were discussing above, interactions that I'm not able to reproduce, or
 deduce by reading the code.

 Sorry for taking so much time and energy for this simple bug, but since
 I'm a new contributor I also need to acquire all the meta knowledge to...
 well, contribute.

 Andrea

-- 
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] #1911: -w doesn't turn off nullModuleExport

[GHC]

#1911: -w doesn't turn off nullModuleExport
---+
 Reporter:  AndreaRossato  |  Owner:  AndreaRossato
 Type:  bug| Status:  assigned 
 Priority:  normal |  Milestone:  6.10 branch  
Component:  Compiler   |Version:  6.8.1
 Severity:  minor  | Resolution:   
 Keywords: | Difficulty:  Easy (1 hr)  
 Testcase: |   Architecture:  Multiple 
   Os:  Multiple   |  
---+
Comment (by NeilMitchell):

 It may not be particularly logical, but it already does in some places!
 Out of all the warning flags listed in the manual, it was the one that
 looked "most likely" - but was a bit of a stretch. Perhaps you need a new
 warning flag, and fix up the other one as well. Or perhaps there is some
 flag name that encompasses both this behaviour and the obvious import one.

-- 
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] #1911: -w doesn't turn off nullModuleExport

[GHC]

#1911: -w doesn't turn off nullModuleExport
---+
 Reporter:  AndreaRossato  |  Owner:  AndreaRossato
 Type:  bug| Status:  assigned 
 Priority:  normal |  Milestone:  6.10 branch  
Component:  Compiler   |Version:  6.8.1
 Severity:  minor  | Resolution:   
 Keywords: | Difficulty:  Easy (1 hr)  
 Testcase: |   Architecture:  Multiple 
   Os:  Multiple   |  
---+
Comment (by igloo):

 I don't think it's at all logical for the `warn-unused-imports` flags to
 control a warning about empty exports.

-- 
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] #1933: Zero times in profiling with GHC-6.8.1

[GHC]

#1933: Zero times in profiling with GHC-6.8.1
---+
 Reporter:  daniel.is.fischer  |  Owner:  simonmar
 Type:  bug| Status:  new 
 Priority:  normal |  Milestone:  6.8.3   
Component:  Profiling  |Version:  6.8.1   
 Severity:  normal | Resolution:  
 Keywords: | Difficulty:  Unknown 
 Testcase: |   Architecture:  x86 
   Os:  Linux  |  
---+
Comment (by daniel.is.fischer):

 I don't really know what I'm doing, but after digging in a number of
 header files I did not understand, I got this programme:
 {{{
 #include 
 #include 
 #include 
 #include 
 #include 
 static volatile int tock = 0;
 static void handler(int i)
 {
tock = 1;
 }

 int main(int argc, char *argv[])
 {

 struct sigevent ev;
 timer_t timer;
 struct itimerspec it;
 struct sigaction action;
 unsigned int i;
 int m,n,count = 0;

 ev.sigev_notify = SIGEV_SIGNAL;
 ev.sigev_signo  = SIGVTALRM;
 printf("%u\n",i);
 printf("Random timer is %d\n",timer);
 printf("Getting time\n");
 m = timer_gettime(timer,&it);
 printf("Resulted in %d\n",m);
 printf("Timer says: interval is %lld, %ld,\nvalue is %lld, %ld\n"
 ,(long long)it.it_interval.tv_sec,it.it_interval.tv_nsec
 ,(long long)it.it_value.tv_sec,it.it_value.tv_nsec);
 printf("timer is %d after first gettime\n",timer);
 if (timer_create(CLOCK_PROCESS_CPUTIME_ID, &ev, &timer) != 0) {
 printf("No CLOCK_PROCESS_CPUTIME_ID timer\n");
exit(1);
 }
 printf("timer created with CLOCK_PROCESS_CPUTIME_ID is %d\n",timer);
 for(n = 3; n < 2; n++){
 for(m = 2; m <= n/2; m++){
 if (!(n%m)) count++;
 }
 }
 printf("%d divisors\n",count);
 printf("Getting time\n");
 m = timer_gettime(timer,&it);
 printf("Resulted in %d\n",m);
 printf("Timer says: interval is %lld, %ld,\nvalue is %lld, %ld\n"
 ,(long long)it.it_interval.tv_sec,it.it_interval.tv_nsec
 ,(long long)it.it_value.tv_sec,it.it_value.tv_nsec);
 printf("timer now is %d\n",timer);
 if (timer_create(CLOCK_REALTIME, &ev, &timer) != 0) {
 printf("No CLOCK_REALTIME timer\n");
exit(2);
 }
 printf("timer created with CLOCK_REALTIME is %d\n",timer);
 printf("Getting time\n");
 m = timer_gettime(timer,&it);
 printf("Resulted in %d\n",m);
 printf("Timer says: interval is %lld, %ld,\nvalue is %lld, %ld\n"
 ,(long long)it.it_interval.tv_sec,it.it_interval.tv_nsec
 ,(long long)it.it_value.tv_sec,it.it_value.tv_nsec);
 printf("timer now is %d\n",timer);
 for(n = 3; n < 2; n++){
 for(m = 2; m <= n/2; m++){
 if (!(n%m)) count++;
 }
 }
 printf("%d divisors\n",count);
 printf("Getting time\n");
 m = timer_gettime(timer,&it);
 printf("Resulted in %d\n",m);
 printf("Timer says: interval is %lld, %ld,\nvalue is %lld, %ld\n"
 ,(long long)it.it_interval.tv_sec,it.it_interval.tv_nsec
 ,(long long)it.it_value.tv_sec,it.it_value.tv_nsec);
 printf("timer finally is %d\n",timer);

 action.sa_handler = handler;
 action.sa_flags = 0;
 sigemptyset(&action.sa_mask);
 if (sigaction(SIGVTALRM, &action, NULL) == -1) {
 printf("SIGVTALRM problem\n");
 exit(3);
 }

 it.it_value.tv_sec = 0;
 it.it_value.tv_nsec = 1;
 it.it_interval = it.it_value;
 if (timer_settime(timer, 0, &it, NULL) != 0) {
 printf("settime problem\n");
 exit(4);
 }

 usleep(100);
 if (tock) exit(0);
 exit(5);
 return 0;
 exit(0);
 }
 }}}
 and from that the output
 {{{
 [EMAIL PROTECTED]:~/Documents> gcc -Wall -o timerTest Timertest.c -lrt
 [EMAIL PROTECTED]:~/Documents> ./timerTest
 134513370
 Random timer is 1075293183
 Getting time
 Resulted in -1
 Timer says: interval is 1075248004, -1073745532,
 value is 1074079461, 1075321808
 timer is 1075293183 after first gettime
 timer created with CLOCK_PROCESS_CPUTIME_ID is 0
 161150 divisors
 Getting time
 Resulted in 0
 Timer says: interval is 0, 0,
 value is 0, 0
 timer now is 0
 timer created with CLOCK_REALTIME is 1
 Getting time
 Resulted in 0
 Timer says: interval is 0, 0,
 value is 0, 0
 timer now is 1
 322300 divisors
 Getting time
 Resulted in 0
 Timer says: interval is 0, 0,
 value is 0, 0
 timer finally is 1
 [EMAIL PROTECTED]:~/Documents>
 }}}
 So if I interpret this right, timer_create does work, but timer_gettime
 doesn't.

 If you give me a good lead, I can investigate further, but I know
 practically nothing about the C-libs, so please be detailed.

-- 
Ticket URL: 

Re: [GHC] #1911: -w doesn't turn off nullModuleExport

[GHC]

#1911: -w doesn't turn off nullModuleExport
---+
 Reporter:  AndreaRossato  |  Owner:  AndreaRossato
 Type:  bug| Status:  assigned 
 Priority:  normal |  Milestone:  6.10 branch  
Component:  Compiler   |Version:  6.8.1
 Severity:  minor  | Resolution:   
 Keywords: | Difficulty:  Easy (1 hr)  
 Testcase: |   Architecture:  Multiple 
   Os:  Multiple   |  
---+
Comment (by NeilMitchell):

 In my example I initially got the above warning when compiling both module
 A and module B. I then added -w to each file, and the B warning went away,
 but not the A warning (the subject of this bug). I then modified the flags
 in B to be only -fno-warn-unused-imports and the warning remained off -
 namely that flag was suppressing the warning in module B.

 It would seem logical if this warning could be suppressed by either -w or
 -fno-warn-unused-imports

 My example was slightly more complicated than just "module B where". I
 tried to reduce a test case but replacing my complicated (but non-
 exporting) module B with the above text removed the warning. Perhaps that
 is another bug?

-- 
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] #1911: -w doesn't turn off nullModuleExport

[GHC]

#1911: -w doesn't turn off nullModuleExport
---+
 Reporter:  AndreaRossato  |  Owner:  AndreaRossato
 Type:  bug| Status:  assigned 
 Priority:  normal |  Milestone:  6.10 branch  
Component:  Compiler   |Version:  6.8.1
 Severity:  minor  | Resolution:   
 Keywords: | Difficulty:  Easy (1 hr)  
 Testcase: |   Architecture:  Multiple 
   Os:  Multiple   |  
---+
Comment (by AndreaRossato):

 Hi Neil,

 I don't think I entirely understand your message. Here warn-unused-imports
 is off by default, that is to say, I need to use -fwarn-unused-imports to
 have the warning reported.

 And, more important, it's use seems to be unrelated to the
 nullModuleExport, which is always reported when a module exports a second
 module which (the second) does not export anything.

 To explain:
 1. Module A:

 module A ( module B ) where
 import module B

 Module B:
 module B where

 Compiling A reports a waring:
 A.hs:1:11: Warning: The export item `module B' exports nothing

 This warning is not suppressed by "-w". And it is unrelated to -fno-warn-
 unused-imports, since A is actually using the export.

 Am I missing something?

 Both this one and the one reported by Simon are generated by the renamer
 and indeed there are no checks for flags.

 (In the meantime I'm preparing the list of unflagged warnings and reading
 this wiki for preparing a patch that complies with the style and the
 guidelines for contributors - which is a useful reading anyhow).

 Andrea

-- 
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] #1931: readline/rlstdc.h not found (and other errors) when building readline on Mac OS X with framework GNUreadline

[GHC]

#1931: readline/rlstdc.h not found (and other errors) when building readline on
Mac OS X with framework GNUreadline
---+
 Reporter:  thorkilnaur|  Owner:  judah
 Type:  bug| Status:  closed   
 Priority:  normal |  Milestone:  6.8.2
Component:  libraries (other)  |Version:  6.9  
 Severity:  normal | Resolution:  duplicate
 Keywords: | Difficulty:  Unknown  
 Testcase: |   Architecture:  Multiple 
   Os:  MacOS X|  
---+
Comment (by thorkilnaur):

 I have now verified that the modified GNUreadline library by judah
 (thanks, also thanks for your kind remainder) allows the build of the
 Haskell readline library to proceed further. Compare
 http://darcs.haskell.org/buildbot/all/tnaur%20PPC%20OSX%20head%202/builds/2
 /step-stage1/0 and
 http://darcs.haskell.org/buildbot/all/tnaur%20PPC%20OSX%20head%202/builds/1
 /step-stage1/0 where you should note that these builds are haunted by
 other problems being investigated (#1843).

 Best regards
 Thorkil

-- 
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] #1933: Zero times in profiling with GHC-6.8.1

[GHC]

#1933: Zero times in profiling with GHC-6.8.1
---+
 Reporter:  daniel.is.fischer  |  Owner:  simonmar
 Type:  bug| Status:  new 
 Priority:  normal |  Milestone:  6.8.3   
Component:  Profiling  |Version:  6.8.1   
 Severity:  normal | Resolution:  
 Keywords: | Difficulty:  Unknown 
 Testcase: |   Architecture:  x86 
   Os:  Linux  |  
---+
Comment (by simonmar):

 (the patch was a darcs patch, sorry for not mentioning that)

 Ok, could you possibly investigate this manually?  It's pretty hard to
 debug it remotely.  To experiment, you can just cut out the test program
 from `aclocal.m4` and play with it separately.

 Clearly something is not working with `timer_create()` on your system, we
 need to figure out what it is, and write a configure test that detects the
 problem.  One thing you could try is modifying the test to test the
 `CLOCK_PROCESS_CPUTIME_ID` timer instead of the `CLOCK_REALTIME` timer,
 but you'll need to add a cpu-time-consuming loop into the code.

-- 
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] #1933: Zero times in profiling with GHC-6.8.1

[GHC]

#1933: Zero times in profiling with GHC-6.8.1
---+
 Reporter:  daniel.is.fischer  |  Owner:  simonmar
 Type:  bug| Status:  new 
 Priority:  normal |  Milestone:  6.8.3   
Component:  Profiling  |Version:  6.8.1   
 Severity:  normal | Resolution:  
 Keywords: | Difficulty:  Unknown 
 Testcase: |   Architecture:  x86 
   Os:  Linux  |  
---+
Comment (by daniel.is.fischer):

 patch applied manually because
 {{{
 [EMAIL PROTECTED]:~/Haskell/RecentHZips/ghc-6.8.1> patch -b aclocal.m4 timer-
 create.patch
 ?
 patch:  ed FAILED
 }}}
 then autoconf; ./configure, last lines of that are
 {{{
 checking for timer_settime... yes
 checking for a working timer_create()... yes
 checking for printf$LDBLStub... no
 checking for pkg-config... /usr/bin/pkg-config
 checking for PAPI_library_init in -lpapi... no
 checking papi.h usability... no
 checking papi.h presence... no
 checking for papi.h... no
 configure: creating ./config.status
 config.status: creating mk/config.mk
 config.status: creating ghc.spec
 config.status: creating extra-gcc-opts
 config.status: creating docs/users_guide/ug-book.xml
 config.status: creating mk/config.h
 config.status: mk/config.h is unchanged
 config.status: executing mk/stamp-h commands
 [EMAIL PROTECTED]:~/Haskell/RecentHZips/ghc-6.8.1>
 }}}
 and HAVE_TIMER_CREATE and USE_TIMER_CREATE are indeed still defined as 1,
 the line #define USE_TIMER_CREATE 1 in includes/ghcautoconf.h is still
 commented out.

-- 
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 maeder):

 With Judah's new framework I can install also the Shellac-readline package
 (probably because readline/history.h is found in /usr/include/ by chance)

 As mentioned above (comment 11) `compiler/ghci/Linker.lhs` should not fail
 if it does not find a framework, because ghci itself has loaded the
 frameworks GMP and GNUreadline already (possibly from the home directory).

 (Only) after this simple change GNUreadline should be mentioned as
 framework in the package.conf file (as it is already the case for the GMP
 framework, that happens to be under /Library/Frameworks for me, too.)

-- 
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] #1946: Ctr-c doesn't work in ghci-6.8.1, probably related to #1922

[GHC]

#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 |   Keywords:   
 Testcase: |   Architecture:  x86  
   Os:  Linux  |  
---+
 In ghci-6.8.1, pressing Ctrl-c once during an evaluation has no influence,
 pressing it twice during the same evaluation results in
 {{{
 Prelude Data.List> foldl' (+) 0 [1 .. 2000]
 : exception :: GhcException

 }}}
 and it only returns to the prompt after a third Ctrl-c
 {{{
 *** Exception: <>
 Prelude Data.List>
 }}}
 However, then no more computations are performed,only ghci commands (:?,
 :i, :t, :q) are then processed.
 A complete sample session, Ctrl-c was pressed once in each of the first
 two evaluations, twice in the third, then once more to produce ***
 Exception: <> and return to the prompt. From then onwards, any
 expression typed at the prompt results in no activity until a further
 Ctrl-c is pressed.
 {{{
 [EMAIL PROTECTED]:~> ghci
 GHCi, version 6.8.1: http://www.haskell.org/ghc/  :? for help
 Loading package base ... linking ... done.
 Prelude> :set +s
 Prelude> :m +Data.List
 Prelude Data.List> foldl' (+) 0 [1 .. 1000]
 500500
 (4.47 secs, 1041858060 bytes)
 Prelude Data.List> foldl' (+) 0 [1 .. 2000]
 2001000
 (8.68 secs, 2081067868 bytes)
 Prelude Data.List> foldl' (+) 0 [1 .. 2000]
 : exception :: GhcException


 *** Exception: <>
 Prelude Data.List> foldl' (+) 0 [1 .. 2000]

 *** Exception: <>
 Prelude Data.List> foldl' (+) 0 [1 .. 20]
 *** Exception: <>
 Prelude Data.List> :?
  Commands available from the prompt:

 evaluate/run 
:add  ... add module(s) to the current target set
:browse [[*]]   display the names defined by 
:cd  Interrupted.
 Prelude Data.List> :i foldl
 foldl :: (a -> b -> a) -> a -> [b] -> a -- Defined in GHC.List
 Prelude Data.List> :t (+) . (^)
 (+) . (^) :: (Integral b, Num a, Num (b -> a)) => a -> (b -> a) -> b -> a
 Prelude Data.List> :q
 Leaving GHCi.
 [EMAIL PROTECTED]:~>
 }}}

-- 
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] #1943: round function causes cblas NaNs

[Simon Marlow]

GHC wrote:


 When I first submitted this the attach file action failed due to the size
 of my binaries.  I mistakenly then resubmitted the bug and attached the
 files to ticket 1944. So this bug should be merged with 1944 or better
 just deleted.


Ticket deleted.

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

Re: [GHC] #1945: Full laziness is sometimes a pessimisation

[GHC]

#1945: Full laziness is sometimes a pessimisation
--+-
 Reporter:  jleedev   |  Owner:   
 Type:  bug   | Status:  closed   
 Priority:  normal|  Milestone:   
Component:  Compiler  |Version:  6.8.1
 Severity:  normal| Resolution:  duplicate
 Keywords:| Difficulty:  Unknown  
 Testcase:|   Architecture:  Unknown  
   Os:  Unknown   |  
--+-
Changes (by simonmar):

  * status:  new => closed
  * difficulty:  => Unknown
  * resolution:  => duplicate
  * summary:  Faulty optimizations => Full laziness is sometimes a
  pessimisation

Comment:

 Thanks for reporting, but this is long-standing issue, see #917.  `-fno-
 full-laziness` is your friend.

-- 
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 thorkilnaur):

 There is some additional discussion on #1931 which I closed as a duplicate
 of this.

 Best regards
 Thorkil

-- 
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] #1933: Zero times in profiling with GHC-6.8.1

[GHC]

#1933: Zero times in profiling with GHC-6.8.1
---+
 Reporter:  daniel.is.fischer  |  Owner:  simonmar
 Type:  bug| Status:  new 
 Priority:  normal |  Milestone:  6.8.3   
Component:  Profiling  |Version:  6.8.1   
 Severity:  normal | Resolution:  
 Keywords: | Difficulty:  Unknown 
 Testcase: |   Architecture:  x86 
   Os:  Linux  |  
---+
Comment (by simonmar):

 Please try the attached patch to `aclocal.m4`.  Apply the patch, then
 `autoconf; ./configure`.

-- 
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] #1593: Improve runInteractiveProcess error message when working directory does not exist

[GHC]

#1593: Improve runInteractiveProcess error message when working directory does 
not
exist
---+
 Reporter:  [EMAIL PROTECTED]  |  Owner:  simonmar
 Type:  task   | Status:  reopened
 Priority:  low|  Milestone:  _|_ 
Component:  libraries/process  |Version:  6.7 
 Severity:  normal | Resolution:  
 Keywords: | Difficulty:  Unknown 
 Testcase:  process004 |   Architecture:  Unknown 
   Os:  Unknown|  
---+
Changes (by simonmar):

  * status:  closed => reopened
  * resolution:  fixed =>
  * summary:  runInteractiveProcess misbehaves when it gets invalid (eg.
  non-existent) working directory parameter =>
  Improve runInteractiveProcess error message
  when working directory does not exist
  * priority:  high => low
  * milestone:  6.8.1 => _|_
  * type:  bug => task

Comment:

 Re-opening as a low-priority task.

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