[ ghc-Bugs-657462 ] internal error: EVACUATED object entered
Bugs item #657462, was opened at 2002-12-22 11:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=657462group_id=8032 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Simon Marlow (simonmar) Summary: internal error: EVACUATED object entered Initial Comment: Submitter: [EMAIL PROTECTED] The compiled program fails with: internal error: EVACUATED object entered! Please report this as a bug to [EMAIL PROTECTED], or http://www.sourceforge.net/projects/ghc/ This happens on FreeBSD 4.7/x86 with at least compiler versions 5.04.1 and 5.05, but not on Mac OS X. Compiling with -O or -fvia-C does not help. -- Comment By: Simon Marlow (simonmar) Date: 2002-12-23 10:21 Message: Logged In: YES user_id=48280 Could you attach the program please? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=657462group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-657462 ] internal error: EVACUATED object entered
Bugs item #657462, was opened at 2002-12-22 03:05 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=657462group_id=8032 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: internal error: EVACUATED object entered Initial Comment: Submitter: [EMAIL PROTECTED] The compiled program fails with: internal error: EVACUATED object entered! Please report this as a bug to [EMAIL PROTECTED], or http://www.sourceforge.net/projects/ghc/ This happens on FreeBSD 4.7/x86 with at least compiler versions 5.04.1 and 5.05, but not on Mac OS X. Compiling with -O or -fvia-C does not help. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=657462group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-655400 ] Returning Double from foreign fun. fails
Bugs item #655400, was opened at 2002-12-17 20:43
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=655400group_id=8032
Category: Compiler
Group: 5.04.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Henrik Nilsson (nhn)
Assigned to: Nobody/Anonymous (nobody)
Summary: Returning Double from foreign fun. fails
Initial Comment:
Returning doubles from foreign functions
can fail when optimizations (-O1) is turned on.
Things work when using the native code generator
or when compiling with -fvia-c and -O0.
I've tried on Linux (RedHat 7.3) with both GHC 5.04.1
and GHC 5.04.2.
What seems to be going on is that the inclusion
of the header file containing the foreign function
prototype is not propagated along with the actual
C call when it gets inlined. This leads to warnings
like:
/usr/local/bin/ghc-5.04.2 -c -fglasgow-exts -O1
-package lang -keep-hc-files -o Graphics/SP/M1.o -ohi
Graphics/SP/M1.hi Graphics/SP/M1.hs
Graphics/SP/M1.hc: In function `r8Hd_fast1':
Graphics/SP/M1.hc:103: warning: implicit declaration of
function `prim_foreignF4'
The original GreenCard definition looks like this
(from a file called Graphics_SP_Foreign.gc):
%fun foreignF4 :: Double - Double
%call (double x)
%code double y;
% y = sin(x);
% printf(x = %f, y = %f\n, x, y);
%result (double y)
The GreenCard generated C code in
Graphics_SP_Foreign_stub_ffi.c
looks like this:
double prim_foreignF4(double x)
{ double y;
do { double y;
y = sin(x);
printf(x = %f, y = %f\n, x, y);
return((double)(y));} while(0);
}
and the related header file,
Graphics_SP_Foreign_stub_ffi.h:
#include math.h
#include c_stuff.h
#include c_stuff2.h
#include HsFFI.h
extern int prim_foreignF1(int x);
extern int prim_foreignF2(int x);
extern double prim_foreignF4(double x);
The GreenCard generated Haskell:
foreignF4 :: Double - Double
foreignF4 x =
unsafePerformIO(
prim_foreignF4 x
= \ y -
(return (y)))
foreign import ccall unsafe
Graphics_SP_Foreign_stub_ffi.h prim_foreignF4
prim_foreignF4 :: Double - IO (Double)
Graphics_SP_Foreign.hc starts like this:
#include Stg.h
#include HsBase.h
#include HsLang.h
#include Graphics_SP_Foreign_stub_ffi.h
#include Graphics_SP_Foreign_stub_ffi.h
#include Graphics_SP_Foreign_stub_ffi.h
i.e., the header file is included properly.
and the place where prim_foreignF4 actually gets
called looks like this:
INFO_TABLE_SRT_BITMAP(s1hc_info,s1hc_ret,0,0,0,0,RET_SMALL,static
,IF_,0,0);
IFN_(s1hc_ret) {
StgDouble _B0_;
StgDouble _B3_;
FB_
_B0_=PK_DBL((W_*)(R1.p+1));
*Sp=(W_)((P_)s1hd_info);
{
StgDouble _ccall_result;
StgDouble _ccall_arg1=_B0_;
CALLER_SAVE_SYSTEM
_ccall_result = (prim_foreignF4((_ccall_arg1)));
CALLER_RESTORE_SYSTEM
_B3_=_ccall_result;
}
ASSIGN_DBL((W_*)(Sp-2),_B3_);
Sp=Sp-3;
JMP_(ENTRY_CODE((P_)(Sp[3])));
FE_
}
This is fine. However, there is another module M1
where foreignF4 also gets called:
module Graphics.SP.M1 where
import Graphics.SP.M2
import Graphics.SP.M3
import Graphics_SP_Foreign
sp_m1 n = Graphics.SP.M1 [\n
++ take n' (repeat ' ') ++ sp_m2 = ++
sp_m2 n' ++ \n
++ take n' (repeat ' ') ++ sp_m3 = ++
sp_m3 n' ++ \n
++ take n' (repeat ' ') ++ foreignF1 3 =
++ show (foreignF1 3) ++ \n
++ take n' (repeat ' ') ++ foreignF2 3 =
++ show (foreignF2 3) ++ \n
++ take n' (repeat ' ') ++ foreignF3 =
++ show foreignF3 ++ \n
++ take n' (repeat ' ') ++ foreignF4 (pi/6)
=
++ show (foreignF4 (pi/6)) ++ \n
++ ]\n
where n' = n + 4
It's .hc file starts like this:
#include Stg.h
#include HsBase.h
#include HsLang.h
i.e., Graphics_SP_Foreign_stub_ffi.h does not get
included.
Yet it does contain the following call to
prim_foreignF4:
II_(r8Hd_info);
IFN_(r8Hd_fast1) {
StgDouble _B0_;
StgDouble _B3_;
FB_
STK_CHK(4,(P_)r8Hd_info,R1.p,0,Sp[-1]=(W_)((ARG_TAG(0)));
Sp=Sp-1;);
_B0_=0.5235987755982988;
Sp[-1]=(W_)((P_)s8Kk_info);
Sp=Sp-1;
{
StgDouble _ccall_result;
StgDouble _ccall_arg1=_B0_;
CALLER_SAVE_SYSTEM
_ccall_result = (prim_foreignF4((_ccall_arg1)));
CALLER_RESTORE_SYSTEM
_B3_=_ccall_result;
}
ASSIGN_DBL((W_*)(Sp-2),_B3_);
Sp=Sp-3;
JMP_(ENTRY_CODE((P_)(Sp[3])));
FE_
}
I've attached the complete source files as well in
case you need them.
If you need further info, I'll be happy to assist.
Regards,
/Henrik
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=655400group_id=8032
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-655400 ] Returning Double from foreign fun. fails
Bugs item #655400, was opened at 2002-12-17 12:43
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=655400group_id=8032
Category: Compiler
Group: 5.04.2
Status: Open
Resolution: None
Priority: 5
Submitted By: Henrik Nilsson (nhn)
Assigned to: Nobody/Anonymous (nobody)
Summary: Returning Double from foreign fun. fails
Initial Comment:
Returning doubles from foreign functions
can fail when optimizations (-O1) is turned on.
Things work when using the native code generator
or when compiling with -fvia-c and -O0.
I've tried on Linux (RedHat 7.3) with both GHC 5.04.1
and GHC 5.04.2.
What seems to be going on is that the inclusion
of the header file containing the foreign function
prototype is not propagated along with the actual
C call when it gets inlined. This leads to warnings
like:
/usr/local/bin/ghc-5.04.2 -c -fglasgow-exts -O1
-package lang -keep-hc-files -o Graphics/SP/M1.o -ohi
Graphics/SP/M1.hi Graphics/SP/M1.hs
Graphics/SP/M1.hc: In function `r8Hd_fast1':
Graphics/SP/M1.hc:103: warning: implicit declaration of
function `prim_foreignF4'
The original GreenCard definition looks like this
(from a file called Graphics_SP_Foreign.gc):
%fun foreignF4 :: Double - Double
%call (double x)
%code double y;
% y = sin(x);
% printf(x = %f, y = %f\n, x, y);
%result (double y)
The GreenCard generated C code in
Graphics_SP_Foreign_stub_ffi.c
looks like this:
double prim_foreignF4(double x)
{ double y;
do { double y;
y = sin(x);
printf(x = %f, y = %f\n, x, y);
return((double)(y));} while(0);
}
and the related header file,
Graphics_SP_Foreign_stub_ffi.h:
#include math.h
#include c_stuff.h
#include c_stuff2.h
#include HsFFI.h
extern int prim_foreignF1(int x);
extern int prim_foreignF2(int x);
extern double prim_foreignF4(double x);
The GreenCard generated Haskell:
foreignF4 :: Double - Double
foreignF4 x =
unsafePerformIO(
prim_foreignF4 x
= \ y -
(return (y)))
foreign import ccall unsafe
Graphics_SP_Foreign_stub_ffi.h prim_foreignF4
prim_foreignF4 :: Double - IO (Double)
Graphics_SP_Foreign.hc starts like this:
#include Stg.h
#include HsBase.h
#include HsLang.h
#include Graphics_SP_Foreign_stub_ffi.h
#include Graphics_SP_Foreign_stub_ffi.h
#include Graphics_SP_Foreign_stub_ffi.h
i.e., the header file is included properly.
and the place where prim_foreignF4 actually gets
called looks like this:
INFO_TABLE_SRT_BITMAP(s1hc_info,s1hc_ret,0,0,0,0,RET_SMALL,static
,IF_,0,0);
IFN_(s1hc_ret) {
StgDouble _B0_;
StgDouble _B3_;
FB_
_B0_=PK_DBL((W_*)(R1.p+1));
*Sp=(W_)((P_)s1hd_info);
{
StgDouble _ccall_result;
StgDouble _ccall_arg1=_B0_;
CALLER_SAVE_SYSTEM
_ccall_result = (prim_foreignF4((_ccall_arg1)));
CALLER_RESTORE_SYSTEM
_B3_=_ccall_result;
}
ASSIGN_DBL((W_*)(Sp-2),_B3_);
Sp=Sp-3;
JMP_(ENTRY_CODE((P_)(Sp[3])));
FE_
}
This is fine. However, there is another module M1
where foreignF4 also gets called:
module Graphics.SP.M1 where
import Graphics.SP.M2
import Graphics.SP.M3
import Graphics_SP_Foreign
sp_m1 n = Graphics.SP.M1 [\n
++ take n' (repeat ' ') ++ sp_m2 = ++
sp_m2 n' ++ \n
++ take n' (repeat ' ') ++ sp_m3 = ++
sp_m3 n' ++ \n
++ take n' (repeat ' ') ++ foreignF1 3 =
++ show (foreignF1 3) ++ \n
++ take n' (repeat ' ') ++ foreignF2 3 =
++ show (foreignF2 3) ++ \n
++ take n' (repeat ' ') ++ foreignF3 =
++ show foreignF3 ++ \n
++ take n' (repeat ' ') ++ foreignF4 (pi/6)
=
++ show (foreignF4 (pi/6)) ++ \n
++ ]\n
where n' = n + 4
It's .hc file starts like this:
#include Stg.h
#include HsBase.h
#include HsLang.h
i.e., Graphics_SP_Foreign_stub_ffi.h does not get
included.
Yet it does contain the following call to
prim_foreignF4:
II_(r8Hd_info);
IFN_(r8Hd_fast1) {
StgDouble _B0_;
StgDouble _B3_;
FB_
STK_CHK(4,(P_)r8Hd_info,R1.p,0,Sp[-1]=(W_)((ARG_TAG(0)));
Sp=Sp-1;);
_B0_=0.5235987755982988;
Sp[-1]=(W_)((P_)s8Kk_info);
Sp=Sp-1;
{
StgDouble _ccall_result;
StgDouble _ccall_arg1=_B0_;
CALLER_SAVE_SYSTEM
_ccall_result = (prim_foreignF4((_ccall_arg1)));
CALLER_RESTORE_SYSTEM
_B3_=_ccall_result;
}
ASSIGN_DBL((W_*)(Sp-2),_B3_);
Sp=Sp-3;
JMP_(ENTRY_CODE((P_)(Sp[3])));
FE_
}
I've attached the complete source files as well in
case you need them.
If you need further info, I'll be happy to assist.
Regards,
/Henrik
--
Comment By: Nobody/Anonymous (nobody)
Date: 2002-12-17 13:55
Message:
Logged In: NO
I have also observed this bug, which also occurs when using
the FFI directly (without any use of GreenCard).
The observation that the inclusion
of the header file containing the foreign function
prototype is not propagated along with the actual
C call is certainly correct. However, note that it is perfectly
reasonable to write foreign import declarations which do not
refer to a header file containing a C prototype, and ghc
[ ghc-Bugs-653694 ] safe calls in the threaded RTS broken
Bugs item #653694, was opened at 2002-12-14 13:04
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=653694group_id=8032
Category: Runtime System
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Wolfgang Thaller (wthaller)
Assigned to: Nobody/Anonymous (nobody)
Summary: safe calls in the threaded RTS broken
Initial Comment:
When returning from a safe (non-threadsafe) call,
resumeThread uses grabCapability to grab the
capability. If another worker thread is executing
haskell code, the capability is not free, but
grabCapability succeeds anyway.
We cannot use grabReturnCapability either, because we
cannot rely on a worker thread being around to wake us.
The only solution I can think of right now is to do
away with the safe/threadsafe distinction and treat all
safe calls as threadsafe. (After all, if we don't spawn
a new worker thread in suspendThread, we will have to
spawn a new worker thread for a callback anyway [in
scheduleThread_], so we're not losing any performance).
The following code fails with various assertion
failures and segfaults. All of them are due to the fact
that the RTS accidentally runs two pieces of haskell
code at once.
This is with ghc-5.05 (CVS HEAD from 11th or 12th of
December) configured with --enable-threaded-rts.
Main.hs
module Main where
import Control.Concurrent(forkIO)
foreign import ccall safe foo foo :: IO ()
foreign export ccall bar bar :: IO ()
bar = putStrLn Hello, world.
fib 0 = 1
fib 1 = 1
fib n = fib (n-1) + fib (n-2)
doSomeWork n = do
putStrLn (fib ++ show n ++ = ++ show (fib n))
doSomeWork (n+1)
main = do
forkIO (doSomeWork 0)
foo
putStrLn foo finished
putStrLn (main says: fib 30 = ++ show (fib 30))
foo.c
extern void bar();
void foo()
{
bar();
}
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=653694group_id=8032
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-630807 ] -O2 generates wrong code
Bugs item #630807, was opened at 2002-10-30 00:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=630807group_id=8032 Category: Compiler Group: 5.04.1 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Simon Peyton Jones (simonpj) Summary: -O2 generates wrong code Initial Comment: I have a program (the Bluespec compiler), where using -O2 generates a program that loops (or at least is VERY slow), whereas not using generates a working program. I can't really give you the source code, but perhaps you can contact me and we can see if we can work something out. -- Lennart [EMAIL PROTECTED] -- Comment By: Simon Marlow (simonmar) Date: 2002-12-13 10:47 Message: Logged In: YES user_id=48280 Fixed in rev. 1.140 of Simplify.lhs, fix will be in 5.04.3 (if we release it). -- Comment By: Nobody/Anonymous (nobody) Date: 2002-10-30 18:31 Message: Logged In: NO Further investigations show that the generated code is not looping, it is indeed correct, but it's just been incredibly pessimised. On a smaller example the unoptmized code finishes in 0.02s and the optmized code in 18s. It seem that the complexity of the (very complicated) algorithm has suddenly become exponential with -O2. -- Comment By: Nobody/Anonymous (nobody) Date: 2002-10-30 00:14 Message: Logged In: NO BTW, this bug is in 5.02 too. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=630807group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-653009 ] com. line args not honoured for recompil
Bugs item #653009, was opened at 2002-12-12 23:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=653009group_id=8032 Category: Compiler Group: None Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: com. line args not honoured for recompil Initial Comment: I compiled a file with a standard compile and link and some flags, include -fallow-overlapping-isntances. I was interested in whether overlapping instances were really required, so I recompiled -- without modifying the file -- without -fallow-overlapping-instances. I got the compilation IS NOT required message, clearly erroneous. Suggestion: flag configuration / compiler state stored in generated code and checked on recompile. My email is [EMAIL PROTECTED] Thanks, Nick -- Comment By: Simon Marlow (simonmar) Date: 2002-12-13 11:07 Message: Logged In: YES user_id=48280 Yes, but (a) make doesn't know that you've changed the options, (b) sometimes you want to change options without recompiling, eg. adding/removing -O, etc. and (c) it's extra work for us to implement :-) Workaround: use -no-recomp -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=653009group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-652927 ] Integer - Int64 sometimes wrong
Bugs item #652927, was opened at 2002-12-12 21:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=652927group_id=8032 Category: hslibs/lang Group: 5.04.2 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Mike Gunter (magunter) Assigned to: Simon Marlow (simonmar) Summary: Integer - Int64 sometimes wrong Initial Comment: Conversion from Integer to Int64 values sometimes produces the wrong value. In particular, it seems to fail on small-magnitude negative values whose representation is large. E.g. (fromIntegral ((2^30 -1 + 2^30) - (2^30 + 2^30 :: Integer))) :: Data.Int.Int64 4294967295 (fromIntegral ((2^30 - 2 + 2^30) - (2^30 - 1 + 2^30 :: Integer))) :: Data.Int.Int64 -1 The Haskell-level workaround is to do the conversion as a non-negative number then negate if needed: let fis (i::Integer) = (fromIntegral (signum i) * fromIntegral (abs i)) :: Data.Int.Int64 fis ((2^30 -1 + 2^30) - (2^30 + 2^30 :: Integer)) -1 -- Comment By: Simon Marlow (simonmar) Date: 2002-12-13 14:26 Message: Logged In: YES user_id=48280 Fixed; thanks. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=652927group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-651842 ] Link failure with -prof (OS X, CVS GHC)
Bugs item #651842, was opened at 2002-12-11 06:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=651842group_id=8032 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: whee (whee) Assigned to: Nobody/Anonymous (nobody) Summary: Link failure with -prof (OS X, CVS GHC) Initial Comment: Using Mac OS X 10.2.2, the linker fails when -prof is in effect: (Relevant output from 'ghc -v -prof --make file.hs -o file') ld -arch ppc -dynamic -framework HaskellSupport [snip] -o file -lcrt1.o -lcrtbegin.o -L/usr/local/lib/ghc-5.05 -L/usr/lib/gcc/darwin/3.1 -L/usr/lib/gcc/darwin -L/usr/libexec/gcc/darwin/ppc/3.1/../../.. file.o -lHShaskell98_p -lHSbase_p -lHSbase_cbits -lHSrts_p -lm -lpthread -lgcc -lSystem | c++filt3 ld: Undefined symbols: _TextziReadziLex_Char_con_info Upon further inspection, the symbol _TextziReadziLex_Char_con_info is indeed not defined in libHSbase_p.a as it should be. It is, however, present in libHSbase.a. After a full clean and rebuild, the problem persists. This is with GHC 5.05 (CVS 2002-12-11). -- Comment By: Wolfgang Thaller (wthaller) Date: 2002-12-13 19:42 Message: Logged In: YES user_id=566359 No problem here (CVS 2002-12-12). Both libHSbase.a and libHSbase_p.a contain the symbol TextziReadziLex_Char_con_info. No error occurs when linking a hello-world style program for profiling. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=651842group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-652863 ] Integer - Int64 sometimes wrong
Bugs item #652863, was opened at 2002-12-12 20:02 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=652863group_id=8032 Category: hslibs/lang Group: 5.04.2 Status: Open Resolution: None Priority: 5 Submitted By: Mike Gunter (magunter) Assigned to: Nobody/Anonymous (nobody) Summary: Integer - Int64 sometimes wrong Initial Comment: Conversion from Integer to Int64 values sometimes produces the wrong value. In particular, it seems to fail on small-magnitude negative values whose representation is large. E.g. (fromIntegral ((2^30 -1 + 2^30) - (2^30 + 2^30 :: Integer))) :: Data.Int.Int64 4294967295 (fromIntegral ((2^30 - 2 + 2^30) - (2^30 - 1 + 2^30 :: Integer))) :: Data.Int.Int64 -1 The Haskell-level workaround is to do the conversion as a non-negative number then negate if needed: let fis (i::Integer) = (fromIntegral (signum i) * fromIntegral (abs i)) :: Data.Int.Int64 fis ((2^30 -1 + 2^30) - (2^30 + 2^30 :: Integer)) -1 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=652863group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-652927 ] Integer - Int64 sometimes wrong
Bugs item #652927, was opened at 2002-12-12 21:24 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=652927group_id=8032 Category: hslibs/lang Group: 5.04.2 Status: Open Resolution: None Priority: 5 Submitted By: Mike Gunter (magunter) Assigned to: Nobody/Anonymous (nobody) Summary: Integer - Int64 sometimes wrong Initial Comment: Conversion from Integer to Int64 values sometimes produces the wrong value. In particular, it seems to fail on small-magnitude negative values whose representation is large. E.g. (fromIntegral ((2^30 -1 + 2^30) - (2^30 + 2^30 :: Integer))) :: Data.Int.Int64 4294967295 (fromIntegral ((2^30 - 2 + 2^30) - (2^30 - 1 + 2^30 :: Integer))) :: Data.Int.Int64 -1 The Haskell-level workaround is to do the conversion as a non-negative number then negate if needed: let fis (i::Integer) = (fromIntegral (signum i) * fromIntegral (abs i)) :: Data.Int.Int64 fis ((2^30 -1 + 2^30) - (2^30 + 2^30 :: Integer)) -1 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=652927group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-653009 ] com. line args not honoured for recompil
Bugs item #653009, was opened at 2002-12-12 15:30 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=653009group_id=8032 Category: Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: com. line args not honoured for recompil Initial Comment: I compiled a file with a standard compile and link and some flags, include -fallow-overlapping-isntances. I was interested in whether overlapping instances were really required, so I recompiled -- without modifying the file -- without -fallow-overlapping-instances. I got the compilation IS NOT required message, clearly erroneous. Suggestion: flag configuration / compiler state stored in generated code and checked on recompile. My email is [EMAIL PROTECTED] Thanks, Nick -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=653009group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-651842 ] Link failure with -prof (OS X, CVS GHC)
Bugs item #651842, was opened at 2002-12-11 00:15 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=651842group_id=8032 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: whee (whee) Assigned to: Nobody/Anonymous (nobody) Summary: Link failure with -prof (OS X, CVS GHC) Initial Comment: Using Mac OS X 10.2.2, the linker fails when -prof is in effect: (Relevant output from 'ghc -v -prof --make file.hs -o file') ld -arch ppc -dynamic -framework HaskellSupport [snip] -o file -lcrt1.o -lcrtbegin.o -L/usr/local/lib/ghc-5.05 -L/usr/lib/gcc/darwin/3.1 -L/usr/lib/gcc/darwin -L/usr/libexec/gcc/darwin/ppc/3.1/../../.. file.o -lHShaskell98_p -lHSbase_p -lHSbase_cbits -lHSrts_p -lm -lpthread -lgcc -lSystem | c++filt3 ld: Undefined symbols: _TextziReadziLex_Char_con_info Upon further inspection, the symbol _TextziReadziLex_Char_con_info is indeed not defined in libHSbase_p.a as it should be. It is, however, present in libHSbase.a. After a full clean and rebuild, the problem persists. This is with GHC 5.05 (CVS 2002-12-11). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=651842group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-648903 ] can't declare instance for type synonim
Bugs item #648903, was opened at 2002-12-05 13:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=648903group_id=8032 Category: Compiler (Type checker) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Igor (alar) Assigned to: Nobody/Anonymous (nobody) Summary: can't declare instance for type synonim Initial Comment: Trying to load into GHCi simple program (in attached file) I receive error stating I can declare class instances only for types defined using data. I beleive it is a bug because Hugs handles this situation normally. Error message: /igor/tst.hs:1: No instance for `Eq (Stack - Stack)' When deriving the `Eq' instance for type `Object' /igor/tst.hs:1: No instance for `Show (Stack - Stack)' When deriving the `Show' instance for type `Object' /igor/tst.hs:4: Illegal instance declaration for `Eq Operator' (The instance type must be of form (T a b c) where T is not a synonym, and a,b,c are distinct type variables) In the instance declaration for `Eq Operator' /igor/tst.hs:6: Illegal instance declaration for `Show Operator' (The instance type must be of form (T a b c) where T is not a synonym, and a,b,c are distinct type variables) In the instance declaration for `Show Operator' -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=648903group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-648903 ] can't declare instance for type synonim
Bugs item #648903, was opened at 2002-12-05 10:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=648903group_id=8032 Category: Compiler (Type checker) Group: None Status: Closed Resolution: Rejected Priority: 5 Submitted By: Igor (alar) Assigned to: Nobody/Anonymous (nobody) Summary: can't declare instance for type synonim Initial Comment: Trying to load into GHCi simple program (in attached file) I receive error stating I can declare class instances only for types defined using data. I beleive it is a bug because Hugs handles this situation normally. Error message: /igor/tst.hs:1: No instance for `Eq (Stack - Stack)' When deriving the `Eq' instance for type `Object' /igor/tst.hs:1: No instance for `Show (Stack - Stack)' When deriving the `Show' instance for type `Object' /igor/tst.hs:4: Illegal instance declaration for `Eq Operator' (The instance type must be of form (T a b c) where T is not a synonym, and a,b,c are distinct type variables) In the instance declaration for `Eq Operator' /igor/tst.hs:6: Illegal instance declaration for `Show Operator' (The instance type must be of form (T a b c) where T is not a synonym, and a,b,c are distinct type variables) In the instance declaration for `Show Operator' -- Comment By: Simon Marlow (simonmar) Date: 2002-12-05 10:54 Message: Logged In: YES user_id=48280 Hugs is wrong on this one, the H98 report states that an instance type cannot refer to a type synonym (section 4.3.2). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=648903group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-648783 ] Compile error for HsNet.h
Bugs item #648783, was opened at 2002-12-05 03:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=648783group_id=8032 Category: hslibs/net Group: 5.04.2 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Compile error for HsNet.h Initial Comment: libraries/network/Network/BSD.hsc fails to compile on RedHat 6.2 (GNU libc 2.1.3) due to an unknown type in_addr_t in HsNet.h: ../../ghc/utils/hsc2hs/hsc2hs-inplace -Iinclude -I. Network/BSD.hsc In file included from BSD.hsc:99: include/HsNet.h:77: parse error before `addr' include/HsNet.h: In function `my_inet_ntoa': include/HsNet.h:80: `addr' undeclared (first use in this function) include/HsNet.h:80: (Each undeclared identifier is reported only once include/HsNet.h:80: for each function it appears in.) make[2]: *** [Network/BSD.hs] Error 1 make[1]: *** [boot] Error 1 make[1]: Leaving directory `/usr/src/fptools-5.04/libraries' make: *** [all] Error 1 5.04.1 had a check for this: #ifndef HAVE_IN_ADDR_T typedef u_int32_t in_addr_t; #endif This has been removed in 5.04.2. -- Glynn Clements [EMAIL PROTECTED] -- Comment By: Simon Marlow (simonmar) Date: 2002-12-05 11:05 Message: Logged In: YES user_id=48280 5.04.1 didn't have that check; as far as I can tell, the workaround came in rev 1.9 of HsNet.h and this change was never merged into the branch. So I'm surprised if 5.04.1 worked on that platform, but it is indeed a bug. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=648783group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-648903 ] can't declare instance for type synonim
Bugs item #648903, was opened at 2002-12-05 02:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=648903group_id=8032 Category: Compiler (Type checker) Group: None Status: Closed Resolution: Rejected Priority: 5 Submitted By: Igor (alar) Assigned to: Nobody/Anonymous (nobody) Summary: can't declare instance for type synonim Initial Comment: Trying to load into GHCi simple program (in attached file) I receive error stating I can declare class instances only for types defined using data. I beleive it is a bug because Hugs handles this situation normally. Error message: /igor/tst.hs:1: No instance for `Eq (Stack - Stack)' When deriving the `Eq' instance for type `Object' /igor/tst.hs:1: No instance for `Show (Stack - Stack)' When deriving the `Show' instance for type `Object' /igor/tst.hs:4: Illegal instance declaration for `Eq Operator' (The instance type must be of form (T a b c) where T is not a synonym, and a,b,c are distinct type variables) In the instance declaration for `Eq Operator' /igor/tst.hs:6: Illegal instance declaration for `Show Operator' (The instance type must be of form (T a b c) where T is not a synonym, and a,b,c are distinct type variables) In the instance declaration for `Show Operator' -- Comment By: Sigbjorn Finne (sigbjorn) Date: 2002-12-05 09:04 Message: Logged In: YES user_id=232905 To get at the 'wrong' behaviour with GHC(i), use -fglasgow- exts. -- Comment By: Simon Marlow (simonmar) Date: 2002-12-05 02:54 Message: Logged In: YES user_id=48280 Hugs is wrong on this one, the H98 report states that an instance type cannot refer to a type synonym (section 4.3.2). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=648903group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-648783 ] Compile error for HsNet.h
Bugs item #648783, was opened at 2002-12-04 19:07 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=648783group_id=8032 Category: hslibs/net Group: 5.04.2 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Compile error for HsNet.h Initial Comment: libraries/network/Network/BSD.hsc fails to compile on RedHat 6.2 (GNU libc 2.1.3) due to an unknown type in_addr_t in HsNet.h: ../../ghc/utils/hsc2hs/hsc2hs-inplace -Iinclude -I. Network/BSD.hsc In file included from BSD.hsc:99: include/HsNet.h:77: parse error before `addr' include/HsNet.h: In function `my_inet_ntoa': include/HsNet.h:80: `addr' undeclared (first use in this function) include/HsNet.h:80: (Each undeclared identifier is reported only once include/HsNet.h:80: for each function it appears in.) make[2]: *** [Network/BSD.hs] Error 1 make[1]: *** [boot] Error 1 make[1]: Leaving directory `/usr/src/fptools-5.04/libraries' make: *** [all] Error 1 5.04.1 had a check for this: #ifndef HAVE_IN_ADDR_T typedef u_int32_t in_addr_t; #endif This has been removed in 5.04.2. -- Glynn Clements [EMAIL PROTECTED] -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=648783group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-642810 ] Still fails to build with GCC 3.2 on Mandrake
Bugs item #642810, was opened at 2002-11-23 18:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=642810group_id=8032 Category: Driver Group: 5.04.1 Status: Open Resolution: None Priority: 5 Submitted By: Joe English (jenglish) Assigned to: Nobody/Anonymous (nobody) Summary: Still fails to build with GCC 3.2 on Mandrake Initial Comment: Following the instructions listed in other bug reports, I bootstrapped GHC 5.04.1 on a machine with an older GCC, then installed that on the target machine (Mandrake 9.0, GCC 3.2). But the mangler is still busted: compiling anything with -O gives errors like: | Prologue junk?: .globl __stginit_PrimPacked | .type __stginit_PrimPacked,@function | __stginit_PrimPacked: | pushl %ebp | movl%esp, %ebp Compiling with '-O -fasm' works, but GHC 5.04.1 still can't recompile itself since parts of it require '-O -fvia-C'. I also tried downloading the current version of ghc-asm.lprl from the CVS repository and using that; still get the same errors. -- Comment By: Simon Marlow (simonmar) Date: 2002-12-03 11:35 Message: Logged In: YES user_id=48280 Re-opened; we really need a workaround for this one. -- Comment By: Joe English (jenglish) Date: 2002-11-28 00:00 Message: Logged In: YES user_id=68433 Yep, adding -mno-omit-leaf-frame-pointer did the trick. Problem solved! -- Comment By: Joe English (jenglish) Date: 2002-11-26 21:18 Message: Logged In: YES user_id=68433 I think I've found the problem: the mangler relies on -fomit-frame-pointer, but gcc-3.2mdk turns -momit-leaf-frame-pointer on by default. The latter flag (apparently) overrides the former, so non-leaf functions end up with unexpected junk in the prologue. I'll try -mno-omit-leaf-frame-pointer and see if that works. (I don't have access to my Mandrake box at the moment; but I can get ghc to *break* in the same way on a Red Hat 8.0 system with `ghc -c -O -optc -momit-leaf-frame-pointer`, so that's a promising sign :-) -- Comment By: Joe English (jenglish) Date: 2002-11-26 18:24 Message: Logged In: YES user_id=68433 Nope, that's not it either. Using ghc -O -v -pgmc gcc-3.2 -march=i386 -mcpu=i386 gives the same result. Back to the drawing board... -- Comment By: Joe English (jenglish) Date: 2002-11-26 16:00 Message: Logged In: YES user_id=68433 Aha: Mandrake's GCC is configured to compile for i586, while Redhat's is configured for i386. I'll bet this is the source of the problem. Will investigate further... -- Comment By: Simon Marlow (simonmar) Date: 2002-11-26 10:48 Message: Logged In: YES user_id=48280 Mandrake shipped a broken GCC, it seems. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=642810group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-642810 ] Still fails to build with GCC 3.2 on Mandrake
Bugs item #642810, was opened at 2002-11-23 10:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=642810group_id=8032 Category: Driver Group: 5.04.1 Status: Open Resolution: None Priority: 5 Submitted By: Joe English (jenglish) Assigned to: Nobody/Anonymous (nobody) Summary: Still fails to build with GCC 3.2 on Mandrake Initial Comment: Following the instructions listed in other bug reports, I bootstrapped GHC 5.04.1 on a machine with an older GCC, then installed that on the target machine (Mandrake 9.0, GCC 3.2). But the mangler is still busted: compiling anything with -O gives errors like: | Prologue junk?: .globl __stginit_PrimPacked | .type __stginit_PrimPacked,@function | __stginit_PrimPacked: | pushl %ebp | movl%esp, %ebp Compiling with '-O -fasm' works, but GHC 5.04.1 still can't recompile itself since parts of it require '-O -fvia-C'. I also tried downloading the current version of ghc-asm.lprl from the CVS repository and using that; still get the same errors. -- Comment By: Joe English (jenglish) Date: 2002-12-03 09:12 Message: Logged In: YES user_id=68433 Simon wrote: Re-opened; we really need a workaround for this one. I've attached the patch I used to build a Mandrake RPM; this just adds -mno-omit-leaf-frame-pointer at the relevant spot in DriverFlags.hs. Unfortunately, applying this patch as it stands *breaks* the compiler if an older gcc is used, since -mno-omit-leaf-frame-pointer was introduced in GCC 3.X. -- Comment By: Simon Marlow (simonmar) Date: 2002-12-03 03:35 Message: Logged In: YES user_id=48280 Re-opened; we really need a workaround for this one. -- Comment By: Joe English (jenglish) Date: 2002-11-27 16:00 Message: Logged In: YES user_id=68433 Yep, adding -mno-omit-leaf-frame-pointer did the trick. Problem solved! -- Comment By: Joe English (jenglish) Date: 2002-11-26 13:18 Message: Logged In: YES user_id=68433 I think I've found the problem: the mangler relies on -fomit-frame-pointer, but gcc-3.2mdk turns -momit-leaf-frame-pointer on by default. The latter flag (apparently) overrides the former, so non-leaf functions end up with unexpected junk in the prologue. I'll try -mno-omit-leaf-frame-pointer and see if that works. (I don't have access to my Mandrake box at the moment; but I can get ghc to *break* in the same way on a Red Hat 8.0 system with `ghc -c -O -optc -momit-leaf-frame-pointer`, so that's a promising sign :-) -- Comment By: Joe English (jenglish) Date: 2002-11-26 10:24 Message: Logged In: YES user_id=68433 Nope, that's not it either. Using ghc -O -v -pgmc gcc-3.2 -march=i386 -mcpu=i386 gives the same result. Back to the drawing board... -- Comment By: Joe English (jenglish) Date: 2002-11-26 08:00 Message: Logged In: YES user_id=68433 Aha: Mandrake's GCC is configured to compile for i586, while Redhat's is configured for i386. I'll bet this is the source of the problem. Will investigate further... -- Comment By: Simon Marlow (simonmar) Date: 2002-11-26 02:48 Message: Logged In: YES user_id=48280 Mandrake shipped a broken GCC, it seems. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=642810group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-646201 ] ghc-5.04: panic! ... tySplitTyConApp ...
Bugs item #646201, was opened at 2002-11-30 21:11
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=646201group_id=8032
Category: Compiler
Group: 5.04.1
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Markus Lauer (mlauer)
Assigned to: Nobody/Anonymous (nobody)
Summary: ghc-5.04: panic! ... tySplitTyConApp ...
Initial Comment:
compiling the below program with
ghc -fglasgow-exts Main.hs
gives the following error:
ghc-5.04: panic! (the `impossible' happened, GHC
version 5.04):
tcSplitTyConApp forall x{-r6S-} :: *.
Main.L{-rr-} x{-r6S-}
-
-- Main.hs
module Main where
newtype FA c = FA (forall x . c x)
newtype L x = L [x]
my_nil = FA (L []) :: FA L
sample :: String
sample = case my_nil of FA (L x) - foo++x
-- -- but this works fine
-- sample = case my_nil of FA x - case x of L y -
foo++y
main = print sample
--
Comment By: Simon Peyton Jones (simonpj)
Date: 2002-12-02 09:08
Message:
Logged In: YES
user_id=50165
This bug is fixed in 5.04.1
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=646201group_id=8032
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-646201 ] ghc-5.04: panic! ... tySplitTyConApp ...
Bugs item #646201, was opened at 2002-11-30 21:11
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=646201group_id=8032
Category: Compiler
Group: 5.04.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Markus Lauer (mlauer)
Assigned to: Nobody/Anonymous (nobody)
Summary: ghc-5.04: panic! ... tySplitTyConApp ...
Initial Comment:
compiling the below program with
ghc -fglasgow-exts Main.hs
gives the following error:
ghc-5.04: panic! (the `impossible' happened, GHC
version 5.04):
tcSplitTyConApp forall x{-r6S-} :: *.
Main.L{-rr-} x{-r6S-}
-
-- Main.hs
module Main where
newtype FA c = FA (forall x . c x)
newtype L x = L [x]
my_nil = FA (L []) :: FA L
sample :: String
sample = case my_nil of FA (L x) - foo++x
-- -- but this works fine
-- sample = case my_nil of FA x - case x of L y -
foo++y
main = print sample
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=646201group_id=8032
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-644657 ] interface decl for PrelTup
Bugs item #644657, was opened at 2002-11-27 10:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=644657group_id=8032 Category: Compiler Group: 5.02 Status: Closed Resolution: Wont Fix Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: interface decl for PrelTup Initial Comment: My literate haskell script uses tupels with 38 elements. When using HUGS I get no errors and the script is running as wanted. Compiling with ghc-5.02.2 following error occurs: Switches_tupel.lhs:1: Failed to find interface decl for `PrelTup.(,)' from module `PrelTup' [EMAIL PROTECTED] -- Comment By: Simon Peyton Jones (simonpj) Date: 2002-11-28 09:41 Message: Logged In: YES user_id=50165 GHC only provides tuples up to size 37. This is indeed a bug, and it's been on the list of things to fix for about ten years. But it's quite tiresome to do anything about and seldom bites. I will update the manual; and I'll make the compiler give a more graceful error message. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=644657group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-645296 ] configure doesn't recognise platform
Bugs item #645296, was opened at 2002-11-28 06:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=645296group_id=8032 Category: Build System Group: 5.04.1 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: configure doesn't recognise platform Initial Comment: the ./configure script said it didn't recognise my build platform (alphaev5-unknown-linux-gnu). after looking in the script, changing the $HostPlatform matching string from alpha*-unknown-linux to alpha*- unknown-linux-gnu was all that was needed to fix it and to get it to compile. so perhaps this could be changed in the next release. thanks. peace. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=645296group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-645296 ] configure doesn't recognise platform
Bugs item #645296, was opened at 2002-11-28 06:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=645296group_id=8032 Category: Build System Group: 5.04.1 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: configure doesn't recognise platform Initial Comment: the ./configure script said it didn't recognise my build platform (alphaev5-unknown-linux-gnu). after looking in the script, changing the $HostPlatform matching string from alpha*-unknown-linux to alpha*- unknown-linux-gnu was all that was needed to fix it and to get it to compile. so perhaps this could be changed in the next release. thanks. peace. -- Comment By: Nobody/Anonymous (nobody) Date: 2002-11-28 06:50 Message: Logged In: NO oh, wait, no. i was a bit too fast. it didn't compile, it stopped due to the alpha-unknown-linux definition. the output: gcc -E -DGLUT_API_VERSION=no -I../includes - traditional-x c prelude/primops.txt.pp | /usr/bin/sed - e '/^#/d' prelude/primops.txt In file included from ../includes/MachDeps.h:19, from prelude/primops.txt.pp:66: ../includes/config.h:8: warning: missing white space after `#define alpha_unknown_linux' ../includes/config.h:9: warning: missing white space after `#define alpha_unknown_linux' ../includes/config.h:9: warning: `alpha_unknown_linux' redefined ../includes/config.h:8: warning: this is the location of the previous definition ../includes/config.h:10: warning: missing white space after `#define alpha_unknown_linux' ../includes/config.h:10: warning: `alpha_unknown_linux' redefined ../includes/config.h:9: warning: this is the location of the previous definition ../utils/genprimopcode/genprimopcode --data-decl prelude/primops.txt primop-data-decl.hs-incl /bin/sh: ../utils/genprimopcode/genprimopcode: No such file or directory make[2]: *** [primop-data-decl.hs-incl] Error 126 make[1]: *** [boot] Error 1 make[1]: Leaving directory `/home/sir/helium/ghc-5.04.1/ghc' make: *** [all] Error 1 i hope you can fix it. thanks in advance. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=645296group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-645296 ] configure doesn't recognise platform
Bugs item #645296, was opened at 2002-11-28 14:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=645296group_id=8032 Category: Build System Group: 5.04.1 Status: Closed Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: configure doesn't recognise platform Initial Comment: the ./configure script said it didn't recognise my build platform (alphaev5-unknown-linux-gnu). after looking in the script, changing the $HostPlatform matching string from alpha*-unknown-linux to alpha*- unknown-linux-gnu was all that was needed to fix it and to get it to compile. so perhaps this could be changed in the next release. thanks. peace. -- Comment By: Simon Marlow (simonmar) Date: 2002-11-28 16:22 Message: Logged In: YES user_id=48280 Your platform isn't currently supported. Please take a look at the building guide, in particular the section on porting GHC: http://www.haskell.org/ghc/docs/latest/html/building/building- guide.html -- Comment By: Nobody/Anonymous (nobody) Date: 2002-11-28 14:50 Message: Logged In: NO oh, wait, no. i was a bit too fast. it didn't compile, it stopped due to the alpha-unknown-linux definition. the output: gcc -E -DGLUT_API_VERSION=no -I../includes - traditional-x c prelude/primops.txt.pp | /usr/bin/sed - e '/^#/d' prelude/primops.txt In file included from ../includes/MachDeps.h:19, from prelude/primops.txt.pp:66: ../includes/config.h:8: warning: missing white space after `#define alpha_unknown_linux' ../includes/config.h:9: warning: missing white space after `#define alpha_unknown_linux' ../includes/config.h:9: warning: `alpha_unknown_linux' redefined ../includes/config.h:8: warning: this is the location of the previous definition ../includes/config.h:10: warning: missing white space after `#define alpha_unknown_linux' ../includes/config.h:10: warning: `alpha_unknown_linux' redefined ../includes/config.h:9: warning: this is the location of the previous definition ../utils/genprimopcode/genprimopcode --data-decl prelude/primops.txt primop-data-decl.hs-incl /bin/sh: ../utils/genprimopcode/genprimopcode: No such file or directory make[2]: *** [primop-data-decl.hs-incl] Error 126 make[1]: *** [boot] Error 1 make[1]: Leaving directory `/home/sir/helium/ghc-5.04.1/ghc' make: *** [all] Error 1 i hope you can fix it. thanks in advance. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=645296group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-644657 ] interface decl for PrelTup
Bugs item #644657, was opened at 2002-11-27 02:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=644657group_id=8032 Category: Compiler Group: 5.02 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: interface decl for PrelTup Initial Comment: My literate haskell script uses tupels with 38 elements. When using HUGS I get no errors and the script is running as wanted. Compiling with ghc-5.02.2 following error occurs: Switches_tupel.lhs:1: Failed to find interface decl for `PrelTup.(,)' from module `PrelTup' [EMAIL PROTECTED] -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=644657group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-642810 ] Still fails to build with GCC 3.2 on Mandrake
Bugs item #642810, was opened at 2002-11-23 10:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=642810group_id=8032 Category: Driver Group: 5.04.1 Status: Closed Resolution: None Priority: 5 Submitted By: Joe English (jenglish) Assigned to: Nobody/Anonymous (nobody) Summary: Still fails to build with GCC 3.2 on Mandrake Initial Comment: Following the instructions listed in other bug reports, I bootstrapped GHC 5.04.1 on a machine with an older GCC, then installed that on the target machine (Mandrake 9.0, GCC 3.2). But the mangler is still busted: compiling anything with -O gives errors like: | Prologue junk?: .globl __stginit_PrimPacked | .type __stginit_PrimPacked,@function | __stginit_PrimPacked: | pushl %ebp | movl%esp, %ebp Compiling with '-O -fasm' works, but GHC 5.04.1 still can't recompile itself since parts of it require '-O -fvia-C'. I also tried downloading the current version of ghc-asm.lprl from the CVS repository and using that; still get the same errors. -- Comment By: Joe English (jenglish) Date: 2002-11-27 16:00 Message: Logged In: YES user_id=68433 Yep, adding -mno-omit-leaf-frame-pointer did the trick. Problem solved! -- Comment By: Joe English (jenglish) Date: 2002-11-26 13:18 Message: Logged In: YES user_id=68433 I think I've found the problem: the mangler relies on -fomit-frame-pointer, but gcc-3.2mdk turns -momit-leaf-frame-pointer on by default. The latter flag (apparently) overrides the former, so non-leaf functions end up with unexpected junk in the prologue. I'll try -mno-omit-leaf-frame-pointer and see if that works. (I don't have access to my Mandrake box at the moment; but I can get ghc to *break* in the same way on a Red Hat 8.0 system with `ghc -c -O -optc -momit-leaf-frame-pointer`, so that's a promising sign :-) -- Comment By: Joe English (jenglish) Date: 2002-11-26 10:24 Message: Logged In: YES user_id=68433 Nope, that's not it either. Using ghc -O -v -pgmc gcc-3.2 -march=i386 -mcpu=i386 gives the same result. Back to the drawing board... -- Comment By: Joe English (jenglish) Date: 2002-11-26 08:00 Message: Logged In: YES user_id=68433 Aha: Mandrake's GCC is configured to compile for i586, while Redhat's is configured for i386. I'll bet this is the source of the problem. Will investigate further... -- Comment By: Simon Marlow (simonmar) Date: 2002-11-26 02:48 Message: Logged In: YES user_id=48280 Mandrake shipped a broken GCC, it seems. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=642810group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-643878 ] sortBy not stable
Bugs item #643878, was opened at 2002-11-26 01:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=643878group_id=8032 Category: Prelude Group: 5.04.1 Status: Closed Resolution: Fixed Priority: 7 Submitted By: Mike Gunter (magunter) Assigned to: Nobody/Anonymous (nobody) Summary: sortBy not stable Initial Comment: The library report requires that sortBy be stable. In 5.04.1 it isn't: gunter.philco.com[1995]$ ghci ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 5.04, for Haskell 98. / /_\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... linking ... done. Loading package haskell98 ... linking ... done. Prelude List.sortBy (\ (_,a) (_,b) - compare a b) $ zip [0..] [100,0,0,0] [(3,0),(2,0),(1,0),(0,100)] . In 5.02.3, it was stable: c966553-A[2314]$ ghci ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 5.02.3, for Haskell 98. / /_\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package std ... linking ... done. Prelude List.sortBy (\ (_,a) (_,b) - compare a b) $ zip [0..] [100,0,0,0] [(1,0),(2,0),(3,0),(0,100)] -- Comment By: Simon Marlow (simonmar) Date: 2002-11-26 09:52 Message: Logged In: YES user_id=48280 This one has been fixed, grab 5.04.2 when it is released. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=643878group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-642810 ] Still fails to build with GCC 3.2
Bugs item #642810, was opened at 2002-11-23 18:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=642810group_id=8032 Category: Driver Group: 5.04.1 Status: Closed Resolution: None Priority: 5 Submitted By: Joe English (jenglish) Assigned to: Nobody/Anonymous (nobody) Summary: Still fails to build with GCC 3.2 Initial Comment: Following the instructions listed in other bug reports, I bootstrapped GHC 5.04.1 on a machine with an older GCC, then installed that on the target machine (Mandrake 9.0, GCC 3.2). But the mangler is still busted: compiling anything with -O gives errors like: | Prologue junk?: .globl __stginit_PrimPacked | .type __stginit_PrimPacked,@function | __stginit_PrimPacked: | pushl %ebp | movl%esp, %ebp Compiling with '-O -fasm' works, but GHC 5.04.1 still can't recompile itself since parts of it require '-O -fvia-C'. I also tried downloading the current version of ghc-asm.lprl from the CVS repository and using that; still get the same errors. -- Comment By: Simon Marlow (simonmar) Date: 2002-11-26 10:48 Message: Logged In: YES user_id=48280 Mandrake shipped a broken GCC, it seems. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=642810group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-642810 ] Still fails to build with GCC 3.2 on Mandrake
Bugs item #642810, was opened at 2002-11-23 10:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=642810group_id=8032 Category: Driver Group: 5.04.1 Status: Closed Resolution: None Priority: 5 Submitted By: Joe English (jenglish) Assigned to: Nobody/Anonymous (nobody) Summary: Still fails to build with GCC 3.2 on Mandrake Initial Comment: Following the instructions listed in other bug reports, I bootstrapped GHC 5.04.1 on a machine with an older GCC, then installed that on the target machine (Mandrake 9.0, GCC 3.2). But the mangler is still busted: compiling anything with -O gives errors like: | Prologue junk?: .globl __stginit_PrimPacked | .type __stginit_PrimPacked,@function | __stginit_PrimPacked: | pushl %ebp | movl%esp, %ebp Compiling with '-O -fasm' works, but GHC 5.04.1 still can't recompile itself since parts of it require '-O -fvia-C'. I also tried downloading the current version of ghc-asm.lprl from the CVS repository and using that; still get the same errors. -- Comment By: Joe English (jenglish) Date: 2002-11-26 08:00 Message: Logged In: YES user_id=68433 Aha: Mandrake's GCC is configured to compile for i586, while Redhat's is configured for i386. I'll bet this is the source of the problem. Will investigate further... -- Comment By: Simon Marlow (simonmar) Date: 2002-11-26 02:48 Message: Logged In: YES user_id=48280 Mandrake shipped a broken GCC, it seems. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=642810group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-642810 ] Still fails to build with GCC 3.2 on Mandrake
Bugs item #642810, was opened at 2002-11-23 10:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=642810group_id=8032 Category: Driver Group: 5.04.1 Status: Closed Resolution: None Priority: 5 Submitted By: Joe English (jenglish) Assigned to: Nobody/Anonymous (nobody) Summary: Still fails to build with GCC 3.2 on Mandrake Initial Comment: Following the instructions listed in other bug reports, I bootstrapped GHC 5.04.1 on a machine with an older GCC, then installed that on the target machine (Mandrake 9.0, GCC 3.2). But the mangler is still busted: compiling anything with -O gives errors like: | Prologue junk?: .globl __stginit_PrimPacked | .type __stginit_PrimPacked,@function | __stginit_PrimPacked: | pushl %ebp | movl%esp, %ebp Compiling with '-O -fasm' works, but GHC 5.04.1 still can't recompile itself since parts of it require '-O -fvia-C'. I also tried downloading the current version of ghc-asm.lprl from the CVS repository and using that; still get the same errors. -- Comment By: Joe English (jenglish) Date: 2002-11-26 10:24 Message: Logged In: YES user_id=68433 Nope, that's not it either. Using ghc -O -v -pgmc gcc-3.2 -march=i386 -mcpu=i386 gives the same result. Back to the drawing board... -- Comment By: Joe English (jenglish) Date: 2002-11-26 08:00 Message: Logged In: YES user_id=68433 Aha: Mandrake's GCC is configured to compile for i586, while Redhat's is configured for i386. I'll bet this is the source of the problem. Will investigate further... -- Comment By: Simon Marlow (simonmar) Date: 2002-11-26 02:48 Message: Logged In: YES user_id=48280 Mandrake shipped a broken GCC, it seems. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=642810group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-643878 ] sortBy not stable
Bugs item #643878, was opened at 2002-11-26 01:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=643878group_id=8032 Category: Prelude Group: 5.04.1 Status: Open Resolution: None Priority: 5 Submitted By: Mike Gunter (magunter) Assigned to: Nobody/Anonymous (nobody) Summary: sortBy not stable Initial Comment: The library report requires that sortBy be stable. In 5.04.1 it isn't: gunter.philco.com[1995]$ ghci ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 5.04, for Haskell 98. / /_\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... linking ... done. Loading package haskell98 ... linking ... done. Prelude List.sortBy (\ (_,a) (_,b) - compare a b) $ zip [0..] [100,0,0,0] [(3,0),(2,0),(1,0),(0,100)] . In 5.02.3, it was stable: c966553-A[2314]$ ghci ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 5.02.3, for Haskell 98. / /_\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package std ... linking ... done. Prelude List.sortBy (\ (_,a) (_,b) - compare a b) $ zip [0..] [100,0,0,0] [(1,0),(2,0),(3,0),(0,100)] -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=643878group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-643878 ] sortBy not stable
Bugs item #643878, was opened at 2002-11-26 01:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=643878group_id=8032 Category: Prelude Group: 5.04.1 Status: Open Resolution: None Priority: 7 Submitted By: Mike Gunter (magunter) Assigned to: Nobody/Anonymous (nobody) Summary: sortBy not stable Initial Comment: The library report requires that sortBy be stable. In 5.04.1 it isn't: gunter.philco.com[1995]$ ghci ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 5.04, for Haskell 98. / /_\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package base ... linking ... done. Loading package haskell98 ... linking ... done. Prelude List.sortBy (\ (_,a) (_,b) - compare a b) $ zip [0..] [100,0,0,0] [(3,0),(2,0),(1,0),(0,100)] . In 5.02.3, it was stable: c966553-A[2314]$ ghci ___ ___ _ / _ \ /\ /\/ __(_) / /_\// /_/ / / | | GHC Interactive, version 5.02.3, for Haskell 98. / /_\/ __ / /___| | http://www.haskell.org/ghc/ \/\/ /_/\/|_| Type :? for help. Loading package std ... linking ... done. Prelude List.sortBy (\ (_,a) (_,b) - compare a b) $ zip [0..] [100,0,0,0] [(1,0),(2,0),(3,0),(0,100)] -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=643878group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-642810 ] Still fails to build with GCC 3.2
Bugs item #642810, was opened at 2002-11-23 10:51 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=642810group_id=8032 Category: Driver Group: 5.04.1 Status: Open Resolution: None Priority: 5 Submitted By: Joe English (jenglish) Assigned to: Nobody/Anonymous (nobody) Summary: Still fails to build with GCC 3.2 Initial Comment: Following the instructions listed in other bug reports, I bootstrapped GHC 5.04.1 on a machine with an older GCC, then installed that on the target machine (Mandrake 9.0, GCC 3.2). But the mangler is still busted: compiling anything with -O gives errors like: | Prologue junk?: .globl __stginit_PrimPacked | .type __stginit_PrimPacked,@function | __stginit_PrimPacked: | pushl %ebp | movl%esp, %ebp Compiling with '-O -fasm' works, but GHC 5.04.1 still can't recompile itself since parts of it require '-O -fvia-C'. I also tried downloading the current version of ghc-asm.lprl from the CVS repository and using that; still get the same errors. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=642810group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-635605 ] ghc-pkg in ghc root directory
Bugs item #635605, was opened at 2002-11-08 17:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=635605group_id=8032 Category: Compiler Group: None Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: ghc-pkg in ghc root directory Initial Comment: ghc-pkg.exe is present in the ghc/bin as well as in the ghc directory itself. Therefore, if you run the utility from the ghc directory, it looks for package.conf in the parent of the ghc directory. -- Comment By: Simon Peyton Jones (simonpj) Date: 2002-11-18 11:27 Message: Logged In: YES user_id=50165 Future versions won't install ghc-pkg twice on Win32 -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=635605group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-635594 ] objectio not included in 5.04 September
Bugs item #635594, was opened at 2002-11-08 17:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=635594group_id=8032 Category: Compiler Group: None Status: Closed Resolution: Accepted Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: objectio not included in 5.04 September Initial Comment: The 5.04 September version of GHC does not include the objectio package whereas the July version does. Installing the package myself failed because I couldn't find any package info to give to ghc-pkg. -- Martijn Schrage, [EMAIL PROTECTED] -- Comment By: Simon Peyton Jones (simonpj) Date: 2002-11-18 11:35 Message: Logged In: YES user_id=50165 True. It's up to Sigbjorn, who builds the Windows installers, whether to include ObjectIO. If he doesn't, you can get it from haskell.org/ObjectIO -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=635594group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-635594 ] objectio not included in 5.04 September
Bugs item #635594, was opened at 2002-11-08 09:28 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=635594group_id=8032 Category: Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: objectio not included in 5.04 September Initial Comment: The 5.04 September version of GHC does not include the objectio package whereas the July version does. Installing the package myself failed because I couldn't find any package info to give to ghc-pkg. -- Martijn Schrage, [EMAIL PROTECTED] -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=635594group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-635605 ] ghc-pkg in ghc root directory
Bugs item #635605, was opened at 2002-11-08 09:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=635605group_id=8032 Category: Compiler Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: ghc-pkg in ghc root directory Initial Comment: ghc-pkg.exe is present in the ghc/bin as well as in the ghc directory itself. Therefore, if you run the utility from the ghc directory, it looks for package.conf in the parent of the ghc directory. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=635605group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-635718 ] Bad space behaviour with huge input file
Bugs item #635718, was opened at 2002-11-08 23:43 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=635718group_id=8032 Category: Compiler Group: 5.04 Status: Open Resolution: None Priority: 5 Submitted By: Antti-Juhani Kaijanaho (ajk) Assigned to: Nobody/Anonymous (nobody) Summary: Bad space behaviour with huge input file Initial Comment: The attached files (actually, just UnicodeData.hs but the other file is imported by it) trigger very bad space and time behaviour in ghc during compilation. One attempt went up to 500 MB of virtual memory (256 physical available) on my i386 machine. The compilation ran for more than an hour until killed (stuck in the rename phase). I had another version (available on request) of this that has all the data in a string, compiled into an object file using gcc (in no time!), accessed using FFI and then using read made into a real data structure. The program, looking up one entry in the resulting FiniteMap, has a memory hit of approximately 130 MB and runs in one minute (which, while still too much, is bearable). So it seems there is lots to improve in the compiler in this case (we are essentially talking about the same process taking way too much time and memory when done by the compiler, compared to the program itself doing it - and even then the memory requirement is outrageous). Even some sort of special-casing pragma that allows me to ask for lighter treatment of pure data would be good (and a way to statically initialize a FiniteMap...) I'm sorry but I do not have any simpler input files to offer. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=635718group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-634379 ] panic with linear implicit parameters
Bugs item #634379, was opened at 2002-11-06 11:41
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=634379group_id=8032
Category: Compiler (Type checker)
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Antti-Juhani Kaijanaho (ajk)
Assigned to: Nobody/Anonymous (nobody)
Summary: panic with linear implicit parameters
Initial Comment:
Observe:
$ ghc -fglasgow-exts -c Unique.hs
ghc-5.04: panic! (the `impossible' happened, GHC
version 5.04):
tcSplitTyConApp {%uniqueSupply{-rF4-} ::
Unique.UniqueSupply{-r7-}}
Please report it as a compiler bug to
[EMAIL PROTECTED],
or http://sourceforge.net/projects/ghc/.
--
Comment By: Simon Peyton Jones (simonpj)
Date: 2002-11-07 11:47
Message:
Logged In: YES
user_id=50165
Thanks for this report. There's an obscure bug in lazy pattern
matching for implcit parameters. It'll be fixed in 5.04.2
Meanwhile, instead of
US r = %uniq
say
r = case %uniq of { US r - r }
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=634379group_id=8032
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-634379 ] panic with linear implicit parameters
Bugs item #634379, was opened at 2002-11-06 13:41
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=634379group_id=8032
Category: Compiler (Type checker)
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Antti-Juhani Kaijanaho (ajk)
Assigned to: Nobody/Anonymous (nobody)
Summary: panic with linear implicit parameters
Initial Comment:
Observe:
$ ghc -fglasgow-exts -c Unique.hs
ghc-5.04: panic! (the `impossible' happened, GHC
version 5.04):
tcSplitTyConApp {%uniqueSupply{-rF4-} ::
Unique.UniqueSupply{-r7-}}
Please report it as a compiler bug to
[EMAIL PROTECTED],
or http://sourceforge.net/projects/ghc/.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=634379group_id=8032
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-632021 ] GHC 5.04 build fail on Mandrake 9.0
Bugs item #632021, was opened at 2002-11-01 04:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=632021group_id=8032 Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: GHC 5.04 build fail on Mandrake 9.0 Initial Comment: I try to compile GHC 5.04.1 on Mandrake 9.0 using the preinstalled GHC 5.02.2, glibc 2.5.5, gcc 3.2. The build process aborts with: ===fptools== Recursively making `boot' in hasktags ghc-pkg hp2ps hsc2hs parallel stat2resid prof unlit gen.. PWD = /home/soft/Development/ghc-5.04.1/ghc/utils ==fptools== gmake boot - --no-print-directory -r; in /home/soft/Development/ghc-5.04.1/ghc/utils/hasktags /usr//bin/ghc -M -optdep-f -optdep.depend -osuf o -ldl -O HaskTags.hs ==fptools== gmake boot - --no-print-directory -r; in /home/soft/Development/ghc-5.04.1/ghc/utils/ghc-pkg /usr//bin/ghc -M -optdep-f -optdep.depend -osuf o -ldl -cpp -DPKG_TOOL -DWANT_PRETTY -package lang -papackage text -O Main.hs Package.hs ParsePkgConfLite.hs gmake all /usr//bin/ghc -ldl -cpp -DPKG_TOOL -DWANT_PRETTY -package lang -package util -package text -O-c Packagage.o Prologue junk?: .globl __stginit_Package __stginit_Package: pushl %ebp movl%esp, %ebp -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=632021group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-632021 ] GHC 5.04 build fail on Mandrake 9.0
Bugs item #632021, was opened at 2002-11-01 12:44 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=632021group_id=8032 Category: None Group: None Status: Closed Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: GHC 5.04 build fail on Mandrake 9.0 Initial Comment: I try to compile GHC 5.04.1 on Mandrake 9.0 using the preinstalled GHC 5.02.2, glibc 2.5.5, gcc 3.2. The build process aborts with: ===fptools== Recursively making `boot' in hasktags ghc-pkg hp2ps hsc2hs parallel stat2resid prof unlit gen.. PWD = /home/soft/Development/ghc-5.04.1/ghc/utils ==fptools== gmake boot - --no-print-directory -r; in /home/soft/Development/ghc-5.04.1/ghc/utils/hasktags /usr//bin/ghc -M -optdep-f -optdep.depend -osuf o -ldl -O HaskTags.hs ==fptools== gmake boot - --no-print-directory -r; in /home/soft/Development/ghc-5.04.1/ghc/utils/ghc-pkg /usr//bin/ghc -M -optdep-f -optdep.depend -osuf o -ldl -cpp -DPKG_TOOL -DWANT_PRETTY -package lang -papackage text -O Main.hs Package.hs ParsePkgConfLite.hs gmake all /usr//bin/ghc -ldl -cpp -DPKG_TOOL -DWANT_PRETTY -package lang -package util -package text -O-c Packagage.o Prologue junk?: .globl __stginit_Package __stginit_Package: pushl %ebp movl%esp, %ebp -- Comment By: Simon Marlow (simonmar) Date: 2002-11-01 16:51 Message: Logged In: YES user_id=48280 The problem here is that your installed GHC 5.02.2 won't work with GCC 3.2. You need to downgrade GCC to 2.95 first, then build GHC 5.04.1. Then you can upgrade GCC again to 3.2. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=632021group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-630807 ] -O2 generates wrong code
Bugs item #630807, was opened at 2002-10-29 16:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=630807group_id=8032 Category: Compiler Group: 5.04.1 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: -O2 generates wrong code Initial Comment: I have a program (the Bluespec compiler), where using -O2 generates a program that loops (or at least is VERY slow), whereas not using generates a working program. I can't really give you the source code, but perhaps you can contact me and we can see if we can work something out. -- Lennart [EMAIL PROTECTED] -- Comment By: Nobody/Anonymous (nobody) Date: 2002-10-30 10:31 Message: Logged In: NO Further investigations show that the generated code is not looping, it is indeed correct, but it's just been incredibly pessimised. On a smaller example the unoptmized code finishes in 0.02s and the optmized code in 18s. It seem that the complexity of the (very complicated) algorithm has suddenly become exponential with -O2. -- Comment By: Nobody/Anonymous (nobody) Date: 2002-10-29 16:14 Message: Logged In: NO BTW, this bug is in 5.02 too. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=630807group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-631320 ] {-# OPTIONS -O0 #-} not allowed
Bugs item #631320, was opened at 2002-10-30 15:57
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=631320group_id=8032
Category: Compiler
Group: 5.04.1
Status: Open
Resolution: None
Priority: 5
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: {-# OPTIONS -O0 #-} not allowed
Initial Comment:
When I tried to turn off the pessimizer for certain
files it complained that the -O0 option was not allowed
in the file. Very annoying.
[EMAIL PROTECTED]
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=631320group_id=8032
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-630807 ] -O2 generates wrong code
Bugs item #630807, was opened at 2002-10-29 16:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=630807group_id=8032 Category: Compiler Group: 5.04.1 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: -O2 generates wrong code Initial Comment: I have a program (the Bluespec compiler), where using -O2 generates a program that loops (or at least is VERY slow), whereas not using generates a working program. I can't really give you the source code, but perhaps you can contact me and we can see if we can work something out. -- Lennart [EMAIL PROTECTED] -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=630807group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-630807 ] -O2 generates wrong code
Bugs item #630807, was opened at 2002-10-29 16:12 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=630807group_id=8032 Category: Compiler Group: 5.04.1 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: -O2 generates wrong code Initial Comment: I have a program (the Bluespec compiler), where using -O2 generates a program that loops (or at least is VERY slow), whereas not using generates a working program. I can't really give you the source code, but perhaps you can contact me and we can see if we can work something out. -- Lennart [EMAIL PROTECTED] -- Comment By: Nobody/Anonymous (nobody) Date: 2002-10-29 16:14 Message: Logged In: NO BTW, this bug is in 5.02 too. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=630807group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-626263 ] GHC loops on attached module
Bugs item #626263, was opened at 2002-10-21 09:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=626263group_id=8032 Category: Compiler Group: 5.04.1 Status: Closed Resolution: Fixed Priority: 5 Submitted By: John Hughes (rjmh) Assigned to: Nobody/Anonymous (nobody) Summary: GHC loops on attached module Initial Comment: I attach a (rather old) parsing library. GHC 5.02.3 compiles it fine, but GHC 5.04.1 runs out of stack. (And yes, I have tried making the stack bigger!) -- Comment By: Simon Peyton Jones (simonpj) Date: 2002-10-22 11:01 Message: Logged In: YES user_id=50165 Yes, this is a known bug in GHC 5.02.1, will be fixed in 5.02.2. Workaround: use 'data' instead of 'newtype' for recursive newtypes. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=626263group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-617082 ] ghc -O generates faulty c code
Bugs item #617082, was opened at 2002-10-01 15:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=617082group_id=8032 Category: Compiler Group: 5.04 Status: Closed Resolution: Duplicate Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: ghc -O generates faulty c code Initial Comment: I have the following file: Bug.hs -- module Bug where foo :: Double - Double foo x = x - (-1.0) -- ghc -c -O Bug.hs /tmp/ghc25320.hc: In function `s3Ny_ret': /tmp/ghc25320.hc:14: invalid lvalue in decrement /tmp/ghc25320.hc:14: parse error before `1.0' Cause - The problem is the following generated c snippet _s3Nx_=PK_DBL((W_*)(R1.p+1))--1.0; The two consecutive minuses should be separated by a space. Ulf Norell [EMAIL PROTECTED] -- Comment By: Simon Marlow (simonmar) Date: 2002-10-14 12:47 Message: Logged In: YES user_id=48280 This was fixed in 5.04.1 (also reported in #604849). -- Comment By: Sven Panne (spanne) Date: 2002-10-03 12:23 Message: Logged In: YES user_id=50298 I've tested it with 5.02.3, 5.04.1 and the CVS HEAD and it works fine in all cases (i.e.the literal is correctly wrapped into parentheses). Which version are you using exactly? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=617082group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-620264 ] rdrNameModule it
Bugs item #620264, was opened at 2002-10-08 14:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=620264group_id=8032 Category: Compiler Group: 5.04.1 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: rdrNameModule it Initial Comment: Iยดm new in this, and probably this is known... or maybe irrelevant: What Iยดve done: (in Prelude) let x = error help! print x id x print it I did not understand why x isnยดt printed (id x works...), but the serious ghc.exe panic! message after trying to 'print it' told me to report this ^_^ I just went through the manual and tried some lines out of it... system: Win XP version: 5.04.1 GHCi E-Mail: [EMAIL PROTECTED] -- Comment By: Simon Marlow (simonmar) Date: 2002-10-14 12:52 Message: Logged In: YES user_id=48280 The bug has been fixed; 5.04.2 will have the fix. To make print x work, you need to give x a type signature. eg. let x = error help! :: Int -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=620264group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-620264 ] rdrNameModule it
Bugs item #620264, was opened at 2002-10-08 07:46 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=620264group_id=8032 Category: Compiler Group: 5.04.1 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: rdrNameModule it Initial Comment: Iยดm new in this, and probably this is known... or maybe irrelevant: What Iยดve done: (in Prelude) let x = error help! print x id x print it I did not understand why x isnยดt printed (id x works...), but the serious ghc.exe panic! message after trying to 'print it' told me to report this ^_^ I just went through the manual and tried some lines out of it... system: Win XP version: 5.04.1 GHCi E-Mail: [EMAIL PROTECTED] -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=620264group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-209351 ] deriving show with unboxed types gives nonsense
Bugs item #209351, was opened at 2000-07-12 13:01 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=209351group_id=8032 Category: Compiler (Type checker) Group: None Status: Open Resolution: None Priority: 5 Submitted By: Julian Seward (sewardj) Assigned to: Simon Marlow (simonmar) Summary: deriving show with unboxed types gives nonsense Initial Comment: deriving show with unboxed types gives nonsense -- specifically, a wierd kind error, which doesn't make it clear what the problem is -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=209351group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-617082 ] ghc -O generates faulty c code
Bugs item #617082, was opened at 2002-10-01 17:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=617082group_id=8032 Category: Compiler Group: 5.04 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: ghc -O generates faulty c code Initial Comment: I have the following file: Bug.hs -- module Bug where foo :: Double - Double foo x = x - (-1.0) -- ghc -c -O Bug.hs /tmp/ghc25320.hc: In function `s3Ny_ret': /tmp/ghc25320.hc:14: invalid lvalue in decrement /tmp/ghc25320.hc:14: parse error before `1.0' Cause - The problem is the following generated c snippet _s3Nx_=PK_DBL((W_*)(R1.p+1))--1.0; The two consecutive minuses should be separated by a space. Ulf Norell [EMAIL PROTECTED] -- Comment By: Sven Panne (spanne) Date: 2002-10-03 14:23 Message: Logged In: YES user_id=50298 I've tested it with 5.02.3, 5.04.1 and the CVS HEAD and it works fine in all cases (i.e.the literal is correctly wrapped into parentheses). Which version are you using exactly? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=617082group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-617082 ] ghc -O generates faulty c code
Bugs item #617082, was opened at 2002-10-01 08:47 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=617082group_id=8032 Category: Compiler Group: 5.04 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: ghc -O generates faulty c code Initial Comment: I have the following file: Bug.hs -- module Bug where foo :: Double - Double foo x = x - (-1.0) -- ghc -c -O Bug.hs /tmp/ghc25320.hc: In function `s3Ny_ret': /tmp/ghc25320.hc:14: invalid lvalue in decrement /tmp/ghc25320.hc:14: parse error before `1.0' Cause - The problem is the following generated c snippet _s3Nx_=PK_DBL((W_*)(R1.p+1))--1.0; The two consecutive minuses should be separated by a space. Ulf Norell [EMAIL PROTECTED] -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=617082group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-586934 ] ghc fail build with gcc 3.1
Bugs item #586934, was opened at 2002-07-26 10:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=586934group_id=8032 Category: Compiler Group: 5.04 Status: Open Resolution: None Priority: 5 Submitted By: geoff (snailtalk) Assigned to: Simon Marlow (simonmar) Summary: ghc fail build with gcc 3.1 Initial Comment: ghc will fail to build with newer gcc if -O is given to ghc. Comfirmed with gcc 3.1, and most probably the upcoming 3.2 as well. Prologue junk?: .globl __stginit_Main __stginit_Main: pushl %ebp movl%esp, %ebp is the ghc complaint (looks like a function prologue in ASM). Temporary fix is to compile with -O -fasm. Note that this also means that you will be unable to bootstrap ghc from source if you have a newer gcc installed on your system. Verified on Linux/x86 only. -- Comment By: Duncan Coutts (duncan_coutts) Date: 2002-09-30 12:57 Message: Logged In: YES user_id=36779 I got exactly this error too. I managed to build ghc 5.04 from source using an older binary package of ghc by doing: install an older gcc: rpm -i gcc-2.96 then using some configury (from memory - appologies for mistakes) ./configure --with-hc=''ghc -pgmcgcc-2.96 \ --with-ghc=ghc -pgmcgcc-2.96 \ --with-gcc=gcc-2.96 This was on Mandrake 9.0, which uses gcc 3.2. It would probably work on the new RH 8 too since it provides an older gcc-2.96 too. I'm going to have a go at building ghc to use gcc 3.2 -- Comment By: geoff (snailtalk) Date: 2002-09-18 11:23 Message: Logged In: YES user_id=20846 That would seem to explain things a bit, since it is possible that the Mandrake gcc 3.1 package were using some snapshot of gcc which could have exhibited this problem, and such problem is also present in the current gcc 3.2. -- Comment By: Simon Marlow (simonmar) Date: 2002-09-18 11:01 Message: Logged In: YES user_id=48280 The problem is that the ghc 5.02.3 installed on your machine is using GCC 3.2, and there were some problems with this. In order to bootstrap 5.04, you will need an older GCC installed. After compiling 5.04, you can upgrade GCC again. -- Comment By: geoff (snailtalk) Date: 2002-09-18 10:47 Message: Logged In: YES user_id=20846 Ah, perhaps I should have been a bit clearer. I was trying to build ghc 5.04 on a machine with ghc 5.02.3 installed. Anyway, since cooker is a development distribution, I retried to reproduce this problem with success. Installed gcc is gcc-3.2-1mdk and ghc-5.02.3-2mdk. Note that ghc used to be available in the Mandrake contrib, it is not there anymore because it does not build with the new gcc, so it was possibly removed. The spec file is still in CVS, grab it here: http://cvs.mandrakesoft.com/cgi-bin/cvsweb.cgi/~checkout~/contrib-SPECS/ghc/ghc.spec?rev=1.12content-type=text/plain You can remove the Patch: field in the spec file as it is not necessary to make the problem reproduce. -- Comment By: Simon Marlow (simonmar) Date: 2002-09-18 09:47 Message: Logged In: YES user_id=48280 The original reporter was building 5.02.3; there were several GCC 3.x related fixes that went into 5.04, so I suggest upgrading. I'll take a look at GCC 3.2 and investigate the new warnings. -- Comment By: Matthew Walton (matthewwalton) Date: 2002-09-18 08:49 Message: Logged In: YES user_id=110768 This is happening to me. Gentoo Linux (on x86) built with GCC 3.2 (but not the official 1.4 release using GCC 3.2, I hacked this one together myself), building GHC with GCC 3.2 using the ebuild scripts from Portage. As well as the GHC complaint here, I also see lots of messages from GCC itself apparently complaining about the validity of the HC files I'm bootstrapping from. For example: CTypesISO.hc:20090: warning: (near initialization for `CTypesISO_zdfIntegralCPtrdiff_closure.payload') CTypesISO.hc:20090: warning: excess elements in array initializer I assume this has something to do with GCC 3.2 having differing ideas about what constitutes valid C. I know they're not errors, but they're worth noting, as well as some warnings about excess tokens at the end of #endif. -- Comment By: geoff (snailtalk) Date: 2002-09-07 06:53 Message: Logged In: YES user_id=20846 Linux version is 2.4.18 kernel, Mandrake cooker. (development distribution). gcc installed is gcc 3.2 from Mandrake cooker. ghc is 5.02.3. Note that it appears not to happen under Debian unstable with their gcc3.2.
[ ghc-Bugs-611512 ] ioeGetErrorString
Bugs item #611512, was opened at 2002-09-19 03:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=611512group_id=8032 Category: None Group: 5.04 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: ioeGetErrorString Initial Comment: From my understanding the Haskell reports, ioeGetErrorString should return the failure string. To quote: For user errors (those which are raised using fail), the string returned by ioeGetErrorString is the argument that was passed to fail On version 5.04, compiled under SunOS, ioeGetErrorString seems to return the result of `show`ing this string. Compiling and running: import IO main = fail foo\ngoo `catch` (putStrLn . ioeGetErrorString) results in: foo\ngoo as opposed to: foo goo Thanks, Gordon [EMAIL PROTECTED] -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=611512group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-611512 ] ioeGetErrorString
Bugs item #611512, was opened at 2002-09-19 10:17 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=611512group_id=8032 Category: None Group: 5.04 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: ioeGetErrorString Initial Comment: From my understanding the Haskell reports, ioeGetErrorString should return the failure string. To quote: For user errors (those which are raised using fail), the string returned by ioeGetErrorString is the argument that was passed to fail On version 5.04, compiled under SunOS, ioeGetErrorString seems to return the result of `show`ing this string. Compiling and running: import IO main = fail foo\ngoo `catch` (putStrLn . ioeGetErrorString) results in: foo\ngoo as opposed to: foo goo Thanks, Gordon [EMAIL PROTECTED] -- Comment By: Simon Marlow (simonmar) Date: 2002-09-19 12:37 Message: Logged In: YES user_id=48280 Fixed in 5.04.1. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=611512group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-586934 ] ghc fail build with gcc 3.1
Bugs item #586934, was opened at 2002-07-26 11:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=586934group_id=8032 Category: Compiler Group: 5.04 Status: Open Resolution: None Priority: 5 Submitted By: geoff (snailtalk) Assigned to: Simon Marlow (simonmar) Summary: ghc fail build with gcc 3.1 Initial Comment: ghc will fail to build with newer gcc if -O is given to ghc. Comfirmed with gcc 3.1, and most probably the upcoming 3.2 as well. Prologue junk?: .globl __stginit_Main __stginit_Main: pushl %ebp movl%esp, %ebp is the ghc complaint (looks like a function prologue in ASM). Temporary fix is to compile with -O -fasm. Note that this also means that you will be unable to bootstrap ghc from source if you have a newer gcc installed on your system. Verified on Linux/x86 only. -- Comment By: Matthew Walton (matthewwalton) Date: 2002-09-18 09:49 Message: Logged In: YES user_id=110768 This is happening to me. Gentoo Linux (on x86) built with GCC 3.2 (but not the official 1.4 release using GCC 3.2, I hacked this one together myself), building GHC with GCC 3.2 using the ebuild scripts from Portage. As well as the GHC complaint here, I also see lots of messages from GCC itself apparently complaining about the validity of the HC files I'm bootstrapping from. For example: CTypesISO.hc:20090: warning: (near initialization for `CTypesISO_zdfIntegralCPtrdiff_closure.payload') CTypesISO.hc:20090: warning: excess elements in array initializer I assume this has something to do with GCC 3.2 having differing ideas about what constitutes valid C. I know they're not errors, but they're worth noting, as well as some warnings about excess tokens at the end of #endif. -- Comment By: geoff (snailtalk) Date: 2002-09-07 07:53 Message: Logged In: YES user_id=20846 Linux version is 2.4.18 kernel, Mandrake cooker. (development distribution). gcc installed is gcc 3.2 from Mandrake cooker. ghc is 5.02.3. Note that it appears not to happen under Debian unstable with their gcc3.2. -- Comment By: Simon Marlow (simonmar) Date: 2002-09-02 15:43 Message: Logged In: YES user_id=48280 I've tried to reproduce this and can't. Could you describe *exactly* what you did to cause the error, including: - Linux flavour/version - what version(s) of gcc are installed, under which names - similarly for GHC Thanks. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=586934group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-586934 ] ghc fail build with gcc 3.1
Bugs item #586934, was opened at 2002-07-26 10:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=586934group_id=8032 Category: Compiler Group: 5.04 Status: Open Resolution: None Priority: 5 Submitted By: geoff (snailtalk) Assigned to: Simon Marlow (simonmar) Summary: ghc fail build with gcc 3.1 Initial Comment: ghc will fail to build with newer gcc if -O is given to ghc. Comfirmed with gcc 3.1, and most probably the upcoming 3.2 as well. Prologue junk?: .globl __stginit_Main __stginit_Main: pushl %ebp movl%esp, %ebp is the ghc complaint (looks like a function prologue in ASM). Temporary fix is to compile with -O -fasm. Note that this also means that you will be unable to bootstrap ghc from source if you have a newer gcc installed on your system. Verified on Linux/x86 only. -- Comment By: Simon Marlow (simonmar) Date: 2002-09-18 09:47 Message: Logged In: YES user_id=48280 The original reporter was building 5.02.3; there were several GCC 3.x related fixes that went into 5.04, so I suggest upgrading. I'll take a look at GCC 3.2 and investigate the new warnings. -- Comment By: Matthew Walton (matthewwalton) Date: 2002-09-18 08:49 Message: Logged In: YES user_id=110768 This is happening to me. Gentoo Linux (on x86) built with GCC 3.2 (but not the official 1.4 release using GCC 3.2, I hacked this one together myself), building GHC with GCC 3.2 using the ebuild scripts from Portage. As well as the GHC complaint here, I also see lots of messages from GCC itself apparently complaining about the validity of the HC files I'm bootstrapping from. For example: CTypesISO.hc:20090: warning: (near initialization for `CTypesISO_zdfIntegralCPtrdiff_closure.payload') CTypesISO.hc:20090: warning: excess elements in array initializer I assume this has something to do with GCC 3.2 having differing ideas about what constitutes valid C. I know they're not errors, but they're worth noting, as well as some warnings about excess tokens at the end of #endif. -- Comment By: geoff (snailtalk) Date: 2002-09-07 06:53 Message: Logged In: YES user_id=20846 Linux version is 2.4.18 kernel, Mandrake cooker. (development distribution). gcc installed is gcc 3.2 from Mandrake cooker. ghc is 5.02.3. Note that it appears not to happen under Debian unstable with their gcc3.2. -- Comment By: Simon Marlow (simonmar) Date: 2002-09-02 14:43 Message: Logged In: YES user_id=48280 I've tried to reproduce this and can't. Could you describe *exactly* what you did to cause the error, including: - Linux flavour/version - what version(s) of gcc are installed, under which names - similarly for GHC Thanks. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=586934group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-610569 ] typo: %lt; should be lt;
Bugs item #610569, was opened at 2002-09-17 14:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=610569group_id=8032 Category: Documentation Group: 5.04.1 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: typo: %lt; should be lt; Initial Comment: in the users_guide.pdf, pages 27-28, and in the ghci.html there is %lt; instead of lt; so instead of: stmt we see: %lt;stmt -- Comment By: Simon Marlow (simonmar) Date: 2002-09-18 09:48 Message: Logged In: YES user_id=48280 Fixed, thanks. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=610569group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-609944 ] deriving Read leads to no parse
Bugs item #609944, was opened at 2002-09-16 14:28
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=609944group_id=8032
Category: Compiler
Group: 5.04.1
Status: Closed
Resolution: Fixed
Priority: 7
Submitted By: Manuel M. T. Chakravarty (chak)
Assigned to: Nobody/Anonymous (nobody)
Summary: deriving Read leads to no parse
Initial Comment:
The program
-- Start Offending Program -
module Main
where
data T = C (Maybe Int) Int
deriving (Show, Read, Eq)
main =
do
let v = C Nothing 1
print v
print $ read (show v) == v
-- End Offending Program -
leads to
AttitudeAdjuster chak 5 (~/haskell): ghc Main.hs
AttitudeAdjuster chak 6 (~/haskell): ./a.out
C Nothing 1
Fail: Prelude.read: no parse
AttitudeAdjuster chak 7 (~/haskell):
Experimentation suggests that it is the `Maybe' type
appearing in the type for which Read is derived that
causes the problem. This problem does *not* occur with
GHC 5.04; ie, has been introduced with patchlevel 1.
(I am not sure whether it is a problem in the Prelude
or the deriving mechanism.)
This bug is pretty serious for me, as it utterly breaks
C-Haskell.
/me waits for GHC 5.04.2...
--
Comment By: Simon Marlow (simonmar)
Date: 2002-09-18 09:48
Message:
Logged In: YES
user_id=48280
This has been fixed, but it remains a known bug in 5.04.1.
--
Comment By: Manuel M. T. Chakravarty (chak)
Date: 2002-09-17 07:12
Message:
Logged In: YES
user_id=10359
This bug can be circumvented by using field labels in the
data declaration; ie, in the above example, use
data T = C {a :: (Maybe Int), b :: Int}
(This workaround has been suggested by Tom Moertel.)
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=609944group_id=8032
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-586934 ] ghc fail build with gcc 3.1
Bugs item #586934, was opened at 2002-07-26 10:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=586934group_id=8032 Category: Compiler Group: 5.04 Status: Open Resolution: None Priority: 5 Submitted By: geoff (snailtalk) Assigned to: Simon Marlow (simonmar) Summary: ghc fail build with gcc 3.1 Initial Comment: ghc will fail to build with newer gcc if -O is given to ghc. Comfirmed with gcc 3.1, and most probably the upcoming 3.2 as well. Prologue junk?: .globl __stginit_Main __stginit_Main: pushl %ebp movl%esp, %ebp is the ghc complaint (looks like a function prologue in ASM). Temporary fix is to compile with -O -fasm. Note that this also means that you will be unable to bootstrap ghc from source if you have a newer gcc installed on your system. Verified on Linux/x86 only. -- Comment By: geoff (snailtalk) Date: 2002-09-18 10:47 Message: Logged In: YES user_id=20846 Ah, perhaps I should have been a bit clearer. I was trying to build ghc 5.04 on a machine with ghc 5.02.3 installed. Anyway, since cooker is a development distribution, I retried to reproduce this problem with success. Installed gcc is gcc-3.2-1mdk and ghc-5.02.3-2mdk. Note that ghc used to be available in the Mandrake contrib, it is not there anymore because it does not build with the new gcc, so it was possibly removed. The spec file is still in CVS, grab it here: http://cvs.mandrakesoft.com/cgi-bin/cvsweb.cgi/~checkout~/contrib-SPECS/ghc/ghc.spec?rev=1.12content-type=text/plain You can remove the Patch: field in the spec file as it is not necessary to make the problem reproduce. -- Comment By: Simon Marlow (simonmar) Date: 2002-09-18 09:47 Message: Logged In: YES user_id=48280 The original reporter was building 5.02.3; there were several GCC 3.x related fixes that went into 5.04, so I suggest upgrading. I'll take a look at GCC 3.2 and investigate the new warnings. -- Comment By: Matthew Walton (matthewwalton) Date: 2002-09-18 08:49 Message: Logged In: YES user_id=110768 This is happening to me. Gentoo Linux (on x86) built with GCC 3.2 (but not the official 1.4 release using GCC 3.2, I hacked this one together myself), building GHC with GCC 3.2 using the ebuild scripts from Portage. As well as the GHC complaint here, I also see lots of messages from GCC itself apparently complaining about the validity of the HC files I'm bootstrapping from. For example: CTypesISO.hc:20090: warning: (near initialization for `CTypesISO_zdfIntegralCPtrdiff_closure.payload') CTypesISO.hc:20090: warning: excess elements in array initializer I assume this has something to do with GCC 3.2 having differing ideas about what constitutes valid C. I know they're not errors, but they're worth noting, as well as some warnings about excess tokens at the end of #endif. -- Comment By: geoff (snailtalk) Date: 2002-09-07 06:53 Message: Logged In: YES user_id=20846 Linux version is 2.4.18 kernel, Mandrake cooker. (development distribution). gcc installed is gcc 3.2 from Mandrake cooker. ghc is 5.02.3. Note that it appears not to happen under Debian unstable with their gcc3.2. -- Comment By: Simon Marlow (simonmar) Date: 2002-09-02 14:43 Message: Logged In: YES user_id=48280 I've tried to reproduce this and can't. Could you describe *exactly* what you did to cause the error, including: - Linux flavour/version - what version(s) of gcc are installed, under which names - similarly for GHC Thanks. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=586934group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-586934 ] ghc fail build with gcc 3.1
Bugs item #586934, was opened at 2002-07-26 10:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=586934group_id=8032 Category: Compiler Group: 5.04 Status: Open Resolution: None Priority: 5 Submitted By: geoff (snailtalk) Assigned to: Simon Marlow (simonmar) Summary: ghc fail build with gcc 3.1 Initial Comment: ghc will fail to build with newer gcc if -O is given to ghc. Comfirmed with gcc 3.1, and most probably the upcoming 3.2 as well. Prologue junk?: .globl __stginit_Main __stginit_Main: pushl %ebp movl%esp, %ebp is the ghc complaint (looks like a function prologue in ASM). Temporary fix is to compile with -O -fasm. Note that this also means that you will be unable to bootstrap ghc from source if you have a newer gcc installed on your system. Verified on Linux/x86 only. -- Comment By: Simon Marlow (simonmar) Date: 2002-09-18 11:01 Message: Logged In: YES user_id=48280 The problem is that the ghc 5.02.3 installed on your machine is using GCC 3.2, and there were some problems with this. In order to bootstrap 5.04, you will need an older GCC installed. After compiling 5.04, you can upgrade GCC again. -- Comment By: geoff (snailtalk) Date: 2002-09-18 10:47 Message: Logged In: YES user_id=20846 Ah, perhaps I should have been a bit clearer. I was trying to build ghc 5.04 on a machine with ghc 5.02.3 installed. Anyway, since cooker is a development distribution, I retried to reproduce this problem with success. Installed gcc is gcc-3.2-1mdk and ghc-5.02.3-2mdk. Note that ghc used to be available in the Mandrake contrib, it is not there anymore because it does not build with the new gcc, so it was possibly removed. The spec file is still in CVS, grab it here: http://cvs.mandrakesoft.com/cgi-bin/cvsweb.cgi/~checkout~/contrib-SPECS/ghc/ghc.spec?rev=1.12content-type=text/plain You can remove the Patch: field in the spec file as it is not necessary to make the problem reproduce. -- Comment By: Simon Marlow (simonmar) Date: 2002-09-18 09:47 Message: Logged In: YES user_id=48280 The original reporter was building 5.02.3; there were several GCC 3.x related fixes that went into 5.04, so I suggest upgrading. I'll take a look at GCC 3.2 and investigate the new warnings. -- Comment By: Matthew Walton (matthewwalton) Date: 2002-09-18 08:49 Message: Logged In: YES user_id=110768 This is happening to me. Gentoo Linux (on x86) built with GCC 3.2 (but not the official 1.4 release using GCC 3.2, I hacked this one together myself), building GHC with GCC 3.2 using the ebuild scripts from Portage. As well as the GHC complaint here, I also see lots of messages from GCC itself apparently complaining about the validity of the HC files I'm bootstrapping from. For example: CTypesISO.hc:20090: warning: (near initialization for `CTypesISO_zdfIntegralCPtrdiff_closure.payload') CTypesISO.hc:20090: warning: excess elements in array initializer I assume this has something to do with GCC 3.2 having differing ideas about what constitutes valid C. I know they're not errors, but they're worth noting, as well as some warnings about excess tokens at the end of #endif. -- Comment By: geoff (snailtalk) Date: 2002-09-07 06:53 Message: Logged In: YES user_id=20846 Linux version is 2.4.18 kernel, Mandrake cooker. (development distribution). gcc installed is gcc 3.2 from Mandrake cooker. ghc is 5.02.3. Note that it appears not to happen under Debian unstable with their gcc3.2. -- Comment By: Simon Marlow (simonmar) Date: 2002-09-02 14:43 Message: Logged In: YES user_id=48280 I've tried to reproduce this and can't. Could you describe *exactly* what you did to cause the error, including: - Linux flavour/version - what version(s) of gcc are installed, under which names - similarly for GHC Thanks. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=586934group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-586934 ] ghc fail build with gcc 3.1
Bugs item #586934, was opened at 2002-07-26 10:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=586934group_id=8032 Category: Compiler Group: 5.04 Status: Open Resolution: None Priority: 5 Submitted By: geoff (snailtalk) Assigned to: Simon Marlow (simonmar) Summary: ghc fail build with gcc 3.1 Initial Comment: ghc will fail to build with newer gcc if -O is given to ghc. Comfirmed with gcc 3.1, and most probably the upcoming 3.2 as well. Prologue junk?: .globl __stginit_Main __stginit_Main: pushl %ebp movl%esp, %ebp is the ghc complaint (looks like a function prologue in ASM). Temporary fix is to compile with -O -fasm. Note that this also means that you will be unable to bootstrap ghc from source if you have a newer gcc installed on your system. Verified on Linux/x86 only. -- Comment By: geoff (snailtalk) Date: 2002-09-18 11:23 Message: Logged In: YES user_id=20846 That would seem to explain things a bit, since it is possible that the Mandrake gcc 3.1 package were using some snapshot of gcc which could have exhibited this problem, and such problem is also present in the current gcc 3.2. -- Comment By: Simon Marlow (simonmar) Date: 2002-09-18 11:01 Message: Logged In: YES user_id=48280 The problem is that the ghc 5.02.3 installed on your machine is using GCC 3.2, and there were some problems with this. In order to bootstrap 5.04, you will need an older GCC installed. After compiling 5.04, you can upgrade GCC again. -- Comment By: geoff (snailtalk) Date: 2002-09-18 10:47 Message: Logged In: YES user_id=20846 Ah, perhaps I should have been a bit clearer. I was trying to build ghc 5.04 on a machine with ghc 5.02.3 installed. Anyway, since cooker is a development distribution, I retried to reproduce this problem with success. Installed gcc is gcc-3.2-1mdk and ghc-5.02.3-2mdk. Note that ghc used to be available in the Mandrake contrib, it is not there anymore because it does not build with the new gcc, so it was possibly removed. The spec file is still in CVS, grab it here: http://cvs.mandrakesoft.com/cgi-bin/cvsweb.cgi/~checkout~/contrib-SPECS/ghc/ghc.spec?rev=1.12content-type=text/plain You can remove the Patch: field in the spec file as it is not necessary to make the problem reproduce. -- Comment By: Simon Marlow (simonmar) Date: 2002-09-18 09:47 Message: Logged In: YES user_id=48280 The original reporter was building 5.02.3; there were several GCC 3.x related fixes that went into 5.04, so I suggest upgrading. I'll take a look at GCC 3.2 and investigate the new warnings. -- Comment By: Matthew Walton (matthewwalton) Date: 2002-09-18 08:49 Message: Logged In: YES user_id=110768 This is happening to me. Gentoo Linux (on x86) built with GCC 3.2 (but not the official 1.4 release using GCC 3.2, I hacked this one together myself), building GHC with GCC 3.2 using the ebuild scripts from Portage. As well as the GHC complaint here, I also see lots of messages from GCC itself apparently complaining about the validity of the HC files I'm bootstrapping from. For example: CTypesISO.hc:20090: warning: (near initialization for `CTypesISO_zdfIntegralCPtrdiff_closure.payload') CTypesISO.hc:20090: warning: excess elements in array initializer I assume this has something to do with GCC 3.2 having differing ideas about what constitutes valid C. I know they're not errors, but they're worth noting, as well as some warnings about excess tokens at the end of #endif. -- Comment By: geoff (snailtalk) Date: 2002-09-07 06:53 Message: Logged In: YES user_id=20846 Linux version is 2.4.18 kernel, Mandrake cooker. (development distribution). gcc installed is gcc 3.2 from Mandrake cooker. ghc is 5.02.3. Note that it appears not to happen under Debian unstable with their gcc3.2. -- Comment By: Simon Marlow (simonmar) Date: 2002-09-02 14:43 Message: Logged In: YES user_id=48280 I've tried to reproduce this and can't. Could you describe *exactly* what you did to cause the error, including: - Linux flavour/version - what version(s) of gcc are installed, under which names - similarly for GHC Thanks. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=586934group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED]
[ ghc-Bugs-610569 ] typo: %lt; should be lt;
Bugs item #610569, was opened at 2002-09-17 07:20 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=610569group_id=8032 Category: Documentation Group: 5.04.1 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: typo: %lt; should be lt; Initial Comment: in the users_guide.pdf, pages 27-28, and in the ghci.html there is %lt; instead of lt; so instead of: stmt we see: %lt;stmt -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=610569group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-605164 ] panic: tcSplitTyConApp with rank-2 type
Bugs item #605164, was opened at 2002-09-05 17:37
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=605164group_id=8032
Category: Compiler
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Ken Shan (ccshan)
Assigned to: Nobody/Anonymous (nobody)
Summary: panic: tcSplitTyConApp with rank-2 type
Initial Comment:
The following program causes GHC 5.04 (i386-linux) to
panic:
{-# OPTIONS -fglasgow-exts #-}
module Bug where
newtype Bug s a = Bug a
runBug :: (forall s. Bug s a) - a
runBug (Bug _) = undefined
cruella:~/u/texmacs$ ghc -c Bug.hs
ghc-5.04: panic! (the `impossible' happened, GHC
version 5.04):
tcSplitTyConApp
forall s{-r3V-} :: *. Bug.Bug{-r2-} s{-r3V-} a{-aaA-}
Please report it as a compiler bug to
[EMAIL PROTECTED],
or http://sourceforge.net/projects/ghc/.
Attached is a transcript.
--
Comment By: Simon Peyton Jones (simonpj)
Date: 2002-09-09 14:03
Message:
Logged In: YES
user_id=50165
Fixed thank you. A strange program, though!
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=605164group_id=8032
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-604858 ] GHC's stack blows up
Bugs item #604858, was opened at 2002-09-05 02:41 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=604858group_id=8032 Category: Compiler Group: 5.04 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Henrik Nilsson (nhn) Assigned to: Nobody/Anonymous (nobody) Summary: GHC's stack blows up Initial Comment: When compiling the included file (part of AFrob) with GHC 5.04 under Linux, GHC's stack blows up. I've tried to increase the size up to 20 Mbyte (at which point compilation takes a lng time, and then the stack still blows up), and I've tried all four possible combinations of -O and -fglasgow-exts. The result is the same in all cases. I used variations of the following command: ghc -c -package lang -package posix -package concurrent -i/usr/local/lib/ghc/imports/hgl:/usr/local/lib/ghc/imports/arrow:/usr/local/lib/ghc/imports/afrp:../Common +RTS -K20M -RTS -o RSParser.o RSParser.hs The result I got in all cases was: stack overflow: use +RTS -Ksize to increase it Everything worked fine with GHC 5.02.2: no need for +RTS -Ksize or anything. If you need more context, try the AFRP/AFrob Hacker's pre-release available from www.haskell.org/afrp. All the best, /Henrik -- Henrik Nilsson Yale University [EMAIL PROTECTED] -- Comment By: Simon Marlow (simonmar) Date: 2002-09-05 11:18 Message: Logged In: YES user_id=48280 I managed to compile this with the forthcoming 5.04.1, so I suspect it was another instance of the newtype bug that was causing the compiler to go into an infinite loop. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=604858group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-605164 ] panic: tcSplitTyConApp with rank-2 type
Bugs item #605164, was opened at 2002-09-05 13:37
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=605164group_id=8032
Category: Compiler
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Ken Shan (ccshan)
Assigned to: Nobody/Anonymous (nobody)
Summary: panic: tcSplitTyConApp with rank-2 type
Initial Comment:
The following program causes GHC 5.04 (i386-linux) to
panic:
{-# OPTIONS -fglasgow-exts #-}
module Bug where
newtype Bug s a = Bug a
runBug :: (forall s. Bug s a) - a
runBug (Bug _) = undefined
cruella:~/u/texmacs$ ghc -c Bug.hs
ghc-5.04: panic! (the `impossible' happened, GHC
version 5.04):
tcSplitTyConApp
forall s{-r3V-} :: *. Bug.Bug{-r2-} s{-r3V-} a{-aaA-}
Please report it as a compiler bug to
[EMAIL PROTECTED],
or http://sourceforge.net/projects/ghc/.
Attached is a transcript.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=605164group_id=8032
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-604889 ] Optimizer introduces non-termination
Bugs item #604889, was opened at 2002-09-05 04:54
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=604889group_id=8032
Category: Compiler
Group: 5.04
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: Henrik Nilsson (nhn)
Assigned to: Simon Marlow (simonmar)
Summary: Optimizer introduces non-termination
Initial Comment:
When compiled with GHC 5.04 and optimization turned on
(-O), AFRP's regression tests fail to terminate. When
compiled with -O0, everything works, except that
somewhat dubious C code seems to be generated (see
below).
I've included a version of the regression tests with
as much code as possible commented out, but you may
need the entire AFRP distribution to make progress on
this one. You can get it as part of the AFrob/AFRP
bundle at www.haskell.org/afrp.
In the regression tests, the following logical
conjunction is used to check if all tests succeeded:
allGood = {- arr_tr
comp_tr
-} first_tr
second_tr
laws_tr
loop_tr {-
looplaws_tr
basicsf_tr
evsrc_tr
coc_tr
switch_tr
kswitch_tr
rswitch_tr
pswitch_tr
rpswitch_tr
wfg_tr
accum_tr
delay_tr
der_tr
loopPre_tr
loopIntegral_tr
react_tr
embed_tr
utils_tr
task_tr
-}
With only the code for the tests first, second,
laws, and loop left, and consequently only the
corresponding four boolean test results left in the
above conjunction, the regression tests fail to
terminate when compiled with -O.
However, if I comment out ANY ONE (or more) of the
four boolean result flags from the conjunction above,
the remaining tests do terminate. Thus there does
not appear to be one single test that fails, but
somehow it is the combination of these four tests
that for some reason results in invalid optimizations.
Additionally, when I compile the main module
(testAFRPMain.hs) with no optimization (-O0), I get
the follwing warning:
ghc -c -fglasgow-exts -O -package lang -package
concurrent -i/usr/local/lib/ghc/imports/arrow:../src
-O0 -o testAFRPMain.o testAFRPMain.hs
/tmp/ghc17120.hc:1150: warning: initialization discards
qualifiers from pointer target type
Again, I'm a bit surprised that C code is generated
here? I thought I was using the native code
generator? This is on a Linux x86 platform.
/Henrik
--
Henrik Nilsson
Yale University
[EMAIL PROTECTED]
--
Comment By: Simon Marlow (simonmar)
Date: 2002-09-06 12:53
Message:
Logged In: YES
user_id=48280
This was caused by a bug in the garbage collector, which
has now been fixed. Thanks for the report.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=604889group_id=8032
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-604849 ] Compiling with -O yields broken .hc file
Bugs item #604849, was opened at 2002-09-04 18:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=604849group_id=8032 Category: Compiler Group: 5.04 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Compiling with -O yields broken .hc file Initial Comment: When compiling the attached source file (part of AFrob) with GHC 5.04 under Linux (RH 7.2) and optimizations turned on, an invalid .hc file is generated. I'm actually surprised that there is an .hc file in the first place, since I thought I was using the native code generator? The generated .hc file is also included. The command I use is: ghc -c -fglasgow-exts -O -package lang -package posix -package concurrent -i/usr/local/lib/ghc/imports/hgl:/usr/local/lib/ghc/imports/arrow:/usr/local/lib/ghc/imports/afrp:../Common -keep-hc-files -o RSWorldGeometry.o RSWorldGeometry.hs The error message I get is: RSWorldGeometry.hc: In function `saF6_ret': RSWorldGeometry.hc:79: invalid lvalue in decrement RSWorldGeometry.hc:79: parse error before `5.0' which makes sense if one looks at the C code. The source module and the generated c file are included in the form of a gzipped tar file. If you need the entire context, try our AFRP/AFrob hacker's pre-release available from www.haskell.org/afrp. All the best, /Henrik -- Henrik Nilsson Yale University [EMAIL PROTECTED] -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=604849group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-604889 ] Optimizer introduces non-termination
Bugs item #604889, was opened at 2002-09-05 04:54
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=604889group_id=8032
Category: Compiler
Group: 5.04
Status: Open
Resolution: None
Priority: 5
Submitted By: Henrik Nilsson (nhn)
Assigned to: Nobody/Anonymous (nobody)
Summary: Optimizer introduces non-termination
Initial Comment:
When compiled with GHC 5.04 and optimization turned on
(-O), AFRP's regression tests fail to terminate. When
compiled with -O0, everything works, except that
somewhat dubious C code seems to be generated (see
below).
I've included a version of the regression tests with
as much code as possible commented out, but you may
need the entire AFRP distribution to make progress on
this one. You can get it as part of the AFrob/AFRP
bundle at www.haskell.org/afrp.
In the regression tests, the following logical
conjunction is used to check if all tests succeeded:
allGood = {- arr_tr
comp_tr
-} first_tr
second_tr
laws_tr
loop_tr {-
looplaws_tr
basicsf_tr
evsrc_tr
coc_tr
switch_tr
kswitch_tr
rswitch_tr
pswitch_tr
rpswitch_tr
wfg_tr
accum_tr
delay_tr
der_tr
loopPre_tr
loopIntegral_tr
react_tr
embed_tr
utils_tr
task_tr
-}
With only the code for the tests first, second,
laws, and loop left, and consequently only the
corresponding four boolean test results left in the
above conjunction, the regression tests fail to
terminate when compiled with -O.
However, if I comment out ANY ONE (or more) of the
four boolean result flags from the conjunction above,
the remaining tests do terminate. Thus there does
not appear to be one single test that fails, but
somehow it is the combination of these four tests
that for some reason results in invalid optimizations.
Additionally, when I compile the main module
(testAFRPMain.hs) with no optimization (-O0), I get
the follwing warning:
ghc -c -fglasgow-exts -O -package lang -package
concurrent -i/usr/local/lib/ghc/imports/arrow:../src
-O0 -o testAFRPMain.o testAFRPMain.hs
/tmp/ghc17120.hc:1150: warning: initialization discards
qualifiers from pointer target type
Again, I'm a bit surprised that C code is generated
here? I thought I was using the native code
generator? This is on a Linux x86 platform.
/Henrik
--
Henrik Nilsson
Yale University
[EMAIL PROTECTED]
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=604889group_id=8032
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-604849 ] Compiling with -O yields broken .hc file
Bugs item #604849, was opened at 2002-09-05 01:45 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=604849group_id=8032 Category: Compiler Group: 5.04 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Compiling with -O yields broken .hc file Initial Comment: When compiling the attached source file (part of AFrob) with GHC 5.04 under Linux (RH 7.2) and optimizations turned on, an invalid .hc file is generated. I'm actually surprised that there is an .hc file in the first place, since I thought I was using the native code generator? The generated .hc file is also included. The command I use is: ghc -c -fglasgow-exts -O -package lang -package posix -package concurrent -i/usr/local/lib/ghc/imports/hgl:/usr/local/lib/ghc/imports/arrow:/usr/local/lib/ghc/imports/afrp:../Common -keep-hc-files -o RSWorldGeometry.o RSWorldGeometry.hs The error message I get is: RSWorldGeometry.hc: In function `saF6_ret': RSWorldGeometry.hc:79: invalid lvalue in decrement RSWorldGeometry.hc:79: parse error before `5.0' which makes sense if one looks at the C code. The source module and the generated c file are included in the form of a gzipped tar file. If you need the entire context, try our AFRP/AFrob hacker's pre-release available from www.haskell.org/afrp. All the best, /Henrik -- Henrik Nilsson Yale University [EMAIL PROTECTED] -- Comment By: Simon Marlow (simonmar) Date: 2002-09-05 10:25 Message: Logged In: YES user_id=48280 Fixed, thanks for the report. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=604849group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-502321 ] tmp file not found after ghci :reload
Bugs item #502321, was opened at 2002-01-11 14:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=502321group_id=8032 Category: Compiler Group: 5.02 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Mike Sperber (sperber) Assigned to: Simon Marlow (simonmar) Summary: tmp file not found after ghci :reload Initial Comment: In ghci, I often see this: Main :reload Compiling HsParser ( flhsparser/HsParser.hs, interpreted ) *** Exception: does not exist Action: openFile Reason: No such file or directory File: /tmp/ghc42863.hspp This was present in 5.02.1 and still is in 5.02.2. -- Comment By: Simon Marlow (simonmar) Date: 2002-09-02 14:39 Message: Logged In: YES user_id=48280 Fixed (rev. 1.115 of ghc/compiler/compMan/CompManager.lhs) -- Comment By: Simon Marlow (simonmar) Date: 2002-07-02 14:07 Message: Logged In: YES user_id=48280 Bug re-opened. Has anyone else seen this? I'm still stumped. -- Comment By: Mike Sperber (sperber) Date: 2002-07-02 13:50 Message: Logged In: YES user_id=43931 No, there's definitely nothing being removed behind GHCi's back. (I could tell a long story about how I know. For lack of space, I'll say that I know. Definitely.) -- Comment By: Simon Marlow (simonmar) Date: 2002-07-02 11:21 Message: Logged In: YES user_id=48280 No bug found (we believe that the /tmp file is being removed behind GHCi's back). GHCi should recover more gracefully but it's low down the priority list. -- Comment By: Simon Marlow (simonmar) Date: 2002-02-27 16:35 Message: Logged In: YES user_id=48280 Do you by any chance have a cron job that periodically cleans old files from /tmp? It sounds like these files are getting removed behind GHCi's back. Nevertheless, I suppose GHCi should recover gracefully since it's only the preprocessed file being cached in /tmp. I'll look into it. -- Comment By: Mike Sperber (sperber) Date: 2002-02-27 16:11 Message: Logged In: YES user_id=43931 Unfortunately, it happens spuriously. But if I keep a session open long enough (between 10 minutes and 2 hours) it happens inevitably. For the record, this is on FreeBSD 4.3. -- Comment By: Simon Marlow (simonmar) Date: 2002-02-27 15:49 Message: Logged In: YES user_id=48280 I can't repeat this bug. Can you give any more information? Is there a repeatable example or does it just happen randomly? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=502321group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-586934 ] ghc fail build with gcc 3.1
Bugs item #586934, was opened at 2002-07-26 10:32 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=586934group_id=8032 Category: Compiler Group: 5.04 Status: Open Resolution: None Priority: 5 Submitted By: geoff (snailtalk) Assigned to: Simon Marlow (simonmar) Summary: ghc fail build with gcc 3.1 Initial Comment: ghc will fail to build with newer gcc if -O is given to ghc. Comfirmed with gcc 3.1, and most probably the upcoming 3.2 as well. Prologue junk?: .globl __stginit_Main __stginit_Main: pushl %ebp movl%esp, %ebp is the ghc complaint (looks like a function prologue in ASM). Temporary fix is to compile with -O -fasm. Note that this also means that you will be unable to bootstrap ghc from source if you have a newer gcc installed on your system. Verified on Linux/x86 only. -- Comment By: Simon Marlow (simonmar) Date: 2002-09-02 14:43 Message: Logged In: YES user_id=48280 I've tried to reproduce this and can't. Could you describe *exactly* what you did to cause the error, including: - Linux flavour/version - what version(s) of gcc are installed, under which names - similarly for GHC Thanks. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=586934group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-575999 ] Array operations in LazyST gone in 5.03
Bugs item #575999, was opened at 2002-07-01 07:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=575999group_id=8032 Category: hslibs/lang Group: 5.02 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Array operations in LazyST gone in 5.03 Initial Comment: In the snapshot of 5.03 the module LazyST does not implement array operations anymore. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=575999group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-502321 ] tmp file not found after ghci :reload
Bugs item #502321, was opened at 2002-01-11 14:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=502321group_id=8032 Category: Compiler Group: 5.02 Status: Closed Resolution: None Priority: 5 Submitted By: Mike Sperber (sperber) Assigned to: Simon Marlow (simonmar) Summary: tmp file not found after ghci :reload Initial Comment: In ghci, I often see this: Main :reload Compiling HsParser ( flhsparser/HsParser.hs, interpreted ) *** Exception: does not exist Action: openFile Reason: No such file or directory File: /tmp/ghc42863.hspp This was present in 5.02.1 and still is in 5.02.2. -- Comment By: Simon Marlow (simonmar) Date: 2002-07-02 11:21 Message: Logged In: YES user_id=48280 No bug found (we believe that the /tmp file is being removed behind GHCi's back). GHCi should recover more gracefully but it's low down the priority list. -- Comment By: Simon Marlow (simonmar) Date: 2002-02-27 16:35 Message: Logged In: YES user_id=48280 Do you by any chance have a cron job that periodically cleans old files from /tmp? It sounds like these files are getting removed behind GHCi's back. Nevertheless, I suppose GHCi should recover gracefully since it's only the preprocessed file being cached in /tmp. I'll look into it. -- Comment By: Mike Sperber (sperber) Date: 2002-02-27 16:11 Message: Logged In: YES user_id=43931 Unfortunately, it happens spuriously. But if I keep a session open long enough (between 10 minutes and 2 hours) it happens inevitably. For the record, this is on FreeBSD 4.3. -- Comment By: Simon Marlow (simonmar) Date: 2002-02-27 15:49 Message: Logged In: YES user_id=48280 I can't repeat this bug. Can you give any more information? Is there a repeatable example or does it just happen randomly? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=502321group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-537295 ] div 0 0 give exception / endless loop
Bugs item #537295, was opened at 2002-03-31 01:36 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=537295group_id=8032 Category: Runtime System Group: 5.02 Status: Closed Resolution: Fixed Priority: 5 Submitted By: geoff (snailtalk) Assigned to: Simon Marlow (simonmar) Summary: div 0 0 give exception / endless loop Initial Comment: There is a problem with the div in ghc, to reproduce: start ghci and type div n 0 where n is any integer (so div 3 0 would work) on a linux box it gives a floating point exception while on a BSD 4.4 box it gives and endless loop using about 87 % of cpu. I have verified this on both the latest release (5.02.2) and 5.02.1. -- Comment By: Simon Marlow (simonmar) Date: 2002-07-02 11:30 Message: Logged In: YES user_id=48280 Fixed by not ignoring SIGFPE. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=537295group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-564616 ] filterPS fails if 255 chs. after match
Bugs item #564616, was opened at 2002-06-04 22:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=564616group_id=8032 Category: hslibs/lang Group: 5.02 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Mike Gunter (magunter) Assigned to: Simon Marlow (simonmar) Summary: filterPS fails if 255 chs. after match Initial Comment: I applied the fix for bug 563651 to revision 1.11 (the one in 5.02.3) of PackedString.lhs. With this, the following program: import System ( getArgs ) import PackedString ( filterPS, packString ) main = System.getArgs = realMain realMain [oldOrNew,c:[]] = print $ filterPS (c ==) (packString str) where str = case oldOrNew of old - ys ++ abcs new - abcs ++ ys where (abcs, ys) = (abcdef,replicate 252 'y') will segmentation fault when given arguments [new,a], [new,b], or [new,c]. Things work as expect with any other character argument x in [new,x]. PackedString.lhs without the fix for bug 563651 works fine in these cases (but fails with [old,d], etc.) This is 5.02.3 with the fix for bug 563651 applied to PackedString.lhs on Debian x86. thanks, mike -- Comment By: Simon Marlow (simonmar) Date: 2002-07-02 11:34 Message: Logged In: YES user_id=48280 Fixed in the rewritten version of PackedString in 5.04. (available as Data.PackedString). -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=564616group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-546756 ] Finalisation in withSocketsDo
Bugs item #546756, was opened at 2002-04-21 13:29 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=546756group_id=8032 Category: hslibs/net Group: 5.02 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Simon Marlow (simonmar) Summary: Finalisation in withSocketsDo Initial Comment: I'm using GHC 5.02.2, but I believe this comment still applies. While debugging my socket-using program on a Win98 machine my DNS (or some related part of networking assembly) appears to die after having my custom application throw an exception. I think the following change will fix this: Replace in Network.Socket module: withSocketsDo act = do x - initWinSock if ( x /= 0 ) then ioError (userError Failed to initialise WinSock) else do v - act shutdownWinSock return v ...with... withSocketsDo act = do x - initWinSock if ( x /= 0 ) then ioError (userError Failed to initialise WinSock) else act `finally` shutdownWinSock I cannot guarantee that this is the solution to my problem, but when I catch all exceptions within the body of the argument IO action the DNS problem does not arise. Also I doubt the exception utility function finally is within scope, this is simply the clearest way to write my fix :) Keep up the good work! -- Comment By: Simon Marlow (simonmar) Date: 2002-07-02 11:39 Message: Logged In: YES user_id=48280 Fix applied; thanks! -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=546756group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-502321 ] tmp file not found after ghci :reload
Bugs item #502321, was opened at 2002-01-11 14:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=502321group_id=8032 Category: Compiler Group: 5.02 Status: Closed Resolution: None Priority: 5 Submitted By: Mike Sperber (sperber) Assigned to: Simon Marlow (simonmar) Summary: tmp file not found after ghci :reload Initial Comment: In ghci, I often see this: Main :reload Compiling HsParser ( flhsparser/HsParser.hs, interpreted ) *** Exception: does not exist Action: openFile Reason: No such file or directory File: /tmp/ghc42863.hspp This was present in 5.02.1 and still is in 5.02.2. -- Comment By: Mike Sperber (sperber) Date: 2002-07-02 13:50 Message: Logged In: YES user_id=43931 No, there's definitely nothing being removed behind GHCi's back. (I could tell a long story about how I know. For lack of space, I'll say that I know. Definitely.) -- Comment By: Simon Marlow (simonmar) Date: 2002-07-02 11:21 Message: Logged In: YES user_id=48280 No bug found (we believe that the /tmp file is being removed behind GHCi's back). GHCi should recover more gracefully but it's low down the priority list. -- Comment By: Simon Marlow (simonmar) Date: 2002-02-27 16:35 Message: Logged In: YES user_id=48280 Do you by any chance have a cron job that periodically cleans old files from /tmp? It sounds like these files are getting removed behind GHCi's back. Nevertheless, I suppose GHCi should recover gracefully since it's only the preprocessed file being cached in /tmp. I'll look into it. -- Comment By: Mike Sperber (sperber) Date: 2002-02-27 16:11 Message: Logged In: YES user_id=43931 Unfortunately, it happens spuriously. But if I keep a session open long enough (between 10 minutes and 2 hours) it happens inevitably. For the record, this is on FreeBSD 4.3. -- Comment By: Simon Marlow (simonmar) Date: 2002-02-27 15:49 Message: Logged In: YES user_id=48280 I can't repeat this bug. Can you give any more information? Is there a repeatable example or does it just happen randomly? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=502321group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-502321 ] tmp file not found after ghci :reload
Bugs item #502321, was opened at 2002-01-11 14:23 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=502321group_id=8032 Category: Compiler Group: 5.02 Status: Open Resolution: None Priority: 5 Submitted By: Mike Sperber (sperber) Assigned to: Simon Marlow (simonmar) Summary: tmp file not found after ghci :reload Initial Comment: In ghci, I often see this: Main :reload Compiling HsParser ( flhsparser/HsParser.hs, interpreted ) *** Exception: does not exist Action: openFile Reason: No such file or directory File: /tmp/ghc42863.hspp This was present in 5.02.1 and still is in 5.02.2. -- Comment By: Simon Marlow (simonmar) Date: 2002-07-02 14:07 Message: Logged In: YES user_id=48280 Bug re-opened. Has anyone else seen this? I'm still stumped. -- Comment By: Mike Sperber (sperber) Date: 2002-07-02 13:50 Message: Logged In: YES user_id=43931 No, there's definitely nothing being removed behind GHCi's back. (I could tell a long story about how I know. For lack of space, I'll say that I know. Definitely.) -- Comment By: Simon Marlow (simonmar) Date: 2002-07-02 11:21 Message: Logged In: YES user_id=48280 No bug found (we believe that the /tmp file is being removed behind GHCi's back). GHCi should recover more gracefully but it's low down the priority list. -- Comment By: Simon Marlow (simonmar) Date: 2002-02-27 16:35 Message: Logged In: YES user_id=48280 Do you by any chance have a cron job that periodically cleans old files from /tmp? It sounds like these files are getting removed behind GHCi's back. Nevertheless, I suppose GHCi should recover gracefully since it's only the preprocessed file being cached in /tmp. I'll look into it. -- Comment By: Mike Sperber (sperber) Date: 2002-02-27 16:11 Message: Logged In: YES user_id=43931 Unfortunately, it happens spuriously. But if I keep a session open long enough (between 10 minutes and 2 hours) it happens inevitably. For the record, this is on FreeBSD 4.3. -- Comment By: Simon Marlow (simonmar) Date: 2002-02-27 15:49 Message: Logged In: YES user_id=48280 I can't repeat this bug. Can you give any more information? Is there a repeatable example or does it just happen randomly? -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=502321group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-493621 ] ghc won't #include from .lhs
Bugs item #493621, was opened at 2001-12-15 11:04
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=493621group_id=8032
Category: Compiler (FFI)
Group: 5.02
Status: Closed
Resolution: None
Priority: 5
Submitted By: Volker Stolz (volkersf)
Assigned to: Nobody/Anonymous (nobody)
Summary: ghc won't #include from .lhs
Initial Comment:
I just found out the hard way that the following does not work:
1)
Write a .hsc using \begin{code}-\end{code} which contains
#include foo.h and calls a function which is prototyped in
foo.h
2) Run this through hsc2hc -o foo.lhs foo.hsc
3) Compile
with ghc: You're prototypes are missing, somehow the include has
been lost :-/
Using plain .hs works.
Solution: Don't use
literate Haskell for .hsc, I haven't checked with bird-tracks,
though, but I suspect the same will happen. I guess that's why it is
called hsc2hs and not hsc2lhs...
--
Comment By: Simon Marlow (simonmar)
Date: 2002-07-02 16:34
Message:
Logged In: YES
user_id=48280
hsc2hs doesn't support literate Haskell input at the moment.
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=108032aid=493621group_id=8032
___
Glasgow-haskell-bugs mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-575999 ] Array operations in LazyST gone in 5.03
Bugs item #575999, was opened at 2002-07-01 14:59 You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=575999group_id=8032 Category: hslibs/lang Group: 5.02 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Array operations in LazyST gone in 5.03 Initial Comment: In the snapshot of 5.03 the module LazyST does not implement array operations anymore. -- Comment By: Simon Marlow (simonmar) Date: 2002-07-02 16:36 Message: Logged In: YES user_id=48280 These will be back in 5.04, thanks for the report. -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=575999group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-561809 ] Read for Arrays does not work
Bugs item #561809, was opened at 2002-05-29 05:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=108032aid=561809group_id=8032 Category: hslibs/lang Group: 5.02 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Read for Arrays does not work Initial Comment: In hugs I can go: Array read (show (array (1,1) [(1,42)])) :: Array Int Int array (1,1) [(1,42)] whereas ghc gives me: Main read (show (array (1,1) [(1,42)])) :: Array Int Int interactive:1: No instance for (Read (Array Int Int)) arising from use of `read' at interactive:1 In an expression with a type signature: read (show (array (1, 1) [(1, 42)])) :: Array Int Int In the definition of `it': read (show (array (1, 1) [(1, 42)])) :: Array Int Int The Haskell Library Report 98 says Read should be defined for Array a b, with (Read a, Ix a, Read b) -- Comment By: Simon Peyton Jones (simonpj) Date: 2002-06-07 16:21 Message: Logged In: YES user_id=50165 Fixed, thank you -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=108032aid=561809group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-564616 ] filterPS fails if 255 chs. after match
Bugs item #564616, was opened at 2002-06-04 22:29 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=108032aid=564616group_id=8032 Category: hslibs/lang Group: 5.02 Status: Open Resolution: None Priority: 5 Submitted By: Mike Gunter (magunter) Assigned to: Nobody/Anonymous (nobody) Summary: filterPS fails if 255 chs. after match Initial Comment: I applied the fix for bug 563651 to revision 1.11 (the one in 5.02.3) of PackedString.lhs. With this, the following program: import System ( getArgs ) import PackedString ( filterPS, packString ) main = System.getArgs = realMain realMain [oldOrNew,c:[]] = print $ filterPS (c ==) (packString str) where str = case oldOrNew of old - ys ++ abcs new - abcs ++ ys where (abcs, ys) = (abcdef,replicate 252 'y') will segmentation fault when given arguments [new,a], [new,b], or [new,c]. Things work as expect with any other character argument x in [new,x]. PackedString.lhs without the fix for bug 563651 works fine in these cases (but fails with [old,d], etc.) This is 5.02.3 with the fix for bug 563651 applied to PackedString.lhs on Debian x86. thanks, mike -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=108032aid=564616group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-563651 ] filterPS fails if skips 255 characters
Bugs item #563651, was opened at 2002-06-02 23:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=108032aid=563651group_id=8032 Category: hslibs/lang Group: 5.02 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Mike Gunter (magunter) Assigned to: Sven Panne (spanne) Summary: filterPS fails if skips 255 characters Initial Comment: The following program: import System ( getArgs ) import PackedString ( filterPS, packString ) main = System.getArgs = realMain realMain [c:[]] = print $ filterPS (c ==) (packString str) where str = replicate 252 'y' ++ abcdef will segmentation fault if given [d], [e], or [f] as it's arguments. Things work as expect with any other argument. Similarly, GHCi segmentation faults when you try to evaluate realMain [d], etc. This is 5.02.3 on Debian x86. thanks, mike -- Comment By: Sven Panne (spanne) Date: 2002-06-03 19:47 Message: Logged In: YES user_id=50298 Thanks, fixed. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=108032aid=563651group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-563651 ] filterPS fails if skips 255 characters
Bugs item #563651, was opened at 2002-06-02 21:37 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=108032aid=563651group_id=8032 Category: hslibs/lang Group: 5.02 Status: Open Resolution: None Priority: 5 Submitted By: Mike Gunter (magunter) Assigned to: Nobody/Anonymous (nobody) Summary: filterPS fails if skips 255 characters Initial Comment: The following program: import System ( getArgs ) import PackedString ( filterPS, packString ) main = System.getArgs = realMain realMain [c:[]] = print $ filterPS (c ==) (packString str) where str = replicate 252 'y' ++ abcdef will segmentation fault if given [d], [e], or [f] as it's arguments. Things work as expect with any other argument. Similarly, GHCi segmentation faults when you try to evaluate realMain [d], etc. This is 5.02.3 on Debian x86. thanks, mike -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=108032aid=563651group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-559987 ] accept does reverse DNS lookup
Bugs item #559987, was opened at 2002-05-24 07:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=108032aid=559987group_id=8032 Category: hslibs/net Group: 5.02 Status: Closed Resolution: Fixed Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: accept does reverse DNS lookup Initial Comment: If accept gets a connection where the connecting machine cannot be found via a reverse DNS lookup, it throws an exception. I noticed this when I tried connecting to a server made with GHC from inside a network that has real IP numbers but no reverse DNS entries, and have had reports of the same problems from inside similar networks. If I disable the server's DNS lookups, connections fail from everywhere. This is the exception: exception during accept: does not exist Action: getHostByAddr Reason: no such host entry I'm fairly sure this isn't an OS quirk, since the machine I'm testing on runs lots of other services that don't have this problem, it seems to be a problem for GHC servers. As you can see from this snippet: aResult - try (accept s) case aResult of Right (h,_,port) - do pid - forkIO (do c1 - takeMVar cc if c1 == 0 then takeMVar l else return () putMVar cc (c1 + 1) handler state h c2 - takeMVar cc if c2 == 1 then putMVar l () else return () putMVar cc (c2-1)) return () Left e - do --DEBUG putStrLn (exception during accept: ++ show e) return () I never actually demand the connecting host name, so I would hope the lookup wouldn't happen I'm testing on a RH 7.1 x86, with the GHC 5.02. Sample code attached -- Comment By: Simon Marlow (simonmar) Date: 2002-05-28 10:07 Message: Logged In: YES user_id=48280 I think the solution to this problem is just to document the behaviour - Socket.accept does return a HostName, so it has to do a reverse lookup. There is a wider issue, namely whether the interface presented by Socket is really the Right Thing, but that debate should be had on the mailing list ([EMAIL PROTECTED]?). -- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-27 12:52 Message: Logged In: NO Thank you for the work-around, using SocketPrim and doing the socket - bind - accept at that level works fine. -- Comment By: Volker Stolz (volkersf) Date: 2002-05-26 07:02 Message: Logged In: YES user_id=126328 You can work around this by using SocketPrim.accept, take a look at Socket.lhs on how it is used there. Maybe the corresponding error should be caught inside Socket and the tuple be changed to 'Maybe HostEntry'? OTOH Socket (now Network) has always been rather high-level with funny things like 'recvFrom', so for practical purposes, you'd end up using SocketPrim anyway. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=108032aid=559987group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-561809 ] Read for Arrays does not work
Bugs item #561809, was opened at 2002-05-28 22:12 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=108032aid=561809group_id=8032 Category: hslibs/lang Group: 5.02 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: Read for Arrays does not work Initial Comment: In hugs I can go: Array read (show (array (1,1) [(1,42)])) :: Array Int Int array (1,1) [(1,42)] whereas ghc gives me: Main read (show (array (1,1) [(1,42)])) :: Array Int Int interactive:1: No instance for (Read (Array Int Int)) arising from use of `read' at interactive:1 In an expression with a type signature: read (show (array (1, 1) [(1, 42)])) :: Array Int Int In the definition of `it': read (show (array (1, 1) [(1, 42)])) :: Array Int Int The Haskell Library Report 98 says Read should be defined for Array a b, with (Read a, Ix a, Read b) -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=108032aid=561809group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-559987 ] accept does reverse DNS lookup
Bugs item #559987, was opened at 2002-05-24 00:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=108032aid=559987group_id=8032 Category: hslibs/net Group: 5.02 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: accept does reverse DNS lookup Initial Comment: If accept gets a connection where the connecting machine cannot be found via a reverse DNS lookup, it throws an exception. I noticed this when I tried connecting to a server made with GHC from inside a network that has real IP numbers but no reverse DNS entries, and have had reports of the same problems from inside similar networks. If I disable the server's DNS lookups, connections fail from everywhere. This is the exception: exception during accept: does not exist Action: getHostByAddr Reason: no such host entry I'm fairly sure this isn't an OS quirk, since the machine I'm testing on runs lots of other services that don't have this problem, it seems to be a problem for GHC servers. As you can see from this snippet: aResult - try (accept s) case aResult of Right (h,_,port) - do pid - forkIO (do c1 - takeMVar cc if c1 == 0 then takeMVar l else return () putMVar cc (c1 + 1) handler state h c2 - takeMVar cc if c2 == 1 then putMVar l () else return () putMVar cc (c2-1)) return () Left e - do --DEBUG putStrLn (exception during accept: ++ show e) return () I never actually demand the connecting host name, so I would hope the lookup wouldn't happen I'm testing on a RH 7.1 x86, with the GHC 5.02. Sample code attached -- Comment By: Nobody/Anonymous (nobody) Date: 2002-05-27 05:52 Message: Logged In: NO Thank you for the work-around, using SocketPrim and doing the socket - bind - accept at that level works fine. -- Comment By: Volker Stolz (volkersf) Date: 2002-05-26 00:02 Message: Logged In: YES user_id=126328 You can work around this by using SocketPrim.accept, take a look at Socket.lhs on how it is used there. Maybe the corresponding error should be caught inside Socket and the tuple be changed to 'Maybe HostEntry'? OTOH Socket (now Network) has always been rather high-level with funny things like 'recvFrom', so for practical purposes, you'd end up using SocketPrim anyway. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=108032aid=559987group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-559987 ] accept does reverse DNS lookup
Bugs item #559987, was opened at 2002-05-24 09:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=108032aid=559987group_id=8032 Category: hslibs/net Group: 5.02 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: accept does reverse DNS lookup Initial Comment: If accept gets a connection where the connecting machine cannot be found via a reverse DNS lookup, it throws an exception. I noticed this when I tried connecting to a server made with GHC from inside a network that has real IP numbers but no reverse DNS entries, and have had reports of the same problems from inside similar networks. If I disable the server's DNS lookups, connections fail from everywhere. This is the exception: exception during accept: does not exist Action: getHostByAddr Reason: no such host entry I'm fairly sure this isn't an OS quirk, since the machine I'm testing on runs lots of other services that don't have this problem, it seems to be a problem for GHC servers. As you can see from this snippet: aResult - try (accept s) case aResult of Right (h,_,port) - do pid - forkIO (do c1 - takeMVar cc if c1 == 0 then takeMVar l else return () putMVar cc (c1 + 1) handler state h c2 - takeMVar cc if c2 == 1 then putMVar l () else return () putMVar cc (c2-1)) return () Left e - do --DEBUG putStrLn (exception during accept: ++ show e) return () I never actually demand the connecting host name, so I would hope the lookup wouldn't happen I'm testing on a RH 7.1 x86, with the GHC 5.02. Sample code attached -- Comment By: Volker Stolz (volkersf) Date: 2002-05-26 09:02 Message: Logged In: YES user_id=126328 You can work around this by using SocketPrim.accept, take a look at Socket.lhs on how it is used there. Maybe the corresponding error should be caught inside Socket and the tuple be changed to 'Maybe HostEntry'? OTOH Socket (now Network) has always been rather high-level with funny things like 'recvFrom', so for practical purposes, you'd end up using SocketPrim anyway. -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=108032aid=559987group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-559987 ] accept does reverse DNS lookup
Bugs item #559987, was opened at 2002-05-24 00:40 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=108032aid=559987group_id=8032 Category: hslibs/net Group: 5.02 Status: Open Resolution: None Priority: 5 Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: accept does reverse DNS lookup Initial Comment: If accept gets a connection where the connecting machine cannot be found via a reverse DNS lookup, it throws an exception. I noticed this when I tried connecting to a server made with GHC from inside a network that has real IP numbers but no reverse DNS entries, and have had reports of the same problems from inside similar networks. If I disable the server's DNS lookups, connections fail from everywhere. This is the exception: exception during accept: does not exist Action: getHostByAddr Reason: no such host entry I'm fairly sure this isn't an OS quirk, since the machine I'm testing on runs lots of other services that don't have this problem, it seems to be a problem for GHC servers. As you can see from this snippet: aResult - try (accept s) case aResult of Right (h,_,port) - do pid - forkIO (do c1 - takeMVar cc if c1 == 0 then takeMVar l else return () putMVar cc (c1 + 1) handler state h c2 - takeMVar cc if c2 == 1 then putMVar l () else return () putMVar cc (c2-1)) return () Left e - do --DEBUG putStrLn (exception during accept: ++ show e) return () I never actually demand the connecting host name, so I would hope the lookup wouldn't happen I'm testing on a RH 7.1 x86, with the GHC 5.02. Sample code attached -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=108032aid=559987group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[ ghc-Bugs-529156 ] Win32 - error on long cmdline with ghci
Bugs item #529156, was opened at 2002-03-12 14:24 You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=108032aid=529156group_id=8032 Category: Compiler Group: 5.02 Status: Closed Resolution: None Priority: 5 Submitted By: Marcus Lindblom (fizzgig) Assigned to: Nobody/Anonymous (nobody) Summary: Win32 - error on long cmdline with ghci Initial Comment: I reported this bug for 5.00 too, and it seems to have stuck. ghci -syslib lang -syslib data -syslib text Main gives: c:\PROGRA~1\GLASGO~1\ghc-5.02\bin\ghc.exe: file `รก?F' does not exist starting ghc with the same arguments (+ --make) works, however. -- Comment By: Marcus Lindblom (fizzgig) Date: 2002-05-17 03:21 Message: Logged In: YES user_id=197414 There was something wrong with my install. ghci.exe was 3584 bytes. I installed 5.02.3 recently and can't repeat the bug. Sorry about occupying your time with this. -- Comment By: Sigbjorn Finne (sigbjorn) Date: 2002-04-08 08:04 Message: Logged In: YES user_id=232905 ghci.exe is just a wrapper, so the --version string is really that of the compiler proper (ghc.exe) Could you check your PATH that you've only got one ghci.exe and that it is 5.02.2's (which is 12637 bytes long)? The creation dates of ghc.exe and ghci.exe ought to be identical too -- if not, something's amiss with your install. Sorry if I appear to be stalling accepting this as a bug, but I'd like to make sure first that this isn't just a local version mismatch problem. -- Comment By: Marcus Lindblom (fizzgig) Date: 2002-04-07 16:21 Message: Logged In: YES user_id=197414 ghci --version says 5.02. also ghci -syslib lang -syslib data -fglasgow-exts gives an access violation. -- Comment By: Sigbjorn Finne (sigbjorn) Date: 2002-03-27 08:20 Message: Logged In: YES user_id=232905 I'm unable to reproduce this. Could you verify that the 'ghci.exe' that's being invoked is 5.02(.2?)'s and not 5.00's? -- You can respond by visiting: http://sourceforge.net/tracker/?func=detailatid=108032aid=529156group_id=8032 ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
