[ 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
RE: ghc-5.02.3: fatal error: getStablePtr: too light
I'm sporadically seeing the following error: ghc-5.02.3: fatal error: getStablePtr: too light Any ideas what it means or how to avoid it? I'm running on Linux. This is fixed in 5.04. I believe it was triggered by making too many stable pointers to the same object. Cheers, Simon ___ 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
External Core typechecker
GHC doesn't seem to do much typechecking on external Core files; it happily compiles .hcr files with type errors that then segfault when you run the program. An example of such a program is attached (the type error is on line 19, where cons is applied to the Integer type and two integer lists). I'm using the latest version of GHC (built from CVS sources yesterday, using GHC 5.04 to bootstrap), on a RedHat Linux box with gcc 2.96. -- Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
External Core typechecker
[ oops, forgot to include the attachment in the last message; it's also
copied here as text ]
%module Main
%rec
{main1 :: GHCziPrim.ZLzmzgZR
(GHCziPrim.Statezh GHCziPrim.RealWorld)
(GHCziPrim.Z2H
(GHCziPrim.Statezh GHCziPrim.RealWorld)
GHCziBase.Z0T) =
%let %rec
{x :: GHCziNum.Integer = lit;
x1 :: GHCziNum.Integer = x}
%in %let %rec
{y :: GHCziBase.ZMZN GHCziNum.Integer =
GHCziBase.zdwZC @ GHCziNum.Integer lit1
(GHCziBase.zdwZC @ GHCziNum.Integer lit2
(GHCziBase.zdwZC @ GHCziNum.Integer lit3
(GHCziBase.zdwZMZN @ GHCziNum.Integer)));
y1 :: GHCziBase.ZMZN GHCziNum.Integer = y}
%in SystemziIO.putStrLn
(show (GHCziBase.ZC @ GHCziNum.Integer y1 y1));
main :: GHCziPrim.ZLzmzgZR
(GHCziPrim.Statezh GHCziPrim.RealWorld)
(GHCziPrim.Z2H
(GHCziPrim.Statezh GHCziPrim.RealWorld)
GHCziBase.Z0T) =
main1;
lit :: GHCziNum.Integer =
fromInteger (GHCziNum.zdwSzh (5::GHCziPrim.Intzh));
fromInteger :: GHCziPrim.ZLzmzgZR
GHCziNum.Integer
GHCziNum.Integer =
GHCziNum.fromInteger @ GHCziNum.Integer zddNum;
lit1 :: GHCziNum.Integer =
fromInteger1 (GHCziNum.zdwSzh (1::GHCziPrim.Intzh));
fromInteger1 :: GHCziPrim.ZLzmzgZR
GHCziNum.Integer
GHCziNum.Integer =
fromInteger;
lit2 :: GHCziNum.Integer =
fromInteger2 (GHCziNum.zdwSzh (2::GHCziPrim.Intzh));
fromInteger2 :: GHCziPrim.ZLzmzgZR
GHCziNum.Integer
GHCziNum.Integer =
fromInteger;
lit3 :: GHCziNum.Integer =
fromInteger3 (GHCziNum.zdwSzh (3::GHCziPrim.Intzh));
fromInteger3 :: GHCziPrim.ZLzmzgZR
GHCziNum.Integer
GHCziNum.Integer =
fromInteger;
show :: GHCziPrim.ZLzmzgZR
(GHCziBase.ZMZN GHCziNum.Integer)
(GHCziBase.ZMZN GHCziBase.Char) =
GHCziShow.show @ (GHCziBase.ZMZN GHCziNum.Integer) zddShow;
zddShow :: GHCziShow.ZCTShow (GHCziBase.ZMZN GHCziNum.Integer) =
GHCziShow.zdfShowZMZN @ GHCziNum.Integer zddShow1;
zddShow1 :: GHCziShow.ZCTShow GHCziNum.Integer =
GHCziNum.zdp2Num @ GHCziNum.Integer zddNum;
zddNum :: GHCziNum.ZCTNum GHCziNum.Integer =
GHCziNum.zdfNumInteger;
Main.zdmain :: GHCziPrim.ZLzmzgZR
(GHCziPrim.Statezh GHCziPrim.RealWorld)
(GHCziPrim.Z2H
(GHCziPrim.Statezh GHCziPrim.RealWorld)
GHCziBase.Z0T) =
GHCziTopHandler.runIO @ GHCziBase.Z0T main};
--
Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt
%module Main
%rec
{main1 :: GHCziPrim.ZLzmzgZR
(GHCziPrim.Statezh GHCziPrim.RealWorld)
(GHCziPrim.Z2H
(GHCziPrim.Statezh GHCziPrim.RealWorld)
GHCziBase.Z0T) =
%let %rec
{x :: GHCziNum.Integer = lit;
x1 :: GHCziNum.Integer = x}
%in %let %rec
{y :: GHCziBase.ZMZN GHCziNum.Integer =
GHCziBase.zdwZC @ GHCziNum.Integer lit1
(GHCziBase.zdwZC @ GHCziNum.Integer lit2
(GHCziBase.zdwZC @ GHCziNum.Integer lit3
(GHCziBase.zdwZMZN @ GHCziNum.Integer)));
y1 :: GHCziBase.ZMZN GHCziNum.Integer = y}
%in SystemziIO.putStrLn
(show (GHCziBase.ZC @ GHCziNum.Integer y1 y1));
main :: GHCziPrim.ZLzmzgZR
(GHCziPrim.Statezh GHCziPrim.RealWorld)
(GHCziPrim.Z2H
(GHCziPrim.Statezh GHCziPrim.RealWorld)
GHCziBase.Z0T) =
main1;
lit :: GHCziNum.Integer =
fromInteger (GHCziNum.zdwSzh (5::GHCziPrim.Intzh));
fromInteger :: GHCziPrim.ZLzmzgZR
GHCziNum.Integer
GHCziNum.Integer =
GHCziNum.fromInteger @ GHCziNum.Integer zddNum;
lit1 :: GHCziNum.Integer =
fromInteger1 (GHCziNum.zdwSzh (1::GHCziPrim.Intzh));
fromInteger1 :: GHCziPrim.ZLzmzgZR
GHCziNum.Integer
GHCziNum.Integer =
fromInteger;
lit2 :: GHCziNum.Integer =
fromInteger2 (GHCziNum.zdwSzh (2::GHCziPrim.Intzh));
fromInteger2 :: GHCziPrim.ZLzmzgZR
GHCziNum.Integer
GHCziNum.Integer =
fromInteger;
lit3 :: GHCziNum.Integer =
fromInteger3 (GHCziNum.zdwSzh (3::GHCziPrim.Intzh));
fromInteger3 :: GHCziPrim.ZLzmzgZR
GHCziNum.Integer
GHCziNum.Integer =
fromInteger;
show :: GHCziPrim.ZLzmzgZR
(GHCziBase.ZMZN GHCziNum.Integer)
(GHCziBase.ZMZN GHCziBase.Char) =
GHCziShow.show @ (GHCziBase.ZMZN GHCziNum.Integer) zddShow;
zddShow :: GHCziShow.ZCTShow (GHCziBase.ZMZN GHCziNum.Integer) =
GHCziShow.zdfShowZMZN @ GHCziNum.Integer zddShow1;
zddShow1 ::
Re: External Core typechecker
To enable type checking of Core, compile with -dcore-lint --sigbjorn - Original Message - From: Kirsten Chevalier [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Thursday, September 05, 2002 12:05 Subject: External Core typechecker GHC doesn't seem to do much typechecking on external Core files; it happily compiles .hcr files with type errors that then segfault when you run the program. An example of such a program is attached (the type error is on line 19, where cons is applied to the Integer type and two integer lists). I'm using the latest version of GHC (built from CVS sources yesterday, using GHC 5.04 to bootstrap), on a RedHat Linux box with gcc 2.96. -- Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: External Core typechecker
On Thu, Sep 05, 2002 at 12:20:27PM -0700, Sigbjorn Finne wrote: To enable type checking of Core, compile with -dcore-lint Ah, thanks. You'd think it would do that by default when starting from an external Core file (hint :-)) -- Kirsten Chevalier * [EMAIL PROTECTED] * Often in error, never in doubt ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
Re: External Core typechecker
Kirsten Chevalier [EMAIL PROTECTED] writes: On Thu, Sep 05, 2002 at 12:20:27PM -0700, Sigbjorn Finne wrote: To enable type checking of Core, compile with -dcore-lint Ah, thanks. You'd think it would do that by default when starting from an external Core file (hint :-)) It actually does, but the type checking code that that front-end (re-)uses does just a limited amount of checking (e.g., function applications aren't checked..), hence the suggestion of using the more thorough -dcore-lint --sigbjorn ___ Glasgow-haskell-bugs mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
