GHC issueshttps://gitlab.haskell.org/ghc/ghc/-/issues2019-07-07T19:17:22Zhttps://gitlab.haskell.org/ghc/ghc/-/issues/702MingW ld.exe produces program which segfaults2019-07-07T19:17:22Zalistair@abayley.orgMingW ld.exe produces program which segfaults(from Alistair Bayley - alistair\@abayley.org)
The C program below works correctly when compiled with GHC and ld 2.13.90, but segfaults on the first call to PQprepare when compiled with ld 2.15.91 (which ships with GHC 6.4.1) and also w...(from Alistair Bayley - alistair\@abayley.org)
The C program below works correctly when compiled with GHC and ld 2.13.90, but segfaults on the first call to PQprepare when compiled with ld 2.15.91 (which ships with GHC 6.4.1) and also with ld 2.16.91. For now I have replaced the ld in C:\\ghc\\ghc-6.4.1\\gcc-lib with ld-2.13.90 (from my MingW installation), but Sigbjorn Finn says that the more recent versions of ld are necessary for large GHCi libraries, so we can't just go back.
One possibly interesting datum (or maybe just a red herring) is this linker message emitted by 2.15.91 and 2.16.91, but not 2.13.90:
```
Info: resolving _PQprepare by linking to __imp__PQprepare (auto-import)
```
You'll need a full Postgres installation to reproduce this in its current state, unfortunately. The commands I use to run it are (assuming the default postgres database has been created, with user postgres, on localhost):
```
ghc -o test.exe test.c "-LC:\Program Files\PostgreSQL\8.1\bin" -lpq "-IC:\Program Files\PostgreSQL\8.1\include"
test.exe user=postgres
```
----
```c
File: test.c
#include <stdio.h>
#include <stdlib.h>
#include "libpq-fe.h"
static void exit_nicely(PGconn *conn)
{
PQfinish(conn);
exit(1);
}
void check_error(PGconn *conn, PGresult *res, ExecStatusType rc, char *msg)
{
if (PQresultStatus(res) != rc)
{
/* fprintf(stderr, msg, PQerrorMessage(conn)); */
fprintf(stderr, "%s: %s\n", msg, PQerrorMessage(conn));
PQclear(res);
exit_nicely(conn);
}
}
int main(int argc, char **argv)
{
const char *conninfo;
PGconn *conn;
PGresult *res;
int nFields;
int i,
j;
Oid paramTypes[10];
/*
* If the user supplies a parameter on the command line, use it as the
* conninfo string; otherwise default to setting dbname=postgres and using
* environment variables or defaults for all other connection parameters.
*/
if (argc > 1)
conninfo = argv[1];
else
conninfo = "dbname = postgres";
/* Make a connection to the database */
conn = PQconnectdb(conninfo);
/* Check to see that the backend connection was successfully made */
if (PQstatus(conn) != CONNECTION_OK)
{
fprintf(stderr, "Connection to database failed: %s", PQerrorMessage(conn));
exit_nicely(conn);
}
res = PQprepare(conn, "x", "DECLARE myportal CURSOR FOR select * from pg_database", 0, paramTypes);
check_error(conn, res, PGRES_COMMAND_OK, "Prepare failed");
/*
* Our test case here involves using a cursor, for which we must be inside
* a transaction block. We could do the whole thing with a single
* PQexec() of "select * from pg_database", but that's too trivial to make
* a good example.
*/
/* Start a transaction block */
res = PQexec(conn, "BEGIN");
check_error(conn, res, PGRES_COMMAND_OK, "BEGIN command failed");
/*
* Should PQclear PGresult whenever it is no longer needed to avoid memory
* leaks
*/
PQclear(res);
/*
* Fetch rows from pg_database, the system catalog of databases
*/
res = PQexec(conn, "DECLARE myportal CURSOR FOR select * from pg_database");
check_error(conn, res, PGRES_COMMAND_OK, "DECLARE CURSOR failed");
PQclear(res);
res = PQexec(conn, "FETCH ALL in myportal");
check_error(conn, res, PGRES_TUPLES_OK, "FETCH ALL failed");
/* first, print out the attribute names */
nFields = PQnfields(res);
for (i = 0; i < nFields; i++)
printf("%-15s", PQfname(res, i));
printf("\n\n");
/* next, print out the rows */
for (i = 0; i < PQntuples(res); i++)
{
for (j = 0; j < nFields; j++)
printf("%-15s", PQgetvalue(res, i, j));
printf("\n");
}
PQclear(res);
/* close the portal ... we don't bother to check for errors ... */
res = PQexec(conn, "CLOSE myportal");
PQclear(res);
/* end the transaction */
res = PQexec(conn, "END");
PQclear(res);
/* close the connection to the database and cleanup */
PQfinish(conn);
return 0;
}
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"MingW ld.exe produces program which segfaults","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"(from Alistair Bayley - alistair@abayley.org)\r\n\r\nThe C program below works correctly when compiled with GHC and ld 2.13.90, but segfaults on the first call to PQprepare when compiled with ld 2.15.91 (which ships with GHC 6.4.1) and also with ld 2.16.91. For now I have replaced the ld in C:\\ghc\\ghc-6.4.1\\gcc-lib with ld-2.13.90 (from my MingW installation), but Sigbjorn Finn says that the more recent versions of ld are necessary for large GHCi libraries, so we can't just go back.\r\n\r\nOne possibly interesting datum (or maybe just a red herring) is this linker message emitted by 2.15.91 and 2.16.91, but not 2.13.90:\r\n\r\n{{{\r\nInfo: resolving _PQprepare by linking to __imp__PQprepare (auto-import)\r\n}}}\r\n\r\nYou'll need a full Postgres installation to reproduce this in its current state, unfortunately. The commands I use to run it are (assuming the default postgres database has been created, with user postgres, on localhost):\r\n\r\n{{{\r\nghc -o test.exe test.c \"-LC:\\Program Files\\PostgreSQL\\8.1\\bin\" -lpq \"-IC:\\Program Files\\PostgreSQL\\8.1\\include\"\r\ntest.exe user=postgres\r\n}}}\r\n\r\n\r\n----\r\n\r\n{{{\r\n#!c\r\nFile: test.c\r\n\r\n#include <stdio.h>\r\n#include <stdlib.h>\r\n#include \"libpq-fe.h\"\r\n\r\nstatic void exit_nicely(PGconn *conn)\r\n{\r\n PQfinish(conn);\r\n exit(1);\r\n}\r\n\r\nvoid check_error(PGconn *conn, PGresult *res, ExecStatusType rc, char *msg)\r\n{\r\n if (PQresultStatus(res) != rc)\r\n {\r\n /* fprintf(stderr, msg, PQerrorMessage(conn)); */\r\n fprintf(stderr, \"%s: %s\\n\", msg, PQerrorMessage(conn));\r\n PQclear(res);\r\n exit_nicely(conn);\r\n }\r\n}\r\n\r\nint main(int argc, char **argv)\r\n{\r\n const char *conninfo;\r\n PGconn *conn;\r\n PGresult *res;\r\n int nFields;\r\n int i,\r\n j;\r\n\tOid paramTypes[10];\r\n\r\n /*\r\n * If the user supplies a parameter on the command line, use it as the\r\n * conninfo string; otherwise default to setting dbname=postgres and using\r\n * environment variables or defaults for all other connection parameters.\r\n */\r\n if (argc > 1)\r\n conninfo = argv[1];\r\n else\r\n conninfo = \"dbname = postgres\";\r\n\r\n /* Make a connection to the database */\r\n conn = PQconnectdb(conninfo);\r\n\r\n /* Check to see that the backend connection was successfully made */\r\n if (PQstatus(conn) != CONNECTION_OK)\r\n {\r\n fprintf(stderr, \"Connection to database failed: %s\", PQerrorMessage(conn));\r\n exit_nicely(conn);\r\n }\r\n\r\n res = PQprepare(conn, \"x\", \"DECLARE myportal CURSOR FOR select * from pg_database\", 0, paramTypes);\r\n check_error(conn, res, PGRES_COMMAND_OK, \"Prepare failed\");\r\n\t\r\n /*\r\n * Our test case here involves using a cursor, for which we must be inside\r\n * a transaction block. We could do the whole thing with a single\r\n * PQexec() of \"select * from pg_database\", but that's too trivial to make\r\n * a good example.\r\n */\r\n\r\n /* Start a transaction block */\r\n res = PQexec(conn, \"BEGIN\");\r\n check_error(conn, res, PGRES_COMMAND_OK, \"BEGIN command failed\");\r\n\r\n /*\r\n * Should PQclear PGresult whenever it is no longer needed to avoid memory\r\n * leaks\r\n */\r\n PQclear(res);\r\n\r\n /*\r\n * Fetch rows from pg_database, the system catalog of databases\r\n */\r\n res = PQexec(conn, \"DECLARE myportal CURSOR FOR select * from pg_database\");\r\n check_error(conn, res, PGRES_COMMAND_OK, \"DECLARE CURSOR failed\");\r\n PQclear(res);\r\n\r\n res = PQexec(conn, \"FETCH ALL in myportal\");\r\n check_error(conn, res, PGRES_TUPLES_OK, \"FETCH ALL failed\");\r\n\r\n /* first, print out the attribute names */\r\n nFields = PQnfields(res);\r\n for (i = 0; i < nFields; i++)\r\n printf(\"%-15s\", PQfname(res, i));\r\n printf(\"\\n\\n\");\r\n\r\n /* next, print out the rows */\r\n for (i = 0; i < PQntuples(res); i++)\r\n {\r\n for (j = 0; j < nFields; j++)\r\n printf(\"%-15s\", PQgetvalue(res, i, j));\r\n printf(\"\\n\");\r\n }\r\n\r\n PQclear(res);\r\n\r\n /* close the portal ... we don't bother to check for errors ... */\r\n res = PQexec(conn, \"CLOSE myportal\");\r\n PQclear(res);\r\n\r\n /* end the transaction */\r\n res = PQexec(conn, \"END\");\r\n PQclear(res);\r\n\r\n /* close the connection to the database and cleanup */\r\n PQfinish(conn);\r\n\r\n return 0;\r\n}\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->6.8.2https://gitlab.haskell.org/ghc/ghc/-/issues/703all binaries built by ghc have executable stacks2019-07-07T19:17:21Zduncanall binaries built by ghc have executable stacks# Non-executable stacks
The GNU toolchain supports marking object files that do not need to use an executable stack. Currently all object files produced by GHC lack these notes and so the linker defaults to using an executable stack for...# Non-executable stacks
The GNU toolchain supports marking object files that do not need to use an executable stack. Currently all object files produced by GHC lack these notes and so the linker defaults to using an executable stack for the resulting binary.
This makes some people grumpy. In particular it makes the Gentoo QA people grumpy. :-)
**The long story**:
http://www.gentoo.org/proj/en/hardened/gnu-stack.xml
**The quick story**:
Every .S file produced by ghc should include:
```
.section .note.GNU-stack,"",@progbits
```
Currently this does not happen for either -fasm or -fvia-C.
## For -fasm
ghc simply does not emit the .section .note.GNU-stack stuff into the assembly output.
## For -fvia-C
ghc emits C which is then compiled by gcc. The resulting .raw_s file does
contain the .section .note.GNU-stack. However ghc then runs the generated assembly through the "evil mangler" which doesn't grok the .section
1. note.GNU-stack and does not emit it to the final assembly file.
So the solution is to get ghc to emit the .note.GNU-stack in it's native code geneerator and to modify the evil mangler to pass the .note.GNU-stack through to the output.
We may still have a problem with the "split objs" feature (which ghc uses for its own libraries). Hopefully it'd just be a matter of adding .note.GNU-stack to each .s file that is spat out by ghc -split-objs.
----
For reference see http://bugs.gentoo.org/show_bug.cgi?id=123698
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Driver |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | Multiple |
</details>
<!-- {"blocked_by":[],"summary":"all binaries built by ghc have executable stacks","status":"New","operating_system":"","component":"Driver","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"Multiple","cc":[""],"type":"Bug","description":"= Non-executable stacks =\r\nThe GNU toolchain supports marking object files that do not need to use an executable stack. Currently all object files produced by GHC lack these notes and so the linker defaults to using an executable stack for the resulting binary.\r\n\r\nThis makes some people grumpy. In particular it makes the Gentoo QA people grumpy. :-)\r\n\r\n'''The long story''':\r\nhttp://www.gentoo.org/proj/en/hardened/gnu-stack.xml\r\n\r\n'''The quick story''':\r\nEvery .S file produced by ghc should include:\r\n{{{\r\n.section .note.GNU-stack,\"\",@progbits\r\n}}}\r\n\r\nCurrently this does not happen for either -fasm or -fvia-C.\r\n\r\n== For -fasm ==\r\nghc simply does not emit the .section .note.GNU-stack stuff into the assembly output.\r\n\r\n== For -fvia-C ==\r\nghc emits C which is then compiled by gcc. The resulting .raw_s file does\r\ncontain the .section .note.GNU-stack. However ghc then runs the generated assembly through the \"evil mangler\" which doesn't grok the .section\r\n.note.GNU-stack and does not emit it to the final assembly file.\r\n\r\nSo the solution is to get ghc to emit the .note.GNU-stack in it's native code geneerator and to modify the evil mangler to pass the .note.GNU-stack through to the output.\r\n\r\nWe may still have a problem with the \"split objs\" feature (which ghc uses for its own libraries). Hopefully it'd just be a matter of adding .note.GNU-stack to each .s file that is spat out by ghc -split-objs.\r\n\r\n----\r\n\r\nFor reference see http://bugs.gentoo.org/show_bug.cgi?id=123698","type_of_failure":"OtherFailure","blocking":[]} -->7.10.1Edward Z. YangEdward Z. Yanghttps://gitlab.haskell.org/ghc/ghc/-/issues/704change array interface to accomodate resizable arrays2019-07-07T19:17:21ZSimon Marlowchange array interface to accomodate resizable arraysSee:
[http://www.haskell.org//pipermail/haskell-prime/2006-February/000708.html](http://www.haskell.org//pipermail/haskell-prime/2006-February/000708.html)
The API for getting the bounds should be monadic, not pure. This is an incompat...See:
[http://www.haskell.org//pipermail/haskell-prime/2006-February/000708.html](http://www.haskell.org//pipermail/haskell-prime/2006-February/000708.html)
The API for getting the bounds should be monadic, not pure. This is an incompatible change, but a relatively small one.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.4.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"change array interface to accomodate resizable arrays","status":"New","operating_system":"Unknown","component":"libraries/base","related":[],"milestone":"6.6","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Task","description":"See:\r\n\r\n[http://www.haskell.org//pipermail/haskell-prime/2006-February/000708.html]\r\n\r\nThe API for getting the bounds should be monadic, not pure. This is an incompatible change, but a relatively small one.","type_of_failure":"OtherFailure","blocking":[]} -->6.6https://gitlab.haskell.org/ghc/ghc/-/issues/705crash on readChan/writeChan2019-07-07T19:17:21Zguestcrash on readChan/writeChanSource code:
http://www.seas.upenn.edu/\~lipeng/tmp/ghc_smp_bug.tar.gz
Compile using the latest Linux binary snapshot (ghc-6.5.20060223):
$ ghc -fglasgow-exts -smp Server.hs --make -o Server.bin
Run on a 2-way SMP machine:
$ ./Serve...Source code:
http://www.seas.upenn.edu/\~lipeng/tmp/ghc_smp_bug.tar.gz
Compile using the latest Linux binary snapshot (ghc-6.5.20060223):
$ ghc -fglasgow-exts -smp Server.hs --make -o Server.bin
Run on a 2-way SMP machine:
$ ./Server.bin +RTS -N1
1. ...
1. ...
Server.bin: internal error: EVACUATED object entered!
Please report this as a compiler bug. See:
> http://www.haskell.org/ghc/reportabug
Aborted
Sometimes I get segmentation fault instead of the above error messages. 100% reproducable on 4 different Linux machines. This bug can be also reproduced using +RTS -N2 by slighly changing the source code. Also reproducable on an older version (20060205). Is it a bug or am I using GHC incorrectly?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Linux |
| Architecture | x86 |
</details>
<!-- {"blocked_by":[],"summary":"GHC SMP bug, crash on readChan/writeChan","status":"New","operating_system":"Linux","component":"Compiler","related":[],"milestone":"6.6","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.5","keywords":["crash","readChan","smp","writeChan"],"differentials":[],"test_case":"","architecture":"x86","cc":[""],"type":"Bug","description":"Source code:\r\n\r\nhttp://www.seas.upenn.edu/~lipeng/tmp/ghc_smp_bug.tar.gz\r\n\r\nCompile using the latest Linux binary snapshot (ghc-6.5.20060223):\r\n\r\n$ ghc -fglasgow-exts -smp Server.hs --make -o Server.bin\r\n\r\nRun on a 2-way SMP machine:\r\n\r\n$ ./Server.bin +RTS -N1\r\n\r\n....\r\n....\r\nServer.bin: internal error: EVACUATED object entered!\r\n Please report this as a compiler bug. See:\r\n http://www.haskell.org/ghc/reportabug\r\nAborted\r\n\r\nSometimes I get segmentation fault instead of the above error messages. 100% reproducable on 4 different Linux machines. This bug can be also reproduced using +RTS -N2 by slighly changing the source code. Also reproducable on an older version (20060205). Is it a bug or am I using GHC incorrectly?","type_of_failure":"OtherFailure","blocking":[]} -->6.6https://gitlab.haskell.org/ghc/ghc/-/issues/706GHC uses _stub.c files regardless of whether any 'foreign import' decls remai...2019-07-07T19:17:20Zncalexan@uci.eduGHC uses _stub.c files regardless of whether any 'foreign import' decls remain in a .hs fileIt appears GHC links any _stub.o files it can find, which is not correct (although usually it only leads to duplicate symbols.) To duplicate, have two modules A and B, and a foreign import in A. A_stub.o will be built as usual. Copy A_st...It appears GHC links any _stub.o files it can find, which is not correct (although usually it only leads to duplicate symbols.) To duplicate, have two modules A and B, and a foreign import in A. A_stub.o will be built as usual. Copy A_stub.o to B_stub.o, relink and have duplicate symbols.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (FFI) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | MacOS X |
| Architecture | powerpc |
</details>
<!-- {"blocked_by":[],"summary":"GHC links _stub.o files regardless of whether any 'foreign import' decls remain in a .hs file","status":"New","operating_system":"MacOS X","component":"Compiler (FFI)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.1","keywords":["ffi,","link"],"differentials":[],"test_case":"","architecture":"powerpc","cc":[""],"type":"Bug","description":"It appears GHC links any _stub.o files it can find, which is not correct (although usually it only leads to duplicate symbols.) To duplicate, have two modules A and B, and a foreign import in A. A_stub.o will be built as usual. Copy A_stub.o to B_stub.o, relink and have duplicate symbols.","type_of_failure":"OtherFailure","blocking":[]} -->7.2.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/707foldr/build seems to be broken2019-07-07T19:17:20Zlennart@augustsson.netfoldr/build seems to be brokenReading the documentation for ghc it says that if a good consumer meets a good producer the intermediate list will disappear. List enumeration is s good producer, and length is a good consumer, so there should be no intermediate list bet...Reading the documentation for ghc it says that if a good consumer meets a good producer the intermediate list will disappear. List enumeration is s good producer, and length is a good consumer, so there should be no intermediate list between these.
Looking at the example below, it sure looks like a list is generated.
```
module CG1 where
foo :: Int -> Int
foo n = length [1..n]
-- Compile with
-- ghc -v5 -ddump-simpl-stats -ddump-rules -O2 -S CG1.hs
-- Output from this compilation
{-
Glasgow Haskell Compiler, Version 6.4.1, for Haskell 98, compiled by GHC version 6.4
....
==================== STG syntax: ====================
CG1.foo =
\r [n_s1Ah]
case n_s1Ah of wild1_s1Ap {
GHC.Base.I# y_s1Ak ->
case GHC.Enum.eftInt 1 y_s1Ak of sat_s1Am {
__DEFAULT ->
case GHC.List.$wlen sat_s1Am 0 of ww_s1Ao {
__DEFAULT -> GHC.Base.I# [ww_s1Ao];
};
};
};
SRT(CG1.foo): []
....
-}
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"foldr/build seems to be broken","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"Reading the documentation for ghc it says that if a good consumer meets a good producer the intermediate list will disappear. List enumeration is s good producer, and length is a good consumer, so there should be no intermediate list between these.\r\n\r\nLooking at the example below, it sure looks like a list is generated.\r\n\r\n{{{\r\n\r\nmodule CG1 where\r\n\r\nfoo :: Int -> Int\r\nfoo n = length [1..n]\r\n\r\n-- Compile with\r\n-- ghc -v5 -ddump-simpl-stats -ddump-rules -O2 -S CG1.hs\r\n\r\n-- Output from this compilation\r\n{-\r\nGlasgow Haskell Compiler, Version 6.4.1, for Haskell 98, compiled by GHC version 6.4\r\n\r\n....\r\n\r\n==================== STG syntax: ====================\r\nCG1.foo =\r\n \\r [n_s1Ah]\r\n\tcase n_s1Ah of wild1_s1Ap {\r\n\t GHC.Base.I# y_s1Ak ->\r\n\t case GHC.Enum.eftInt 1 y_s1Ak of sat_s1Am {\r\n\t\t__DEFAULT ->\r\n\t\t case GHC.List.$wlen sat_s1Am 0 of ww_s1Ao {\r\n\t\t __DEFAULT -> GHC.Base.I# [ww_s1Ao];\r\n\t\t };\r\n\t };\r\n\t};\r\nSRT(CG1.foo): []\r\n\r\n....\r\n\r\n-}\r\n\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/708Compiler error2019-07-07T19:17:20Zr.j.rorije@student.utwente.nlCompiler errorHi,
I am using Data.Generics and type classes to be able to compare values on their most inner type. Doing this a compiler bug occurred. I have tried to find a minimum example that crashed. The example I found may be not as minimal as y...Hi,
I am using Data.Generics and type classes to be able to compare values on their most inner type. Doing this a compiler bug occurred. I have tried to find a minimum example that crashed. The example I found may be not as minimal as you would like, though. I can not track down the exact source of the error, but the error occurs only when using the function mycast. when **both** implementations of mycast are removed no error occurs.
I hope I made the problem clear enough, otherwise, feel free to contact me.
source of the bug-example:
[http://wwwhome.cs.utwente.nl/\~rorijerj/Test.hs](http://wwwhome.cs.utwente.nl/~rorijerj/Test.hs)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Windows |
| Architecture | x86 |
</details>
<!-- {"blocked_by":[],"summary":"Error: Data.Generics / Cast","status":"New","operating_system":"Windows","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"x86","cc":[""],"type":"Bug","description":"Hi,\r\n\r\nI am using Data.Generics and type classes to be able to compare values on their most inner type. Doing this a compiler bug occurred. I have tried to find a minimum example that crashed. The example I found may be not as minimal as you would like, though. I can not track down the exact source of the error, but the error occurs only when using the function mycast. when '''both''' implementations of mycast are removed no error occurs.\r\n\r\nI hope I made the problem clear enough, otherwise, feel free to contact me.\r\n\r\nsource of the bug-example: \r\n[http://wwwhome.cs.utwente.nl/~rorijerj/Test.hs]","type_of_failure":"OtherFailure","blocking":[]} -->6.4.2Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/709"Fixup too large" error with -fasm on PowerPC2019-07-07T19:17:20ZSimon Marlow"Fixup too large" error with -fasm on PowerPCThe native code generator on PowerPC can sometimes generate code that doesn't pass the assembler. The error is "Fixup too large" from the assembler.
Workaround is to use `-fvia-C`.
Wolfgang Thaller says this: Conditional branches on th...The native code generator on PowerPC can sometimes generate code that doesn't pass the assembler. The error is "Fixup too large" from the assembler.
Workaround is to use `-fvia-C`.
Wolfgang Thaller says this: Conditional branches on the PowerPC only have 16 bits for the displacement. I have been reluctant to fix this so far because it means either slowing down all conditional branches or actually checking the size of the generated code before deciding what branch instructions to use, which I'm afraid would add an additional pass to the NCG.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Compiler (NCG) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Multiple |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"\"Fixup too large\" error with -fasm on PowerPC","status":"New","operating_system":"Multiple","component":"Compiler (NCG)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The native code generator on PowerPC can sometimes generate code that doesn't pass the assembler. The error is \"Fixup too large\" from the assembler.\r\n\r\nWorkaround is to use {{{-fvia-C}}}.\r\n\r\nWolfgang Thaller says this: Conditional branches on the PowerPC only have 16 bits for the displacement. I have been reluctant to fix this so far because it means either slowing down all conditional branches or actually checking the size of the generated code before deciding what branch instructions to use, which I'm afraid would add an additional pass to the NCG.","type_of_failure":"OtherFailure","blocking":[]} -->6.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/710library reorganisation2019-07-07T19:17:19ZSimon Marlowlibrary reorganisationThis is the place I'm going to record the planned reorganisations to the packages we ship with GHC. Some of this may happen for 6.6. Please comment.
### Goals
- make the base package less monolithic by extracting parts into separate pa...This is the place I'm going to record the planned reorganisations to the packages we ship with GHC. Some of this may happen for 6.6. Please comment.
### Goals
- make the base package less monolithic by extracting parts into separate packages
- hence reduce the amount of library code that needs to be built to bootstrap GHC.
- make it possible to build and ship GHC with a minimal set of libraries, without
removing the possibility of delivering it with a more comprehensive set too.
- packages provided with a GHC installation should be upgradable.
### Activities
- GHC's libraries need to be built using Cabal. Some of the things we need to do
before this can happen:
\* Cabal needs support for using a specific package database
\* we need to support `-split-objs` with `--make`
- Abstract away from the particular packages that are built in the GHC tree. Make
It possible to populate `libraries` with any Cabal packages you like, which
are built and installed with GHC. (subject to the minimum requirements: base,
haskell98, unix, template-haskell, readline, ...).
### Library reorganisation
The following modules could be removed from base (perhaps not exhaustive, and there may be dependencies I haven't considered):
- `Control.Applicative`
- `Data.Array.*`
- `Data.Foldable`
- `Data.Graph`
- `Data.HashTable` (replace with Jan-Willem Maessen's version)
- `Data.IntMap`
- `Data.IntSet`
- `Data.Map`
- `Data.Monoid`
- `Data.Sequence`
- `Data.Set`
- `Data.Traversable`
- `Data.Tree`
- `Text.Html` (to `network` package?)
- `Text.PrettyPrint.*`
- `Text.Printf`
- `Text.Regex` (integrate with, or replace by, [JRegex](http://repetae.net/john/computer/haskell/JRegex/)?)
Some libraries we want to add:
- [FastPackedStrings](http://www.cse.unsw.edu.au/~dons/fps.html) (replace `Data.PackedString`)
These were deprecated in 6.4, and can be removed now:
- `Data.FiniteMap`
- old interface in `Data.Set`
- `withObject` in `Foreign.Marshal.Utils`
These are deprecated now, and can be removed later:
- `Data.FunctorM`
- `Data.Queue`6.8.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/711shutdownHaskell() does not return allocated memory on Unix2019-07-07T19:17:19Zlennart.augustsson@credit-suisse.comshutdownHaskell() does not return allocated memory on UnixCalling shutdownHaskell() doesn't actually return the memory allocated.
This can be very bad when loading and unloading DLLs many times.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ------------...Calling shutdownHaskell() doesn't actually return the memory allocated.
This can be very bad when loading and unloading DLLs many times.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Multiple |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"shutdownHaskell() does not return allocated memory","status":"New","operating_system":"Multiple","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.5","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"Calling shutdownHaskell() doesn't actually return the memory allocated.\r\nThis can be very bad when loading and unloading DLLs many times.","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/712getDirectoryContents: failed (No error)2019-07-07T19:17:19ZSimon MarlowgetDirectoryContents: failed (No error)Reported on ghc-bugs by martin.boeker\@uniklinik-freiburg.de:
this error has been reported before and was fixed in ghc 6.4.1 but has been revived in ghc 6.4.2:
```
test3.exe: .: getDirectoryContents: failed (No error)
module Main wher...Reported on ghc-bugs by martin.boeker\@uniklinik-freiburg.de:
this error has been reported before and was fixed in ghc 6.4.1 but has been revived in ghc 6.4.2:
```
test3.exe: .: getDirectoryContents: failed (No error)
module Main where
import System.Directory
main = do s <- getDirectoryContents "."
putStr (concat s)
```
This works fine for ghc 6.4.1 bld1. The error is encountered in 6.4.2 snapshots from Feb. 25 and newer (elder ones have not tested), and the same snapshots with the MinGW files from afore mentioned ghc 6.4.1 (it's not the MinGW).
My system is: Cygwin (WinXP) and ghc 6.4.1 bld1 or 6.4.2 (Cajal works better).
I would like to add a wish: could we have a native Cygwin port?
----------------------
See also, previous incarnation of this bug (perhaps):
http://www.haskell.org//pipermail/glasgow-haskell-bugs/2005-July/005338.html
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"getDirectoryContents: failed (No error)","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"6.4.2","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Reported on ghc-bugs by martin.boeker@uniklinik-freiburg.de:\r\n\r\nthis error has been reported before and was fixed in ghc 6.4.1 but has been revived in ghc 6.4.2:\r\n\r\n{{{\r\ntest3.exe: .: getDirectoryContents: failed (No error)\r\n\r\nmodule Main where\r\n\r\nimport System.Directory\r\n\r\nmain = do s <- getDirectoryContents \".\"\r\n putStr (concat s)\r\n}}}\r\n\r\nThis works fine for ghc 6.4.1 bld1. The error is encountered in 6.4.2 snapshots from Feb. 25 and newer (elder ones have not tested), and the same snapshots with the MinGW files from afore mentioned ghc 6.4.1 (it's not the MinGW).\r\n\r\nMy system is: Cygwin (WinXP) and ghc 6.4.1 bld1 or 6.4.2 (Cajal works better).\r\n\r\nI would like to add a wish: could we have a native Cygwin port?\r\n\r\n\r\n----------------------\r\n\r\nSee also, previous incarnation of this bug (perhaps):\r\n\r\nhttp://www.haskell.org//pipermail/glasgow-haskell-bugs/2005-July/005338.html","type_of_failure":"OtherFailure","blocking":[]} -->6.4.2https://gitlab.haskell.org/ghc/ghc/-/issues/713SMP + FFI = crash...2019-07-07T19:17:19Zlipeng@cis.upenn.eduSMP + FFI = crash...Source code will be attached. This is a modified version of bug #705: each thread calls a safe C function via FFI. The normal behavior of the program is to loop forever. The program works fine using +RTS -N1, but when using +RTS -N2 or m...Source code will be attached. This is a modified version of bug #705: each thread calls a safe C function via FFI. The normal behavior of the program is to loop forever. The program works fine using +RTS -N1, but when using +RTS -N2 or more threads on a SMP machine, it crashes nondeterministically with all kinds of funny error messages. I can reproduce it on difference linux SMP machines.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"SMP + FFI = crash...","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.5","keywords":["crash","ffi","smp"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Source code will be attached. This is a modified version of bug #705: each thread calls a safe C function via FFI. The normal behavior of the program is to loop forever. The program works fine using +RTS -N1, but when using +RTS -N2 or more threads on a SMP machine, it crashes nondeterministically with all kinds of funny error messages. I can reproduce it on difference linux SMP machines.","type_of_failure":"OtherFailure","blocking":[]} -->6.6https://gitlab.haskell.org/ghc/ghc/-/issues/714Inconsistency between handling functional dependencies in class and signature...2019-07-07T19:17:18Zclaus.reinke@talk21.comInconsistency between handling functional dependencies in class and signature constraintsthe user's guide claims
1. 4.2 3. There are no restrictions on the context in a class declaration (which introduces superclasses), except that the class hierarchy must be acyclic.
and we also have
1. 4.3.1 1. Each universally quantif...the user's guide claims
1. 4.2 3. There are no restrictions on the context in a class declaration (which introduces superclasses), except that the class hierarchy must be acyclic.
and we also have
1. 4.3.1 1. Each universally quantified type variable tvi must be reachable from type
suggesting that FDs are taken into account when considering reachability
but that only seems to work for signature, not for class constraints,
as the attached example shows. I wouldn't go so far as claiming this
as a bug, but it prevents an otherwise straightforward encoding of
ATS in FDs (where the superclass encodes the type function, see last
month's discussion on haskell-cafe).
\[grr, there isn't a button for attachment on this form, so I'll paste the code\]
```
{-# OPTIONS_GHC -fglasgow-exts #-}
class C a b | a -> b
class C a b => D a
f :: C a b => a
f = undefined
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.5 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"inconsistency between handling of class and signature constraints","status":"New","operating_system":"Unknown","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.5","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"FeatureRequest","description":"the user's guide claims\r\n\r\n7.4.2 3. There are no restrictions on the context in a class declaration (which introduces superclasses), except that the class hierarchy must be acyclic. \r\n\r\nand we also have \r\n\r\n7.4.3.1 1. Each universally quantified type variable tvi must be reachable from type\r\nsuggesting that FDs are taken into account when considering reachability\r\n\r\nbut that only seems to work for signature, not for class constraints,\r\nas the attached example shows. I wouldn't go so far as claiming this\r\nas a bug, but it prevents an otherwise straightforward encoding of\r\nATS in FDs (where the superclass encodes the type function, see last\r\nmonth's discussion on haskell-cafe).\r\n\r\n[grr, there isn't a button for attachment on this form, so I'll paste the code]\r\n{{{\r\n{-# OPTIONS_GHC -fglasgow-exts #-}\r\nclass C a b | a -> b\r\nclass C a b => D a\r\nf :: C a b => a\r\nf = undefined\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchSimon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/715OpenAL package fails to compile with older headers2019-07-07T19:17:18Zayqazi@yahoo.co.ukOpenAL package fails to compile with older headersHi,
My architecture:
Gentoo Linux on a Pentium III 500HMz
I perform the following steps:
$ (mkdir ghc-darcs; cd ghc-darcs; \\
> darcs get --partial http://darcs.haskell.org/ghc)
$ (cd ghc-darcs/ghc; chmod +x darcs-all; ./darcs-all...Hi,
My architecture:
Gentoo Linux on a Pentium III 500HMz
I perform the following steps:
$ (mkdir ghc-darcs; cd ghc-darcs; \\
> darcs get --partial http://darcs.haskell.org/ghc)
$ (cd ghc-darcs/ghc; chmod +x darcs-all; ./darcs-all get)
$ mkdir ghc-build
$ lndir $PWD/ghc-darcs/ghc ghc-build
$ cd ghc-build; \\
autoreconf; \\
1. /configure --prefix=/usr/local/ghc
I then place the following build.mk file into ghc-build/mk:
\#BuildFlavour = devel
BuildFlavour = perf
ifeq "$(BuildFlavour)" "devel"
GhcCompilerWays =
SRC_HC_OPTS = -H32m -O0 $(MyWarningOpts)
GhcHcOpts = -Rghc-timing -DDEBUG
GhcLibHcOpts = -O -dcore-lint $(MyWarningOpts) -keep-hc-files
GhcLibWays =
\# profiled RTS
\#GhcRtsCcOpts = -pg -g
\# Optimised/profiled RTS
\#GhcRtsCcOpts = -O2 -pg
\#GhcRtsWithFrontPanel = YES
\#SRC_HC_OPTS += `gtk-config --libs`
SplitObjs = NO
NoFibWays =
SRC_RUNTEST_OPTS += +RTS -H10m -RTS
STRIP=:
endif
\# -------- 1. A Performance/Distribution build--------------------------------
ifeq "$(BuildFlavour)" "perf"
SRC_HC_OPTS = -H32m -O $(MyWarningOpts)
GhcHcOpts = -Rghc-timing
GhcLibHcOpts =
GhcLibWays = p
\# Multiprocessor Haskell
GhcLibWays += s
GhcRtsCcOpts = -O2 -fomit-frame-pointer -mpreferred-stack-boundary=2 -march=pentium3
endif
I then do (from the ghc-build directory):
$ nice make
Here is a snippet of last part of the output I get:
------------------------------------------------------------------------
==fptools== make all -wr -f Makefile;
in /home/ayqazi/src/packages/ghc/ghc-build/libraries/OpenAL
------------------------------------------------------------------------
1. ./../ghc/compiler/ghc-inplace -H32m -O -W -fno-warn-unused-matches -fwarn-unused-imports -Wall -fffi -Iinclude '-\#include "HsOpenAL.h"' -cpp -DCALLCONV=ccall -ignore-package OpenAL -package base -package OpenGL -fgenerics -split-objs -c Sound/OpenAL/ALC/Capture.hs -o Sound/OpenAL/ALC/Capture.o -ohi Sound/OpenAL/ALC/Capture.hi
Sound/OpenAL/ALC/Capture.hs:85:3:
Couldn't match expected type `NumSamples'
against inferred type `Sound.OpenAL.Config.ALCint'
Expected type: GettableStateVar NumSamples
Inferred type: GettableStateVar Sound.OpenAL.Config.ALCint
In the expression:
makeGettableStateVar $ (getInteger (Just device) CaptureSamples)
In the definition of `captureNumSamples':
captureNumSamples device
= makeGettableStateVar $ (getInteger (Just device) CaptureSamples)
make[2]: *** [Sound/OpenAL/ALC/Capture.o] Error 1
make[1]: *** [all] Error 1
make[1]: Leaving directory `/home/ayqazi/src/packages/ghc/ghc-build/libraries'
make: \*\*\* \[build\] Error 1
make: Leaving directory \`/home/ayqazi/src/packages/ghc/ghc-build'
Thanks
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Linux |
| Architecture | x86 |
</details>
<!-- {"blocked_by":[],"summary":"Compile fails for ghc HEAD","status":"New","operating_system":"Linux","component":"Compiler","related":[],"milestone":"6.6","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.5","keywords":["build","compile","error"],"differentials":[],"test_case":"","architecture":"x86","cc":[""],"type":"Bug","description":"Hi,\r\n\r\nMy architecture:\r\n\r\nGentoo Linux on a Pentium III 500HMz\r\n\r\nI perform the following steps:\r\n\r\n$ (mkdir ghc-darcs; cd ghc-darcs; \\\r\n darcs get --partial http://darcs.haskell.org/ghc)\r\n\r\n$ (cd ghc-darcs/ghc; chmod +x darcs-all; ./darcs-all get)\r\n\r\n$ mkdir ghc-build\r\n\r\n$ lndir $PWD/ghc-darcs/ghc ghc-build\r\n\r\n$ cd ghc-build; \\\r\n\tautoreconf; \\\r\n\t./configure --prefix=/usr/local/ghc\r\n\r\nI then place the following build.mk file into ghc-build/mk:\r\n\r\n#BuildFlavour = devel\r\nBuildFlavour = perf\r\n\r\nifeq \"$(BuildFlavour)\" \"devel\"\r\n\r\nGhcCompilerWays =\r\n\r\nSRC_HC_OPTS = -H32m -O0 $(MyWarningOpts)\r\nGhcHcOpts = -Rghc-timing -DDEBUG\r\nGhcLibHcOpts = -O -dcore-lint $(MyWarningOpts) -keep-hc-files \r\nGhcLibWays =\r\n\r\n# profiled RTS\r\n#GhcRtsCcOpts = -pg -g\r\n\r\n# Optimised/profiled RTS\r\n#GhcRtsCcOpts = -O2 -pg\r\n\r\n#GhcRtsWithFrontPanel = YES\r\n#SRC_HC_OPTS += `gtk-config --libs`\r\n\r\nSplitObjs = NO\r\n\r\nNoFibWays =\r\nSRC_RUNTEST_OPTS += +RTS -H10m -RTS\r\nSTRIP=:\r\n\r\nendif\r\n\r\n# -------- 1. A Performance/Distribution build--------------------------------\r\n\r\nifeq \"$(BuildFlavour)\" \"perf\"\r\n\r\nSRC_HC_OPTS = -H32m -O $(MyWarningOpts)\r\nGhcHcOpts = -Rghc-timing\r\nGhcLibHcOpts =\r\n\r\nGhcLibWays = p\r\n\r\n# Multiprocessor Haskell\r\nGhcLibWays += s\r\n\r\nGhcRtsCcOpts = -O2 -fomit-frame-pointer -mpreferred-stack-boundary=2 -march=pentium3\r\nendif\r\n\r\nI then do (from the ghc-build directory):\r\n\r\n$ nice make\r\n\r\nHere is a snippet of last part of the output I get:\r\n\r\n------------------------------------------------------------------------\r\n==fptools== make all -wr -f Makefile;\r\n in /home/ayqazi/src/packages/ghc/ghc-build/libraries/OpenAL\r\n------------------------------------------------------------------------\r\n../../ghc/compiler/ghc-inplace -H32m -O -W -fno-warn-unused-matches -fwarn-unused-imports -Wall -fffi -Iinclude '-#include \"HsOpenAL.h\"' -cpp -DCALLCONV=ccall -ignore-package OpenAL -package base -package OpenGL -fgenerics -split-objs -c Sound/OpenAL/ALC/Capture.hs -o Sound/OpenAL/ALC/Capture.o -ohi Sound/OpenAL/ALC/Capture.hi\r\n\r\nSound/OpenAL/ALC/Capture.hs:85:3:\r\n Couldn't match expected type `NumSamples'\r\n against inferred type `Sound.OpenAL.Config.ALCint'\r\n Expected type: GettableStateVar NumSamples\r\n Inferred type: GettableStateVar Sound.OpenAL.Config.ALCint\r\n In the expression:\r\n makeGettableStateVar $ (getInteger (Just device) CaptureSamples)\r\n In the definition of `captureNumSamples':\r\n captureNumSamples device\r\n = makeGettableStateVar $ (getInteger (Just device) CaptureSamples)\r\nmake[2]: *** [Sound/OpenAL/ALC/Capture.o] Error 1\r\nmake[1]: *** [all] Error 1\r\nmake[1]: Leaving directory `/home/ayqazi/src/packages/ghc/ghc-build/libraries'\r\nmake: *** [build] Error 1\r\nmake: Leaving directory `/home/ayqazi/src/packages/ghc/ghc-build'\r\n\r\nThanks","type_of_failure":"OtherFailure","blocking":[]} -->pannepannehttps://gitlab.haskell.org/ghc/ghc/-/issues/716Unloading a dll generated by GHC doesn't free all resources2019-07-07T19:17:17Zlennart@augustsson.netUnloading a dll generated by GHC doesn't free all resourcesThere seems to be resource leaks in load&unload of a DLL.
If you put it in a loop strange thing can happen.
So one thing I notiticed is that several places
(Ticker.c, IOManager.c) create threads, but I could not
find the place where the...There seems to be resource leaks in load&unload of a DLL.
If you put it in a loop strange thing can happen.
So one thing I notiticed is that several places
(Ticker.c, IOManager.c) create threads, but I could not
find the place where these threads die.
How are they supposed to die shutdownHaskell() is called?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Unloading a dll generated by GHC doesn't free all resources","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"There seems to be resource leaks in load&unload of a DLL.\r\nIf you put it in a loop strange thing can happen.\r\n\r\nSo one thing I notiticed is that several places \r\n(Ticker.c, IOManager.c) create threads, but I could not\r\nfind the place where these threads die.\r\nHow are they supposed to die shutdownHaskell() is called?","type_of_failure":"OtherFailure","blocking":[]} -->6.8.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/717Compiling large constant data structure fails2019-07-07T19:17:17Zluettich@tzi.deCompiling large constant data structure failsI am trying to compile a large data strcture as list into a Haskell module (Source is linked below)
and GHC fails with this error message:
Compiling CASL_DL.!PredefinedSign ( ./CASL_DL/PredefinedSign.hs, ./CASL_DL/PredefinedSign.o )
/tm...I am trying to compile a large data strcture as list into a Haskell module (Source is linked below)
and GHC fails with this error message:
Compiling CASL_DL.!PredefinedSign ( ./CASL_DL/PredefinedSign.hs, ./CASL_DL/PredefinedSign.o )
/tmp/ghc12137.s:30942:Fixup of 39588 too large for field width of 16 bits
/tmp/ghc12137.s:30939:Fixup of 39600 too large for field width of 16 bits
With the flag '-fvia-C', GHC can compile the file without an error.
Sources, including a Makefile with used GHC options, are available at [sources](http://www.informatik.uni-bremen.de/~luettich/forGHCBug-Large-data-structure.tgz)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Compiling large constant data structure fails","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I am trying to compile a large data strcture as list into a Haskell module (Source is linked below) \r\nand GHC fails with this error message:\r\n\r\nCompiling CASL_DL.!PredefinedSign ( ./CASL_DL/PredefinedSign.hs, ./CASL_DL/PredefinedSign.o )\r\n/tmp/ghc12137.s:30942:Fixup of 39588 too large for field width of 16 bits\r\n/tmp/ghc12137.s:30939:Fixup of 39600 too large for field width of 16 bits\r\n\r\nWith the flag '-fvia-C', GHC can compile the file without an error.\r\n\r\nSources, including a Makefile with used GHC options, are available at [http://www.informatik.uni-bremen.de/~luettich/forGHCBug-Large-data-structure.tgz sources]","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/718FinalizerEnvPtr and newForeignPtrEnv missing from Freign.ForeignPtr2019-07-07T19:17:17ZWolfram KahlFinalizerEnvPtr and newForeignPtrEnv missing from Freign.ForeignPtrThe type `FinalizerEnvPtr` and, more importantly,
the function `newForeignPtrEnv` specified in Section 5.5 of the FFI addendum
are missing from the GHC version of the `Foreign` libraries.
There is not even a comment about this in `base/G...The type `FinalizerEnvPtr` and, more importantly,
the function `newForeignPtrEnv` specified in Section 5.5 of the FFI addendum
are missing from the GHC version of the `Foreign` libraries.
There is not even a comment about this in `base/GHC/ForeignPtr.hs`.
(I checked the source of the last nightly snapshot --- not there either.)
I have reason to believe that my current attempts to use a `"wrapper"` foreign import
to achieve the effect of `newForeignPtrEnv` are the reason behind segmentation faults
I haven't (yet) been able to track down to anything else.
Since these segfaults are a blocker for me, and since this is a point of non-conformance
to a 'Standard', I proposed priority 'high'.
(This is obviously operating system and architecture independent,
but neither 'Unknown' nor 'multiple' in the menus below seem appropriate.)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------------- |
| Version | 6.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | libraries/haskell98 |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"FinalizerEnvPtr and newForeignPtrEnv missing from Freign.ForeignPtr","status":"New","operating_system":"Unknown","component":"libraries/haskell98","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"The type `FinalizerEnvPtr` and, more importantly,\r\nthe function `newForeignPtrEnv` specified in Section 5.5 of the FFI addendum\r\nare missing from the GHC version of the `Foreign` libraries.\r\nThere is not even a comment about this in `base/GHC/ForeignPtr.hs`.\r\n(I checked the source of the last nightly snapshot --- not there either.)\r\n\r\nI have reason to believe that my current attempts to use a `\"wrapper\"` foreign import\r\nto achieve the effect of `newForeignPtrEnv` are the reason behind segmentation faults\r\nI haven't (yet) been able to track down to anything else.\r\n\r\nSince these segfaults are a blocker for me, and since this is a point of non-conformance\r\nto a 'Standard', I proposed priority 'high'.\r\n\r\n(This is obviously operating system and architecture independent,\r\nbut neither 'Unknown' nor 'multiple' in the menus below seem appropriate.)","type_of_failure":"OtherFailure","blocking":[]} -->6.6https://gitlab.haskell.org/ghc/ghc/-/issues/719error messages are too long sometimes2019-07-07T19:17:17ZSimon Marlowerror messages are too long sometimesThe depth limit stuff in the pretty printer could use some tweaking. eg. see attached example.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version ...The depth limit stuff in the pretty printer could use some tweaking. eg. see attached example.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"error messages are too long sometimes","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"The depth limit stuff in the pretty printer could use some tweaking. eg. see attached example.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/720Map/Set range function2019-07-07T19:17:17ZjpbernardyMap/Set range functionData.Map seems to lack a way to perform range queries
like "fetch all elements between keys low and high".
The naive implementation is easy:
```
range :: Ord k => k -> k -> Map.Map k v -> [(k,v)]
range low high = toList . fst . split hi...Data.Map seems to lack a way to perform range queries
like "fetch all elements between keys low and high".
The naive implementation is easy:
```
range :: Ord k => k -> k -> Map.Map k v -> [(k,v)]
range low high = toList . fst . split high . snd . split low
```
But this is not very fast for larger maps. Maybe
this operation could be provided in Data.Map?Not GHChttps://gitlab.haskell.org/ghc/ghc/-/issues/721Write Data.Trie2019-07-07T19:17:16ZjpbernardyWrite Data.TriePull the various Trie implementations that lie around, and make something that has (roughly) the same interface as Data.Map, but for lists as keys.
See this thread on the libraries mailing list.
http://www.haskell.org//pipermail/librari...Pull the various Trie implementations that lie around, and make something that has (roughly) the same interface as Data.Map, but for lists as keys.
See this thread on the libraries mailing list.
http://www.haskell.org//pipermail/libraries/2005-February/003217.html
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.4.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Write Data.Trie","status":"New","operating_system":"Unknown","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.1","keywords":["collections"],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Task","description":"Pull the various Trie implementations that lie around, and make something that has (roughly) the same interface as Data.Map, but for lists as keys.\r\n\r\nSee this thread on the libraries mailing list.\r\nhttp://www.haskell.org//pipermail/libraries/2005-February/003217.html","type_of_failure":"OtherFailure","blocking":[]} -->6.8.1jpbernardyjpbernardyhttps://gitlab.haskell.org/ghc/ghc/-/issues/722Adrian Hey's StringMap library in the collections package.2019-07-07T19:17:16ZjpbernardyAdrian Hey's StringMap library in the collections package.- Bring Adrian Hey's StringMap to a higher level of completeness, so it can be made an instance of the Map class.
- Add an abstraction layer, as close a possible to Data.Map, so it can be a drop-in replacement in most cases.- Bring Adrian Hey's StringMap to a higher level of completeness, so it can be made an instance of the Map class.
- Add an abstraction layer, as close a possible to Data.Map, so it can be a drop-in replacement in most cases.Not GHCAdrian Hey (if he accepts)Adrian Hey (if he accepts)https://gitlab.haskell.org/ghc/ghc/-/issues/723The package database should be a directory of files instead of a single file2019-07-07T19:17:16ZSimon MarlowThe package database should be a directory of files instead of a single fileThis would help package systems that want to install packages by just unpacking a bunch of files onto the filesystem, amongst other things.
See: [http://www.haskell.org//pipermail/glasgow-haskell-users/2006-March/009838.html](http://www...This would help package systems that want to install packages by just unpacking a bunch of files onto the filesystem, amongst other things.
See: [http://www.haskell.org//pipermail/glasgow-haskell-users/2006-March/009838.html](http://www.haskell.org//pipermail/glasgow-haskell-users/2006-March/009838.html)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.4.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"The package database should be a directory of files instead of a single file","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Task","description":"This would help package systems that want to install packages by just unpacking a bunch of files onto the filesystem, amongst other things.\r\n\r\nSee: [http://www.haskell.org//pipermail/glasgow-haskell-users/2006-March/009838.html]","type_of_failure":"OtherFailure","blocking":[]} -->6.12 branchhttps://gitlab.haskell.org/ghc/ghc/-/issues/724tee complains if used in a process started by ghc2019-07-07T19:17:16Zguesttee complains if used in a process started by ghcI have the following program:
```
import System
main = getArgs >>= system . head
```
i.e., a simple wrapper around the system command. I compile this using
```
ghc -o Sys --make Sys.hs
```
into a binary `Sys`. If I then call
```
./...I have the following program:
```
import System
main = getArgs >>= system . head
```
i.e., a simple wrapper around the system command. I compile this using
```
ghc -o Sys --make Sys.hs
```
into a binary `Sys`. If I then call
```
./Sys "yes | head -n 20000000 | tee /dev/null"
```
the program quits with the message `tee: write error`. I tried on some
machines, and on some I have to increase the argument to `head`, but at
some point it always fails. Calling the shell command directly gives no
error. However, calling
```
./Sys "yes | head -n 20000000" | tee /dev/null
```
(note the difference!) also fails.
This bug is a showstopper for my current project. In my program, I call
other programs which internally employ tee for logging. Whenever there
is a lot of screen output, there seems to be a good chance that my program
fails.
I have no idea if this is a problem with `tee` or with `ghc`, but I couldn't
yet reproduce it in any non-ghc context.
Andres Loeh
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"tee complains if used in a process started by ghc","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"I have the following program:\r\n{{{\r\nimport System\r\n\r\nmain = getArgs >>= system . head\r\n}}}\r\ni.e., a simple wrapper around the system command. I compile this using\r\n{{{\r\nghc -o Sys --make Sys.hs\r\n}}}\r\ninto a binary `Sys`. If I then call\r\n{{{\r\n./Sys \"yes | head -n 20000000 | tee /dev/null\"\r\n}}}\r\nthe program quits with the message `tee: write error`. I tried on some\r\nmachines, and on some I have to increase the argument to `head`, but at\r\nsome point it always fails. Calling the shell command directly gives no\r\nerror. However, calling\r\n{{{\r\n./Sys \"yes | head -n 20000000\" | tee /dev/null\r\n}}}\r\n(note the difference!) also fails.\r\n\r\nThis bug is a showstopper for my current project. In my program, I call\r\nother programs which internally employ tee for logging. Whenever there\r\nis a lot of screen output, there seems to be a good chance that my program\r\nfails.\r\n\r\nI have no idea if this is a problem with `tee` or with `ghc`, but I couldn't\r\nyet reproduce it in any non-ghc context.\r\n\r\nAndres Loeh","type_of_failure":"OtherFailure","blocking":[]} -->6.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/725bug with -O2 -optc-O22019-07-07T19:17:15ZBulat Ziganshin <Bulat.Ziganshin@gmail.com>bug with -O2 -optc-O2the attached program can' be compiled with ghc/mingw32 6.4.1 using "-O2 -optc-O2" options
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version ...the attached program can' be compiled with ghc/mingw32 6.4.1 using "-O2 -optc-O2" options
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"bug with -O2 -optc-O2","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"the attached program can' be compiled with ghc/mingw32 6.4.1 using \"-O2 -optc-O2\" options","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/726error messages can include too much source code2019-07-07T19:17:15ZBulat Ziganshin <Bulat.Ziganshin@gmail.com>error messages can include too much source codethe attached program contains bug and when GHC reports this bug, it prints the whole block, which can contain many-many lines
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------...the attached program contains bug and when GHC reports this bug, it prints the whole block, which can contain many-many lines
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.4.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"error messages can include too much source code","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"FeatureRequest","description":"the attached program contains bug and when GHC reports this bug, it prints the whole block, which can contain many-many lines","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/727Write a generic Trie.2019-07-07T19:17:15ZjpbernardyWrite a generic Trie.Write a generic Trie.
See this thread:
http://www.haskell.org//pipermail/libraries/2006-March/004974.html
Other useful URLs:
- http://www.informatik.uni-bonn.de/\~ralf/publications/Masses.pdf
- http://www.eyrie.org/\~zednenem/2006/gen...Write a generic Trie.
See this thread:
http://www.haskell.org//pipermail/libraries/2006-March/004974.html
Other useful URLs:
- http://www.informatik.uni-bonn.de/\~ralf/publications/Masses.pdf
- http://www.eyrie.org/\~zednenem/2006/gentrie/https://gitlab.haskell.org/ghc/ghc/-/issues/728switch to compacting collection when swapping occurs2019-07-07T19:17:14ZSimon Marlowswitch to compacting collection when swapping occursOne avenue for tuning the GC to work better in low memory conditions is for it to auto-switch to compacting collection when swapping is happening. We can detect swapping using `getrusage()` on Unix systems. See:
[http://www.haskell.org/...One avenue for tuning the GC to work better in low memory conditions is for it to auto-switch to compacting collection when swapping is happening. We can detect swapping using `getrusage()` on Unix systems. See:
[http://www.haskell.org//pipermail/glasgow-haskell-users/2006-March/009863.html](http://www.haskell.org//pipermail/glasgow-haskell-users/2006-March/009863.html)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.4.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"switch to compacting collection when swapping occurs","status":"New","operating_system":"Unknown","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Task","description":"One avenue for tuning the GC to work better in low memory conditions is for it to auto-switch to compacting collection when swapping is happening. We can detect swapping using {{{getrusage()}}} on Unix systems. See:\r\n\r\n[http://www.haskell.org//pipermail/glasgow-haskell-users/2006-March/009863.html]","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/729Build system uses wrong version of include files.2019-07-07T19:17:14ZguestBuild system uses wrong version of include files.The situation: I am building 6.4.1 using 6.4.1. The installed version was by a package installer. Now I want to build a source myself, since I want to see if I can change some things. After the usual stuff and doing make I obtain this er...The situation: I am building 6.4.1 using 6.4.1. The installed version was by a package installer. Now I want to build a source myself, since I want to see if I can change some things. After the usual stuff and doing make I obtain this error message:
```
utils/PrimPacked.lhs:263:0:
Warning: foreign declaration uses deprecated non-standard syntax
In file included from /tmp/ghc25249.hc:5:
/usr/local/lib/ghc-6.4.1/include/HsUnix.h: In function '__hsunix_rtldNext':
/usr/local/lib/ghc-6.4.1/include/HsUnix.h:103: error: 'RTLD_NEXT' undeclared (first use in this function)
/usr/local/lib/ghc-6.4.1/include/HsUnix.h:103: error: (Each undeclared identifier is reported only once
/usr/local/lib/ghc-6.4.1/include/HsUnix.h:103: error: for each function it appears in.)
/usr/local/lib/ghc-6.4.1/include/HsUnix.h: In function '__hsunix_rtldDefault':
/usr/local/lib/ghc-6.4.1/include/HsUnix.h:107: error: 'RTLD_DEFAULT' undeclared (first use in this function)
<<ghc: 50080464 bytes, 11 GCs, 1535164/2972296 avg/max bytes residency (2 samples), 19M in use, 0.13 INIT (0.00 elapsed), 0.51 MUT (1.45 elapsed), 0.28 GC (0.36 elapsed) :ghc>>
make[2]: *** [stage1/utils/PrimPacked.o] Error 1
make[1]: *** [all] Error 1
make: *** [build] Error 1
```
Having looked at it for a while and discussing the problem with Arthur van Leeuwen,
we decided that the problem is that the build system uses the HsUnix.h file of the
existing distribution, and not the one from the sources. The problem arises because
these two files are different.https://gitlab.haskell.org/ghc/ghc/-/issues/730ghc needs a man page2019-07-07T19:17:14Zalmeidaraf@yahoo.comghc needs a man pageI think a manual page for ghc would be really nice. I like every binary on my system to have a manual page with its description and ghc doesn't seem to offer one (at least not that I could find). Thank you all for your attention.
<detai...I think a manual page for ghc would be really nice. I like every binary on my system to have a manual page with its description and ghc doesn't seem to offer one (at least not that I could find). Thank you all for your attention.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.4.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"ghc needs a man page","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"FeatureRequest","description":"I think a manual page for ghc would be really nice. I like every binary on my system to have a manual page with its description and ghc doesn't seem to offer one (at least not that I could find). Thank you all for your attention.","type_of_failure":"OtherFailure","blocking":[]} -->6.6.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/731GHCi doesn't work on powerpc642019-07-07T19:17:13ZSimon MarlowGHCi doesn't work on powerpc64See diagnosis from Duncan Coutts:
> [http://www.haskell.org//pipermail/cvs-ghc/2006-March/028889.html](http://www.haskell.org//pipermail/cvs-ghc/2006-March/028889.html)
<details><summary>Trac metadata</summary>
| Trac field ...See diagnosis from Duncan Coutts:
> [http://www.haskell.org//pipermail/cvs-ghc/2006-March/028889.html](http://www.haskell.org//pipermail/cvs-ghc/2006-March/028889.html)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHCi doesn't work on powerpc64","status":"New","operating_system":"Unknown","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"See diagnosis from Duncan Coutts:\r\n\r\n [http://www.haskell.org//pipermail/cvs-ghc/2006-March/028889.html]","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/732Error in shutdownHaskell() in Win32 DLL2019-07-07T19:17:13Zcschmidt@deds.nlError in shutdownHaskell() in Win32 DLLIf an exception occurs in a Windows DLL produced by GHC,
the following error message appears:
```
ghcDll: internal error: too many hs_exit()s
Please report this as a bug to glasgow-haskell-bugs@haskell.org,
or http://www.sourcef...If an exception occurs in a Windows DLL produced by GHC,
the following error message appears:
```
ghcDll: internal error: too many hs_exit()s
Please report this as a bug to glasgow-haskell-bugs@haskell.org,
or http://www.sourceforge.net/projects/ghc/
```
## How to reproduce
1. Make a Haskell DLL using the enclosed Dll.hs and dllMain.c, e.g.
```
ghc -c Dll.hs -fglasgow-exts
ghc -c dllMain.c
ghc --mk-dll -o test.dll Dll.o Dll_stub.o dllMain.o
```
1. Generate an export library for the DLL, e.g.
```
lib /DEF:test.def /MACHINE:x86 /OUT:test.lib
```
1. Compile the executable with Visual C++ and run it.
```
cl -c testdll.cpp
link testdll.obj test.lib /OUT:testdll.exe
testdll.exe
```
Note: if I comment out the shutdownHaskell() call from dllMain.c
(the line marked with /\*\*\*/), it works fine.
Kind regards,
Cyril
--- Dll.hs ---
```
module Dll (test) where
foreign export ccall test :: IO ()
test = error "Exception occurred"
```
--- dllMain.c ---
```
#include <windows.h>
#include <Rts.h>
extern void __stginit_Dll(void);
static char* args[] = { "ghcDll", NULL };
BOOL
STDCALL
DllMain
( HANDLE hModule
, DWORD reason
, void* reserved
)
{
if (reason == DLL_PROCESS_ATTACH) {
startupHaskell(1, args, __stginit_Dll);
return TRUE;
} else if (reason == DLL_PROCESS_DETACH) {
/***/ shutdownHaskell();
}
return TRUE;
}
```
--- test.def ---
```
EXPORTS
test
```
--- testdll.cpp ---
```
extern "C" void test();
int main() {
test();
return 0;
}
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Error in shutdownHaskell() in Win32 DLL","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"6.4.2","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"If an exception occurs in a Windows DLL produced by GHC,\r\nthe following error message appears:\r\n\r\n{{{\r\nghcDll: internal error: too many hs_exit()s\r\n Please report this as a bug to glasgow-haskell-bugs@haskell.org,\r\n or http://www.sourceforge.net/projects/ghc/\r\n}}}\r\n\r\n== How to reproduce ==\r\n\r\n1. Make a Haskell DLL using the enclosed Dll.hs and dllMain.c, e.g.\r\n{{{\r\nghc -c Dll.hs -fglasgow-exts\r\nghc -c dllMain.c\r\nghc --mk-dll -o test.dll Dll.o Dll_stub.o dllMain.o\r\n}}}\r\n\r\n2. Generate an export library for the DLL, e.g.\r\n{{{\r\nlib /DEF:test.def /MACHINE:x86 /OUT:test.lib\r\n}}}\r\n\r\n3. Compile the executable with Visual C++ and run it.\r\n{{{\r\ncl -c testdll.cpp\r\nlink testdll.obj test.lib /OUT:testdll.exe\r\ntestdll.exe\r\n}}}\r\n\r\nNote: if I comment out the shutdownHaskell() call from dllMain.c\r\n(the line marked with /***/), it works fine.\r\n\r\nKind regards,\r\n\r\nCyril\r\n\r\n --- Dll.hs ---\r\n{{{\r\nmodule Dll (test) where\r\n\r\nforeign export ccall test :: IO ()\r\n\r\ntest = error \"Exception occurred\"\r\n}}}\r\n\r\n --- dllMain.c ---\r\n{{{\r\n#include <windows.h>\r\n#include <Rts.h>\r\n\r\nextern void __stginit_Dll(void);\r\n\r\nstatic char* args[] = { \"ghcDll\", NULL };\r\n\r\nBOOL\r\nSTDCALL\r\nDllMain\r\n ( HANDLE hModule\r\n , DWORD reason\r\n , void* reserved\r\n )\r\n{\r\n if (reason == DLL_PROCESS_ATTACH) {\r\n startupHaskell(1, args, __stginit_Dll);\r\n return TRUE;\r\n } else if (reason == DLL_PROCESS_DETACH) {\r\n/***/ shutdownHaskell();\r\n }\r\n return TRUE;\r\n}\r\n}}}\r\n\r\n --- test.def ---\r\n{{{\r\nEXPORTS\r\n\ttest\r\n}}}\r\n\r\n --- testdll.cpp ---\r\n{{{\r\nextern \"C\" void test();\r\n\r\nint main() {\r\n\ttest();\r\n\treturn 0;\r\n}\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->6.4.2https://gitlab.haskell.org/ghc/ghc/-/issues/733Problem compiling .lhs files with lines that begin with #2019-07-07T19:17:13ZguestProblem compiling .lhs files with lines that begin with #Lines starting with \# inside a .lhs make ghc yield "lexical error".
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.4.1 ...Lines starting with \# inside a .lhs make ghc yield "lexical error".
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Problem compiling .lhs files with lines that begin with #","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"Lines starting with # inside a .lhs make ghc yield \"lexical error\".","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/734Spurious type variable scope error report2019-07-07T19:17:13Zred5_2@hotmail.comSpurious type variable scope error reportA spurious error message about a variable being out of scope can be triggered by a kind error. The kind error and scope error need not occur in the same function.
This code reproduces the error:
```
data Val v sm = Val
foo :: forall v ...A spurious error message about a variable being out of scope can be triggered by a kind error. The kind error and scope error need not occur in the same function.
This code reproduces the error:
```
data Val v sm = Val
foo :: forall v sm. Val v sm
foo = undefined
where foo1 :: Val v sm
foo1 = bar
-- Correct type signature: bar :: forall v sm. Val v sm
bar :: forall v. Val v
bar = undefined foo
```
The reported error looks like this:
```
GHC internal error: `v' is not in scope
In the type signature: foo1 :: Val v sm
In the definition of `foo':
foo = undefined
where
foo1 :: Val v sm
foo1 = bar
```
A kind error is also reported for the type signature of `bar`.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler (Type checker) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Spurious type variable scope error report","status":"New","operating_system":"","component":"Compiler (Type checker)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"A spurious error message about a variable being out of scope can be triggered by a kind error. The kind error and scope error need not occur in the same function.\r\n\r\nThis code reproduces the error:\r\n\r\n{{{\r\ndata Val v sm = Val\r\nfoo :: forall v sm. Val v sm\r\nfoo = undefined\r\n where foo1 :: Val v sm\r\n foo1 = bar\r\n-- Correct type signature: bar :: forall v sm. Val v sm\r\nbar :: forall v. Val v\r\nbar = undefined foo\r\n}}}\r\n\r\nThe reported error looks like this:\r\n\r\n{{{\r\nGHC internal error: `v' is not in scope\r\nIn the type signature: foo1 :: Val v sm\r\nIn the definition of `foo':\r\n foo = undefined\r\n where\r\n foo1 :: Val v sm\r\n foo1 = bar\r\n}}}\r\n\r\nA kind error is also reported for the type signature of `bar`.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/735Missing case in fgl/Data/Graph/Inductive/Internal/RootPath.hs2019-07-07T19:17:13Zlnagy@fit.eduMissing case in fgl/Data/Graph/Inductive/Internal/RootPath.hsIn the package `fgl', in the file Data/Graph/Inductive/Internal/RootPath.hs
a case is missing from the function `findP' that causes it to crash on
some graphs (but not all).
Patch that fixes the bug:
```
--- RootPath.hs 2006-03-27 18:1...In the package `fgl', in the file Data/Graph/Inductive/Internal/RootPath.hs
a case is missing from the function `findP' that causes it to crash on
some graphs (but not all).
Patch that fixes the bug:
```
--- RootPath.hs 2006-03-27 18:16:26.000000000 -0500
+++ RootPath.hs 2006-03-27 18:16:01.000000000 -0500
@@ -34,6 +34,7 @@
-- | Find the first path in a tree that starts with the given node
findP :: Node -> LRTree a -> [LNode a]
findP _ [] = []
+findP v ((LP []):ps) = findP v ps
findP v ((LP (p@((w,_):_))):ps) | v==w = p
| otherwise = findP v ps
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------- |
| Version | 6.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries (other) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Multiple |
| Architecture | Multiple |
</details>
<!-- {"blocked_by":[],"summary":"Missing case in fgl/Data/Graph/Inductive/Internal/RootPath.hs","status":"New","operating_system":"Multiple","component":"libraries (other)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"Multiple","cc":[""],"type":"Bug","description":"In the package `fgl', in the file Data/Graph/Inductive/Internal/RootPath.hs\r\na case is missing from the function `findP' that causes it to crash on\r\nsome graphs (but not all).\r\n\r\nPatch that fixes the bug:\r\n{{{\r\n\r\n\r\n--- RootPath.hs 2006-03-27 18:16:26.000000000 -0500\r\n+++ RootPath.hs 2006-03-27 18:16:01.000000000 -0500\r\n@@ -34,6 +34,7 @@\r\n -- | Find the first path in a tree that starts with the given node\r\n findP :: Node -> LRTree a -> [LNode a]\r\n findP _ [] = []\r\n+findP v ((LP []):ps) = findP v ps\r\n findP v ((LP (p@((w,_):_))):ps) | v==w = p\r\n | otherwise = findP v ps\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/736Allowing any newtype of the IO monad to be used in FFI and extra optional ent...2019-07-07T19:17:12Zbrianh@metamilk.comAllowing any newtype of the IO monad to be used in FFI and extra optional entry pointHi -
When designing an API it is desirable to be able to encode the correct usage patterns for functions in the API in the type of the functions themselves, rather than relying on the user understanding the documentation and having to us...Hi -
When designing an API it is desirable to be able to encode the correct usage patterns for functions in the API in the type of the functions themselves, rather than relying on the user understanding the documentation and having to use runtime checks to ensure correct usage.
Consider the following callback which uses a typical C API (DirectX) to draw something to the screen:
```
void Render(int width, int height){
Clear();
BeginScene();
DrawSquare();
EndScene();
}
```
In Haskell with the FFI at present, we can define an equivalent API and use it as follows:
```
type RenderCallback = Int -> Int -> IO ()
clear :: IO ()
scene :: IO () -> IO ()
drawSquare :: IO ()
onRender :: RenderCallback -> IO ()
runGraphicsWindow :: IO () -> IO ()
render :: RenderCallback
render w h = do
clear
scene $ do
drawSquare
main = runGraphicsWindow $ do
onRender render
```
This is all very well, but just like the C equivalent, it doesn't encode the fact that drawSquare can only be called between BeginScene and EndScene. For example the following render callback would result in a runtime error or at least an unexpected result for the user:
```
badRender w h = drawSquare
```
To allow the type checker to enforce correct usage, we can use different monads which just wrap the IO monad as follows:
```
newtype RenderM a = RenderM (IO a) deriving (Functor, Monad, MonadIO)
newtype DrawM a = DrawM (IO a) deriving (Functor, Monad, MonadIO)
type RenderCallback = Int -> Int -> RenderM ()
clear :: RenderM ()
scene :: DrawM () -> RenderM ()
drawSquare :: DrawM ()
```
Now the good render function is well typed and the badRender function is ill typed.
With the current GHC implementation, it is possible to provide the interface above by using some fiddly wrapper functions to remove the wrapper monads and replace them with the IO monad, for example:
```
type RenderCallbackIO = Int -> Int -> IO ()
foreign import ccall "wrapper" mkRenderCallbackIO ::
RenderCallbackIO -> IO (FunPtr RenderCallbackIO)
dropRenderM :: RenderCallback -> RenderCallbackIO
dropRenderM f x y = let RenderM io = f x y in io
foreign import ccall api_onRender :: FunPtr RenderCallbackIO -> IO ()
onRender :: RenderCallback -> IO ()
onRender f = mkRenderCallbackIO (dropRenderM f) >>= api_onRender
foreign import ccall api_clear :: IO ()
clear :: RenderM ()
clear = liftIO $ api_clear
```
As far as I can tell, GHC currently optimizes out all the overhead involved in converting between RenderM and IO. However the extra marshalling functions are fiddly to write, in particular since different versions of dropRenderM would be needed for different numbers of arguments in whatever function returns something in RenderM, and all these extra functions also obscure the simplicity of the original design.
Therefore I propose that for any monad M defined by:
```
newtype M a = M (IO a) deriving (Functor, Monad, MonadIO)
```
M a should be able to appear in place of IO a anywhere in a foreign function definition since all 'M' does is to enforce typing on the Haskell side and has no relevance to the foreign language API, just as IO has no relevance to the foreign language either. This would mean we'd no longer have to write extra wrapper functions and rely on the compiler optimizing them out.
A related point is that the "API-safety == type correctness" gained by using different monads can at the moment be subverted because the entry point into a Haskell program is the main function which returns a value of type IO (). This means that initialization code for any API must be able to run in the IO monad. However every monad discussed above allows you to lift IO operations into it, so there is nothing to stop someone trying to make a nested re-initialization of the API in the middle of a callback...
It is necessary to allow IO actions to be lifted into the callback monads so the callbacks can make use of IORefs etc. However it is undesirable to allow the API to be re-initialized (in such a nested way).
Therefore I propose (perhaps this should have been a separate ticket but I don't know how to link two tickets together so I've bundled both issues in this ticket) that there should be an alternative entry point into a Haskell program with the following type:
```
newtype MainM a = MainM (IO a) deriving (Functor, Monad, MonadIO)
_main :: MainM ()
```
with this default implementation:
```
_main = liftIO $ main
```
so that all existing programs will still work.
If _main is explicitly defined by the user, the user's definition should be used instead, and any definition of "main" will have no special significance. This would allow the API's initialization function to be safely typed as:
```
runGraphicsWindow :: IO () -> MainM ()
_main = runGraphicsWindow $ do
onRender render
```
Thus the user would be prevented from making nested calls to the initialization function.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.4.1 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Multiple |
| Architecture | Multiple |
</details>
<!-- {"blocked_by":[],"summary":"Allowing any newtype of the IO monad to be used in FFI and extra optional entry point","status":"New","operating_system":"Multiple","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.1","keywords":["FFI","entry","foreign","monad","point"],"differentials":[],"test_case":"","architecture":"Multiple","cc":[""],"type":"FeatureRequest","description":"Hi -\r\nWhen designing an API it is desirable to be able to encode the correct usage patterns for functions in the API in the type of the functions themselves, rather than relying on the user understanding the documentation and having to use runtime checks to ensure correct usage.\r\nConsider the following callback which uses a typical C API (DirectX) to draw something to the screen:\r\n{{{\r\n void Render(int width, int height){\r\n Clear();\r\n BeginScene();\r\n DrawSquare();\r\n EndScene();\r\n }\r\n}}}\r\n\r\nIn Haskell with the FFI at present, we can define an equivalent API and use it as follows:\r\n{{{\r\n type RenderCallback = Int -> Int -> IO ()\r\n \r\n clear :: IO ()\r\n scene :: IO () -> IO ()\r\n drawSquare :: IO ()\r\n\r\n onRender :: RenderCallback -> IO ()\r\n runGraphicsWindow :: IO () -> IO ()\r\n\r\n render :: RenderCallback\r\n render w h = do\r\n clear\r\n scene $ do\r\n drawSquare\r\n\r\n main = runGraphicsWindow $ do\r\n onRender render\r\n}}}\r\n\r\nThis is all very well, but just like the C equivalent, it doesn't encode the fact that drawSquare can only be called between BeginScene and EndScene. For example the following render callback would result in a runtime error or at least an unexpected result for the user:\r\n{{{\r\n badRender w h = drawSquare\r\n}}}\r\n\r\nTo allow the type checker to enforce correct usage, we can use different monads which just wrap the IO monad as follows:\r\n{{{\r\n newtype RenderM a = RenderM (IO a) deriving (Functor, Monad, MonadIO)\r\n newtype DrawM a = DrawM (IO a) deriving (Functor, Monad, MonadIO)\r\n\r\n type RenderCallback = Int -> Int -> RenderM ()\r\n\r\n clear :: RenderM ()\r\n scene :: DrawM () -> RenderM ()\r\n drawSquare :: DrawM ()\r\n}}}\r\nNow the good render function is well typed and the badRender function is ill typed.\r\n\r\nWith the current GHC implementation, it is possible to provide the interface above by using some fiddly wrapper functions to remove the wrapper monads and replace them with the IO monad, for example:\r\n{{{\r\n type RenderCallbackIO = Int -> Int -> IO ()\r\n\r\n foreign import ccall \"wrapper\" mkRenderCallbackIO ::\r\n RenderCallbackIO -> IO (FunPtr RenderCallbackIO)\r\n\r\n dropRenderM :: RenderCallback -> RenderCallbackIO\r\n dropRenderM f x y = let RenderM io = f x y in io\r\n\r\n foreign import ccall api_onRender :: FunPtr RenderCallbackIO -> IO ()\r\n\r\n onRender :: RenderCallback -> IO ()\r\n onRender f = mkRenderCallbackIO (dropRenderM f) >>= api_onRender\r\n\r\n foreign import ccall api_clear :: IO ()\r\n\r\n clear :: RenderM ()\r\n clear = liftIO $ api_clear\r\n}}}\r\nAs far as I can tell, GHC currently optimizes out all the overhead involved in converting between RenderM and IO. However the extra marshalling functions are fiddly to write, in particular since different versions of dropRenderM would be needed for different numbers of arguments in whatever function returns something in RenderM, and all these extra functions also obscure the simplicity of the original design.\r\n\r\nTherefore I propose that for any monad M defined by:\r\n{{{\r\n newtype M a = M (IO a) deriving (Functor, Monad, MonadIO)\r\n}}}\r\nM a should be able to appear in place of IO a anywhere in a foreign function definition since all 'M' does is to enforce typing on the Haskell side and has no relevance to the foreign language API, just as IO has no relevance to the foreign language either. This would mean we'd no longer have to write extra wrapper functions and rely on the compiler optimizing them out.\r\n\r\nA related point is that the \"API-safety == type correctness\" gained by using different monads can at the moment be subverted because the entry point into a Haskell program is the main function which returns a value of type IO (). This means that initialization code for any API must be able to run in the IO monad. However every monad discussed above allows you to lift IO operations into it, so there is nothing to stop someone trying to make a nested re-initialization of the API in the middle of a callback...\r\n\r\nIt is necessary to allow IO actions to be lifted into the callback monads so the callbacks can make use of IORefs etc. However it is undesirable to allow the API to be re-initialized (in such a nested way).\r\n\r\nTherefore I propose (perhaps this should have been a separate ticket but I don't know how to link two tickets together so I've bundled both issues in this ticket) that there should be an alternative entry point into a Haskell program with the following type:\r\n{{{\r\n newtype MainM a = MainM (IO a) deriving (Functor, Monad, MonadIO)\r\n\r\n _main :: MainM ()\r\n}}}\r\nwith this default implementation:\r\n{{{\r\n _main = liftIO $ main\r\n}}}\r\nso that all existing programs will still work.\r\nIf _main is explicitly defined by the user, the user's definition should be used instead, and any definition of \"main\" will have no special significance. This would allow the API's initialization function to be safely typed as:\r\n{{{\r\n runGraphicsWindow :: IO () -> MainM ()\r\n\r\n _main = runGraphicsWindow $ do\r\n onRender render\r\n}}}\r\nThus the user would be prevented from making nested calls to the initialization function.","type_of_failure":"OtherFailure","blocking":[]} -->6.8.1Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/737Pattern match failure in coreSyn/CoreUtils.lhs2019-07-07T19:17:12ZekarttunPattern match failure in coreSyn/CoreUtils.lhsThis seems to fail with 6.4.1, and 6.5 too, works fine in ghci.
```
e@yui:~/CONFI/nir$ ghc -c -no-recomp bug.hs
ghc-6.4.2.20060328: panic! (the `impossible' happened, GHC version 6.4.2.20060328):
coreSyn/CoreUtils.lhs:(617,36)-...This seems to fail with 6.4.1, and 6.5 too, works fine in ghci.
```
e@yui:~/CONFI/nir$ ghc -c -no-recomp bug.hs
ghc-6.4.2.20060328: panic! (the `impossible' happened, GHC version 6.4.2.20060328):
coreSyn/CoreUtils.lhs:(617,36)-(618,71): Non-exhaustive patterns in case
Please report this as a compiler bug. See:
http://www.haskell.org/ghc/reportabug
```
```
{-# OPTIONS -fglasgow-exts -O2 #-}
data IHandler st where
IHandler :: Serialize (TxContext ev) => String -> IO ev -> (res -> IO ()) -> Ev st ev res -> IHandler st
data Ev st ev res = Ev
data TxContext evt = TxContext
data TxConfig = TxConfig
data M a = M a
class Serialize a where
instance Serialize a => Serialize (TxContext a)
instance Serialize Int
instance Serialize ()
data IHR st = forall res ev. Serialize (TxContext ev) => IHR (TxContext ev)
runHandler :: M (IHR st) -> IHandler st -> IO ()
runHandler queue ih@(IHandler tstring inp out run) = do
runHandler queue ih
main = runHandler undefined $ IHandler "foo" (return ()) undefined undefined
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Pattern match failure in coreSyn/CoreUtils.lhs","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"This seems to fail with 6.4.1, and 6.5 too, works fine in ghci.\r\n\r\n{{{\r\ne@yui:~/CONFI/nir$ ghc -c -no-recomp bug.hs \r\nghc-6.4.2.20060328: panic! (the `impossible' happened, GHC version 6.4.2.20060328):\r\n coreSyn/CoreUtils.lhs:(617,36)-(618,71): Non-exhaustive patterns in case\r\n\r\n\r\nPlease report this as a compiler bug. See:\r\n http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\n\r\n{{{\r\n{-# OPTIONS -fglasgow-exts -O2 #-}\r\n\r\ndata IHandler st where\r\n IHandler :: Serialize (TxContext ev) => String -> IO ev -> (res -> IO ()) -> Ev st ev res -> IHandler st\r\n\r\ndata Ev st ev res = Ev\r\ndata TxContext evt = TxContext\r\ndata TxConfig = TxConfig\r\ndata M a = M a\r\n\r\nclass Serialize a where\r\ninstance Serialize a => Serialize (TxContext a)\r\ninstance Serialize Int\r\ninstance Serialize ()\r\n\r\ndata IHR st = forall res ev. Serialize (TxContext ev) => IHR (TxContext ev) \r\n\r\n\r\nrunHandler :: M (IHR st) -> IHandler st -> IO ()\r\nrunHandler queue ih@(IHandler tstring inp out run) = do\r\n runHandler queue ih\r\n\r\nmain = runHandler undefined $ IHandler \"foo\" (return ()) undefined undefined\r\n\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/738ghc can't load files with selinux Enforcing2019-07-07T19:17:11Zjon.fairbairn@cl.cam.ac.ukghc can't load files with selinux Enforcingghc fails (not always) to load files when selinux is in Enforcing mode:
----
```
calligramme:~/haskell/
15:49:24$ sudo setenforce Permissive
Password:
calligramme:~/haskell/
15:49:45$ ghci
___ ___ _
/ _ \ /\ /\/ __(...ghc fails (not always) to load files when selinux is in Enforcing mode:
----
```
calligramme:~/haskell/
15:49:24$ sudo setenforce Permissive
Password:
calligramme:~/haskell/
15:49:45$ ghci
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 6.4.1, for Haskell 98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
\____/\/ /_/\____/|_| Type :? for help.
Loading package base-1.0 ... linking ... done.
Prelude> :l State_machine.lhs
Compiling Main ( State_machine.lhs, interpreted )
Ok, modules loaded: Main.
*Main> :q
Leaving GHCi.
calligramme:~/haskell/
15:49:55$ sudo setenforce Enforcing
calligramme:~/haskell/
15:50:06$ ghci
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 6.4.1, for Haskell 98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
\____/\/ /_/\____/|_| Type :? for help.
Loading package base-1.0 ... linking ... done.
Prelude> :l State_machine.lhs
Compiling Main ( State_machine.lhs, interpreted )
ghc-6.4.1: internal error: mallocBytesRWX: failed to protect 0x0x1660730
Please report this as a bug to glasgow-haskell-bugs@haskell.org,
or http://www.sourceforge.net/projects/ghc/
```
This only seems to happen on x86_64
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | x86_64 (amd64) |
</details>
<!-- {"blocked_by":[],"summary":"ghc can't load files with selinux Enforcing","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"x86_64 (amd64)","cc":[""],"type":"Bug","description":"ghc fails (not always) to load files when selinux is in Enforcing mode:\r\n\r\n----\r\n\r\n{{{\r\n calligramme:~/haskell/\r\n15:49:24$ sudo setenforce Permissive\r\nPassword:\r\n calligramme:~/haskell/\r\n15:49:45$ ghci\r\n ___ ___ _\r\n / _ \\ /\\ /\\/ __(_)\r\n / /_\\// /_/ / / | | GHC Interactive, version 6.4.1, for Haskell 98.\r\n/ /_\\\\/ __ / /___| | http://www.haskell.org/ghc/\r\n\\____/\\/ /_/\\____/|_| Type :? for help.\r\n\r\nLoading package base-1.0 ... linking ... done.\r\nPrelude> :l State_machine.lhs\r\nCompiling Main ( State_machine.lhs, interpreted )\r\nOk, modules loaded: Main.\r\n*Main> :q\r\nLeaving GHCi.\r\n calligramme:~/haskell/\r\n15:49:55$ sudo setenforce Enforcing\r\n calligramme:~/haskell/\r\n15:50:06$ ghci\r\n ___ ___ _\r\n / _ \\ /\\ /\\/ __(_)\r\n / /_\\// /_/ / / | | GHC Interactive, version 6.4.1, for Haskell 98.\r\n/ /_\\\\/ __ / /___| | http://www.haskell.org/ghc/\r\n\\____/\\/ /_/\\____/|_| Type :? for help.\r\n\r\nLoading package base-1.0 ... linking ... done.\r\nPrelude> :l State_machine.lhs\r\nCompiling Main ( State_machine.lhs, interpreted )\r\nghc-6.4.1: internal error: mallocBytesRWX: failed to protect 0x0x1660730\r\n\r\n Please report this as a bug to glasgow-haskell-bugs@haskell.org,\r\n or http://www.sourceforge.net/projects/ghc/\r\n\r\n}}}\r\n\r\nThis only seems to happen on x86_64","type_of_failure":"OtherFailure","blocking":[]} -->6.10.1https://gitlab.haskell.org/ghc/ghc/-/issues/739command-line expressions with double-quoted strings misinterpret some special...2019-07-07T19:17:11Zpedromiguel.duarte@gmail.comcommand-line expressions with double-quoted strings misinterpret some special symbolstry for instance
ghc -e " reverse \\"2\<3\\" "
or
ghc -e " reverse \\"2\^3\\" "
The first gives a parsing error,
while the second returns "32" instead of "3\^2"
<details><summary>Trac metadata</summary>
| Trac field | Val...try for instance
ghc -e " reverse \\"2\<3\\" "
or
ghc -e " reverse \\"2\^3\\" "
The first gives a parsing error,
while the second returns "32" instead of "3\^2"
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"command-line expressions with double-quoted strings misinterpret some special symbols","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"try for instance\r\n\r\nghc -e \" reverse \\\"2<3\\\" \"\r\nor\r\nghc -e \" reverse \\\"2^3\\\" \"\r\n\r\nThe first gives a parsing error, \r\nwhile the second returns \"32\" instead of \"3^2\"","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/740Copyright information is wrong in some GHC source files2019-07-07T19:17:11ZguestCopyright information is wrong in some GHC source filesI noticed with some amusement that the copyright in some
of the GHC library files is wrong. It claims the copyright
belongs to the University of Glasgow, but it doesn't
(at least not for all the code).
I know, because I wrote the origina...I noticed with some amusement that the copyright in some
of the GHC library files is wrong. It claims the copyright
belongs to the University of Glasgow, but it doesn't
(at least not for all the code).
I know, because I wrote the original code. And copyright law
states that the author holds the copyright even if the work does
not contain a copyright notice.
An example of such a file is libraries/base/GHC/Float.lhs.
I don't really care if this is fixed our not; I'm happy to share
the code, but a line of attribution doesn't seem like an outrageous
request.
> -- Lennart
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | lowest |
| Resolution | Unresolved |
| Component | Prelude |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Copyright information is wrong in some GHC source files","status":"New","operating_system":"Unknown","component":"Prelude","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"I noticed with some amusement that the copyright in some\r\nof the GHC library files is wrong. It claims the copyright\r\nbelongs to the University of Glasgow, but it doesn't\r\n(at least not for all the code).\r\nI know, because I wrote the original code. And copyright law\r\nstates that the author holds the copyright even if the work does\r\nnot contain a copyright notice.\r\nAn example of such a file is libraries/base/GHC/Float.lhs.\r\n\r\nI don't really care if this is fixed our not; I'm happy to share\r\nthe code, but a line of attribution doesn't seem like an outrageous\r\nrequest.\r\n\r\n -- Lennart","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/741full laziness2019-07-07T19:17:11Zguestfull lazinessGHC 6.4.1 isn't fully lazy as the following code snippet demonstrates.
```
> module Test where
> data Nat = Z | S Nat
> deriving (Show, Eq)
>
> memo f = \ n -> case n of Z -> f_Z
> S...GHC 6.4.1 isn't fully lazy as the following code snippet demonstrates.
```
> module Test where
> data Nat = Z | S Nat
> deriving (Show, Eq)
>
> memo f = \ n -> case n of Z -> f_Z
> S n -> f_S n
> where f_Z = f Z
> f_S = memo (\ y -> f (S y))
>
> fib :: Nat -> Integer
> fib Z = 0
> fib (S Z) = 1
> fib (S (S n)) = fib (S n) + fib n
>
> fib' :: Nat -> Integer
> fib' = memo fib
> where
> fib Z = 0
> fib (S Z) = 1
> fib (S (S n)) = fib' (S n) + fib' n
```
Hugs calculates the memoized version of fib much faster.
Test\> :set +s
Test\> map fib \[0 .. 30\]
\[0,1,1,2,3,5,8,13,21,34,55,89,144,233,377,610,987,1597,2584,4181,6765,10946,17711,28657,46368,75025,121393,196418,317811,514229,832040\]
(21162936 reductions, 29882544 cells, 30 garbage collections)
Test\> map fib' \[0 .. 30\]
\[0,1,1,2,3,5,8,13,21,34,55,89,144,233,377,610,987,1597,2584,4181,6765,10946,17711,28657,46368,75025,121393,196418,317811,514229,832040\]
(18924 reductions, 25176 cells)
By contrast, GHCi gives:
- Test\> :set +s
- Test\> map fib \[0 .. 30\]
\[0,1,1,2,3,5,8,13,21,34,55,89,144,233,377,610,987,1597,2584,4181,6765,10946,17711,28657,46368,75025,121393,196418,317811,514229,832040\]
(5.71 secs, 423333160 bytes)
- Test\> map fib' \[0 .. 30\]
\[0,1,1,2,3,5,8,13,21,34,55,89,144,233,377,610,987,1597,2584,4181,6765,10946,17711,28657,46368,75025,121393,196418,317811,514229,832040\]
(19.75 secs, 2430652680 bytes)
The memoized version is actually slower. The flags
-no-full-laziness and -ffull-laziness seem to have no influence on the performance.
```
> instance Num Nat where
> fromInteger 0 = Z
> fromInteger (n + 1) = S (fromInteger n)
> Z + n = n
> S m + n = S (m + n)
> Z * n = Z
> S m * n = (m * n) + n
> Z - n = Z
> S m - Z = S m
> S m - S n = m - n
>
> instance Enum Nat where
> succ = S
> pred Z = Z
> pred (S n) = n
> toEnum = fromInteger . toInteger
> fromEnum Z = 0
> fromEnum (S n) = fromEnum n + 1
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"full laziness","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"GHC 6.4.1 isn't fully lazy as the following code snippet demonstrates.\r\n\r\n{{{\r\n> module Test where\r\n\r\n> data Nat = Z | S Nat\r\n> deriving (Show, Eq)\r\n>\r\n> memo f = \\ n -> case n of Z -> f_Z\r\n> S n -> f_S n\r\n> where f_Z = f Z\r\n> f_S = memo (\\ y -> f (S y))\r\n>\r\n> fib :: Nat -> Integer\r\n> fib Z = 0\r\n> fib (S Z) = 1\r\n> fib (S (S n)) = fib (S n) + fib n\r\n>\r\n> fib' :: Nat -> Integer\r\n> fib' = memo fib\r\n> where\r\n> fib Z = 0\r\n> fib (S Z) = 1\r\n> fib (S (S n)) = fib' (S n) + fib' n\r\n}}}\r\n\r\nHugs calculates the memoized version of fib much faster.\r\n\r\nTest> :set +s\r\nTest> map fib [0 .. 30]\r\n[0,1,1,2,3,5,8,13,21,34,55,89,144,233,377,610,987,1597,2584,4181,6765,10946,17711,28657,46368,75025,121393,196418,317811,514229,832040]\r\n(21162936 reductions, 29882544 cells, 30 garbage collections)\r\nTest> map fib' [0 .. 30]\r\n[0,1,1,2,3,5,8,13,21,34,55,89,144,233,377,610,987,1597,2584,4181,6765,10946,17711,28657,46368,75025,121393,196418,317811,514229,832040]\r\n(18924 reductions, 25176 cells)\r\n\r\nBy contrast, GHCi gives:\r\n\r\n*Test> :set +s\r\n*Test> map fib [0 .. 30]\r\n[0,1,1,2,3,5,8,13,21,34,55,89,144,233,377,610,987,1597,2584,4181,6765,10946,17711,28657,46368,75025,121393,196418,317811,514229,832040]\r\n(5.71 secs, 423333160 bytes)\r\n*Test> map fib' [0 .. 30]\r\n[0,1,1,2,3,5,8,13,21,34,55,89,144,233,377,610,987,1597,2584,4181,6765,10946,17711,28657,46368,75025,121393,196418,317811,514229,832040]\r\n(19.75 secs, 2430652680 bytes)\r\n\r\nThe memoized version is actually slower. The flags\r\n\r\n\t-no-full-laziness and -ffull-laziness seem to have no influence on the performance.\r\n\r\n{{{\r\n> instance Num Nat where\r\n> fromInteger 0 = Z\r\n> fromInteger (n + 1) = S (fromInteger n)\r\n> Z + n = n\r\n> S m + n = S (m + n)\r\n> Z * n = Z\r\n> S m * n = (m * n) + n\r\n> Z - n = Z\r\n> S m - Z = S m\r\n> S m - S n = m - n\r\n>\r\n> instance Enum Nat where\r\n> succ = S\r\n> pred Z = Z\r\n> pred (S n) = n\r\n> toEnum = fromInteger . toInteger\r\n> fromEnum Z = 0\r\n> fromEnum (S n) = fromEnum n + 1\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/742HGL broken on Windows2019-07-07T19:17:10ZguestHGL broken on WindowsThe following program (example from "The Haskell School of Expression") runs very slowly, often taking a couple of minutes to create a window:
```
import Graphics.SOE
main = runGraphics (
do w <- openWindow "Hello" (300,300)
draw...The following program (example from "The Haskell School of Expression") runs very slowly, often taking a couple of minutes to create a window:
```
import Graphics.SOE
main = runGraphics (
do w <- openWindow "Hello" (300,300)
drawInWindow w (text(100,200) "Hello world!")
k <- getKey w
closeWindow w
)
```
Using: GHC 6.4.1 release (msi installer).
System: Windows 2000 sp4, 5.00.2195
GCC: 3.4.2 (mingw-special)
make:
```
C:\Documents and Settings\Administrator\My Documents\progging_projects\Haskell>ghc --make -v -dcore-lint main.hs
Glasgow Haskell Compiler, Version 6.4.1, for Haskell 98, compiled by GHC version 6.4
Using package config file: C:\ghc\ghc-6.4.1\package.conf
Hsc static flags: -static
*** Chasing dependencies:
Chasing modules from: main.hs
Stable modules:
*** Compiling Main ( main.hs, main.o ):
compile: input file main.hs
*** Checking old interface for Main:
Skipping Main ( main.hs, main.o )
*** Deleting temp files
Deleting: C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ghc2064.s
Warning: deleting non-existent C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/ghc2064.s
Upsweep completely successful.
*** Deleting temp files
Deleting:
link: linkables are ...
LinkableM (Mon Apr 10 00:14:25 Eastern Daylight Time 2006) Main
[DotO main.o]
Linking ...
*** Linker
C:\ghc\ghc-6.4.1\gcc -BC:\ghc\ghc-6.4.1\gcc-lib/ -v -o main.exe -DDONT_WANT_WIN32_DLL_SUPPORT main.o -LC:/ghc/ghc-6.4.1
-LC:/ghc/ghc-6.4.1/gcc-lib -lHSHGL -lHSWin32 -lHSWin32_cbits -luser32 -lgdi32 -lwinmm -lkernel32 -ladvapi32 -lHSbase -lH
Sbase_cbits -lwsock32 -lmsvcrt -lkernel32 -luser32 -lshell32 -lHSrts -lm -lgmp -lwsock32 -u _GHCziBase_Izh_static_info -
u _GHCziBase_Czh_static_info -u _GHCziFloat_Fzh_static_info -u _GHCziFloat_Dzh_static_info -u _GHCziPtr_Ptr_static_info
-u _GHCziWord_Wzh_static_info -u _GHCziInt_I8zh_static_info -u _GHCziInt_I16zh_static_info -u _GHCziInt_I32zh_static_inf
o -u _GHCziInt_I64zh_static_info -u _GHCziWord_W8zh_static_info -u _GHCziWord_W16zh_static_info -u _GHCziWord_W32zh_stat
ic_info -u _GHCziWord_W64zh_static_info -u _GHCziStable_StablePtr_static_info -u _GHCziBase_Izh_con_info -u _GHCziBase_C
zh_con_info -u _GHCziFloat_Fzh_con_info -u _GHCziFloat_Dzh_con_info -u _GHCziPtr_Ptr_con_info -u _GHCziPtr_FunPtr_con_in
fo -u _GHCziStable_StablePtr_con_info -u _GHCziBase_False_closure -u _GHCziBase_True_closure -u _GHCziPack_unpackCString
_closure -u _GHCziIOBase_stackOverflow_closure -u _GHCziIOBase_heapOverflow_closure -u _GHCziIOBase_NonTermination_closu
re -u _GHCziIOBase_BlockedOnDeadMVar_closure -u _GHCziIOBase_BlockedIndefinitely_closure -u _GHCziIOBase_Deadlock_closur
e -u _GHCziWeak_runFinalizzerBatch_closure -u ___stginit_Prelude
Reading specs from C:/ghc/ghc-6.4.1/gcc-lib/specs
Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw
--enable-threads --disable-nls --enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shared --e
nable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm --disable-libgcj-debug --ena
ble-interpreter --enable-hash-synchronization --enable-libstdcxx-debug
Thread model: win32
gcc version 3.4.2 (mingw-special)
C:/ghc/ghc-6.4.1/gcc-lib/collect2.exe -Bdynamic -o main.exe -u _GHCziBase_Izh_static_info -u _GHCziBase_Czh_static_info
-u _GHCziFloat_Fzh_static_info -u _GHCziFloat_Dzh_static_info -u _GHCziPtr_Ptr_static_info -u _GHCziWord_Wzh_static_inf
o -u _GHCziInt_I8zh_static_info -u _GHCziInt_I16zh_static_info -u _GHCziInt_I32zh_static_info -u _GHCziInt_I64zh_static_
info -u _GHCziWord_W8zh_static_info -u _GHCziWord_W16zh_static_info -u _GHCziWord_W32zh_static_info -u _GHCziWord_W64zh_
static_info -u _GHCziStable_StablePtr_static_info -u _GHCziBase_Izh_con_info -u _GHCziBase_Czh_con_info -u _GHCziFloat_F
zh_con_info -u _GHCziFloat_Dzh_con_info -u _GHCziPtr_Ptr_con_info -u _GHCziPtr_FunPtr_con_info -u _GHCziStable_StablePtr
_con_info -u _GHCziBase_False_closure -u _GHCziBase_True_closure -u _GHCziPack_unpackCString_closure -u _GHCziIOBase_sta
ckOverflow_closure -u _GHCziIOBase_heapOverflow_closure -u _GHCziIOBase_NonTermination_closure -u _GHCziIOBase_BlockedOn
DeadMVar_closure -u _GHCziIOBase_BlockedIndefinitely_closure -u _GHCziIOBase_Deadlock_closure -u _GHCziWeak_runFinalizze
rBatch_closure -u ___stginit_Prelude C:/ghc/ghc-6.4.1/gcc-lib/crt2.o C:/ghc/ghc-6.4.1/gcc-lib/crtbegin.o -LC:/ghc/ghc-6.
4.1 -LC:/ghc/ghc-6.4.1/gcc-lib -LC:/ghc/ghc-6.4.1/gcc-lib -L/mingw/lib/gcc/mingw32/3.4.2 -L/mingw/lib/gcc/mingw32/3.4.2/
../../../../mingw32/lib -L/mingw/lib -L/mingw/lib/gcc/mingw32/3.4.2/../../.. main.o -lHSHGL -lHSWin32 -lHSWin32_cbits -l
user32 -lgdi32 -lwinmm -lkernel32 -ladvapi32 -lHSbase -lHSbase_cbits -lwsock32 -lmsvcrt -lkernel32 -luser32 -lshell32 -l
HSrts -lm -lgmp -lwsock32 -lmingw32 -lgcc -lmoldname -lmingwex -lmsvcrt -luser32 -lkernel32 -ladvapi32 -lshell32 -lmingw
32 -lgcc -lmoldname -lmingwex -lmsvcrt C:/ghc/ghc-6.4.1/gcc-lib/crtend.o
link: done
```Not GHChttps://gitlab.haskell.org/ghc/ghc/-/issues/743-M limit exceeded by a factor of 22019-07-07T19:17:10ZSimon Marlow-M limit exceeded by a factor of 2See
[http://www.haskell.org//pipermail/glasgow-haskell-users/2006-April/009977.html](http://www.haskell.org//pipermail/glasgow-haskell-users/2006-April/009977.html)
<details><summary>Trac metadata</summary>
| Trac field | ...See
[http://www.haskell.org//pipermail/glasgow-haskell-users/2006-April/009977.html](http://www.haskell.org//pipermail/glasgow-haskell-users/2006-April/009977.html)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ----------------------- |
| Version | 6.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | ketil+haskell@ii.uib.no |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"-M limit exceeded by a factor of 2","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"6.6","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["ketil+haskell@ii.uib.no"],"type":"Bug","description":"See\r\n\r\n[http://www.haskell.org//pipermail/glasgow-haskell-users/2006-April/009977.html]","type_of_failure":"OtherFailure","blocking":[]} -->6.6.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/744ghc-pkg lies about location of haddock-interfaces and haddock-html2019-07-07T19:17:10Zavatar@hot.eeghc-pkg lies about location of haddock-interfaces and haddock-htmlI installed ghc from ghc-6.4.1-1.i386.rpm. This places the haddock interfaces and haddock-documenation into /usr/share/doc/ghc-6.4.1/libraries. However
> ghc-pkg field base haddock-interfaces
/usr/share/ghc-6.4.1/html/libraries/base/b...I installed ghc from ghc-6.4.1-1.i386.rpm. This places the haddock interfaces and haddock-documenation into /usr/share/doc/ghc-6.4.1/libraries. However
> ghc-pkg field base haddock-interfaces
/usr/share/ghc-6.4.1/html/libraries/base/base.haddock
> which is wrong. (had to modify package.conf by hand)
Cheers,
> Misha
Additional info:
SuSE 10
\> uname -a
Linux avatar 2.6.13-15.8-default #1 Tue Feb 7 11:07:24 UTC 2006 i686 i686 i386 GNU/Linux
> \> ghc -v
Glasgow Haskell Compiler, Version 6.4.1, for Haskell 98, compiled by GHC version 6.4.1
Using package config file: /usr/lib/ghc-6.4.1/package.conf
Using package config file: /home/avatar/.ghc/i386-linux-6.4.1/package.conf
Hsc static flags: -static
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | x86 |
</details>
<!-- {"blocked_by":[],"summary":"ghc-pkg lies about location of haddock-interfaces and haddock-html","status":"New","operating_system":"","component":"Documentation","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"x86","cc":[""],"type":"Bug","description":"I installed ghc from ghc-6.4.1-1.i386.rpm. This places the haddock interfaces and haddock-documenation into /usr/share/doc/ghc-6.4.1/libraries. However\r\n\r\n> ghc-pkg field base haddock-interfaces\r\n /usr/share/ghc-6.4.1/html/libraries/base/base.haddock\r\n\r\n which is wrong. (had to modify package.conf by hand)\r\n\r\nCheers,\r\n Misha\r\n\r\nAdditional info:\r\n SuSE 10\r\n > uname -a\r\n Linux avatar 2.6.13-15.8-default #1 Tue Feb 7 11:07:24 UTC 2006 i686 i686 i386 GNU/Linux\r\n > ghc -v\r\nGlasgow Haskell Compiler, Version 6.4.1, for Haskell 98, compiled by GHC version 6.4.1\r\nUsing package config file: /usr/lib/ghc-6.4.1/package.conf\r\nUsing package config file: /home/avatar/.ghc/i386-linux-6.4.1/package.conf\r\nHsc static flags: -static","type_of_failure":"OtherFailure","blocking":[]} -->6.6.1pannepannehttps://gitlab.haskell.org/ghc/ghc/-/issues/745GHC should recover better from bad type signatures2019-07-07T19:17:10ZSimon Peyton JonesGHC should recover better from bad type signaturesGHC currently bales out as soon as it finds an ill-kinded top-level type signature.
It didn't use to... it recovered and found more errors. An example is test tcfail113 (see diff below). The change is a consequence of some reorganisatio...GHC currently bales out as soon as it finds an ill-kinded top-level type signature.
It didn't use to... it recovered and found more errors. An example is test tcfail113 (see diff below). The change is a consequence of some reorganisation in TcBinds.
Fixing this would be nice, but perhaps not all that important
Simon
```
*** ./tcfail113.stderr 2003-12-10 14:24:30.000000000 +0000
--- ./tcfail113.comp.stderr 2006-03-30 10:05:53.000000000 +0100
***************
*** 1,12 ****
- tcfail113.hs:7:6:
- Kind error: `Maybe' is not applied to enough type arguments
- In the type signature: f :: [Maybe]
-
- tcfail113.hs:10:7:
- Kind error: Expecting kind `* -> *', but `Int' has kind `*'
- In the type signature: g :: T Int
-
tcfail113.hs:13:5:
Kind error: `Int' is applied to too many type arguments
In the type signature: h :: Int Int
```Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/746ghc panic! with foreign import wrapper involving Bool2019-07-07T19:17:09Zbrianh@metamilk.comghc panic! with foreign import wrapper involving BoolI encounter a strange 'ghc panic' bug when I try to export the function onKeyDown below. I'm using ghc 6.4 and WindowsXP on x86.
The bug seems to be caused by the use of `Bool` in `DumaKeyCallback`, because when I change the `Bool` to a...I encounter a strange 'ghc panic' bug when I try to export the function onKeyDown below. I'm using ghc 6.4 and WindowsXP on x86.
The bug seems to be caused by the use of `Bool` in `DumaKeyCallback`, because when I change the `Bool` to an `Int` everything compiles ok. Therefore I wonder if this is something to do with the compilation of "wrapper" imports not liking a Bool in the type signature?
Anyway here is the full standalone example and session transcript:
```
module Keyboard
( Key(..)
, KeyCallback
, onKeyDown -- compiles fine if this export is commented out
) where
import Foreign.Ptr
data Key
= KeyLButton -- other keys ommitted
| KeyDown
deriving (Enum)
type KeyCallback = Key -> IO ()
type DumaKeyCallback = Bool -> Int -> IO () -- Crashes GHC
-- type DumaKeyCallback = Int -> Int -> IO () -- But this compiles fine!!!! ?
foreign import ccall "wrapper" mkDumaKeyCallback :: DumaKeyCallback -> IO (FunPtr DumaKeyCallback)
toDumaKeyCallback :: KeyCallback -> DumaKeyCallback
toDumaKeyCallback f = \alt key -> f (toEnum key)
foreign import ccall duma_onKeyDown :: FunPtr DumaKeyCallback -> IO ()
onKeyDown :: KeyCallback -> IO ()
onKeyDown f = mkDumaKeyCallback (toDumaKeyCallback f) >>= duma_onKeyDown
```
Transcript:
```
>ghc -fglasgow-exts -fffi -v keyboard.hs
Glasgow Haskell Compiler, Version 6.4, for Haskell 98, compiled by GHC version 6.2.2
Using package config file: c:\ghc\ghc-6.4\package.conf
Hsc static flags: -static
*** Checking old interface for Keyboard:
*** Parser:
*** Renamer/typechecker:
*** Desugar:
Result size = 354
*** Simplify:
Result size = 528
Result size = 443
Result size = 415
*** Tidy Core:
Result size = 415
*** CorePrep:
Result size = 500
*** Stg2Stg:
*** CodeGen:
*** CodeOutput:
*** Deleting temp files
Deleting: C:/DOCUME~1/TYPHON~1/LOCALS~1/Temp/ghc4084.s
Warning: deleting non-existent C:/DOCUME~1/TYPHON~1/LOCALS~1/Temp/ghc4084.s
ghc: panic! (the `impossible' happened, GHC version 6.4):
DsForeign.getPrimTyOf GHCziBase.Bool{(w) tc 3c}
Please report it as a compiler bug to glasgow-haskell-bugs@haskell.org,
or http://sourceforge.net/projects/ghc/.
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.4 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Windows |
| Architecture | x86 |
</details>
<!-- {"blocked_by":[],"summary":"ghc panic! with foreign import wrapper involving Bool","status":"New","operating_system":"Windows","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4","keywords":["Bool","DsForeign","FFI"],"differentials":[],"test_case":"","architecture":"x86","cc":[""],"type":"Bug","description":"I encounter a strange 'ghc panic' bug when I try to export the function onKeyDown below. I'm using ghc 6.4 and WindowsXP on x86.\r\n\r\nThe bug seems to be caused by the use of {{{Bool}}} in {{{DumaKeyCallback}}}, because when I change the {{{Bool}}} to an {{{Int}}} everything compiles ok. Therefore I wonder if this is something to do with the compilation of \"wrapper\" imports not liking a Bool in the type signature?\r\n\r\nAnyway here is the full standalone example and session transcript:\r\n{{{\r\nmodule Keyboard\r\n\t( Key(..)\r\n\t, KeyCallback\r\n\r\n\t, onKeyDown -- compiles fine if this export is commented out\r\n\r\n\t) where\r\n\r\nimport Foreign.Ptr\r\n\r\ndata Key\r\n\t= KeyLButton -- other keys ommitted\r\n\t| KeyDown\r\n\tderiving (Enum)\r\n\r\ntype KeyCallback = Key -> IO ()\r\n\r\ntype DumaKeyCallback = Bool -> Int -> IO () -- Crashes GHC\r\n\r\n-- type DumaKeyCallback = Int -> Int -> IO () -- But this compiles fine!!!! ?\r\n\r\nforeign import ccall \"wrapper\" mkDumaKeyCallback :: DumaKeyCallback -> IO (FunPtr DumaKeyCallback)\r\n\r\ntoDumaKeyCallback :: KeyCallback -> DumaKeyCallback\r\ntoDumaKeyCallback f = \\alt key -> f (toEnum key)\r\n\r\nforeign import ccall duma_onKeyDown :: FunPtr DumaKeyCallback -> IO ()\r\n\r\nonKeyDown :: KeyCallback -> IO ()\r\nonKeyDown f = mkDumaKeyCallback (toDumaKeyCallback f) >>= duma_onKeyDown\r\n}}}\r\nTranscript:\r\n{{{\r\n>ghc -fglasgow-exts -fffi -v keyboard.hs\r\nGlasgow Haskell Compiler, Version 6.4, for Haskell 98, compiled by GHC version 6.2.2\r\nUsing package config file: c:\\ghc\\ghc-6.4\\package.conf\r\nHsc static flags: -static\r\n*** Checking old interface for Keyboard:\r\n*** Parser:\r\n*** Renamer/typechecker:\r\n*** Desugar:\r\n Result size = 354\r\n*** Simplify:\r\n Result size = 528\r\n Result size = 443\r\n Result size = 415\r\n*** Tidy Core:\r\n Result size = 415\r\n*** CorePrep:\r\n Result size = 500\r\n*** Stg2Stg:\r\n*** CodeGen:\r\n*** CodeOutput:\r\n*** Deleting temp files\r\nDeleting: C:/DOCUME~1/TYPHON~1/LOCALS~1/Temp/ghc4084.s\r\nWarning: deleting non-existent C:/DOCUME~1/TYPHON~1/LOCALS~1/Temp/ghc4084.s\r\nghc: panic! (the `impossible' happened, GHC version 6.4):\r\n DsForeign.getPrimTyOf GHCziBase.Bool{(w) tc 3c}\r\n\r\nPlease report it as a compiler bug to glasgow-haskell-bugs@haskell.org,\r\nor http://sourceforge.net/projects/ghc/.\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->6.6https://gitlab.haskell.org/ghc/ghc/-/issues/747Unloading a dll does not clean up properly2019-07-07T19:17:09ZguestUnloading a dll does not clean up properlyWhen a DLL is loaded it calls initUserSignals() and initDefaultHandlers().
This sets up some signal (event) handlers.
When the DLL is unloaded it does not remove those handlers.
This means that if the events happen after the DLL has been...When a DLL is loaded it calls initUserSignals() and initDefaultHandlers().
This sets up some signal (event) handlers.
When the DLL is unloaded it does not remove those handlers.
This means that if the events happen after the DLL has been unloaded
it will dispatch into non-loaded code. This is, obviously, bad.
It's very dubious if a DLL should install these handlers at all.
At least there should be a flag if they should be installed or not.
And if installed they should be removed on exit.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.4.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Multiple |
| Architecture | Multiple |
</details>
<!-- {"blocked_by":[],"summary":"Unloading a dll does not clean up properly","status":"New","operating_system":"Multiple","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"Multiple","cc":[""],"type":"Bug","description":"When a DLL is loaded it calls initUserSignals() and initDefaultHandlers().\r\nThis sets up some signal (event) handlers.\r\nWhen the DLL is unloaded it does not remove those handlers.\r\nThis means that if the events happen after the DLL has been unloaded\r\nit will dispatch into non-loaded code. This is, obviously, bad.\r\n\r\nIt's very dubious if a DLL should install these handlers at all.\r\nAt least there should be a flag if they should be installed or not.\r\nAnd if installed they should be removed on exit.","type_of_failure":"OtherFailure","blocking":[]} -->6.6https://gitlab.haskell.org/ghc/ghc/-/issues/748VISUAL HASKELL won't find imports2019-07-07T19:17:09ZJorge.Pelizzoni@loria.frVISUAL HASKELL won't find importsI've just installed Visual Haskell (18/04/2006) and things work fine till I try to import any standard package. I've used -v and it just searches in the src directory of the project.
Configuration info:
Visual Haskell 0.1
MS Development...I've just installed Visual Haskell (18/04/2006) and things work fine till I try to import any standard package. I've used -v and it just searches in the src directory of the project.
Configuration info:
Visual Haskell 0.1
MS Development Environment 2003 Version 7.1.3088
Microsoft .NET Framework 1.1 Version 1.1.4322 SP1
Microsoft Windows XP Professional Version 5.1.2600 Service Pack 2 Build 2600
Thanks in advance. Cheers,
Jorge.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"VISUAL HASKELL won't find imports","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I've just installed Visual Haskell (18/04/2006) and things work fine till I try to import any standard package. I've used -v and it just searches in the src directory of the project.\r\n\r\nConfiguration info:\r\nVisual Haskell 0.1\r\nMS Development Environment 2003 Version 7.1.3088\r\nMicrosoft .NET Framework 1.1 Version 1.1.4322 SP1\r\nMicrosoft Windows XP Professional Version 5.1.2600 Service Pack 2 Build 2600\r\n\r\nThanks in advance. Cheers,\r\n\r\nJorge.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/749Building 6.4.2 fails2019-07-07T19:17:09ZguestBuilding 6.4.2 failsTrying to rebuild 6.4.2 with 6.4.2 or 6.4.1 fails for me:
1. ./utils/ghc-pkg/ghc-pkg-inplace --force --update-package \<package.conf.inplace
Reading package info from stdin ... done.
h:\\src-with-old-ghc\\ghc-6.4.2.20060411"\\ghc\\rts"...Trying to rebuild 6.4.2 with 6.4.2 or 6.4.1 fails for me:
1. ./utils/ghc-pkg/ghc-pkg-inplace --force --update-package \<package.conf.inplace
Reading package info from stdin ... done.
h:\\src-with-old-ghc\\ghc-6.4.2.20060411"\\ghc\\rts" doesn't exist or isn't a directory (ignoring)
h:\\src-with-old-ghc\\ghc-6.4.2.20060411"\\ghc\\rts\\gmp" doesn't exist or isn't a directory (ignoring)
h:\\src-with-old-ghc\\ghc-6.4.2.20060411"\\ghc\\includes" doesn't exist or isn't a directory (ignoring)
The reason seems to be some mssing single quotes in package.mk.
-DFPTOOLS_TOP_ABS=\\"${FPTOOLS_TOP_ABS}\\"
to
-DFPTOOLS_TOP_ABS='\\"${FPTOOLS_TOP_ABS}\\"'
fixes that problem.
But maybe I have some other prblem that causes this?
> -- Lennart
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.4.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Building 6.4.2 fails","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Trying to rebuild 6.4.2 with 6.4.2 or 6.4.1 fails for me:\r\n../utils/ghc-pkg/ghc-pkg-inplace --force --update-package <package.conf.inplace\r\nReading package info from stdin ... done.\r\nh:\\src-with-old-ghc\\ghc-6.4.2.20060411\"\\ghc\\rts\" doesn't exist or isn't a directory (ignoring)\r\nh:\\src-with-old-ghc\\ghc-6.4.2.20060411\"\\ghc\\rts\\gmp\" doesn't exist or isn't a directory (ignoring)\r\nh:\\src-with-old-ghc\\ghc-6.4.2.20060411\"\\ghc\\includes\" doesn't exist or isn't a directory (ignoring)\r\n\r\nThe reason seems to be some mssing single quotes in package.mk.\r\n-DFPTOOLS_TOP_ABS=\\\"${FPTOOLS_TOP_ABS}\\\"\r\nto\r\n-DFPTOOLS_TOP_ABS='\\\"${FPTOOLS_TOP_ABS}\\\"'\r\nfixes that problem.\r\n\r\nBut maybe I have some other prblem that causes this?\r\n\r\n -- Lennart","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/750Set -M, -H, -c and other memory-related values based on available virtual/phy...2019-07-07T19:17:08ZSimon MarlowSet -M, -H, -c and other memory-related values based on available virtual/physical memoryFrom John Meacham:
> perhaps if `-M` is not otherwise set, `getrlimit(RLIMIT_AS,..)` could be
> called and the maximum heap size set to just under that, since it is the
> point that the OS will forcefully kill the program anyway.
Ravi ...From John Meacham:
> perhaps if `-M` is not otherwise set, `getrlimit(RLIMIT_AS,..)` could be
> called and the maximum heap size set to just under that, since it is the
> point that the OS will forcefully kill the program anyway.
Ravi Nanavati would like to be able to set the value to a percentage of physical RAM, e.g. `prog +RTS -H256m -M95% -RTS'.
Bulat Ziganshin would like to be able to do the same with `-c\`.https://gitlab.haskell.org/ghc/ghc/-/issues/751ghc 6.4.2 on OS X 10.4.6 fails a compiler error building Crypto-3.0.3.2019-07-07T19:17:08Zgwright@antiope.comghc 6.4.2 on OS X 10.4.6 fails a compiler error building Crypto-3.0.3.I have just installed ghc 6.4.2 on OS X 10.4.6. It was built from source using
ghc 6.4 as a bootstrap compiler. (The build was done using darwinports. Everything
was identical to the darwinports build of 6.4.1 except that `--disable-open...I have just installed ghc 6.4.2 on OS X 10.4.6. It was built from source using
ghc 6.4 as a bootstrap compiler. (The build was done using darwinports. Everything
was identical to the darwinports build of 6.4.1 except that `--disable-openal` and
`--disable-alut` had to be specified.)
I have successfully rebuilt haddock and the NewBinary library. When building
the Crypto library (version 3.0.3), I get odd and not consistently reproducible
errors.
The `./Setup configure` phase runs fine, but the `./Setup build` phase fails. Having
run this a few times, I've seen shell return values of 1(once), 11 (once) and 10 (several times),
but no other error message. Once I did obtain:
```
crossroads-able> sudo ./Setup build
Preprocessing library Crypto-3.0.3...
Preprocessing executables for Crypto-3.0.3...
Building Crypto-3.0.3...
Chasing modules from: Codec.ASN1,Codec.ASN1.BER,Codec.ASN1.InformationFramework,Codec.ASN1.TLV,Codec.ASN1.X509,Codec.ASN1.X509.AttributeCertificateDefinitions,Codec.ASN1.PKCS1v15,Codec.ASN1.PKCS8,Codec.Binary.Base64,Codec.Encryption.RSA,Codec.Encryption.RSA.EMEOAEP,Codec.Encryption.RSA.MGF,Codec.Encryption.RSA.NumberTheory,Codec.Encryption.DES,Codec.Encryption.AES,Codec.Encryption.Blowfish,Codec.Encryption.Modes,Codec.Encryption.Padding,Codec.Text.Raw,Codec.Utils,Data.Digest.MD5,Data.Digest.SHA1,Data.LargeWord,Codec.Encryption.BlowfishAux,Codec.Encryption.DESAux,Data.Digest.SHA1Aux,Codec.Encryption.AESAux,Data.Digest.MD5Aux
Compiling Data.Digest.MD5Aux ( ./Data/Digest/MD5Aux.hs, dist/build/Data/Digest/MD5Aux.o )
./Data/Digest/MD5Aux.hs:107:0:
Warning: No explicit method nor default method for `*'
In the instance declaration for `Num ABCD'
./Data/Digest/MD5Aux.hs:107:0:
Warning: No explicit method nor default method for `abs'
In the instance declaration for `Num ABCD'
./Data/Digest/MD5Aux.hs:107:0:
Warning: No explicit method nor default method for `signum'
In the instance declaration for `Num ABCD'
./Data/Digest/MD5Aux.hs:107:0:
Warning: No explicit method nor default method for `fromInteger'
In the instance declaration for `Num ABCD'
ghc-6.4.2: internal error: scavenge_stack: weird activation record found on stack: 0
Please report this as a compiler bug. See:
http://www.haskell.org/ghc/reportabug
```
Any ideas?
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.4.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | MacOS X |
| Architecture | powerpc |
</details>
<!-- {"blocked_by":[],"summary":"ghc 6.4.2 on OS X 10.4.6 fails a compiler error building Crypto-3.0.3.","status":"New","operating_system":"MacOS X","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"powerpc","cc":[""],"type":"Bug","description":"I have just installed ghc 6.4.2 on OS X 10.4.6. It was built from source using\r\nghc 6.4 as a bootstrap compiler. (The build was done using darwinports. Everything\r\nwas identical to the darwinports build of 6.4.1 except that {{{--disable-openal}}} and\r\n{{{--disable-alut}}} had to be specified.)\r\n\r\nI have successfully rebuilt haddock and the NewBinary library. When building\r\nthe Crypto library (version 3.0.3), I get odd and not consistently reproducible\r\nerrors.\r\n\r\nThe {{{./Setup configure}}} phase runs fine, but the {{{./Setup build}}} phase fails. Having\r\nrun this a few times, I've seen shell return values of 1(once), 11 (once) and 10 (several times),\r\nbut no other error message. Once I did obtain:\r\n\r\n{{{\r\ncrossroads-able> sudo ./Setup build\r\nPreprocessing library Crypto-3.0.3...\r\nPreprocessing executables for Crypto-3.0.3...\r\nBuilding Crypto-3.0.3...\r\nChasing modules from: Codec.ASN1,Codec.ASN1.BER,Codec.ASN1.InformationFramework,Codec.ASN1.TLV,Codec.ASN1.X509,Codec.ASN1.X509.AttributeCertificateDefinitions,Codec.ASN1.PKCS1v15,Codec.ASN1.PKCS8,Codec.Binary.Base64,Codec.Encryption.RSA,Codec.Encryption.RSA.EMEOAEP,Codec.Encryption.RSA.MGF,Codec.Encryption.RSA.NumberTheory,Codec.Encryption.DES,Codec.Encryption.AES,Codec.Encryption.Blowfish,Codec.Encryption.Modes,Codec.Encryption.Padding,Codec.Text.Raw,Codec.Utils,Data.Digest.MD5,Data.Digest.SHA1,Data.LargeWord,Codec.Encryption.BlowfishAux,Codec.Encryption.DESAux,Data.Digest.SHA1Aux,Codec.Encryption.AESAux,Data.Digest.MD5Aux\r\nCompiling Data.Digest.MD5Aux ( ./Data/Digest/MD5Aux.hs, dist/build/Data/Digest/MD5Aux.o )\r\n\r\n./Data/Digest/MD5Aux.hs:107:0:\r\n Warning: No explicit method nor default method for `*'\r\n In the instance declaration for `Num ABCD'\r\n\r\n./Data/Digest/MD5Aux.hs:107:0:\r\n Warning: No explicit method nor default method for `abs'\r\n In the instance declaration for `Num ABCD'\r\n\r\n./Data/Digest/MD5Aux.hs:107:0:\r\n Warning: No explicit method nor default method for `signum'\r\n In the instance declaration for `Num ABCD'\r\n\r\n./Data/Digest/MD5Aux.hs:107:0:\r\n Warning: No explicit method nor default method for `fromInteger'\r\n In the instance declaration for `Num ABCD'\r\nghc-6.4.2: internal error: scavenge_stack: weird activation record found on stack: 0\r\n Please report this as a compiler bug. See:\r\n http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\n\r\nAny ideas?","type_of_failure":"OtherFailure","blocking":[]} -->6.4.3https://gitlab.haskell.org/ghc/ghc/-/issues/752ghc-6.4.2 not running under solaris2019-07-07T19:17:08ZChristian Maederghc-6.4.2 not running under solarisghc-6.4.2 created under solaris goes to sleep and does not terminate even for the simplest hs-file.
```
-bash-3.00$ ghc -v --make hello.hs
Glasgow Haskell Compiler, Version 6.4.2, for Haskell 98, compiled by GHC version 6.4.2
Using pack...ghc-6.4.2 created under solaris goes to sleep and does not terminate even for the simplest hs-file.
```
-bash-3.00$ ghc -v --make hello.hs
Glasgow Haskell Compiler, Version 6.4.2, for Haskell 98, compiled by GHC version 6.4.2
Using package config file: /local/home/maeder/ghc-6.4.2/lib/ghc-6.4.2/package.conf
Using package config file: /home/maeder/.ghc/sparc-solaris2-6.4.2/package.conf
Hsc static flags: -static
*** Chasing dependencies:
Chasing modules from: hello.hs
Stable modules:
*** Compiling Main ( hello.hs, interpreted ):
compile: input file hello.hs
*** Checking old interface for Main:
Compiling Main ( hello.hs, hello.o )
*** Parser:
*** Renamer/typechecker:
*** Desugar:
Result size = 10
*** Simplify:
Result size = 10
Result size = 8
Result size = 8
*** Tidy Core:
Result size = 8
*** CorePrep:
Result size = 10
*** Stg2Stg:
*** CodeGen:
*** CodeOutput:
*** C Compiler
gcc -x c /tmp/ghc5623.hc -o /tmp/ghc5623.raw_s -w -fno-strict-aliasing -v -S -Wimplicit -O -D__GLASGOW_HASKELL__=604 -I . -I /local/home/maeder/ghc-6.4.2/lib/ghc-6.4.2/include
Reading specs from /export/local/mirror/sparc-solaris/lang/bin/../lib/gcc/sparc-sun-solaris2.10/3.4.4/specs
Configured with: ../gcc-3.4.4/configure --prefix=/usr/local/lang -program-suffix=_3.4.4 --with-gnu-as --with-as=/usr/local/bin/gnu-as --with-ld=/usr/ccs/bin/ld --enable-version-specific-runtime-libs --enable-languages=c,c++,f77 : (reconfigured) ../gcc-3.4.4/configure --prefix=/usr/local/lang -program-suffix=_3.4.4_s10 --with-as=/usr/ccs/bin/as --with-ld=/usr/ccs/bin/ld --enable-version-specific-runtime-libs --enable-languages=c,c++,f77 : (reconfigured) ../gcc-3.4.4/configure --prefix=/usr/local/lang -program-suffix=_3.4.4 --with-gnu-as --with-as=/usr/local/bin/gnu-as --with-gnu-ld --with-ld=/usr/local/bin/gnu-ld --enable-version-specific-runtime-libs --enable-languages=c,c++,f77 : (reconfigured) ../gcc-3.4.4/configure --prefix=/usr/local/lang -program-suffix=_3.4.4_s10 --with-gnu-as --with-as=/usr/local/bin/gnu-as --with-gnu-ld --with-ld=/usr/local/bin/gnu-ld --enable-version-specific-runtime-libs --enable-languages=c,c++,f77
Thread model: posix
gcc version 3.4.4
/export/local/mirror/sparc-solaris/lang/bin/../libexec/gcc/sparc-sun-solaris2.10/3.4.4/cc1 -quiet -v -I . -I /local/home/maeder/ghc-6.4.2/lib/ghc-6.4.2/include -iprefix /export/local/mirror/sparc-solaris/lang/bin/../lib/gcc/sparc-sun-solaris2.10/3.4.4/ -D__GLASGOW_HASKELL__=604 /tmp/ghc5623.hc -quiet -dumpbase ghc5623.hc -mcpu=v7 -auxbase-strip /tmp/ghc5623.raw_s -O -Wimplicit -w -version -fno-strict-aliasing -o /tmp/ghc5623.raw_s
ignoring nonexistent directory "/export/local/mirror/sparc-solaris/lang/bin/../lib/gcc/sparc-sun-solaris2.10/3.4.4/../../../../sparc-sun-solaris2.10/include"
ignoring duplicate directory "/usr/local/lang/lib/gcc/sparc-sun-solaris2.10/3.4.4/include"
ignoring nonexistent directory "/usr/local/lang/lib/gcc/sparc-sun-solaris2.10/3.4.4/../../../../sparc-sun-solaris2.10/include"
#include "..." search starts here:
#include <...> search starts here:
.
/local/home/maeder/ghc-6.4.2/lib/ghc-6.4.2/include
/export/local/mirror/sparc-solaris/lang/bin/../lib/gcc/sparc-sun-solaris2.10/3.4.4/include
/usr/local/include
/usr/local/lang/include
/usr/include
End of search list.
GNU C version 3.4.4 (sparc-sun-solaris2.10)
compiled by GNU C version 3.4.4.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
```6.4.3https://gitlab.haskell.org/ghc/ghc/-/issues/753DLL generated by ghc does exit()2019-07-07T19:17:07ZguestDLL generated by ghc does exit()If you generate a DLL with ghc there is a number of places in
the runtime system that does exit(). This is not an acceptable
behaviour for a DLL. The user might have loaded a DLL into another
application and will have no chance to save c...If you generate a DLL with ghc there is a number of places in
the runtime system that does exit(). This is not an acceptable
behaviour for a DLL. The user might have loaded a DLL into another
application and will have no chance to save changes, etc.
I will try to fix this problem. A patch will be forthcoming.
> -- Lennart
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.4.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"DLL generated by ghc does exit()","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"If you generate a DLL with ghc there is a number of places in\r\nthe runtime system that does exit(). This is not an acceptable\r\nbehaviour for a DLL. The user might have loaded a DLL into another\r\napplication and will have no chance to save changes, etc.\r\n\r\nI will try to fix this problem. A patch will be forthcoming.\r\n\r\n -- Lennart","type_of_failure":"OtherFailure","blocking":[]} -->6.6https://gitlab.haskell.org/ghc/ghc/-/issues/754EVACUATED object entered2019-07-07T19:17:07Zmatt@mattcox.caEVACUATED object enteredusing GHC 6.4.2 on Mac OS X 10.4.6, darwinports build.
```
Error: Target com.apple.build returned: shell command "cd "/opt/local/var/db/dports/build/_opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_devel_darc...using GHC 6.4.2 on Mac OS X 10.4.6, darwinports build.
```
Error: Target com.apple.build returned: shell command "cd "/opt/local/var/db/dports/build/_opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_devel_darcs/work/darcs-1.0.6" && PREFIX=/opt/local make all" returned error 2
Command output: Rebuild dependencies ...
test -f \Context.hs || echo unknown | ./stringify Context context > \Context.hs
ghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c ThisVersion.lhs
ghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c Autoconf.lhs
ghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c Workaround.hs
ghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c FastPackedString.hs
ghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c Printer.lhs
ghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c DarcsUtils.lhs
ghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c Compat.hs
ghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c AtExit.lhs
ghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c SignalHandler.lhs
ghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c DarcsURL.hs
ghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c Lock.lhs
ghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c CheckFileSystem.lhs
ghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c Exec.lhs
ghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c Curl.hs
ghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c CommandLine.lhs
ghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c PatchMatchData.lhs
ghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c DarcsFlags.lhs
ghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c External.hs
ghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c ColourPrinter.lhs
ghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c UTF8.lhs
ghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c FileName.lhs
ghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c DarcsIO.lhs
ghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c RegChars.lhs
ghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c Map.hs
ghc-6.4.2: internal error: EVACUATED object entered!
Please report this as a compiler bug. See:
http://www.haskell.org/ghc/reportabug
make: *** [Map.o] Error 254
```
Was trying to compile Darcs.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.4.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"EVACUATED object entered","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"using GHC 6.4.2 on Mac OS X 10.4.6, darwinports build.\r\n{{{\r\nError: Target com.apple.build returned: shell command \"cd \"/opt/local/var/db/dports/build/_opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_devel_darcs/work/darcs-1.0.6\" && PREFIX=/opt/local make all\" returned error 2\r\nCommand output: Rebuild dependencies ...\r\ntest -f \\Context.hs || echo unknown | ./stringify Context context > \\Context.hs\r\nghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c ThisVersion.lhs\r\nghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c Autoconf.lhs\r\nghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c Workaround.hs\r\nghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c FastPackedString.hs\r\nghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c Printer.lhs\r\nghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c DarcsUtils.lhs\r\nghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c Compat.hs\r\nghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c AtExit.lhs\r\nghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c SignalHandler.lhs\r\nghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c DarcsURL.hs\r\nghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c Lock.lhs\r\nghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c CheckFileSystem.lhs\r\nghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c Exec.lhs\r\nghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c Curl.hs\r\nghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c CommandLine.lhs\r\nghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c PatchMatchData.lhs\r\nghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c DarcsFlags.lhs\r\nghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c External.hs\r\nghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c ColourPrinter.lhs\r\nghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c UTF8.lhs\r\nghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c FileName.lhs\r\nghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c DarcsIO.lhs\r\nghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c RegChars.lhs\r\nghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c Map.hs\r\nghc-6.4.2: internal error: EVACUATED object entered!\r\n Please report this as a compiler bug. See:\r\n http://www.haskell.org/ghc/reportabug\r\nmake: *** [Map.o] Error 254\r\n}}}\r\nWas trying to compile Darcs.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/755GHC 6.4.2 crashes frequently on OSX Tiger 10.4.62019-07-07T19:17:07ZguestGHC 6.4.2 crashes frequently on OSX Tiger 10.4.6I've installed GHC 6.4.2 through darwinports on my OSX Tiger 10.4.6. It seems to be fairly unstable, since it has crashed on every attempt to compile darcs, hmake and haddock.
Here's the crash-log (compiling darcs).
```
Host Name: ...I've installed GHC 6.4.2 through darwinports on my OSX Tiger 10.4.6. It seems to be fairly unstable, since it has crashed on every attempt to compile darcs, hmake and haddock.
Here's the crash-log (compiling darcs).
```
Host Name: Cube
Date/Time: 2006-04-25 13:29:27.872 -0400
OS Version: 10.4.6 (Build 8I127)
Report Version: 4
Command: ghc-6.4.2
Path: /opt/local/lib/ghc-6.4.2/ghc-6.4.2
Parent: make [3825]
Version: ??? (???)
PID: 3828
Thread: 0
Exception: EXC_BAD_ACCESS (0x0001)
Codes: KERN_INVALID_ADDRESS (0x0001) at 0xfffffffe
Thread 0 Crashed:
0 ghc-6.4.2 0x00a678e4 0x1000 + 10905828
1 ghc-6.4.2 0x00a67b90 0x1000 + 10906512
2 ghc-6.4.2 0x00a60154 0x1000 + 10875220
3 ghc-6.4.2 0x00aa9080 0x1000 + 11174016
4 ghc-6.4.2 0x00a5fb9c 0x1000 + 10873756
5 ghc-6.4.2 0x00a6077c 0x1000 + 10876796
6 ghc-6.4.2 0x00a60634 0x1000 + 10876468
7 ghc-6.4.2 0x00a8bf24 0x1000 + 11054884
8 ghc-6.4.2 0x00a37818 0x1000 + 10709016
9 ghc-6.4.2 0x0000239c 0x1000 + 5020
10 ghc-6.4.2 0x00002244 0x1000 + 4676
Thread 1:
0 libSystem.B.dylib 0x9002c128 semaphore_wait_signal_trap + 8
1 libSystem.B.dylib 0x90030bec pthread_cond_wait + 480
2 ghc-6.4.2 0x00aadbf4 0x1000 + 11193332
3 ghc-6.4.2 0x00aadf80 0x1000 + 11194240
4 ghc-6.4.2 0x00a60224 0x1000 + 10875428
5 ghc-6.4.2 0x00acdd78 0x1000 + 11324792
6 ghc-6.4.2 0x00a5fb9c 0x1000 + 10873756
7 ghc-6.4.2 0x00a5f85c 0x1000 + 10872924
8 ghc-6.4.2 0x00aadc58 0x1000 + 11193432
9 libSystem.B.dylib 0x9002ba68 _pthread_body + 96
Thread 2:
0 libSystem.B.dylib 0x9002c128 semaphore_wait_signal_trap + 8
1 libSystem.B.dylib 0x90030bec pthread_cond_wait + 480
2 ghc-6.4.2 0x00aadbf4 0x1000 + 11193332
3 ghc-6.4.2 0x00aae0c4 0x1000 + 11194564
4 ghc-6.4.2 0x00a5f964 0x1000 + 10873188
5 ghc-6.4.2 0x00a5f85c 0x1000 + 10872924
6 ghc-6.4.2 0x00aadc58 0x1000 + 11193432
7 libSystem.B.dylib 0x9002ba68 _pthread_body + 96
Thread 0 crashed with PPC Thread State 64:
srr0: 0x0000000000a678e4 srr1: 0x000000000000d030 vrsave: 0x0000000000000000
cr: 0x28000224 xer: 0x0000000020000004 lr: 0x0000000000a67b90 ctr: 0x0000000000a67ae4
r0: 0x0000000000000004 r1: 0x00000000bfffc940 r2: 0x0000000000000002 r3: 0x0000000001f45738
r4: 0x0000000000000000 r5: 0x00000000a000416c r6: 0x00000000ffffffff r7: 0x0000000000000001
r8: 0x0000000000000002 r9: 0x00000000fffffff6 r10: 0x0000000000000001 r11: 0x0000000001bbf004
r12: 0x00000000900017b8 r13: 0x0000000000000000 r14: 0x0000000001cc3110 r15: 0x0000000000be0b48
r16: 0x0000000001cc3104 r17: 0x0000000000be0094 r18: 0x0000000001cc2c28 r19: 0x0000000000bdcbb4
r20: 0x0000000000bdcbb4 r21: 0x0000000000bdcbb4 r22: 0x0000000001bbedf0 r23: 0x0000000000000000
r24: 0x0000000001f45b38 r25: 0x0000000001f45738 r26: 0x0000000000000000 r27: 0x0000000000c2d098
r28: 0x0000000000000000 r29: 0x0000000001bbede8 r30: 0x0000000000000002 r31: 0x0000000001bbf004
Binary Images Description:
0x1000 - 0xb7afff ghc-6.4.2 /opt/local/lib/ghc-6.4.2/ghc-6.4.2
0xc37000 - 0xc58fff libreadline.5.0.dylib /opt/local/lib/libreadline.5.0.dylib
0xe05000 - 0xe32fff libgmp.3.dylib /opt/local/lib/libgmp.3.dylib
0x8fe00000 - 0x8fe51fff dyld 44.4 /usr/lib/dyld
0x90000000 - 0x901bbfff libSystem.B.dylib /usr/lib/libSystem.B.dylib
0x90213000 - 0x90218fff libmathCommon.A.dylib /usr/lib/system/libmathCommon.A.dylib
0x965c1000 - 0x965effff libncurses.5.4.dylib /usr/lib/libncurses.5.4.dylib
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.4.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC 6.4.2 crashes frequently on OSX Tiger 10.4.6","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"6.4.2","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.2","keywords":["crash"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I've installed GHC 6.4.2 through darwinports on my OSX Tiger 10.4.6. It seems to be fairly unstable, since it has crashed on every attempt to compile darcs, hmake and haddock.\r\n\r\n\r\nHere's the crash-log (compiling darcs).\r\n{{{\r\n\r\nHost Name: Cube\r\nDate/Time: 2006-04-25 13:29:27.872 -0400\r\nOS Version: 10.4.6 (Build 8I127)\r\nReport Version: 4\r\n\r\nCommand: ghc-6.4.2\r\nPath: /opt/local/lib/ghc-6.4.2/ghc-6.4.2\r\nParent: make [3825]\r\n\r\nVersion: ??? (???)\r\n\r\nPID: 3828\r\nThread: 0\r\n\r\nException: EXC_BAD_ACCESS (0x0001)\r\nCodes: KERN_INVALID_ADDRESS (0x0001) at 0xfffffffe\r\n\r\nThread 0 Crashed:\r\n0 ghc-6.4.2 \t0x00a678e4 0x1000 + 10905828\r\n1 ghc-6.4.2 \t0x00a67b90 0x1000 + 10906512\r\n2 ghc-6.4.2 \t0x00a60154 0x1000 + 10875220\r\n3 ghc-6.4.2 \t0x00aa9080 0x1000 + 11174016\r\n4 ghc-6.4.2 \t0x00a5fb9c 0x1000 + 10873756\r\n5 ghc-6.4.2 \t0x00a6077c 0x1000 + 10876796\r\n6 ghc-6.4.2 \t0x00a60634 0x1000 + 10876468\r\n7 ghc-6.4.2 \t0x00a8bf24 0x1000 + 11054884\r\n8 ghc-6.4.2 \t0x00a37818 0x1000 + 10709016\r\n9 ghc-6.4.2 \t0x0000239c 0x1000 + 5020\r\n10 ghc-6.4.2 \t0x00002244 0x1000 + 4676\r\n\r\nThread 1:\r\n0 libSystem.B.dylib \t0x9002c128 semaphore_wait_signal_trap + 8\r\n1 libSystem.B.dylib \t0x90030bec pthread_cond_wait + 480\r\n2 ghc-6.4.2 \t0x00aadbf4 0x1000 + 11193332\r\n3 ghc-6.4.2 \t0x00aadf80 0x1000 + 11194240\r\n4 ghc-6.4.2 \t0x00a60224 0x1000 + 10875428\r\n5 ghc-6.4.2 \t0x00acdd78 0x1000 + 11324792\r\n6 ghc-6.4.2 \t0x00a5fb9c 0x1000 + 10873756\r\n7 ghc-6.4.2 \t0x00a5f85c 0x1000 + 10872924\r\n8 ghc-6.4.2 \t0x00aadc58 0x1000 + 11193432\r\n9 libSystem.B.dylib \t0x9002ba68 _pthread_body + 96\r\n\r\nThread 2:\r\n0 libSystem.B.dylib \t0x9002c128 semaphore_wait_signal_trap + 8\r\n1 libSystem.B.dylib \t0x90030bec pthread_cond_wait + 480\r\n2 ghc-6.4.2 \t0x00aadbf4 0x1000 + 11193332\r\n3 ghc-6.4.2 \t0x00aae0c4 0x1000 + 11194564\r\n4 ghc-6.4.2 \t0x00a5f964 0x1000 + 10873188\r\n5 ghc-6.4.2 \t0x00a5f85c 0x1000 + 10872924\r\n6 ghc-6.4.2 \t0x00aadc58 0x1000 + 11193432\r\n7 libSystem.B.dylib \t0x9002ba68 _pthread_body + 96\r\n\r\nThread 0 crashed with PPC Thread State 64:\r\n srr0: 0x0000000000a678e4 srr1: 0x000000000000d030 vrsave: 0x0000000000000000\r\n cr: 0x28000224 xer: 0x0000000020000004 lr: 0x0000000000a67b90 ctr: 0x0000000000a67ae4\r\n r0: 0x0000000000000004 r1: 0x00000000bfffc940 r2: 0x0000000000000002 r3: 0x0000000001f45738\r\n r4: 0x0000000000000000 r5: 0x00000000a000416c r6: 0x00000000ffffffff r7: 0x0000000000000001\r\n r8: 0x0000000000000002 r9: 0x00000000fffffff6 r10: 0x0000000000000001 r11: 0x0000000001bbf004\r\n r12: 0x00000000900017b8 r13: 0x0000000000000000 r14: 0x0000000001cc3110 r15: 0x0000000000be0b48\r\n r16: 0x0000000001cc3104 r17: 0x0000000000be0094 r18: 0x0000000001cc2c28 r19: 0x0000000000bdcbb4\r\n r20: 0x0000000000bdcbb4 r21: 0x0000000000bdcbb4 r22: 0x0000000001bbedf0 r23: 0x0000000000000000\r\n r24: 0x0000000001f45b38 r25: 0x0000000001f45738 r26: 0x0000000000000000 r27: 0x0000000000c2d098\r\n r28: 0x0000000000000000 r29: 0x0000000001bbede8 r30: 0x0000000000000002 r31: 0x0000000001bbf004\r\n\r\nBinary Images Description:\r\n 0x1000 - 0xb7afff ghc-6.4.2 \t/opt/local/lib/ghc-6.4.2/ghc-6.4.2\r\n 0xc37000 - 0xc58fff libreadline.5.0.dylib \t/opt/local/lib/libreadline.5.0.dylib\r\n 0xe05000 - 0xe32fff libgmp.3.dylib \t/opt/local/lib/libgmp.3.dylib\r\n0x8fe00000 - 0x8fe51fff dyld 44.4\t/usr/lib/dyld\r\n0x90000000 - 0x901bbfff libSystem.B.dylib \t/usr/lib/libSystem.B.dylib\r\n0x90213000 - 0x90218fff libmathCommon.A.dylib \t/usr/lib/system/libmathCommon.A.dylib\r\n0x965c1000 - 0x965effff libncurses.5.4.dylib \t/usr/lib/libncurses.5.4.dylib\r\n\r\n\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->6.4.2https://gitlab.haskell.org/ghc/ghc/-/issues/756Threaded RTS deadlock when used with Visual Haskell2019-07-07T19:17:06ZSimon MarlowThreaded RTS deadlock when used with Visual HaskellIt has been reported that the threaded RTS on the HEAD doesn't work with Visual Haskell, apparently it hangs.
Reported by Krasimir Angelov, here:
[http://www.haskell.org//pipermail/cvs-ghc/2006-February/028529.html](http://www.haskell....It has been reported that the threaded RTS on the HEAD doesn't work with Visual Haskell, apparently it hangs.
Reported by Krasimir Angelov, here:
[http://www.haskell.org//pipermail/cvs-ghc/2006-February/028529.html](http://www.haskell.org//pipermail/cvs-ghc/2006-February/028529.html)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------------- |
| Version | 6.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | kr.angelov@gmail.com |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Threaded RTS deadlock when used with Visual Haskell","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"6.6","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"simonmar"},"version":"6.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":["kr.angelov@gmail.com"],"type":"Bug","description":"It has been reported that the threaded RTS on the HEAD doesn't work with Visual Haskell, apparently it hangs.\r\n\r\nReported by Krasimir Angelov, here:\r\n\r\n[http://www.haskell.org//pipermail/cvs-ghc/2006-February/028529.html]","type_of_failure":"OtherFailure","blocking":[]} -->6.6Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/757Compiler error when trying to run ZFS2019-07-07T19:17:06Zdeweese@myrealbox.comCompiler error when trying to run ZFSWhen trying to run ZFS.hs in ghci from http://okmij.org/ftp/packages/ZFS.tar.gz, I get:
> ___ ___ _
> / _ \\ /\\ /\\/ __(_)
/ /_\\// /_/ / / \| \| GHC Interactive, version 6.4.2, for Haskell 98.
/ /_\\\\/ __ / /___\| \| http://www.ha...When trying to run ZFS.hs in ghci from http://okmij.org/ftp/packages/ZFS.tar.gz, I get:
> ___ ___ _
> / _ \\ /\\ /\\/ __(_)
/ /_\\// /_/ / / \| \| GHC Interactive, version 6.4.2, for Haskell 98.
/ /_\\\\/ __ / /___\| \| http://www.haskell.org/ghc/
\\____/\\/ /_/\\____/\|_\| Type :? for help.
Loading package base-1.0 ... linking ... done.
Compiling PromptTR ( ./PromptTR.hs, interpreted )
ghc-6.4.2: internal error: mallocBytesRWX: failed to protect 0x0x9b18468
Please report this as a compiler bug. See:
> http://www.haskell.org/ghc/reportabug
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.4.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Compiler error when trying to run ZFS","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"When trying to run ZFS.hs in ghci from http://okmij.org/ftp/packages/ZFS.tar.gz, I get:\r\n ___ ___ _\r\n / _ \\ /\\ /\\/ __(_)\r\n / /_\\// /_/ / / | | GHC Interactive, version 6.4.2, for Haskell 98.\r\n/ /_\\\\/ __ / /___| | http://www.haskell.org/ghc/\r\n\\____/\\/ /_/\\____/|_| Type :? for help.\r\n\r\nLoading package base-1.0 ... linking ... done.\r\nCompiling PromptTR ( ./PromptTR.hs, interpreted )\r\nghc-6.4.2: internal error: mallocBytesRWX: failed to protect 0x0x9b18468\r\n\r\n Please report this as a compiler bug. See:\r\n http://www.haskell.org/ghc/reportabug","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/758Error compiling darcs on Mac OS X2019-07-07T19:17:06Zcharles.gerungan@gmail.comError compiling darcs on Mac OS XThe only reason I'm using ghc is to compile darcs on Mac OS X 10.4.6 build 8I127, so I'm not really sure about anything that's happening here. I've attached the output of the console after compilation failed using Darwinports. Hope it he...The only reason I'm using ghc is to compile darcs on Mac OS X 10.4.6 build 8I127, so I'm not really sure about anything that's happening here. I've attached the output of the console after compilation failed using Darwinports. Hope it helps.
charles\@aluminum \~ $ sudo port -v upgrade darcs
Password:
---\> Configuring darcs
checking for darcs... darcs
checking the release state... release
checking for gcc... gcc
checking for C compiler default output file name... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking how to run the C preprocessor... gcc -E
checking for a BSD-compatible install... /usr/bin/install -c
checking for ghc... ghc
checking where GHC keeps its libraries... /opt/local/lib/ghc-6.4.2
checking GHC.Handle.openFd... NOT old API
checking GHC.Handle.openFd new API... okay
checking for module System.Posix.Signals(installHandler, Handler(..), Signal,
> sigINT, sigHUP, sigABRT, sigALRM, sigTERM, sigPIPE,)... yes
checking for module Text.Regex( mkRegex, matchRegex, Regex )... yes
checking for module Debug.QuickCheck( quickCheck )... in package QuickCheck
checking for module Control.Monad.Error... in package util
checking for module Control.Monad.Error... yes
checking for module Text.ParserCombinators.Parsec... in package parsec
checking getCurrentDirectory... uses /
checking for module System.Posix.Files( createLink )... yes
checking createDirectoryIfMissing... has createDirectoryIfMissing
checking renameFile... okay
checking for module System.Posix.Files( fileMode, getFileStatus, setFileMode )... yes
checking for module System.Posix.Files( fileMode, getFileStatus, setFileMode )... yes
checking whether to optimize... yes
checking whether to profile... no
checking whether to use mmap... yes
checking whether to do PackedString debugging... no
checking whether to use wxhaskell... no
checking whether to build docs... yes
checking for latex... no
configure: WARNING: Cannot find latex in your path!
checking for dvips... no
configure: WARNING: Cannot find dvips in your path!
checking for latex2html... no
configure: WARNING: Cannot find latex2html in your path!
checking for htlatex... no
configure: WARNING: Cannot find htlatex in your path either!
checking for hevea... no
configure: WARNING: Cannot find hevea in your path either!
checking for sendmail... /usr/sbin/sendmail
checking for MAPISendMail in -lmapi32... no
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking for libcurl... 7.15.3
checking for curl_global_init in -lcurl... yes
checking for egrep... grep -E
checking for ANSI C header files... yes
checking for sys/types.h... yes
checking for sys/stat.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for memory.h... yes
checking for strings.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for unistd.h... yes
checking windows.h usability... no
checking windows.h presence... no
checking for windows.h... no
checking term.h usability... yes
checking term.h presence... yes
checking for term.h... yes
checking for library containing tgetent... -lcurses
checking zlib.h usability... yes
checking zlib.h presence... yes
checking for zlib.h... yes
checking for gzopen... yes
checking whether to enable Git support... no
checking for gdiff... no
checking for gnudiff... no
checking for diff... diff
checking for makensis.exe... no
checking whether byte ordering is bigendian... yes
configure: creating ./config.status
config.status: creating autoconf.mk
config.status: creating gitlib.h
config.status: creating Autoconf.lhs
config.status: creating ThisVersion.lhs
config.status: creating cgi/darcs.cgi
config.status: creating cgi/README
config.status: creating cgi/cgi.conf
config.status: executing config.command commands
The build is configured as follows:
bindir = ${exec_prefix}/bin
sbindir = ${exec_prefix}/sbin
mandir = /opt/local/share/man
datadir = ${prefix}/share
sysconfdir = ${prefix}/etc
> libexecdir = ${exec_prefix}/libexec
Build Manual = no
> Git support = no
If you want to adjust any of these values, edit autoconf.mk and
Autoconf.lhs -- or run configure with appropriate settings.
---\> Building darcs with target all
rm -f Main.hi Main.o
ghc -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -optl-L/opt/local/lib -optl-L/opt/local/lib -optl-lcurl -optl-L/opt/local/lib -optl-L/opt/local/lib -optl-lssl -optl-lcrypto -optl-L/opt/local/lib -optl-lz -optl-lcurses -o stringify stringify.hs
/usr/bin/ld: warning prebinding disabled because dependent library: /opt/local/lib/libcurl.3.dylib is not prebound
test -f \\Context.hs \|\| echo unknown \| ./stringify Context context \> \\Context.hs
Rebuild dependencies ...
test -f \\Context.hs \|\| echo unknown \| ./stringify Context context \> \\Context.hs
ghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c ThisVersion.lhs
ghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c Autoconf.lhs
ghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c Workaround.hs
ghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c FastPackedString.hs
ghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c Printer.lhs
ghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c DarcsUtils.lhs
ghc-6.4.2: internal error: scavenge_stack: weird activation record found on stack: 441
Please report this as a compiler bug. See:
> http://www.haskell.org/ghc/reportabug
make: \*\*\* \[DarcsUtils.o\] Error 254
Error: Target com.apple.build returned: shell command "cd "/opt/local/var/db/dports/build/_opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_devel_darcs/work/darcs-1.0.6" && PREFIX=/opt/local make all" returned error 2
Command output: rm -f Main.hi Main.o
ghc -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -optl-L/opt/local/lib -optl-L/opt/local/lib -optl-lcurl -optl-L/opt/local/lib -optl-L/opt/local/lib -optl-lssl -optl-lcrypto -optl-L/opt/local/lib -optl-lz -optl-lcurses -o stringify stringify.hs
/usr/bin/ld: warning prebinding disabled because dependent library: /opt/local/lib/libcurl.3.dylib is not prebound
test -f \\Context.hs \|\| echo unknown \| ./stringify Context context \> \\Context.hs
Rebuild dependencies ...
test -f \\Context.hs \|\| echo unknown \| ./stringify Context context \> \\Context.hs
ghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c ThisVersion.lhs
ghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c Autoconf.lhs
ghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c Workaround.hs
ghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c FastPackedString.hs
ghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c Printer.lhs
ghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c DarcsUtils.lhs
ghc-6.4.2: internal error: scavenge_stack: weird activation record found on stack: 441
Please report this as a compiler bug. See:
> http://www.haskell.org/ghc/reportabug
make: \*\*\* \[DarcsUtils.o\] Error 254
Warning: the following items did not execute (for darcs): com.apple.destroot com.apple.build
Error: Unable to upgrade port: 1
charles\@aluminum \~ $ ghc -v
Glasgow Haskell Compiler, Version 6.4.2, for Haskell 98, compiled by GHC version 6.4.2
Using package config file: /opt/local/lib/ghc-6.4.2/package.conf
Using package config file: /Users/charles/.ghc/powerpc-darwin-6.4.2/package.conf
Hsc static flags: -static
- \*\* Deleting temp files
Deleting:
ghc-6.4.2: no input files
Usage: For basic information, try the \`--help' option.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.4.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Error compiling darcs on Mac OS X","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The only reason I'm using ghc is to compile darcs on Mac OS X 10.4.6 build 8I127, so I'm not really sure about anything that's happening here. I've attached the output of the console after compilation failed using Darwinports. Hope it helps.\r\n\r\n\r\ncharles@aluminum ~ $ sudo port -v upgrade darcs\r\nPassword:\r\n---> Configuring darcs\r\nchecking for darcs... darcs\r\nchecking the release state... release\r\nchecking for gcc... gcc\r\nchecking for C compiler default output file name... a.out\r\nchecking whether the C compiler works... yes\r\nchecking whether we are cross compiling... no\r\nchecking for suffix of executables... \r\nchecking for suffix of object files... o\r\nchecking whether we are using the GNU C compiler... yes\r\nchecking whether gcc accepts -g... yes\r\nchecking for gcc option to accept ANSI C... none needed\r\nchecking how to run the C preprocessor... gcc -E\r\nchecking for a BSD-compatible install... /usr/bin/install -c\r\nchecking for ghc... ghc\r\nchecking where GHC keeps its libraries... /opt/local/lib/ghc-6.4.2\r\nchecking GHC.Handle.openFd... NOT old API\r\nchecking GHC.Handle.openFd new API... okay\r\nchecking for module System.Posix.Signals(installHandler, Handler(..), Signal,\r\n sigINT, sigHUP, sigABRT, sigALRM, sigTERM, sigPIPE,)... yes\r\nchecking for module Text.Regex( mkRegex, matchRegex, Regex )... yes\r\nchecking for module Debug.QuickCheck( quickCheck )... in package QuickCheck\r\nchecking for module Control.Monad.Error... in package util\r\nchecking for module Control.Monad.Error... yes\r\nchecking for module Text.ParserCombinators.Parsec... in package parsec\r\nchecking getCurrentDirectory... uses /\r\nchecking for module System.Posix.Files( createLink )... yes\r\nchecking createDirectoryIfMissing... has createDirectoryIfMissing\r\nchecking renameFile... okay\r\nchecking for module System.Posix.Files( fileMode, getFileStatus, setFileMode )... yes\r\nchecking for module System.Posix.Files( fileMode, getFileStatus, setFileMode )... yes\r\nchecking whether to optimize... yes\r\nchecking whether to profile... no\r\nchecking whether to use mmap... yes\r\nchecking whether to do PackedString debugging... no\r\nchecking whether to use wxhaskell... no\r\nchecking whether to build docs... yes\r\nchecking for latex... no\r\nconfigure: WARNING: Cannot find latex in your path!\r\nchecking for dvips... no\r\nconfigure: WARNING: Cannot find dvips in your path!\r\nchecking for latex2html... no\r\nconfigure: WARNING: Cannot find latex2html in your path!\r\nchecking for htlatex... no\r\nconfigure: WARNING: Cannot find htlatex in your path either!\r\nchecking for hevea... no\r\nconfigure: WARNING: Cannot find hevea in your path either!\r\nchecking for sendmail... /usr/sbin/sendmail\r\nchecking for MAPISendMail in -lmapi32... no\r\nchecking for gawk... no\r\nchecking for mawk... no\r\nchecking for nawk... no\r\nchecking for awk... awk\r\nchecking for libcurl... 7.15.3\r\nchecking for curl_global_init in -lcurl... yes\r\nchecking for egrep... grep -E\r\nchecking for ANSI C header files... yes\r\nchecking for sys/types.h... yes\r\nchecking for sys/stat.h... yes\r\nchecking for stdlib.h... yes\r\nchecking for string.h... yes\r\nchecking for memory.h... yes\r\nchecking for strings.h... yes\r\nchecking for inttypes.h... yes\r\nchecking for stdint.h... yes\r\nchecking for unistd.h... yes\r\nchecking windows.h usability... no\r\nchecking windows.h presence... no\r\nchecking for windows.h... no\r\nchecking term.h usability... yes\r\nchecking term.h presence... yes\r\nchecking for term.h... yes\r\nchecking for library containing tgetent... -lcurses\r\nchecking zlib.h usability... yes\r\nchecking zlib.h presence... yes\r\nchecking for zlib.h... yes\r\nchecking for gzopen... yes\r\nchecking whether to enable Git support... no\r\nchecking for gdiff... no\r\nchecking for gnudiff... no\r\nchecking for diff... diff\r\nchecking for makensis.exe... no\r\nchecking whether byte ordering is bigendian... yes\r\nconfigure: creating ./config.status\r\nconfig.status: creating autoconf.mk\r\nconfig.status: creating gitlib.h\r\nconfig.status: creating Autoconf.lhs\r\nconfig.status: creating ThisVersion.lhs\r\nconfig.status: creating cgi/darcs.cgi\r\nconfig.status: creating cgi/README\r\nconfig.status: creating cgi/cgi.conf\r\nconfig.status: executing config.command commands\r\n\r\nThe build is configured as follows:\r\n\r\n bindir = ${exec_prefix}/bin\r\n sbindir = ${exec_prefix}/sbin\r\n mandir = /opt/local/share/man\r\n datadir = ${prefix}/share\r\n sysconfdir = ${prefix}/etc\r\n libexecdir = ${exec_prefix}/libexec\r\n\r\n Build Manual = no\r\n Git support = no\r\n\r\nIf you want to adjust any of these values, edit autoconf.mk and\r\nAutoconf.lhs -- or run configure with appropriate settings.\r\n\r\n---> Building darcs with target all\r\nrm -f Main.hi Main.o\r\nghc -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -optl-L/opt/local/lib -optl-L/opt/local/lib -optl-lcurl -optl-L/opt/local/lib -optl-L/opt/local/lib -optl-lssl -optl-lcrypto -optl-L/opt/local/lib -optl-lz -optl-lcurses -o stringify stringify.hs\r\n/usr/bin/ld: warning prebinding disabled because dependent library: /opt/local/lib/libcurl.3.dylib is not prebound\r\ntest -f \\Context.hs || echo unknown | ./stringify Context context > \\Context.hs\r\nRebuild dependencies ...\r\ntest -f \\Context.hs || echo unknown | ./stringify Context context > \\Context.hs\r\nghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c ThisVersion.lhs\r\nghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c Autoconf.lhs\r\nghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c Workaround.hs\r\nghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c FastPackedString.hs\r\nghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c Printer.lhs\r\nghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c DarcsUtils.lhs\r\nghc-6.4.2: internal error: scavenge_stack: weird activation record found on stack: 441\r\n Please report this as a compiler bug. See:\r\n http://www.haskell.org/ghc/reportabug\r\nmake: *** [DarcsUtils.o] Error 254\r\nError: Target com.apple.build returned: shell command \"cd \"/opt/local/var/db/dports/build/_opt_local_var_db_dports_sources_rsync.rsync.darwinports.org_dpupdate_dports_devel_darcs/work/darcs-1.0.6\" && PREFIX=/opt/local make all\" returned error 2\r\nCommand output: rm -f Main.hi Main.o\r\nghc -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -optl-L/opt/local/lib -optl-L/opt/local/lib -optl-lcurl -optl-L/opt/local/lib -optl-L/opt/local/lib -optl-lssl -optl-lcrypto -optl-L/opt/local/lib -optl-lz -optl-lcurses -o stringify stringify.hs\r\n/usr/bin/ld: warning prebinding disabled because dependent library: /opt/local/lib/libcurl.3.dylib is not prebound\r\ntest -f \\Context.hs || echo unknown | ./stringify Context context > \\Context.hs\r\nRebuild dependencies ...\r\ntest -f \\Context.hs || echo unknown | ./stringify Context context > \\Context.hs\r\nghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c ThisVersion.lhs\r\nghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c Autoconf.lhs\r\nghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c Workaround.hs\r\nghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c FastPackedString.hs\r\nghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c Printer.lhs\r\nghc -I/opt/local/include -cpp -package QuickCheck -package util -package parsec -O -funbox-strict-fields -I/opt/local/include -Wall -Werror -I. -I/opt/local/include -DHAVE_CURSES -DHAVE_CURL -c DarcsUtils.lhs\r\nghc-6.4.2: internal error: scavenge_stack: weird activation record found on stack: 441\r\n Please report this as a compiler bug. See:\r\n http://www.haskell.org/ghc/reportabug\r\nmake: *** [DarcsUtils.o] Error 254\r\n\r\nWarning: the following items did not execute (for darcs): com.apple.destroot com.apple.build\r\nError: Unable to upgrade port: 1\r\ncharles@aluminum ~ $ ghc -v\r\nGlasgow Haskell Compiler, Version 6.4.2, for Haskell 98, compiled by GHC version 6.4.2\r\nUsing package config file: /opt/local/lib/ghc-6.4.2/package.conf\r\nUsing package config file: /Users/charles/.ghc/powerpc-darwin-6.4.2/package.conf\r\nHsc static flags: -static\r\n*** Deleting temp files\r\nDeleting: \r\nghc-6.4.2: no input files\r\nUsage: For basic information, try the `--help' option.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/759RULES ignored by recompilation checker2019-07-07T19:17:06Zrl@cse.unsw.edu.auRULES ignored by recompilation checkerThe recompilation checker does not seem to take RULES into account. This can lead to some really nasty optimisation bugs. A small example:
```
[rl@rl-lap stuff]$ cat T.hs
module T where
foo n = n+1
{-# RULES
"foo" forall n.
foo (foo n...The recompilation checker does not seem to take RULES into account. This can lead to some really nasty optimisation bugs. A small example:
```
[rl@rl-lap stuff]$ cat T.hs
module T where
foo n = n+1
{-# RULES
"foo" forall n.
foo (foo n) = foo (n+2)
#-}
[rl@rl-lap stuff]$ cat U.hs
module Main where
import T
main = print $ foo (foo 5)
[rl@rl-lap stuff]$ ghc --make U.hs -O
Chasing modules from: U.hs
Compiling T ( ./T.hs, ./T.o )
Compiling Main ( U.hs, U.o )
Linking ...
```
Change the rule in T.hs:
```
[rl@rl-lap stuff]$ cat T.hs
module T where
foo n = n+1
{-# RULES
"foo" forall n.
foo (foo n) = foo (n+3)
#-}
[rl@rl-lap stuff]$ ghc --make U.hs -O
Chasing modules from: U.hs
Compiling T ( ./T.hs, ./T.o )
Skipping Main ( U.hs, U.o )
Linking ...
[rl@rl-lap stuff]$ ghc -c U.hs -O
compilation IS NOT required
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.4.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"RULES ignored by recompilation checker","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"The recompilation checker does not seem to take RULES into account. This can lead to some really nasty optimisation bugs. A small example:\r\n\r\n{{{\r\n[rl@rl-lap stuff]$ cat T.hs\r\nmodule T where\r\nfoo n = n+1\r\n{-# RULES\r\n\"foo\" forall n.\r\n foo (foo n) = foo (n+2)\r\n#-}\r\n\r\n[rl@rl-lap stuff]$ cat U.hs\r\nmodule Main where\r\nimport T\r\nmain = print $ foo (foo 5)\r\n\r\n[rl@rl-lap stuff]$ ghc --make U.hs -O\r\nChasing modules from: U.hs\r\nCompiling T ( ./T.hs, ./T.o )\r\nCompiling Main ( U.hs, U.o )\r\nLinking ...\r\n}}}\r\n\r\nChange the rule in T.hs:\r\n\r\n{{{\r\n[rl@rl-lap stuff]$ cat T.hs\r\nmodule T where\r\nfoo n = n+1\r\n{-# RULES\r\n\"foo\" forall n.\r\n foo (foo n) = foo (n+3)\r\n#-}\r\n\r\n[rl@rl-lap stuff]$ ghc --make U.hs -O\r\nChasing modules from: U.hs\r\nCompiling T ( ./T.hs, ./T.o )\r\nSkipping Main ( U.hs, U.o )\r\nLinking ...\r\n[rl@rl-lap stuff]$ ghc -c U.hs -O\r\ncompilation IS NOT required\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->6.6Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/760Template Haskell doesn't like scoped type variables2019-07-07T19:17:05Zrl@cse.unsw.edu.auTemplate Haskell doesn't like scoped type variablesGHC panics is scoped type variables are used in \[d\| ... \|\]:
```
[rl@rl-lap stuff]$ cat R.hs
$(id [d| f (x :: a) = x |])
[rl@rl-lap stuff]$ ghc -fglasgow-exts -c R.hs
ghc-6.4.2: panic! (the `impossible' happened, GHC version 6.4.2):...GHC panics is scoped type variables are used in \[d\| ... \|\]:
```
[rl@rl-lap stuff]$ cat R.hs
$(id [d| f (x :: a) = x |])
[rl@rl-lap stuff]$ ghc -fglasgow-exts -c R.hs
ghc-6.4.2: panic! (the `impossible' happened, GHC version 6.4.2):
Failed binder lookup: a{tv a18c}
Please report this as a compiler bug. See:
http://www.haskell.org/ghc/reportabug
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.4.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Template Haskell doesn't like scoped type variables","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"GHC panics is scoped type variables are used in [d| ... |]:\r\n{{{\r\n[rl@rl-lap stuff]$ cat R.hs\r\n$(id [d| f (x :: a) = x |])\r\n\r\n[rl@rl-lap stuff]$ ghc -fglasgow-exts -c R.hs\r\nghc-6.4.2: panic! (the `impossible' happened, GHC version 6.4.2):\r\n Failed binder lookup: a{tv a18c}\r\n\r\nPlease report this as a compiler bug. See:\r\n http://www.haskell.org/ghc/reportabug\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->6.6Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/761Occasional Segmentation Fault and strange object 178632019-07-07T19:17:05ZguestOccasional Segmentation Fault and strange object 17863Hello,
I have noticed the last few months GHC throws an occasional segmentation fault. Unfortunately it's not repeatable and is not related to any particular progam. The error happens every couple of weeks or so. I have noticed this pro...Hello,
I have noticed the last few months GHC throws an occasional segmentation fault. Unfortunately it's not repeatable and is not related to any particular progam. The error happens every couple of weeks or so. I have noticed this problem with the following GHC versions:
- 6.4.1 generic linux distribution
- 6.4.1 source distribution compiled with
> configure --prefix=/cadtools/contrib
> make
> make install
- 6.4.2 generic linux distribution
Here's my system info (RHEL3):
\~\> uname -a
Linux nenya 2.4.21-37.ELsmp #1 SMP Wed Sep 7 13:28:55 EDT 2005 i686 i686 i386 GNU/Linux
\~\> gcc -v
Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.3/specs
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux
Thread model: posix
gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-53)
This morning, a compilation first seg-faulted, then errored out with scavenge_mutable_list: strange object? 17863, then compiled cleanly. Unfortuanely I did not have -v set at the time of the errors. Here are the three "make" runs:
autochip/autochip/dev\> make
runghc MakeHelp.hs
alex -g XMLLexer.x
ghc --make -W -threaded -o autochip Autochip
Chasing modules from: Autochip
Compiling AutochipHelp ( ./AutochipHelp.hs, ./AutochipHelp.o )
Compiling XMLLexer ( ./XMLLexer.hs, ./XMLLexer.o )
make: \*\*\* \[autochip\] Segmentation fault
Exit 2
autochip/autochip/dev\> make
ghc --make -W -threaded -o autochip Autochip
Chasing modules from: Autochip
Skipping AutochipHelp ( ./AutochipHelp.hs, ./AutochipHelp.o )
Compiling XMLLexer ( ./XMLLexer.hs, ./XMLLexer.o )
1. /XMLLexer.hs:242:41: Warning: Defined but not used: `rest'
./XMLLexer.hs:245:43: Warning: Defined but not used: `rest'
1. /XMLLexer.hs:266:0: Warning: Defined but not used: `alexAndPred'
./XMLLexer.hs:270:0: Warning: Defined but not used: `alexPrevCharIs'
1. /XMLLexer.hs:273:0: Warning: Defined but not used: `alexPrevCharIsOneOf'
./XMLLexer.hs:276:0: Warning: Defined but not used: `alexRightContext'
1. /XMLLexer.hs:285:0: Warning: Defined but not used: `iUnbox'
wrappers.hs:16:0: Warning: Defined but not used: `alexInputPrevChar'
wrappers.hs:16:19: Warning: Defined but not used: `p'
wrappers.hs:16:23: Warning: Defined but not used: `s'
wrappers.hs:19:13: Warning: Defined but not used: `p'
wrappers.hs:19:15: Warning: Defined but not used: `c'
wrappers.hs:41:21: Warning: Defined but not used: `c'
wrappers.hs:160:31: Warning: Defined but not used: `len'
Compiling Flow.Types ( ./Flow/Types.hs, ./Flow/Types.o )
Compiling Flow.Merge ( ./Flow/Merge.hs, ./Flow/Merge.o )
Compiling XML ( ./XML.hs, ./XML.o )
Compiling Flow.XML ( ./Flow/XML.hs, ./Flow/XML.o )
Compiling DirectoryStructure ( ./DirectoryStructure.hs, ./DirectoryStructure.o )
Compiling FreeMind ( ./FreeMind.hs, ./FreeMind.o )
Compiling Utils ( ./Utils.hs, ./Utils.o )
Compiling Flow.Common ( ./Flow/Common.hs, ./Flow/Common.o )
Compiling Flow.Makefile ( ./Flow/Makefile.hs, ./Flow/Makefile.o )
Compiling Flow.Graph ( ./Flow/Graph.hs, ./Flow/Graph.o )
Compiling Flow.State ( ./Flow/State.hs, ./Flow/State.o )
Compiling Flow.Graphviz ( ./Flow/Graphviz.hs, ./Flow/Graphviz.o )
ghc-6.4.2: internal error: scavenge_mutable_list: strange object? 17863
Please report this as a compiler bug. See:
> http://www.haskell.org/ghc/reportabug
make: \*\*\* \[autochip\] Error 254
Exit 2
autochip/autochip/dev\> make
ghc --make -W -threaded -o autochip Autochip
Chasing modules from: Autochip
Skipping AutochipHelp ( ./AutochipHelp.hs, ./AutochipHelp.o )
Skipping XMLLexer ( ./XMLLexer.hs, ./XMLLexer.o )
Skipping Flow.Types ( ./Flow/Types.hs, ./Flow/Types.o )
Skipping Flow.Merge ( ./Flow/Merge.hs, ./Flow/Merge.o )
Skipping XML ( ./XML.hs, ./XML.o )
Skipping Flow.XML ( ./Flow/XML.hs, ./Flow/XML.o )
Skipping DirectoryStructure ( ./DirectoryStructure.hs, ./DirectoryStructure.o )
Skipping FreeMind ( ./FreeMind.hs, ./FreeMind.o )
Skipping Utils ( ./Utils.hs, ./Utils.o )
Skipping Flow.Common ( ./Flow/Common.hs, ./Flow/Common.o )
Skipping Flow.Makefile ( ./Flow/Makefile.hs, ./Flow/Makefile.o )
Skipping Flow.Graph ( ./Flow/Graph.hs, ./Flow/Graph.o )
Skipping Flow.State ( ./Flow/State.hs, ./Flow/State.o )
Compiling Flow.Graphviz ( ./Flow/Graphviz.hs, ./Flow/Graphviz.o )
Compiling Execute ( ./Execute.hs, ./Execute.o )
Compiling NewBlock ( ./NewBlock.hs, ./NewBlock.o )
1. /NewBlock.hs:17:22: Warning: Defined but not used: \`technology'
Compiling CheckBlock ( ./CheckBlock.hs, ./CheckBlock.o )
Compiling Version ( ./Version.hs, ./Version.o )
Compiling Flow.HTTPD ( ./Flow/HTTPD.hs, ./Flow/HTTPD.o )
Compiling Flow ( ./Flow.hs, ./Flow.o )
Compiling Main ( Autochip.hs, Autochip.o )
Linking ...
\#ghc --make -W -prof -auto-all -threaded -o autochip Autochip
autochip/autochip/dev\>
Thanks for your help and any suggestions!
-Tom
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.4.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Occasional Segmentation Fault and strange object 17863","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.2","keywords":["17863","object","strange"],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"Hello,\r\n\r\nI have noticed the last few months GHC throws an occasional segmentation fault. Unfortunately it's not repeatable and is not related to any particular progam. The error happens every couple of weeks or so. I have noticed this problem with the following GHC versions:\r\n\r\n- 6.4.1 generic linux distribution\r\n- 6.4.1 source distribution compiled with\r\n configure --prefix=/cadtools/contrib\r\n make\r\n make install\r\n- 6.4.2 generic linux distribution\r\n\r\nHere's my system info (RHEL3):\r\n\r\n~> uname -a\r\nLinux nenya 2.4.21-37.ELsmp #1 SMP Wed Sep 7 13:28:55 EDT 2005 i686 i686 i386 GNU/Linux\r\n~> gcc -v\r\nReading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2.3/specs\r\nConfigured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --with-system-zlib --enable-__cxa_atexit --host=i386-redhat-linux\r\nThread model: posix\r\ngcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-53)\r\n\r\n\r\nThis morning, a compilation first seg-faulted, then errored out with scavenge_mutable_list: strange object? 17863, then compiled cleanly. Unfortuanely I did not have -v set at the time of the errors. Here are the three \"make\" runs:\r\n\r\nautochip/autochip/dev> make\r\nrunghc MakeHelp.hs\r\nalex -g XMLLexer.x\r\nghc --make -W -threaded -o autochip Autochip\r\nChasing modules from: Autochip\r\nCompiling AutochipHelp ( ./AutochipHelp.hs, ./AutochipHelp.o )\r\nCompiling XMLLexer ( ./XMLLexer.hs, ./XMLLexer.o )\r\nmake: *** [autochip] Segmentation fault\r\nExit 2\r\nautochip/autochip/dev> make\r\nghc --make -W -threaded -o autochip Autochip\r\nChasing modules from: Autochip\r\nSkipping AutochipHelp ( ./AutochipHelp.hs, ./AutochipHelp.o )\r\nCompiling XMLLexer ( ./XMLLexer.hs, ./XMLLexer.o )\r\n \r\n./XMLLexer.hs:242:41: Warning: Defined but not used: `rest'\r\n \r\n./XMLLexer.hs:245:43: Warning: Defined but not used: `rest'\r\n \r\n./XMLLexer.hs:266:0: Warning: Defined but not used: `alexAndPred'\r\n \r\n./XMLLexer.hs:270:0: Warning: Defined but not used: `alexPrevCharIs'\r\n \r\n./XMLLexer.hs:273:0: Warning: Defined but not used: `alexPrevCharIsOneOf'\r\n \r\n./XMLLexer.hs:276:0: Warning: Defined but not used: `alexRightContext'\r\n \r\n./XMLLexer.hs:285:0: Warning: Defined but not used: `iUnbox'\r\n \r\nwrappers.hs:16:0: Warning: Defined but not used: `alexInputPrevChar'\r\n \r\nwrappers.hs:16:19: Warning: Defined but not used: `p'\r\n \r\nwrappers.hs:16:23: Warning: Defined but not used: `s'\r\n \r\nwrappers.hs:19:13: Warning: Defined but not used: `p'\r\n \r\nwrappers.hs:19:15: Warning: Defined but not used: `c'\r\n \r\nwrappers.hs:41:21: Warning: Defined but not used: `c'\r\n \r\nwrappers.hs:160:31: Warning: Defined but not used: `len'\r\nCompiling Flow.Types ( ./Flow/Types.hs, ./Flow/Types.o )\r\nCompiling Flow.Merge ( ./Flow/Merge.hs, ./Flow/Merge.o )\r\nCompiling XML ( ./XML.hs, ./XML.o )\r\nCompiling Flow.XML ( ./Flow/XML.hs, ./Flow/XML.o )\r\nCompiling DirectoryStructure ( ./DirectoryStructure.hs, ./DirectoryStructure.o )\r\nCompiling FreeMind ( ./FreeMind.hs, ./FreeMind.o )\r\nCompiling Utils ( ./Utils.hs, ./Utils.o )\r\nCompiling Flow.Common ( ./Flow/Common.hs, ./Flow/Common.o )\r\nCompiling Flow.Makefile ( ./Flow/Makefile.hs, ./Flow/Makefile.o )\r\nCompiling Flow.Graph ( ./Flow/Graph.hs, ./Flow/Graph.o )\r\nCompiling Flow.State ( ./Flow/State.hs, ./Flow/State.o )\r\nCompiling Flow.Graphviz ( ./Flow/Graphviz.hs, ./Flow/Graphviz.o )\r\nghc-6.4.2: internal error: scavenge_mutable_list: strange object? 17863\r\n Please report this as a compiler bug. See:\r\n http://www.haskell.org/ghc/reportabug\r\nmake: *** [autochip] Error 254\r\nExit 2\r\nautochip/autochip/dev> make\r\nghc --make -W -threaded -o autochip Autochip\r\nChasing modules from: Autochip\r\nSkipping AutochipHelp ( ./AutochipHelp.hs, ./AutochipHelp.o )\r\nSkipping XMLLexer ( ./XMLLexer.hs, ./XMLLexer.o )\r\nSkipping Flow.Types ( ./Flow/Types.hs, ./Flow/Types.o )\r\nSkipping Flow.Merge ( ./Flow/Merge.hs, ./Flow/Merge.o )\r\nSkipping XML ( ./XML.hs, ./XML.o )\r\nSkipping Flow.XML ( ./Flow/XML.hs, ./Flow/XML.o )\r\nSkipping DirectoryStructure ( ./DirectoryStructure.hs, ./DirectoryStructure.o )\r\nSkipping FreeMind ( ./FreeMind.hs, ./FreeMind.o )\r\nSkipping Utils ( ./Utils.hs, ./Utils.o )\r\nSkipping Flow.Common ( ./Flow/Common.hs, ./Flow/Common.o )\r\nSkipping Flow.Makefile ( ./Flow/Makefile.hs, ./Flow/Makefile.o )\r\nSkipping Flow.Graph ( ./Flow/Graph.hs, ./Flow/Graph.o )\r\nSkipping Flow.State ( ./Flow/State.hs, ./Flow/State.o )\r\nCompiling Flow.Graphviz ( ./Flow/Graphviz.hs, ./Flow/Graphviz.o )\r\nCompiling Execute ( ./Execute.hs, ./Execute.o )\r\nCompiling NewBlock ( ./NewBlock.hs, ./NewBlock.o )\r\n \r\n./NewBlock.hs:17:22: Warning: Defined but not used: `technology'\r\nCompiling CheckBlock ( ./CheckBlock.hs, ./CheckBlock.o )\r\nCompiling Version ( ./Version.hs, ./Version.o )\r\nCompiling Flow.HTTPD ( ./Flow/HTTPD.hs, ./Flow/HTTPD.o )\r\nCompiling Flow ( ./Flow.hs, ./Flow.o )\r\nCompiling Main ( Autochip.hs, Autochip.o )\r\nLinking ...\r\n#ghc --make -W -prof -auto-all -threaded -o autochip Autochip\r\nautochip/autochip/dev>\r\n\r\nThanks for your help and any suggestions!\r\n\r\n-Tom","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/762Unregistered build fails because libghccompat is not built2019-07-07T19:17:05Zjeremy at n-heptane.comUnregistered build fails because libghccompat is not builtI believe that this bug:
http://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/9108
Can be fixed by changing the build instructions on this page:
http://www.haskell.org/ghc/docs/6.4.1/html/building/sec-porting-ghc.html\#unregi...I believe that this bug:
http://article.gmane.org/gmane.comp.lang.haskell.glasgow.user/9108
Can be fixed by changing the build instructions on this page:
http://www.haskell.org/ghc/docs/6.4.1/html/building/sec-porting-ghc.html\#unregisterised-porting
These two lines, currently do \*not\* cause the .hc files for compat to be created:
```
$ make boot UseStage1=YES
$ make -k UseStage1=YES EXTRA_HC_OPTS='-O -fvia-C -keep-hc-files'
```
but changing the first line to:
```
$ make boot UseStage1=YES EXTRA_HC_OPTS='-O -fvia-C -keep-hc-files'
```
does.https://gitlab.haskell.org/ghc/ghc/-/issues/763Breakpoint mechanism crashes when there's a type error2019-07-07T19:17:05ZSimon Peyton JonesBreakpoint mechanism crashes when there's a type errorTest tcfail032 is failing thus;
```
- tcfail032.hs:14:7:
- Inferred type is less polymorphic than expected
- Quantified type variable `a' is mentioned in the environment:
- x :: a -> Int (bound at tcfail032.hs:14:2)
- In ...Test tcfail032 is failing thus;
```
- tcfail032.hs:14:7:
- Inferred type is less polymorphic than expected
- Quantified type variable `a' is mentioned in the environment:
- x :: a -> Int (bound at tcfail032.hs:14:2)
- In the expression: x
- In the expression: (x :: (Eq a) => a -> Int)
- In the definition of `f': f x = (x :: (Eq a) => a -> Int)
--- 1,6 ----
+ ghc-6.5: panic! (the 'impossible' happened)
+ (GHC version 6.5 for i386-unknown-linux):
+ find_thing Identifier `breakpointJump{v 011}'
```
Something to do with the new breakpoint mechanism.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Breakpoint mechanism crashes when there's a type error","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"OwnedBy","contents":"lemmih"},"version":"6.5","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"Test tcfail032 is failing thus;\r\n{{{\r\n- tcfail032.hs:14:7:\r\n- Inferred type is less polymorphic than expected\r\n- Quantified type variable `a' is mentioned in the environment:\r\n- \tx :: a -> Int (bound at tcfail032.hs:14:2)\r\n- In the expression: x\r\n- In the expression: (x :: (Eq a) => a -> Int)\r\n- In the definition of `f': f x = (x :: (Eq a) => a -> Int)\r\n--- 1,6 ----\r\n+ ghc-6.5: panic! (the 'impossible' happened)\r\n+ (GHC version 6.5 for i386-unknown-linux):\r\n+ \tfind_thing Identifier `breakpointJump{v 011}'\r\n}}}\r\n\r\nSomething to do with the new breakpoint mechanism.","type_of_failure":"OtherFailure","blocking":[]} -->LemmihLemmihhttps://gitlab.haskell.org/ghc/ghc/-/issues/764DESTDIR Makefile variable2019-07-07T19:17:05ZguestDESTDIR Makefile variableI'd like the Makefile to have a DESTDIR parameter. This is destined to ease package creation. After the ./configure step the system should be configured to be installed in $(prefix)/bin and other locations. In the "make install" step you...I'd like the Makefile to have a DESTDIR parameter. This is destined to ease package creation. After the ./configure step the system should be configured to be installed in $(prefix)/bin and other locations. In the "make install" step you would specify a different root directory, like "make install DESTDIR=/tmp/fake-rootdir" to get all files copied to /tmp/fake-rootdir$(prefix)/bin (etc) instead of the real destination directories.
This is nothing new. Most famous free software packages provide some way or another of doing this. The DESTDIR name is the typical one in software using the autotools package.
Thanks in advance and keep up the good work.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.4.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"DESTDIR Makefile variable","status":"New","operating_system":"Unknown","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"FeatureRequest","description":"I'd like the Makefile to have a DESTDIR parameter. This is destined to ease package creation. After the ./configure step the system should be configured to be installed in $(prefix)/bin and other locations. In the \"make install\" step you would specify a different root directory, like \"make install DESTDIR=/tmp/fake-rootdir\" to get all files copied to /tmp/fake-rootdir$(prefix)/bin (etc) instead of the real destination directories.\r\n\r\nThis is nothing new. Most famous free software packages provide some way or another of doing this. The DESTDIR name is the typical one in software using the autotools package.\r\n\r\nThanks in advance and keep up the good work.","type_of_failure":"OtherFailure","blocking":[]} -->6.6.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/765x86_64 NCG goes via unsigned for FFI Int return types.2019-07-07T19:17:04Zduncan.coutts@worc.ox.ac.ukx86_64 NCG goes via unsigned for FFI Int return types.With ghc-6.4.2 on x86_64 and using the -fasm NCG we get the wrong answer for this FFI test case:
cbit.c:
```
int c_id (int n) {
return n;
}
```
hsbit.hs:
```
module Foo where
foreign import ccall unsafe "c_id" c_id :: Int -> ...With ghc-6.4.2 on x86_64 and using the -fasm NCG we get the wrong answer for this FFI test case:
cbit.c:
```
int c_id (int n) {
return n;
}
```
hsbit.hs:
```
module Foo where
foreign import ccall unsafe "c_id" c_id :: Int -> IO Int
```
```
ghc -c cbit.c
ghc -fffi --make test.hs cbit.o
./a.out
4294967295
```
Going via C we get the correct answer:
```
ghc -fvia-C -fffi --make test.hs cbit.o
/tmp/ghc32363.hc:135: warning: implicit declaration of function `c_id'
./a.out
-1
```
Obviously what's going on is that we're converting to an unsigned int value at some point so negative values are wrapping round.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.4.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | high |
| Resolution | Unresolved |
| Component | Compiler (NCG) |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"x86_64 NCG goes via unsigned for FFI Int return types.","status":"New","operating_system":"","component":"Compiler (NCG)","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"With ghc-6.4.2 on x86_64 and using the -fasm NCG we get the wrong answer for this FFI test case:\r\n\r\ncbit.c:\r\n{{{\r\nint c_id (int n) {\r\n return n;\r\n}\r\n}}}\r\n\r\nhsbit.hs:\r\n{{{\r\nmodule Foo where\r\nforeign import ccall unsafe \"c_id\" c_id :: Int -> IO Int\r\n}}}\r\n\r\n{{{\r\nghc -c cbit.c\r\nghc -fffi --make test.hs cbit.o\r\n./a.out\r\n4294967295\r\n}}}\r\n\r\nGoing via C we get the correct answer:\r\n\r\n{{{\r\nghc -fvia-C -fffi --make test.hs cbit.o\r\n/tmp/ghc32363.hc:135: warning: implicit declaration of function `c_id'\r\n./a.out\r\n-1\r\n}}}\r\n\r\nObviously what's going on is that we're converting to an unsigned int value at some point so negative values are wrapping round.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/766GHC 6.4.2 won't build on Mac OS X2019-07-07T19:17:04ZguestGHC 6.4.2 won't build on Mac OS X**Problem**
I'm running Mac OS X Tiger (10.4.6) and trying to build GHC 6.4.2 (using GCC 4.0.1 and GHC 6.4.1) and I'm ran into a problem where certain constants (e.g., UNDO_DELETE, UNDO_INSERT, UNDO_BEGIN, UNDO_END) are not found, causin...**Problem**
I'm running Mac OS X Tiger (10.4.6) and trying to build GHC 6.4.2 (using GCC 4.0.1 and GHC 6.4.1) and I'm ran into a problem where certain constants (e.g., UNDO_DELETE, UNDO_INSERT, UNDO_BEGIN, UNDO_END) are not found, causing compilation to stop. The same issue occurred for at least one other user with GHC 6.5; unfortunately, I can't find the post again.
**Solution?**
Tiger ships with a NetBSD partial version of the readline library in /usr. Unfortunately, this file lacks a lot of the functionality in the GNU readline and is not compatible enough.
To get around this:
\# Download and decompress the GNU readline library, v5.1 tarball (other version may work)
\# cd \<readline source dir\>
\# ./configure
\# make
\# sudo make install \#Installs to /usr/lib/include and /usr/lib/bin
\# cd \<GHC source dir\>
\# export LDFLAGS=-L/usr/local/lib \# tell linker to use GNU version of readline
\# export CPPFLAGS=-I/usr/local/include \# tell compiler to use GNU version of readline
\# ./configure --disable-openal --disable-alut \# Audio disabled because of unrealted bug
\# make
\# sudo make install
This should do it. Steps 7 and 8 could cause problems because the compile will look for ALL libraries in /usr/local before looking in /usr.
The compilation is successful and ghc and ghci run; however, Unfortunately, I won't be able to test the results for some time.
**Follow-Up?**
It should be possible to detect the lack of readline through the configure process. The NetBSD bad readline.h file results in the following statements:
\<pre\>
checking for rl_erase_empty_line in -lreadline... no
checking for rl_free_undo_list in -lreadline... no
\</pre\>
The GNU readline 5.1 library results in the following statements:
\<pre\>
checking for rl_erase_empty_line in -lreadline... yes
checking for rl_free_undo_list in -lreadline... yes
\</pre\>
It may be possible to create a test in the configure file by looking at the platform and these two functions. Also, the platform-specific documentation could be updated.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.4.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHC 6.4.2 won't build on Mac OS X","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"'''Problem'''\r\nI'm running Mac OS X Tiger (10.4.6) and trying to build GHC 6.4.2 (using GCC 4.0.1 and GHC 6.4.1) and I'm ran into a problem where certain constants (e.g., UNDO_DELETE, UNDO_INSERT, UNDO_BEGIN, UNDO_END) are not found, causing compilation to stop. The same issue occurred for at least one other user with GHC 6.5; unfortunately, I can't find the post again.\r\n\r\n'''Solution?'''\r\nTiger ships with a NetBSD partial version of the readline library in /usr. Unfortunately, this file lacks a lot of the functionality in the GNU readline and is not compatible enough. \r\n\r\nTo get around this:\r\n# Download and decompress the GNU readline library, v5.1 tarball (other version may work)\r\n# cd <readline source dir>\r\n# ./configure\r\n# make\r\n# sudo make install #Installs to /usr/lib/include and /usr/lib/bin\r\n# cd <GHC source dir>\r\n# export LDFLAGS=-L/usr/local/lib # tell linker to use GNU version of readline\r\n# export CPPFLAGS=-I/usr/local/include # tell compiler to use GNU version of readline\r\n# ./configure --disable-openal --disable-alut # Audio disabled because of unrealted bug\r\n# make\r\n# sudo make install\r\n\r\nThis should do it. Steps 7 and 8 could cause problems because the compile will look for ALL libraries in /usr/local before looking in /usr.\r\n\r\nThe compilation is successful and ghc and ghci run; however, Unfortunately, I won't be able to test the results for some time.\r\n\r\n'''Follow-Up?'''\r\nIt should be possible to detect the lack of readline through the configure process. The NetBSD bad readline.h file results in the following statements:\r\n<pre>\r\nchecking for rl_erase_empty_line in -lreadline... no\r\nchecking for rl_free_undo_list in -lreadline... no\r\n</pre>\r\n\r\nThe GNU readline 5.1 library results in the following statements:\r\n<pre>\r\nchecking for rl_erase_empty_line in -lreadline... yes\r\nchecking for rl_free_undo_list in -lreadline... yes\r\n</pre>\r\n\r\nIt may be possible to create a test in the configure file by looking at the platform and these two functions. Also, the platform-specific documentation could be updated.","type_of_failure":"OtherFailure","blocking":[]} -->6.4.3https://gitlab.haskell.org/ghc/ghc/-/issues/767withMVar family have a bug2019-07-07T19:17:03ZSimon MarlowwithMVar family have a bug`withMVar` is defined like this:
```
withMVar :: MVar a -> (a -> IO b) -> IO b
withMVar m io =
block $ do
a <- takeMVar m
b <- catch (unblock (io a))
(\e -> do putMVar m a; throw e)
putMVar m a
return b
```...`withMVar` is defined like this:
```
withMVar :: MVar a -> (a -> IO b) -> IO b
withMVar m io =
block $ do
a <- takeMVar m
b <- catch (unblock (io a))
(\e -> do putMVar m a; throw e)
putMVar m a
return b
```
unfortunately this has a (very rare) bug: `catch` can raise a stack overflow exception, which would leave the `MVar` empty.
This is a tricky one. Perhaps in the event of a stack overflow, catch should ensure that the exception is passed directly to its handler, and we always add some extra stack space for the handler.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"withMVar family have a bug","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"{{{withMVar}}} is defined like this:\r\n\r\n{{{\r\nwithMVar :: MVar a -> (a -> IO b) -> IO b\r\nwithMVar m io = \r\n block $ do\r\n a <- takeMVar m\r\n b <- catch (unblock (io a))\r\n \t (\\e -> do putMVar m a; throw e)\r\n putMVar m a\r\n return b\r\n}}}\r\n\r\nunfortunately this has a (very rare) bug: {{{catch}}} can raise a stack overflow exception, which would leave the {{{MVar}}} empty.\r\n\r\nThis is a tricky one. Perhaps in the event of a stack overflow, catch should ensure that the exception is passed directly to its handler, and we always add some extra stack space for the handler.","type_of_failure":"OtherFailure","blocking":[]} -->6.8.1https://gitlab.haskell.org/ghc/ghc/-/issues/768Improve performance of binary serialisation for interface files2019-07-07T19:17:03ZSimon MarlowImprove performance of binary serialisation for interface filesutils/Binary.hs can be made significantly faster. See:
[http://www.haskell.org//pipermail/glasgow-haskell-users/2006-April/010037.html](http://www.haskell.org//pipermail/glasgow-haskell-users/2006-April/010037.html)
Until we have a sta...utils/Binary.hs can be made significantly faster. See:
[http://www.haskell.org//pipermail/glasgow-haskell-users/2006-April/010037.html](http://www.haskell.org//pipermail/glasgow-haskell-users/2006-April/010037.html)
Until we have a standard highly-tuned binary I/O library, I think applying some optimisations to GHC's private binary library will be worthwhile.
The first thing to do is replace IORef (IOUArray Int Word8) with a fast mutable pointer, backed by either a ForeignPtr or a MutableByteArr\#.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.4.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Improve performance of binary serialisation for interface files","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Task","description":"utils/Binary.hs can be made significantly faster. See:\r\n\r\n[http://www.haskell.org//pipermail/glasgow-haskell-users/2006-April/010037.html]\r\n\r\nUntil we have a standard highly-tuned binary I/O library, I think applying some optimisations to GHC's private binary library will be worthwhile. \r\n\r\nThe first thing to do is replace IORef (IOUArray Int Word8) with a fast mutable pointer, backed by either a ForeignPtr or a MutableByteArr#.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/769Heap profiling: time tag format2019-07-07T19:17:03ZguestHeap profiling: time tag formatIf you enable heap profiling and then use hp2ps to generate a graph it occasionally reports records out of order. The reason is the time tag at the beginning and end of each record, which is printed with two decimal places. When the time...If you enable heap profiling and then use hp2ps to generate a graph it occasionally reports records out of order. The reason is the time tag at the beginning and end of each record, which is printed with two decimal places. When the time reaches an integer number of seconds it is printed as e.g. 6.100 instead of 7.00. hp2ps interprets this as 6.1 seconds.
This applies to at least 6.4, 6.4.1 and 6.4.2. I've seen it on Windows, but I expect it applies to other OSes as well.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.4.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Multiple |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Heap profiling: time tag format","status":"New","operating_system":"Multiple","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.2","keywords":["heap","profiling"],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"If you enable heap profiling and then use hp2ps to generate a graph it occasionally reports records out of order. The reason is the time tag at the beginning and end of each record, which is printed with two decimal places. When the time reaches an integer number of seconds it is printed as e.g. 6.100 instead of 7.00. hp2ps interprets this as 6.1 seconds.\r\n\r\nThis applies to at least 6.4, 6.4.1 and 6.4.2. I've seen it on Windows, but I expect it applies to other OSes as well.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/770Huge array leads to various crashes2019-07-07T19:17:03ZdonsHuge array leads to various crashesFirst spotted over irc (!):
<table><tr><th>20:32 dons</th>
<td>\> array (minBound,maxBound) (zip \[0..\] (repeat ())) :: Array Int ()</td></tr>
<tr><th>20:32 lambdabot</th>
<td>internal error: evacuate: strange closure type 37792</td></...First spotted over irc (!):
<table><tr><th>20:32 dons</th>
<td>\> array (minBound,maxBound) (zip \[0..\] (repeat ())) :: Array Int ()</td></tr>
<tr><th>20:32 lambdabot</th>
<td>internal error: evacuate: strange closure type 37792</td></tr>
<tr><th>20:32 lambdabot</th>
<td>Please report this as a bug to glasgow-haskell-bugs\@haskell.org,</td></tr>
<tr><th>20:32 lambdabot</th>
<td>or http://www.sourceforge.net/projects/ghc/</td></tr></table>
The following program:
<table><tr><th>import Data.Array
main = print (array (minBound,maxBound) (zip \[0..\] (repeat ())) </th>
<td>Array Int ())</td></tr></table>
leads to a variety of different crashes in 6.4.1, 6.4.2 and the head. I'm fairly sure
this was reported once before, but it seems to have crept back in.
With 6.4.2/OpenBSD/x86:
$ ./a.out
a.out: internal error: stg_ap_ppp_ret
Please report this as a compiler bug. See:
http://www.haskell.org/ghc/reportabug
With 6.4.2/Linux/amd64/ghci:
Data.Array\> array (minBound,maxBound) (zip \[0..\] (repeat ())) :: Array Int ()
array Segmentation fault
With 6.5:
$ ./a.out
zsh: segmentation fault (core dumped) ./a.out
-- Don
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Multiple |
| Architecture | Multiple |
</details>
<!-- {"blocked_by":[],"summary":"Huge array leads to various crashes","status":"New","operating_system":"Multiple","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.5","keywords":[],"differentials":[],"test_case":"","architecture":"Multiple","cc":[""],"type":"Bug","description":"First spotted over irc (!): \r\n\r\n 20:32 dons:: > array (minBound,maxBound) (zip [0..] (repeat ())) :: Array Int ()\r\n 20:32 lambdabot:: internal error: evacuate: strange closure type 37792\r\n 20:32 lambdabot:: Please report this as a bug to glasgow-haskell-bugs@haskell.org,\r\n 20:32 lambdabot:: or http://www.sourceforge.net/projects/ghc/\r\n\r\nThe following program:\r\n\r\n import Data.Array\r\n main = print (array (minBound,maxBound) (zip [0..] (repeat ())) :: Array Int ())\r\n\r\nleads to a variety of different crashes in 6.4.1, 6.4.2 and the head. I'm fairly sure \r\nthis was reported once before, but it seems to have crept back in.\r\n\r\nWith 6.4.2/OpenBSD/x86:\r\n $ ./a.out \r\n a.out: internal error: stg_ap_ppp_ret\r\n Please report this as a compiler bug. See:\r\n http://www.haskell.org/ghc/reportabug\r\n\r\nWith 6.4.2/Linux/amd64/ghci:\r\n Data.Array> array (minBound,maxBound) (zip [0..] (repeat ())) :: Array Int ()\r\n array Segmentation fault\r\n \r\nWith 6.5:\r\n $ ./a.out\r\n zsh: segmentation fault (core dumped) ./a.out\r\n\r\n-- Don","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/771GHC typing too constrained2019-07-07T19:17:03ZguestGHC typing too constrainedfor the following program:
```
module Bug where
f :: Maybe Bool
f = g ()
g () = do { f; error "bug?" }
```
If I ask ghci (version: 6.4.1) what the type of g is, it says:
```
*Bug> :t g
g :: () -> Maybe Bool
```
However, I t...for the following program:
```
module Bug where
f :: Maybe Bool
f = g ()
g () = do { f; error "bug?" }
```
If I ask ghci (version: 6.4.1) what the type of g is, it says:
```
*Bug> :t g
g :: () -> Maybe Bool
```
However, I think it should be:
```
Bug> :t g
g :: () -> Maybe a
```
as reported by Hugs (version: March 2005).
I first thought this was a monomorphism-restriction gotcha, but g is obviously a function, not a constant. And Hugs reports the more general expected type anyhow.
I'm curious to see if this is a real bug or some weird interaction with ghci..https://gitlab.haskell.org/ghc/ghc/-/issues/772checkPrecMatch2019-07-07T19:17:02ZguestcheckPrecMatch```
*Research> :r
Compiling Statistics.DescriptiveAnalysis.KeyHistoryListImpl ( ./Statistics/DescriptiveAnalysis/KeyHistoryListImpl.hs, interpreted )
: panic! (the `impossible' happened, GHC version 6.4.2):
checkPrecMatch
Please...```
*Research> :r
Compiling Statistics.DescriptiveAnalysis.KeyHistoryListImpl ( ./Statistics/DescriptiveAnalysis/KeyHistoryListImpl.hs, interpreted )
: panic! (the `impossible' happened, GHC version 6.4.2):
checkPrecMatch
Please report this as a compiler bug. See:
http://www.haskell.org/ghc/reportabug
```
This happened when i compile in GHCI:
```
module Test where
class TestInfo a where
type Bla = String
-- GADT Descriptors
data Descriptor where
BA :: String -> Descriptor
GA :: (Show a, TestInfo a) => Either a (String, String) -> Descriptor
SA :: String -> Descriptor
AA :: String -> [Bla]-> Descriptor
TA :: Bla -> Bla -> Bla -> Descriptor
instance Eq Descriptor where
(BA descr1) == (BA descr2) = descr1 == descr2
(GA grpsubj) == (GA grpsubj2) = show grpsubj == show grpsubj2 -- might not be correct
(SA descr) == (SA descr2) = descr == descr2
(AA descr keys) == (AA descr2 keys2) = (descr == descr2) && (keys == keys2)
(TA orikey key1 key2) == (TA orikeyB key1B key2B) = (orikey == orikeyB) && (key1 == key1B) && (key2 == key2B)
(==) = error "Error pattern not found in (==)"
```
The last line give the compilation error
Peter, peteanom\@gmail.com6.4.2https://gitlab.haskell.org/ghc/ghc/-/issues/773garbage collector bug?2019-07-07T19:17:02ZFergus Henderson <fjh-mailbox-68@galois.com>garbage collector bug?ghc.exe: internal error: update_fwd: unknown/strange object 0
Please report this as a bug to glasgow-haskell-bugs\@haskell.org,
> or http://www.sourceforge.net/projects/ghc/
This occurred using ghc 6.4.1 on a Windows XP system,
when...ghc.exe: internal error: update_fwd: unknown/strange object 0
Please report this as a bug to glasgow-haskell-bugs\@haskell.org,
> or http://www.sourceforge.net/projects/ghc/
This occurred using ghc 6.4.1 on a Windows XP system,
when running the following command:
ghc -i. -i./ghc -i./win32 -package concurrent -package net -package parsec -pack
age QuickCheck -O2 -Wall -package-name galois +RTS -M500M -RTS -Iwin32/include
-Iinclude -c Data/Symbolic.hs -o Data/Symbolic.o
The error is repeatable.
Unfortunately I can't publish the source files that I'm trying to compile,
but I may be able to give someone a copy if they are willing to have a look
at the problem. (This is revision 10447 of trunk/lib/galois in the \[private\]
Galois SVN repository.)
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"garbage collector bug?","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"ghc.exe: internal error: update_fwd: unknown/strange object 0\r\n Please report this as a bug to glasgow-haskell-bugs@haskell.org,\r\n or http://www.sourceforge.net/projects/ghc/\r\n\r\nThis occurred using ghc 6.4.1 on a Windows XP system,\r\nwhen running the following command:\r\n\r\nghc -i. -i./ghc -i./win32 -package concurrent -package net -package parsec -pack\r\nage QuickCheck -O2 -Wall -package-name galois +RTS -M500M -RTS -Iwin32/include\r\n-Iinclude -c Data/Symbolic.hs -o Data/Symbolic.o\r\n\r\nThe error is repeatable.\r\nUnfortunately I can't publish the source files that I'm trying to compile,\r\nbut I may be able to give someone a copy if they are willing to have a look\r\nat the problem. (This is revision 10447 of trunk/lib/galois in the [private]\r\nGalois SVN repository.)","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/774Building GHC 6.4.2 on Solaris 10 SPARC2019-07-07T19:17:02Zflorenz@cs.tu-berlin.deBuilding GHC 6.4.2 on Solaris 10 SPARCThere is trouble building GHC 6.4.2 on Solaris 10 SPARC.
The OS version is
$ uname -a
SunOS bruja 5.10 Generic_118833-03 sun4u sparc SUNW,Sun-Fire
The GCC version is
$ gcc -v
Reading specs from /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3....There is trouble building GHC 6.4.2 on Solaris 10 SPARC.
The OS version is
$ uname -a
SunOS bruja 5.10 Generic_118833-03 sun4u sparc SUNW,Sun-Fire
The GCC version is
$ gcc -v
Reading specs from /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/specs
Configured with: /gates/sfw10/builds/sfw10-gate/usr/src/cmd/gcc/gcc-3.4.3/configure --prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++ --enable-shared
Thread model: posix
gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
The error occurs in building stage2, there is an unresolved symbol (shed_yield) in rts/libHSrts_thr.a(OSThreads.thr_o)
gmake throws out the following:
```
gmake[2]: Entering directory `/home/pub/src/ghc-6.4.2/ghc/compiler'
../../ghc/compiler/stage1/ghc-inplace -o stage2/ghc-6.4.2 -H16m -O
-istage2/utils -istage2/basicTypes -istage2/types -istage2/hsSyn -istage2/prelude -istage2/rename -istage2/typecheck
-istage2/deSugar -istage2/coreSyn -istage2/specialise
-istage2/simplCore -istage2/stranal -istage2/stgSyn
-istage2/simplStg -istage2/codeGen -istage2/main
-istage2/profiling -istage2/parser -istage2/cprAnalysis
-istage2/compMan -istage2/ndpFlatten -istage2/iface -istage2/cmm
-istage2/ghci -Istage2 -DOMIT_NATIVE_CODEGEN -DGHCI -package
template-haskell -threaded -cpp -fglasgow-exts -fno-generics
-Rghc-timing -I. -IcodeGen -InativeGen -Iparser -package unix
-package Cabal -ignore-package lang -recomp -Rghc-timing -H16M
'-#include "hschooks.h"' -no-link-chk
stage2/basicTypes/BasicTypes.o stage2/basicTypes/DataCon.o
stage2/basicTypes/Demand.o stage2/basicTypes/FieldLabel.o
stage2/basicTypes/Id.o stage2/basicTypes/IdInfo.o
stage2/basicTypes/Literal.o stage2/basicTypes/MkId.o
stage2/basicTypes/Module.o stage2/basicTypes/Name.o
stage2/basicTypes/NameEnv.o stage2/basicTypes/NameSet.o
stage2/basicTypes/NewDemand.o stage2/basicTypes/OccName.o
stage2/basicTypes/RdrName.o stage2/basicTypes/SrcLoc.o
stage2/basicTypes/UniqSupply.o stage2/basicTypes/Unique.o
stage2/basicTypes/Var.o stage2/basicTypes/VarEnv.o
stage2/basicTypes/VarSet.o stage2/cmm/CLabel.o stage2/cmm/Cmm.o
stage2/cmm/CmmLex.o stage2/cmm/CmmLint.o stage2/cmm/CmmParse.o
stage2/cmm/CmmUtils.o stage2/cmm/MachOp.o stage2/cmm/PprC.o
stage2/cmm/PprCmm.o stage2/codeGen/Bitmap.o
stage2/codeGen/CgBindery.o stage2/codeGen/CgCallConv.o
stage2/codeGen/CgCase.o stage2/codeGen/CgClosure.o
stage2/codeGen/CgCon.o stage2/codeGen/CgExpr.o
stage2/codeGen/CgForeignCall.o stage2/codeGen/CgHeapery.o
stage2/codeGen/CgInfoTbls.o stage2/codeGen/CgLetNoEscape.o
stage2/codeGen/CgMonad.o stage2/codeGen/CgParallel.o
stage2/codeGen/CgPrimOp.o stage2/codeGen/CgProf.o
stage2/codeGen/CgStackery.o stage2/codeGen/CgTailCall.o
stage2/codeGen/CgTicky.o stage2/codeGen/CgUtils.o
stage2/codeGen/ClosureInfo.o stage2/codeGen/CodeGen.o
stage2/codeGen/SMRep.o stage2/compMan/CompManager.o
stage2/coreSyn/CoreFVs.o stage2/coreSyn/CoreLint.o
stage2/coreSyn/CorePrep.o stage2/coreSyn/CoreSubst.o
stage2/coreSyn/CoreSyn.o stage2/coreSyn/CoreTidy.o
stage2/coreSyn/CoreUnfold.o stage2/coreSyn/CoreUtils.o
stage2/coreSyn/ExternalCore.o stage2/coreSyn/MkExternalCore.o
stage2/coreSyn/PprCore.o stage2/coreSyn/PprExternalCore.o
stage2/cprAnalysis/CprAnalyse.o stage2/deSugar/Check.o
stage2/deSugar/Desugar.o stage2/deSugar/DsArrows.o
stage2/deSugar/DsBinds.o stage2/deSugar/DsCCall.o
stage2/deSugar/DsExpr.o stage2/deSugar/DsForeign.o
stage2/deSugar/DsGRHSs.o stage2/deSugar/DsListComp.o
stage2/deSugar/DsMeta.o stage2/deSugar/DsMonad.o
stage2/deSugar/DsUtils.o stage2/deSugar/Match.o
stage2/deSugar/MatchCon.o stage2/deSugar/MatchLit.o
stage2/ghci/ByteCodeAsm.o stage2/ghci/ByteCodeFFI.o
stage2/ghci/ByteCodeGen.o stage2/ghci/ByteCodeInstr.o
stage2/ghci/ByteCodeItbls.o stage2/ghci/ByteCodeLink.o
stage2/ghci/InteractiveUI.o stage2/ghci/Linker.o
stage2/ghci/ObjLink.o stage2/hsSyn/Convert.o
stage2/hsSyn/HsBinds.o stage2/hsSyn/HsDecls.o
stage2/hsSyn/HsExpr.o stage2/hsSyn/HsImpExp.o stage2/hsSyn/HsLit.o
stage2/hsSyn/HsPat.o stage2/hsSyn/HsSyn.o stage2/hsSyn/HsTypes.o
stage2/hsSyn/HsUtils.o stage2/iface/BinIface.o
stage2/iface/BuildTyCl.o stage2/iface/IfaceEnv.o
stage2/iface/IfaceSyn.o stage2/iface/IfaceType.o
stage2/iface/LoadIface.o stage2/iface/MkIface.o
stage2/iface/TcIface.o stage2/main/CmdLineOpts.o
stage2/main/CodeOutput.o stage2/main/Config.o
stage2/main/Constants.o stage2/main/DriverFlags.o
stage2/main/DriverMkDepend.o stage2/main/DriverPhases.o
stage2/main/DriverPipeline.o stage2/main/DriverState.o
stage2/main/DriverUtil.o stage2/main/ErrUtils.o
stage2/main/Finder.o stage2/main/GetImports.o
stage2/main/HscMain.o stage2/main/HscStats.o
stage2/main/HscTypes.o stage2/main/Main.o
stage2/main/PackageConfig.o stage2/main/Packages.o
stage2/main/ParsePkgConf.o stage2/main/SysTools.o
stage2/main/TidyPgm.o stage2/ndpFlatten/FlattenInfo.o
stage2/ndpFlatten/FlattenMonad.o stage2/ndpFlatten/Flattening.o
stage2/ndpFlatten/NDPCoreUtils.o stage2/ndpFlatten/PArrAnal.o
stage2/parser/Ctype.o stage2/parser/LexCore.o
stage2/parser/Lexer.o stage2/parser/Parser.o
stage2/parser/ParserCore.o stage2/parser/ParserCoreUtils.o
stage2/parser/RdrHsSyn.o stage2/prelude/ForeignCall.o
stage2/prelude/PrelInfo.o stage2/prelude/PrelNames.o
stage2/prelude/PrelRules.o stage2/prelude/PrimOp.o
stage2/prelude/TysPrim.o stage2/prelude/TysWiredIn.o
stage2/profiling/CostCentre.o stage2/profiling/SCCfinal.o
stage2/rename/RnBinds.o stage2/rename/RnEnv.o
stage2/rename/RnExpr.o stage2/rename/RnHsSyn.o
stage2/rename/RnNames.o stage2/rename/RnSource.o
stage2/rename/RnTypes.o stage2/simplCore/CSE.o
stage2/simplCore/FloatIn.o stage2/simplCore/FloatOut.o
stage2/simplCore/LiberateCase.o stage2/simplCore/OccurAnal.o
stage2/simplCore/SAT.o stage2/simplCore/SATMonad.o
stage2/simplCore/SetLevels.o stage2/simplCore/SimplCore.o
stage2/simplCore/SimplEnv.o stage2/simplCore/SimplMonad.o
stage2/simplCore/SimplUtils.o stage2/simplCore/Simplify.o
stage2/simplStg/SRT.o stage2/simplStg/SimplStg.o
stage2/simplStg/StgStats.o stage2/specialise/Rules.o
stage2/specialise/SpecConstr.o stage2/specialise/Specialise.o
stage2/stgSyn/CoreToStg.o stage2/stgSyn/StgLint.o
stage2/stgSyn/StgSyn.o stage2/stranal/DmdAnal.o
stage2/stranal/SaAbsInt.o stage2/stranal/SaLib.o
stage2/stranal/StrictAnal.o stage2/stranal/WorkWrap.o
stage2/stranal/WwLib.o stage2/typecheck/Inst.o
stage2/typecheck/TcArrows.o stage2/typecheck/TcBinds.o
stage2/typecheck/TcClassDcl.o stage2/typecheck/TcDefaults.o
stage2/typecheck/TcDeriv.o stage2/typecheck/TcEnv.o
stage2/typecheck/TcExpr.o stage2/typecheck/TcForeign.o
stage2/typecheck/TcGenDeriv.o stage2/typecheck/TcHsSyn.o
stage2/typecheck/TcHsType.o stage2/typecheck/TcInstDcls.o
stage2/typecheck/TcMType.o stage2/typecheck/TcMatches.o
stage2/typecheck/TcPat.o stage2/typecheck/TcRnDriver.o
stage2/typecheck/TcRnMonad.o stage2/typecheck/TcRnTypes.o
stage2/typecheck/TcRules.o stage2/typecheck/TcSimplify.o
stage2/typecheck/TcSplice.o stage2/typecheck/TcTyClsDecls.o
stage2/typecheck/TcTyDecls.o stage2/typecheck/TcType.o
stage2/typecheck/TcUnify.o stage2/types/Class.o
stage2/types/FunDeps.o stage2/types/Generics.o
stage2/types/InstEnv.o stage2/types/Kind.o stage2/types/TyCon.o
stage2/types/Type.o stage2/types/TypeRep.o stage2/types/Unify.o
stage2/utils/Bag.o stage2/utils/Binary.o stage2/utils/BitSet.o
stage2/utils/BufWrite.o stage2/utils/Digraph.o
stage2/utils/FastMutInt.o stage2/utils/FastString.o
stage2/utils/FastTypes.o stage2/utils/FiniteMap.o
stage2/utils/IOEnv.o stage2/utils/ListSetOps.o
stage2/utils/Maybes.o stage2/utils/OrdList.o
stage2/utils/Outputable.o stage2/utils/Panic.o
stage2/utils/Pretty.o stage2/utils/PrimPacked.o
stage2/utils/StringBuffer.o stage2/utils/UnicodeUtil.o
stage2/utils/UniqFM.o stage2/utils/UniqSet.o stage2/utils/Util.o
stage2/parser/hschooks.o
Undefined first referenced
symbol in file
sched_yield /home/pub/src/ghc-6.4.2/ghc/rts/libHSrts_thr.a(OSThreads.thr_o)
ld: fatal: Symbol referencing errors. No output written to stage2/ghc-6.4.2
collect2: ld returned 1 exit status
<<ghc: 12902560 bytes, 3 GCs, 160656/160656 avg/max bytes residency (1 samples), 15M in use, 0.00 INIT (0.00 elapsed), 0.12 MUT (3.42 elapsed), 0.03 GC (0.05 elapsed) :ghc>>
gmake[2]: *** [stage2/ghc-6.4.2] Error 1
gmake[2]: Leaving directory `/home/pub/src/ghc-6.4.2/ghc/compiler'
gmake[1]: *** [stage2] Error 2
gmake[1]: Leaving directory `/home/pub/src/ghc-6.4.2'
gmake: *** [bootstrap2] Error 2
```
Help is very much appreciated, regards,
Florian
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.4.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Build System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Building GHC 6.4.2 on Solaris 10 SPARC","status":"New","operating_system":"","component":"Build System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"There is trouble building GHC 6.4.2 on Solaris 10 SPARC.\r\n\r\nThe OS version is\r\n$ uname -a\r\nSunOS bruja 5.10 Generic_118833-03 sun4u sparc SUNW,Sun-Fire\r\n\r\nThe GCC version is\r\n$ gcc -v\r\nReading specs from /usr/sfw/lib/gcc/sparc-sun-solaris2.10/3.4.3/specs\r\nConfigured with: /gates/sfw10/builds/sfw10-gate/usr/src/cmd/gcc/gcc-3.4.3/configure --prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++ --enable-shared\r\nThread model: posix\r\ngcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath)\r\n\r\nThe error occurs in building stage2, there is an unresolved symbol (shed_yield) in rts/libHSrts_thr.a(OSThreads.thr_o)\r\n\r\ngmake throws out the following:\r\n{{{\r\ngmake[2]: Entering directory `/home/pub/src/ghc-6.4.2/ghc/compiler'\r\n../../ghc/compiler/stage1/ghc-inplace -o stage2/ghc-6.4.2 -H16m -O\r\n-istage2/utils -istage2/basicTypes -istage2/types -istage2/hsSyn -istage2/prelude -istage2/rename -istage2/typecheck \r\n-istage2/deSugar -istage2/coreSyn -istage2/specialise \r\n-istage2/simplCore -istage2/stranal -istage2/stgSyn \r\n-istage2/simplStg -istage2/codeGen -istage2/main \r\n-istage2/profiling -istage2/parser -istage2/cprAnalysis \r\n-istage2/compMan -istage2/ndpFlatten -istage2/iface -istage2/cmm \r\n -istage2/ghci -Istage2 -DOMIT_NATIVE_CODEGEN -DGHCI -package \r\ntemplate-haskell -threaded -cpp -fglasgow-exts -fno-generics \r\n-Rghc-timing -I. -IcodeGen -InativeGen -Iparser -package unix \r\n-package Cabal -ignore-package lang -recomp -Rghc-timing -H16M \r\n'-#include \"hschooks.h\"' -no-link-chk \r\nstage2/basicTypes/BasicTypes.o stage2/basicTypes/DataCon.o \r\nstage2/basicTypes/Demand.o stage2/basicTypes/FieldLabel.o \r\nstage2/basicTypes/Id.o stage2/basicTypes/IdInfo.o \r\nstage2/basicTypes/Literal.o stage2/basicTypes/MkId.o \r\nstage2/basicTypes/Module.o stage2/basicTypes/Name.o \r\nstage2/basicTypes/NameEnv.o stage2/basicTypes/NameSet.o \r\nstage2/basicTypes/NewDemand.o stage2/basicTypes/OccName.o \r\nstage2/basicTypes/RdrName.o stage2/basicTypes/SrcLoc.o \r\nstage2/basicTypes/UniqSupply.o stage2/basicTypes/Unique.o \r\nstage2/basicTypes/Var.o stage2/basicTypes/VarEnv.o \r\nstage2/basicTypes/VarSet.o stage2/cmm/CLabel.o stage2/cmm/Cmm.o \r\nstage2/cmm/CmmLex.o stage2/cmm/CmmLint.o stage2/cmm/CmmParse.o \r\nstage2/cmm/CmmUtils.o stage2/cmm/MachOp.o stage2/cmm/PprC.o \r\nstage2/cmm/PprCmm.o stage2/codeGen/Bitmap.o \r\nstage2/codeGen/CgBindery.o stage2/codeGen/CgCallConv.o \r\nstage2/codeGen/CgCase.o stage2/codeGen/CgClosure.o \r\nstage2/codeGen/CgCon.o stage2/codeGen/CgExpr.o \r\nstage2/codeGen/CgForeignCall.o stage2/codeGen/CgHeapery.o \r\nstage2/codeGen/CgInfoTbls.o stage2/codeGen/CgLetNoEscape.o \r\nstage2/codeGen/CgMonad.o stage2/codeGen/CgParallel.o \r\nstage2/codeGen/CgPrimOp.o stage2/codeGen/CgProf.o \r\nstage2/codeGen/CgStackery.o stage2/codeGen/CgTailCall.o \r\nstage2/codeGen/CgTicky.o stage2/codeGen/CgUtils.o \r\nstage2/codeGen/ClosureInfo.o stage2/codeGen/CodeGen.o \r\nstage2/codeGen/SMRep.o stage2/compMan/CompManager.o \r\nstage2/coreSyn/CoreFVs.o stage2/coreSyn/CoreLint.o \r\nstage2/coreSyn/CorePrep.o stage2/coreSyn/CoreSubst.o \r\nstage2/coreSyn/CoreSyn.o stage2/coreSyn/CoreTidy.o \r\nstage2/coreSyn/CoreUnfold.o stage2/coreSyn/CoreUtils.o \r\nstage2/coreSyn/ExternalCore.o stage2/coreSyn/MkExternalCore.o \r\nstage2/coreSyn/PprCore.o stage2/coreSyn/PprExternalCore.o \r\nstage2/cprAnalysis/CprAnalyse.o stage2/deSugar/Check.o \r\nstage2/deSugar/Desugar.o stage2/deSugar/DsArrows.o \r\nstage2/deSugar/DsBinds.o stage2/deSugar/DsCCall.o \r\nstage2/deSugar/DsExpr.o stage2/deSugar/DsForeign.o \r\nstage2/deSugar/DsGRHSs.o stage2/deSugar/DsListComp.o \r\nstage2/deSugar/DsMeta.o stage2/deSugar/DsMonad.o \r\nstage2/deSugar/DsUtils.o stage2/deSugar/Match.o \r\nstage2/deSugar/MatchCon.o stage2/deSugar/MatchLit.o \r\nstage2/ghci/ByteCodeAsm.o stage2/ghci/ByteCodeFFI.o \r\nstage2/ghci/ByteCodeGen.o stage2/ghci/ByteCodeInstr.o \r\nstage2/ghci/ByteCodeItbls.o stage2/ghci/ByteCodeLink.o \r\nstage2/ghci/InteractiveUI.o stage2/ghci/Linker.o \r\nstage2/ghci/ObjLink.o stage2/hsSyn/Convert.o \r\nstage2/hsSyn/HsBinds.o stage2/hsSyn/HsDecls.o \r\nstage2/hsSyn/HsExpr.o stage2/hsSyn/HsImpExp.o stage2/hsSyn/HsLit.o \r\n stage2/hsSyn/HsPat.o stage2/hsSyn/HsSyn.o stage2/hsSyn/HsTypes.o \r\n stage2/hsSyn/HsUtils.o stage2/iface/BinIface.o \r\nstage2/iface/BuildTyCl.o stage2/iface/IfaceEnv.o \r\nstage2/iface/IfaceSyn.o stage2/iface/IfaceType.o \r\nstage2/iface/LoadIface.o stage2/iface/MkIface.o \r\nstage2/iface/TcIface.o stage2/main/CmdLineOpts.o \r\nstage2/main/CodeOutput.o stage2/main/Config.o \r\nstage2/main/Constants.o stage2/main/DriverFlags.o \r\nstage2/main/DriverMkDepend.o stage2/main/DriverPhases.o \r\nstage2/main/DriverPipeline.o stage2/main/DriverState.o \r\nstage2/main/DriverUtil.o stage2/main/ErrUtils.o \r\nstage2/main/Finder.o stage2/main/GetImports.o \r\nstage2/main/HscMain.o stage2/main/HscStats.o \r\nstage2/main/HscTypes.o stage2/main/Main.o \r\nstage2/main/PackageConfig.o stage2/main/Packages.o \r\nstage2/main/ParsePkgConf.o stage2/main/SysTools.o \r\nstage2/main/TidyPgm.o stage2/ndpFlatten/FlattenInfo.o \r\nstage2/ndpFlatten/FlattenMonad.o stage2/ndpFlatten/Flattening.o \r\nstage2/ndpFlatten/NDPCoreUtils.o stage2/ndpFlatten/PArrAnal.o \r\nstage2/parser/Ctype.o stage2/parser/LexCore.o \r\nstage2/parser/Lexer.o stage2/parser/Parser.o \r\nstage2/parser/ParserCore.o stage2/parser/ParserCoreUtils.o \r\nstage2/parser/RdrHsSyn.o stage2/prelude/ForeignCall.o \r\nstage2/prelude/PrelInfo.o stage2/prelude/PrelNames.o \r\nstage2/prelude/PrelRules.o stage2/prelude/PrimOp.o \r\nstage2/prelude/TysPrim.o stage2/prelude/TysWiredIn.o \r\nstage2/profiling/CostCentre.o stage2/profiling/SCCfinal.o \r\nstage2/rename/RnBinds.o stage2/rename/RnEnv.o \r\nstage2/rename/RnExpr.o stage2/rename/RnHsSyn.o \r\nstage2/rename/RnNames.o stage2/rename/RnSource.o \r\nstage2/rename/RnTypes.o stage2/simplCore/CSE.o \r\nstage2/simplCore/FloatIn.o stage2/simplCore/FloatOut.o \r\nstage2/simplCore/LiberateCase.o stage2/simplCore/OccurAnal.o \r\nstage2/simplCore/SAT.o stage2/simplCore/SATMonad.o \r\nstage2/simplCore/SetLevels.o stage2/simplCore/SimplCore.o \r\nstage2/simplCore/SimplEnv.o stage2/simplCore/SimplMonad.o \r\nstage2/simplCore/SimplUtils.o stage2/simplCore/Simplify.o \r\nstage2/simplStg/SRT.o stage2/simplStg/SimplStg.o \r\nstage2/simplStg/StgStats.o stage2/specialise/Rules.o \r\nstage2/specialise/SpecConstr.o stage2/specialise/Specialise.o \r\nstage2/stgSyn/CoreToStg.o stage2/stgSyn/StgLint.o \r\nstage2/stgSyn/StgSyn.o stage2/stranal/DmdAnal.o \r\nstage2/stranal/SaAbsInt.o stage2/stranal/SaLib.o \r\nstage2/stranal/StrictAnal.o stage2/stranal/WorkWrap.o \r\nstage2/stranal/WwLib.o stage2/typecheck/Inst.o \r\nstage2/typecheck/TcArrows.o stage2/typecheck/TcBinds.o \r\nstage2/typecheck/TcClassDcl.o stage2/typecheck/TcDefaults.o \r\nstage2/typecheck/TcDeriv.o stage2/typecheck/TcEnv.o \r\nstage2/typecheck/TcExpr.o stage2/typecheck/TcForeign.o \r\nstage2/typecheck/TcGenDeriv.o stage2/typecheck/TcHsSyn.o \r\nstage2/typecheck/TcHsType.o stage2/typecheck/TcInstDcls.o \r\nstage2/typecheck/TcMType.o stage2/typecheck/TcMatches.o \r\nstage2/typecheck/TcPat.o stage2/typecheck/TcRnDriver.o \r\nstage2/typecheck/TcRnMonad.o stage2/typecheck/TcRnTypes.o \r\nstage2/typecheck/TcRules.o stage2/typecheck/TcSimplify.o \r\nstage2/typecheck/TcSplice.o stage2/typecheck/TcTyClsDecls.o \r\nstage2/typecheck/TcTyDecls.o stage2/typecheck/TcType.o \r\nstage2/typecheck/TcUnify.o stage2/types/Class.o \r\nstage2/types/FunDeps.o stage2/types/Generics.o \r\nstage2/types/InstEnv.o stage2/types/Kind.o stage2/types/TyCon.o \r\nstage2/types/Type.o stage2/types/TypeRep.o stage2/types/Unify.o \r\nstage2/utils/Bag.o stage2/utils/Binary.o stage2/utils/BitSet.o \r\nstage2/utils/BufWrite.o stage2/utils/Digraph.o \r\nstage2/utils/FastMutInt.o stage2/utils/FastString.o \r\nstage2/utils/FastTypes.o stage2/utils/FiniteMap.o \r\nstage2/utils/IOEnv.o stage2/utils/ListSetOps.o \r\nstage2/utils/Maybes.o stage2/utils/OrdList.o \r\nstage2/utils/Outputable.o stage2/utils/Panic.o \r\nstage2/utils/Pretty.o stage2/utils/PrimPacked.o \r\nstage2/utils/StringBuffer.o stage2/utils/UnicodeUtil.o \r\nstage2/utils/UniqFM.o stage2/utils/UniqSet.o stage2/utils/Util.o \r\nstage2/parser/hschooks.o \r\nUndefined first referenced\r\n symbol in file\r\nsched_yield /home/pub/src/ghc-6.4.2/ghc/rts/libHSrts_thr.a(OSThreads.thr_o)\r\nld: fatal: Symbol referencing errors. No output written to stage2/ghc-6.4.2\r\ncollect2: ld returned 1 exit status\r\n<<ghc: 12902560 bytes, 3 GCs, 160656/160656 avg/max bytes residency (1 samples), 15M in use, 0.00 INIT (0.00 elapsed), 0.12 MUT (3.42 elapsed), 0.03 GC (0.05 elapsed) :ghc>>\r\ngmake[2]: *** [stage2/ghc-6.4.2] Error 1\r\ngmake[2]: Leaving directory `/home/pub/src/ghc-6.4.2/ghc/compiler'\r\ngmake[1]: *** [stage2] Error 2\r\ngmake[1]: Leaving directory `/home/pub/src/ghc-6.4.2'\r\ngmake: *** [bootstrap2] Error 2\r\n}}}\r\n\r\nHelp is very much appreciated, regards,\r\n\r\nFlorian","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/775ctime_r call in Solaris 10 SPARC2019-07-07T19:17:02Zflorenz@cs.tu-berlin.dectime_r call in Solaris 10 SPARCGHC 6.4.2 does not build on Solaris 10 because ctime_r takes three instead of two arguments.
The error is in file ghc/rts/RtsUtils.c. I did a quickfix to continue building but it is not very nice:
```
$ diff patched/ghc/rts/RtsUtils.c ...GHC 6.4.2 does not build on Solaris 10 because ctime_r takes three instead of two arguments.
The error is in file ghc/rts/RtsUtils.c. I did a quickfix to continue building but it is not very nice:
```
$ diff patched/ghc/rts/RtsUtils.c orig/ghc/rts/RtsUtils.c
190c190
< ctime_r(&now, nowstr, 26);
---
> ctime_r(&now, nowstr);
```
An extract of
$ man ctime
shows
```
SYNOPSIS
#include <time.h>
char *ctime(const time_t *clock);
struct tm *localtime(const time_t *clock);
struct tm *gmtime(const time_t *clock);
char *asctime(const struct tm *tm);
extern time_t timezone, altzone;
extern int daylight;
extern char *tzname[2];
void tzset(void);
char *ctime_r(const time_t *clock, char *buf, int buflen);
struct tm *localtime_r(const time_t *restrict clock, struct
tm *restrict res);
struct tm *gmtime_r(const time_t *restrict clock, struct tm
*restrict res);
char *asctime_r(const struct tm *restrict tm, char *restrict
buf, int buflen);
```
The exact OS version is
$ uname -a
SunOS bruja 5.10 Generic_118833-03 sun4u sparc SUNW,Sun-Fire
My suspect is that something in the autoconf spec is not correct for Solaris 10.
Regards,
Florian
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.4.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ctime_r call in Solaris 10 SPARC","status":"New","operating_system":"","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"GHC 6.4.2 does not build on Solaris 10 because ctime_r takes three instead of two arguments.\r\n\r\nThe error is in file ghc/rts/RtsUtils.c. I did a quickfix to continue building but it is not very nice:\r\n\r\n{{{\r\n$ diff patched/ghc/rts/RtsUtils.c orig/ghc/rts/RtsUtils.c\r\n190c190\r\n< ctime_r(&now, nowstr, 26);\r\n---\r\n> ctime_r(&now, nowstr);\r\n}}}\r\n\r\nAn extract of\r\n\r\n$ man ctime\r\n\r\nshows\r\n\r\n{{{\r\nSYNOPSIS\r\n #include <time.h>\r\n\r\n char *ctime(const time_t *clock);\r\n\r\n struct tm *localtime(const time_t *clock);\r\n\r\n struct tm *gmtime(const time_t *clock);\r\n\r\n char *asctime(const struct tm *tm);\r\n\r\n extern time_t timezone, altzone;\r\n extern int daylight;\r\n extern char *tzname[2];\r\n\r\n void tzset(void);\r\n\r\n char *ctime_r(const time_t *clock, char *buf, int buflen);\r\n\r\n struct tm *localtime_r(const time_t *restrict clock, struct\r\n tm *restrict res);\r\n\r\n struct tm *gmtime_r(const time_t *restrict clock, struct tm\r\n *restrict res);\r\n\r\n char *asctime_r(const struct tm *restrict tm, char *restrict\r\n buf, int buflen);\r\n}}}\r\n\r\nThe exact OS version is\r\n\r\n$ uname -a\r\n\r\nSunOS bruja 5.10 Generic_118833-03 sun4u sparc SUNW,Sun-Fire\r\n\r\nMy suspect is that something in the autoconf spec is not correct for Solaris 10.\r\n\r\nRegards,\r\n\r\nFlorian","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/776GHCi 6.4.2 reports an internal error: unknown/strange object2019-07-07T19:17:02Zjohn.detreville@microsoft.comGHCi 6.4.2 reports an internal error: unknown/strange objectI have a medium-sized interpreted program that seems to corrupt the heap when running under GHCi. Here's a couple of examples. (Ignore the first run, of course.)
```
C:\Documents and Settings\johndetr\My Documents\Haskell\Eval>ghci
_...I have a medium-sized interpreted program that seems to corrupt the heap when running under GHCi. Here's a couple of examples. (Ignore the first run, of course.)
```
C:\Documents and Settings\johndetr\My Documents\Haskell\Eval>ghci
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 6.4.2, for Haskell 98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
\____/\/ /_/\____/|_| Type :? for help.
Loading package base-1.0 ... linking ... done.
Prelude> :load Main
Compiling Types ( ./Types.hs, interpreted )
Compiling Layout ( ./Layout.hs, interpreted )
Compiling Eval ( ./Eval.hs, interpreted )
Compiling Main ( Main.hs, interpreted )
Ok, modules loaded: Main, Eval, Layout, Types.
*Main> main
Loading package haskell98-1.0 ... linking ... done.
Loading package haskell-src-1.0 ... linking ... done.
HsVar (UnQual (HsIdent "result"))
338350
[Node (Color 0.0 0.5 0.0) 12005 "338350"]
GHC's heap exhausted: current limit is 268435456 bytes;
Use the `-M<size>' option to increase the total heap size.
C:\Documents and Settings\johndetr\My Documents\Haskell\Eval>ghci +RTS -M500m
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 6.4.2, for Haskell 98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
\____/\/ /_/\____/|_| Type :? for help.
Loading package base-1.0 ... linking ... done.
Prelude> :load Main
Compiling Types ( ./Types.hs, interpreted )
Compiling Layout ( ./Layout.hs, interpreted )
Compiling Eval ( ./Eval.hs, interpreted )
Compiling Main ( Main.hs, interpreted )
Ok, modules loaded: Main, Eval, Layout, Types.
*Main> main
Loading package haskell98-1.0 ... linking ... done.
Loading package haskell-src-1.0 ... linking ... done.
HsVar (UnQual (HsIdent "result"))
338350
[Node (Color 0.0 0.5 0.0) 12005 "338350"]
<interactive>: internal error: update_fwd: unknown/strange object 38769
Please report this as a compiler bug. See:
http://www.haskell.org/ghc/reportabug
C:\Documents and Settings\johndetr\My Documents\Haskell\Eval>ghci +RTS -M800m
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 6.4.2, for Haskell 98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
\____/\/ /_/\____/|_| Type :? for help.
Loading package base-1.0 ... linking ... done.
Prelude> :load Main
Compiling Types ( ./Types.hs, interpreted )
Compiling Layout ( ./Layout.hs, interpreted )
Compiling Eval ( ./Eval.hs, interpreted )
Compiling Main ( Main.hs, interpreted )
Ok, modules loaded: Main, Eval, Layout, Types.
*Main> main
<interactive>:1:0: Not in scope: `gain'
*Main> main
Loading package haskell98-1.0 ... linking ... done.
Loading package haskell-src-1.0 ... linking ... done.
HsVar (UnQual (HsIdent "result"))
338350
[Node (Color 0.0 0.5 0.0) 12005 "338350"]
<interactive>: internal error: update_fwd: unknown/strange object 38769
Please report this as a compiler bug. See:
http://www.haskell.org/ghc/reportabug
```
So, would you like the source files? Or how else can I help?
Also, I run into the "gain" bug above quite often when I type ahead to GHCi under Windows. I assume this is known behavior.
Finally, when I got the initial message above to use the -M flag, it took me forever to remember to add the +RTS flag. Perhaps the message could be reworded to help people like me?
Cheers,
John
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.4.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"GHCi 6.4.2 reports an internal error: unknown/strange object","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"6.4.2","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I have a medium-sized interpreted program that seems to corrupt the heap when running under GHCi. Here's a couple of examples. (Ignore the first run, of course.)\r\n\r\n\r\n{{{\r\nC:\\Documents and Settings\\johndetr\\My Documents\\Haskell\\Eval>ghci\r\n ___ ___ _\r\n / _ \\ /\\ /\\/ __(_)\r\n / /_\\// /_/ / / | | GHC Interactive, version 6.4.2, for Haskell 98.\r\n/ /_\\\\/ __ / /___| | http://www.haskell.org/ghc/\r\n\\____/\\/ /_/\\____/|_| Type :? for help.\r\n\r\nLoading package base-1.0 ... linking ... done.\r\nPrelude> :load Main\r\nCompiling Types ( ./Types.hs, interpreted )\r\nCompiling Layout ( ./Layout.hs, interpreted )\r\nCompiling Eval ( ./Eval.hs, interpreted )\r\nCompiling Main ( Main.hs, interpreted )\r\nOk, modules loaded: Main, Eval, Layout, Types.\r\n*Main> main\r\nLoading package haskell98-1.0 ... linking ... done.\r\nLoading package haskell-src-1.0 ... linking ... done.\r\nHsVar (UnQual (HsIdent \"result\"))\r\n338350\r\n[Node (Color 0.0 0.5 0.0) 12005 \"338350\"]\r\nGHC's heap exhausted: current limit is 268435456 bytes;\r\nUse the `-M<size>' option to increase the total heap size.\r\n\r\nC:\\Documents and Settings\\johndetr\\My Documents\\Haskell\\Eval>ghci +RTS -M500m\r\n ___ ___ _\r\n / _ \\ /\\ /\\/ __(_)\r\n / /_\\// /_/ / / | | GHC Interactive, version 6.4.2, for Haskell 98.\r\n/ /_\\\\/ __ / /___| | http://www.haskell.org/ghc/\r\n\\____/\\/ /_/\\____/|_| Type :? for help.\r\n\r\nLoading package base-1.0 ... linking ... done.\r\nPrelude> :load Main\r\nCompiling Types ( ./Types.hs, interpreted )\r\nCompiling Layout ( ./Layout.hs, interpreted )\r\nCompiling Eval ( ./Eval.hs, interpreted )\r\nCompiling Main ( Main.hs, interpreted )\r\nOk, modules loaded: Main, Eval, Layout, Types.\r\n*Main> main\r\nLoading package haskell98-1.0 ... linking ... done.\r\nLoading package haskell-src-1.0 ... linking ... done.\r\nHsVar (UnQual (HsIdent \"result\"))\r\n338350\r\n[Node (Color 0.0 0.5 0.0) 12005 \"338350\"]\r\n<interactive>: internal error: update_fwd: unknown/strange object 38769\r\n Please report this as a compiler bug. See:\r\n http://www.haskell.org/ghc/reportabug\r\n\r\nC:\\Documents and Settings\\johndetr\\My Documents\\Haskell\\Eval>ghci +RTS -M800m\r\n ___ ___ _\r\n / _ \\ /\\ /\\/ __(_)\r\n / /_\\// /_/ / / | | GHC Interactive, version 6.4.2, for Haskell 98.\r\n/ /_\\\\/ __ / /___| | http://www.haskell.org/ghc/\r\n\\____/\\/ /_/\\____/|_| Type :? for help.\r\n\r\nLoading package base-1.0 ... linking ... done.\r\nPrelude> :load Main\r\nCompiling Types ( ./Types.hs, interpreted )\r\nCompiling Layout ( ./Layout.hs, interpreted )\r\nCompiling Eval ( ./Eval.hs, interpreted )\r\nCompiling Main ( Main.hs, interpreted )\r\nOk, modules loaded: Main, Eval, Layout, Types.\r\n*Main> main\r\n\r\n<interactive>:1:0: Not in scope: `gain'\r\n*Main> main\r\nLoading package haskell98-1.0 ... linking ... done.\r\nLoading package haskell-src-1.0 ... linking ... done.\r\nHsVar (UnQual (HsIdent \"result\"))\r\n338350\r\n[Node (Color 0.0 0.5 0.0) 12005 \"338350\"]\r\n<interactive>: internal error: update_fwd: unknown/strange object 38769\r\n Please report this as a compiler bug. See:\r\n http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nSo, would you like the source files? Or how else can I help?\r\n\r\nAlso, I run into the \"gain\" bug above quite often when I type ahead to GHCi under Windows. I assume this is known behavior.\r\n\r\nFinally, when I got the initial message above to use the -M flag, it took me forever to remember to add the +RTS flag. Perhaps the message could be reworded to help people like me?\r\n\r\nCheers,\r\nJohn","type_of_failure":"OtherFailure","blocking":[]} -->6.4.3https://gitlab.haskell.org/ghc/ghc/-/issues/777Typos in user guide example2019-07-07T19:17:01ZguestTypos in user guide exampleIn section "7.4.1.3 Liberalised type synonyms" of the user guide i find the following example:
> type Discard a = forall b. Show b =\> a -\> b -\> (a, String)
> f :: Discard a
> f x y = (x, show y)
> g :: Discard Int -\> (Int,Bool) --...In section "7.4.1.3 Liberalised type synonyms" of the user guide i find the following example:
> type Discard a = forall b. Show b =\> a -\> b -\> (a, String)
> f :: Discard a
> f x y = (x, show y)
> g :: Discard Int -\> (Int,Bool) -- A rank-2 type
> g f = f Int True
It seems like that Bool should be String.. and that Int should be an actual number?
I am new to haskell.. so I might just be missing something here..
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------- |
| Version | 6.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Documentation |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Typos in user guide example","status":"New","operating_system":"Unknown","component":"Documentation","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.5","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"In section \"7.4.1.3 Liberalised type synonyms\" of the user guide i find the following example:\r\n\r\n type Discard a = forall b. Show b => a -> b -> (a, String)\r\n\r\n f :: Discard a\r\n f x y = (x, show y)\r\n\r\n g :: Discard Int -> (Int,Bool) -- A rank-2 type\r\n g f = f Int True\r\n\r\n\r\nIt seems like that Bool should be String.. and that Int should be an actual number?\r\nI am new to haskell.. so I might just be missing something here..","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/778building with gcc-4.1.x causes ghc to enter infinite allocation loop2019-07-07T19:17:01Zguestbuilding with gcc-4.1.x causes ghc to enter infinite allocation loopI have the same program using both ghci and ghc. ghci gives:
```
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 6.4.2, for Haskell 98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc...I have the same program using both ghci and ghc. ghci gives:
```
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 6.4.2, for Haskell 98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
\____/\/ /_/\____/|_| Type :? for help.
ghc-6.4.2: out of memory (requested 1048576 bytes)
```
and ghc gives:
```
ghc -ignore-package Cabal --make -Wall -fno-warn-unused-matches -cpp -i. -odir dist/tmp -hidir dist/tmp Setup.lhs -o setup
ghc-6.4.2: out of memory (requested 1048576 bytes)
```
I have 2 gigs of ram, and 3 of swap. When I run ghci, my free memory quickly drops from \~1.9 Gb to less than 10 Mb, at which point, I get the out of memory error.
I'm running gentoo on my laptop, with gcc 4.1.1 and kernel 2.6.17-rc1-mm26.4.3https://gitlab.haskell.org/ghc/ghc/-/issues/779small bugs in Language.Haskell.TH.Ppr.pprint2019-07-07T19:17:01Zskata@cs.miyazaki-u.ac.jpsmall bugs in Language.Haskell.TH.Ppr.pprintThank you very much for developing GHC. I would like to report two small bugs and
my patch for them.
(These problems apply at least to 6.4.1, 6.4.2, and the current 6.5 in the darcs repository)
Problem 1:
pprint does not deal with pare...Thank you very much for developing GHC. I would like to report two small bugs and
my patch for them.
(These problems apply at least to 6.4.1, 6.4.2, and the current 6.5 in the darcs repository)
Problem 1:
pprint does not deal with parentheses of types of higher-order functions correctly, i.e.:
\[skata\@mermaid\]\~% ghci -fth -v0\[\[BR\]\]
Prelude\> Language.Haskell.TH.runQ \[t\| (Int-\>Int)-\>Int \|\] \>\>= \\e -\> putStrLn (Language.Haskell.TH.pprint e)\[\[BR\]\]
Loading package template-haskell-1.0 ... linking ... done.\[\[BR\]\]
GHC.Base.Int -\> GHC.Base.Int -\> GHC.Base.Int
I believe '(GHC.Base.Int -\> GHC.Base.Int) -\> GHC.Base.Int' should be printed.
Problem 2:
pprint does not parenthesize operators used as functions, e.g.:
Prelude\> Language.Haskell.TH.runQ \[\| (.) id id \|\] \>\>= \\e -\> putStrLn (Language.Haskell.TH.pprint e)[c \`elem\` "!\#$%&\~=\|+\*\<\>?-\^@:./\\\\"\`\[\[BR](BR]]
GHC.Base.. GHC.Base.id GHC.Base.id
I think 'GHC.Base..' should be parenthesized.
Patch:
Hopefully the following patch works (at least for me):
`== running darcs whatsnew in libraries/template-haskell`[[BR]]
`{`[[BR]]
`hunk ./Language/Haskell/TH/Ppr.hs 42`[[BR]]
`- ppr v = pprName v -- text (show v)`[[BR]]
`+ ppr v = case nameBase v of c:_ )
`+ -> parens (pprName v)`\[\[BR\]\]
`+ _ -> pprName v`\[\[BR\]\]
`hunk ./Language/Haskell/TH/Ppr.hs 289`\[\[BR\]\]
`-pprTyApp (ArrowT, [arg1,arg2]) = sep [ppr arg1 <+> text "->", ppr arg2]`\[\[BR\]\]
`+pprTyApp (ArrowT, [arg1,arg2]) = sep [ppr' arg1 <+> text "->", ppr arg2]`\[\[BR\]\]
`+ where ppr' t = case split t of (ArrowT, [_,_]) -> parens (ppr t)`\[\[BR\]\]
`+ _ -> ppr t`\[\[BR\]\]
`}`\[\[BR\]\]
Best regards,
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ---------------- |
| Version | 6.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Template Haskell |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Multiple |
| Architecture | Multiple |
</details>
<!-- {"blocked_by":[],"summary":"small bugs in Language.Haskell.TH.Ppr.pprint","status":"New","operating_system":"Multiple","component":"Template Haskell","related":[],"milestone":"6.4.2","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.5","keywords":[],"differentials":[],"test_case":"","architecture":"Multiple","cc":[""],"type":"Bug","description":"Thank you very much for developing GHC. I would like to report two small bugs and \r\nmy patch for them.\r\n\r\n(These problems apply at least to 6.4.1, 6.4.2, and the current 6.5 in the darcs repository)\r\n\r\nProblem 1:\r\npprint does not deal with parentheses of types of higher-order functions correctly, i.e.:\r\n\r\n[skata@mermaid]~% ghci -fth -v0[[BR]]\r\nPrelude> Language.Haskell.TH.runQ [t| (Int->Int)->Int |] >>= \\e -> putStrLn (Language.Haskell.TH.pprint e)[[BR]]\r\nLoading package template-haskell-1.0 ... linking ... done.[[BR]]\r\nGHC.Base.Int -> GHC.Base.Int -> GHC.Base.Int\r\n\r\nI believe '(GHC.Base.Int -> GHC.Base.Int) -> GHC.Base.Int' should be printed.\r\n\r\nProblem 2:\r\npprint does not parenthesize operators used as functions, e.g.:\r\n\r\nPrelude> Language.Haskell.TH.runQ [| (.) id id |] >>= \\e -> putStrLn (Language.Haskell.TH.pprint e)[[BR]]\r\nGHC.Base.. GHC.Base.id GHC.Base.id\r\n\r\nI think 'GHC.Base..' should be parenthesized.\r\n\r\nPatch:\r\nHopefully the following patch works (at least for me):\r\n\r\n`== running darcs whatsnew in libraries/template-haskell`[[BR]]\r\n`{`[[BR]]\r\n`hunk ./Language/Haskell/TH/Ppr.hs 42`[[BR]]\r\n`- ppr v = pprName v -- text (show v)`[[BR]]\r\n`+ ppr v = case nameBase v of c:_ | c `elem` \"!#$%&~=|+*<>?-^@:./\\\\\"`[[BR]]\r\n`+ -> parens (pprName v)`[[BR]]\r\n`+ _ -> pprName v`[[BR]]\r\n`hunk ./Language/Haskell/TH/Ppr.hs 289`[[BR]]\r\n`-pprTyApp (ArrowT, [arg1,arg2]) = sep [ppr arg1 <+> text \"->\", ppr arg2]`[[BR]]\r\n`+pprTyApp (ArrowT, [arg1,arg2]) = sep [ppr' arg1 <+> text \"->\", ppr arg2]`[[BR]]\r\n`+ where ppr' t = case split t of (ArrowT, [_,_]) -> parens (ppr t)`[[BR]]\r\n`+ _ -> ppr t`[[BR]]\r\n`}`[[BR]]\r\n\r\nBest regards,","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/780internal error: mallocBytesRWX:2019-07-07T19:17:00Zdreamer.tan@gmail.cominternal error: mallocBytesRWX:while loading my code (RBtrees implementation) sometimes interpreter says: OK
but sometimes (quite often) it crashes with description like:
```
Prelude Main> :load E.hs
Compiling Main ( E.hs, interpreted )
ghc-6.4.2: interna...while loading my code (RBtrees implementation) sometimes interpreter says: OK
but sometimes (quite often) it crashes with description like:
```
Prelude Main> :load E.hs
Compiling Main ( E.hs, interpreted )
ghc-6.4.2: internal error: mallocBytesRWX: failed to protect 0x0xa8e5c70
Please report this as a compiler bug. See:
http://www.haskell.org/ghc/reportabug
```
my RBtrees implementation is not finished yet, I found out that interpreter
crashes only after I add "veryLeftChild" function (code below).
Compiler works fine with or without this function, no problems.
my code:
```
module Main
where
import IO
{- --- implementacja drzew czerwono-czarnych wg. Okasakiego ---------------- -}
data Color = Red | Black
data Tree x = E | T Color (Tree x) x (Tree x)
type Set a = Tree a
-- empty : T -> bool
empty = E
-- member : x,T -> bool
member _ E = False
member n@(k,x,y) (T _ l (k',_,_) r) | k < k' = member n l
| k > k' = member n r
| k == k' = True
-- insert : x,T -> T
insert n@(k,x,y) s = makeBlack(insert_ s)
where
insert_ (T col l n'@(k',x',y') r ) | k < k' = balance col (insert_ l) n' r
| k > k' = balance col l n' (insert_ r)
| k == k' = T col l n r ;
insert_ E = T Red E n E ;
makeBlack (T _ l n' r) = T Black l n' r
-- balance T -> T
balance Black (T Red (T Red a x b) y c) z d = T Red (T Black a x b) y (T Black c z d)
balance Black (T Red a x (T Red b y c)) z d = T Red (T Black a x b) y (T Black c z d)
balance Black a x (T Red (T Red b y c) z d) = T Red (T Black a x b) y (T Black c z d)
balance Black a x (T Red b y (T Red c z d)) = T Red (T Black a x b) y (T Black c z d)
balance color a x b = T color a x b
-- locate x,T -> T
locate k tree@(T _ left@(T _ _ k1 _) k' right@(T _ _ k2 _)) | k == k' = tree
| k1 < k && k < k2 = tree
| k1 >= k = locate k left
| k <= k2 = locate k right
veryLeftChild tree@(T _ left k _) | left == E = k
| True = veryLeftChild left
-- next k tree =
-- delete : x,T -> T
{- remove n@(k,x,y) s = remove_ s
where
remove_ -}
{- --- main i miedzymordzie ------------------------------------------------ -}
main = do
hSetBuffering stdin LineBuffering
n <- getLine
while (rInt n) empty -- wywolanie operacji na drzewie (poczatkowo pustym)
rInt :: String -> Int
rInt = read
-- scan : String -> (cmd, x, y)
scan (l:' ':xs) = ( l, rInt x, rInt y )
where
(x,y) = scan xs;
scan (x:xs) | x == ' ' = ([], xs)
| True = (x:xs', ys') where (xs',ys') = scan(xs)
scan [] = ([],[])
-- while iteruje operacje i razy na tree
while i tree = do
if i == 0
then return []
else do
cmd <- getLine
let (output, tree') = command (scan cmd) tree
putStr output
r <- while (i-1) tree'
return r
-- wywoluje odpowiednia operacje na drzewie
command (cmd,x,y) tree | cmd == 'W' = ("", insert (x*x+y*y,x,y) tree )
| cmd == 'U' = ("usun\n", tree )
| cmd == 'D' = ("dalszy\n", tree )
| cmd == 'B' = ("blizszy\n", tree )
| True = error "wrong command"
```
I use ghc 6.4.2, Linux, Fedora Core 5, x86. For any further info contact me through dreamer.tan\@gmail.com
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.4.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | GHCi |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"internal error: mallocBytesRWX:","status":"New","operating_system":"","component":"GHCi","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"while loading my code (RBtrees implementation) sometimes interpreter says: OK\r\nbut sometimes (quite often) it crashes with description like:\r\n{{{\r\nPrelude Main> :load E.hs\r\nCompiling Main ( E.hs, interpreted )\r\nghc-6.4.2: internal error: mallocBytesRWX: failed to protect 0x0xa8e5c70\r\n\r\n Please report this as a compiler bug. See:\r\n http://www.haskell.org/ghc/reportabug\r\n}}}\r\n\r\nmy RBtrees implementation is not finished yet, I found out that interpreter\r\ncrashes only after I add \"veryLeftChild\" function (code below). \r\nCompiler works fine with or without this function, no problems.\r\nmy code:\r\n\r\n{{{\r\nmodule Main\r\n where\r\n\r\nimport IO\r\n\r\n{- --- implementacja drzew czerwono-czarnych wg. Okasakiego ---------------- -}\r\n\r\ndata Color = Red | Black\r\ndata Tree x = E | T Color (Tree x) x (Tree x)\r\n\r\ntype Set a = Tree a\r\n\r\n-- empty : T -> bool\r\nempty = E\r\n\r\n-- member : x,T -> bool\r\nmember _ E = False\r\nmember n@(k,x,y) (T _ l (k',_,_) r) | k < k' = member n l\r\n\t\t\t\t\t\t\t\t\t| k > k' = member n r\r\n\t\t\t\t\t\t\t\t\t| k == k' = True\r\n\r\n-- insert : x,T -> T\r\ninsert n@(k,x,y) s = makeBlack(insert_ s)\r\n\twhere\r\n\t\tinsert_ (T col l n'@(k',x',y') r ) | k < k' = balance col (insert_ l) n' r\r\n\t\t\t\t\t\t\t\t\t\t | k > k' = balance col l n' (insert_ r)\r\n\t\t\t\t\t\t\t\t\t\t | k == k' = T col l n r ;\r\n\t\tinsert_ E = T Red E n E ;\r\n\t\tmakeBlack (T _ l n' r) = T Black l n' r\r\n\r\n-- balance T -> T\r\nbalance Black (T Red (T Red a x b) y c) z d = T Red (T Black a x b) y (T Black c z d)\r\nbalance Black (T Red a x (T Red b y c)) z d = T Red (T Black a x b) y (T Black c z d)\r\nbalance Black a x (T Red (T Red b y c) z d) = T Red (T Black a x b) y (T Black c z d)\r\nbalance Black a x (T Red b y (T Red c z d)) = T Red (T Black a x b) y (T Black c z d)\r\nbalance color a x b = T color a x b\r\n\r\n\r\n-- locate x,T -> T\r\nlocate k tree@(T _ left@(T _ _ k1 _) k' right@(T _ _ k2 _)) | k == k' \t\t\t= tree\r\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t| k1 < k && k < k2 = tree\r\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t| k1 >= k\t\t\t= locate k left\r\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t| k <= k2\t\t\t= locate k right\r\n\r\nveryLeftChild tree@(T _ left k _) | left == E\t= k\r\n\t\t\t\t\t\t\t\t | True \t\t= veryLeftChild left\r\n\r\n-- next k tree = \r\n\r\n\r\n-- delete : x,T -> T\r\n{- remove n@(k,x,y) s = remove_ s\r\n\twhere\r\n\t\tremove_ -}\r\n\r\n{- --- main i miedzymordzie ------------------------------------------------ -}\r\n\r\nmain = do\r\n\thSetBuffering stdin LineBuffering\r\n\tn <- getLine\r\n\twhile (rInt n) empty -- wywolanie operacji na drzewie (poczatkowo pustym)\r\n\r\nrInt :: String -> Int\r\nrInt = read\r\n\r\n-- scan : String -> (cmd, x, y)\r\nscan (l:' ':xs) = ( l, rInt x, rInt y )\r\n\twhere\r\n\t\t(x,y) = scan xs;\r\n\t\tscan (x:xs) | x == ' ' = ([], xs)\r\n\t\t\t\t\t| True = (x:xs', ys') where (xs',ys') = scan(xs)\r\n\t\tscan [] = ([],[])\r\n\r\n-- while iteruje operacje i razy na tree\r\nwhile i tree = do\r\n\tif i == 0\r\n\t\tthen return []\r\n\t\telse do\r\n\t\t\tcmd <- getLine\r\n\t\t\tlet (output, tree') = command (scan cmd) tree\r\n\t\t\tputStr output\r\n\t\t\tr <- while (i-1) tree'\r\n\t\t\treturn r\r\n\r\n-- wywoluje odpowiednia operacje na drzewie\r\ncommand (cmd,x,y) tree | cmd == 'W' = (\"\", insert (x*x+y*y,x,y) tree )\r\n\t\t\t\t\t | cmd == 'U' = (\"usun\\n\", tree )\r\n\t\t\t\t\t | cmd == 'D' = (\"dalszy\\n\", tree )\r\n\t\t\t\t\t | cmd == 'B' = (\"blizszy\\n\", tree )\r\n\t\t\t\t\t | True\t\t= error \"wrong command\"\r\n\r\n}}}\r\n\r\nI use ghc 6.4.2, Linux, Fedora Core 5, x86. For any further info contact me through dreamer.tan@gmail.com","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/781GHCi on x86_64, cannot link to static data in shared libs2019-07-07T19:16:59ZguestGHCi on x86_64, cannot link to static data in shared libsSystem.Posix.getEnvironment fails on Linux 2.6.16-1.2108_FC4smp
with a segfault. (x86_64)
```
[aleator@thoth HopenCV]$ ghci
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 6.5.20060527, for...System.Posix.getEnvironment fails on Linux 2.6.16-1.2108_FC4smp
with a segfault. (x86_64)
```
[aleator@thoth HopenCV]$ ghci
___ ___ _
/ _ \ /\ /\/ __(_)
/ /_\// /_/ / / | | GHC Interactive, version 6.5.20060527, for Haskell 98.
/ /_\\/ __ / /___| | http://www.haskell.org/ghc/
\____/\/ /_/\____/|_| Type :? for help.
Loading package base-1.0 ... linking ... done.
Prelude> :m +System.Posix.Env
Prelude System.Posix.Env> getEnv "USER"
Loading package unix-1.0 ... linking ... done.
Just "aleator"
Prelude System.Posix.Env> getEnvironment
Segmentation fault
```
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"getEnvironment segfaults (6.5.20060527 - snapshot)","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.5","keywords":["getEnvironment"],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"System.Posix.getEnvironment fails on Linux 2.6.16-1.2108_FC4smp\r\nwith a segfault. (x86_64)\r\n\r\n{{{\r\n[aleator@thoth HopenCV]$ ghci\r\n ___ ___ _\r\n / _ \\ /\\ /\\/ __(_)\r\n / /_\\// /_/ / / | | GHC Interactive, version 6.5.20060527, for Haskell 98.\r\n/ /_\\\\/ __ / /___| | http://www.haskell.org/ghc/\r\n\\____/\\/ /_/\\____/|_| Type :? for help.\r\n\r\nLoading package base-1.0 ... linking ... done.\r\nPrelude> :m +System.Posix.Env\r\nPrelude System.Posix.Env> getEnv \"USER\"\r\nLoading package unix-1.0 ... linking ... done.\r\nJust \"aleator\"\r\nPrelude System.Posix.Env> getEnvironment\r\nSegmentation fault\r\n}}}","type_of_failure":"OtherFailure","blocking":[]} -->8.0.1https://gitlab.haskell.org/ghc/ghc/-/issues/782GHCi input does not support unicode2019-07-07T19:16:58ZSimon MarlowGHCi input does not support unicodeCurrently GHCi interprets input from the command line as Latin-1, it is encoded into UTF-8 internally (see stringToStringBuffer). We should accept input in UTF-8.
<details><summary>Trac metadata</summary>
| Trac field | Val...Currently GHCi interprets input from the command line as Latin-1, it is encoded into UTF-8 internally (see stringToStringBuffer). We should accept input in UTF-8.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.4.1 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"GHCi input does not support unicode","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"6.6","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"Currently GHCi interprets input from the command line as Latin-1, it is encoded into UTF-8 internally (see stringToStringBuffer). We should accept input in UTF-8.","type_of_failure":"OtherFailure","blocking":[]} -->6.8.2Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/783SRTs bigger than they should be?2019-07-07T19:16:58ZguestSRTs bigger than they should be?Windows XP, GHC 6.4.2 binary package.
Will attach the relevant module.
```
...
Compiling Dist ( ./Dist.hs, ./Dist.o )
ghc: internal error: update_fwd: unknown/strange object 0
Please report this as a compiler bug. See...Windows XP, GHC 6.4.2 binary package.
Will attach the relevant module.
```
...
Compiling Dist ( ./Dist.hs, ./Dist.o )
ghc: internal error: update_fwd: unknown/strange object 0
Please report this as a compiler bug. See:
http://www.haskell.org/ghc/reportabug
```7.2.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/784defining type of returned value2019-07-07T19:16:58ZBulat Ziganshin <Bulat.Ziganshin@gmail.com>defining type of returned value<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.4.2 |
| Type | Bug |
| TypeOfFailure |...<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.4.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"defining type of returned value","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/785Allow partial application of type synonyms2019-07-22T13:16:05ZBulat Ziganshin <Bulat.Ziganshin@gmail.com>Allow partial application of type synonymsthe enclosed program shows what i need. in particular, it is useful for arrays library, which widely uses higher-kind type constructors and classes around them
<details><summary>Trac metadata</summary>
| Trac field | Value ...the enclosed program shows what i need. in particular, it is useful for arrays library, which widely uses higher-kind type constructors and classes around them
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.4.2 |
| Type | FeatureRequest |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"partial application of type function","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"FeatureRequest","description":"the enclosed program shows what i need. in particular, it is useful for arrays library, which widely uses higher-kind type constructors and classes around them","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/786bugs around tagToEnum#2019-07-07T19:16:57ZBulat Ziganshin <Bulat.Ziganshin@gmail.com>bugs around tagToEnum#i've enclosed 3 modules which reports various problems. all they use tagToEnum\# and these bugs may be is because of the following, stated in CgExpr.lhs:
```
-- If you're reading this code in the attempt to figure
--...i've enclosed 3 modules which reports various problems. all they use tagToEnum\# and these bugs may be is because of the following, stated in CgExpr.lhs:
```
-- If you're reading this code in the attempt to figure
-- out why the compiler panic'ed here, it is probably because
-- you used tagToEnum# in a non-monomorphic setting, e.g.,
-- intToTg :: Enum a => Int -> a ; intToTg (I# x#) = tagToEnum# x#
-- That won't work.
tycon = tyConAppTyCon res_ty
```6.6Simon Peyton JonesSimon Peyton Joneshttps://gitlab.haskell.org/ghc/ghc/-/issues/787compacting GC2019-07-07T19:16:56ZBulat Ziganshin <Bulat.Ziganshin@gmail.com>compacting GCalthough Simon Marlow said that 6.4.2 finally fixed all compacting GC bugs, i still easily find one when i started to compile my libraries. enclosed file, when compiled with cmdline:
ghc Locking.hs +RTS -c
reports the following:
ghc.E...although Simon Marlow said that 6.4.2 finally fixed all compacting GC bugs, i still easily find one when i started to compile my libraries. enclosed file, when compiled with cmdline:
ghc Locking.hs +RTS -c
reports the following:
ghc.EXE: internal error: update_fwd: unknown/strange object 30600
Please report this as a compiler bug. See:
> http://www.haskell.org/ghc/reportabug
if you want to see more bugs, try to compile any large module - i encountered problems when compiling just Data.Array.Base or Data.Map from 6.4.2 libs using the same cmdline
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.4.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"compacting GC","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"although Simon Marlow said that 6.4.2 finally fixed all compacting GC bugs, i still easily find one when i started to compile my libraries. enclosed file, when compiled with cmdline:\r\n\r\nghc Locking.hs +RTS -c\r\n\r\nreports the following:\r\n\r\nghc.EXE: internal error: update_fwd: unknown/strange object 30600\r\n Please report this as a compiler bug. See:\r\n http://www.haskell.org/ghc/reportabug\r\n\r\n\r\nif you want to see more bugs, try to compile any large module - i encountered problems when compiling just Data.Array.Base or Data.Map from 6.4.2 libs using the same cmdline","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/788Implement class aliases and/or constraint synonyms2019-07-07T19:16:55ZSimon Peyton JonesImplement class aliases and/or constraint synonymsIt would be good to implement
- John Meacham's intriguing: [class alias proposal](http://repetae.net/john/recent/out/classalias.html), or
- Dominic Orchard and Tom Schrijvers's [Haskell type constraints unleashed](http://users.ugent.be/...It would be good to implement
- John Meacham's intriguing: [class alias proposal](http://repetae.net/john/recent/out/classalias.html), or
- Dominic Orchard and Tom Schrijvers's [Haskell type constraints unleashed](http://users.ugent.be/~tschrijv/Research/papers/constraint_families.pdf)
- Superclass defaulting: #2895
Some combination of these looks very desirable.
Other relevant links:
- http://haskell.org/haskellwiki/Class_alias
- http://markmail.org/message/sxr24pdvjq7dagco\#query:%22class%20alias%22%20proposal%20haskell+page:1+mid:weh6k4krwdmnvoyt+state:results
- http://www.mail-archive.com/haskell\@haskell.org/msg17356.html
- http://haskell.org/haskellwiki/Superclass_defaults.
- http://haskell.org/haskellwiki/Class_system_extension_proposal
- http://www.haskell.org/haskellwiki/Hac5/Projects\#Type_class_aliaseshttps://gitlab.haskell.org/ghc/ghc/-/issues/789BCOs can only have 64k instructions: linkBCO: >= 64k insns in BCO2019-07-07T19:16:54ZSimon Peyton JonesBCOs can only have 64k instructions: linkBCO: >= 64k insns in BCOFredrick Eaton (frederik\@a5.repetae.net) said:
Here I'm reading a very large matrix from a file and turning it into a
template Haskell expression. Probably not the most efficient thing to
do, but the error message could be clearer...
...Fredrick Eaton (frederik\@a5.repetae.net) said:
Here I'm reading a very large matrix from a file and turning it into a
template Haskell expression. Probably not the most efficient thing to
do, but the error message could be clearer...
```
*Main> let y = $(qFast (\f -> runIO $ readMatrixFile "data.txt" (runQ.f)));
ghc-6.4.2: panic! (the `impossible' happened, GHC version 6.4.2):
linkBCO: >= 64k insns in BCO
```
Indeed, the error message is unhelpful.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.4.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | low |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"BCOs can only have 64k instructions","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"Fredrick Eaton (frederik@a5.repetae.net) said:\r\n\r\nHere I'm reading a very large matrix from a file and turning it into a\r\ntemplate Haskell expression. Probably not the most efficient thing to\r\ndo, but the error message could be clearer...\r\n{{{\r\n*Main> let y = $(qFast (\\f -> runIO $ readMatrixFile \"data.txt\" (runQ.f)));\r\nghc-6.4.2: panic! (the `impossible' happened, GHC version 6.4.2):\r\n linkBCO: >= 64k insns in BCO\r\n\r\n}}}\r\nIndeed, the error message is unhelpful.","type_of_failure":"OtherFailure","blocking":[]} -->6.12.1https://gitlab.haskell.org/ghc/ghc/-/issues/790Redundant re-link when ".exe" omitted2019-07-07T19:16:54ZSimon Peyton JonesRedundant re-link when ".exe" omitted(Reported by Neil Mitchell.)
GHC 6.4.2 doesn't normally relink when invoked with --make if the
target file has not changed. This is very very useful!
Create a Main.hs, and compile with `ghc --make` twice, first time it
compiles, second...(Reported by Neil Mitchell.)
GHC 6.4.2 doesn't normally relink when invoked with --make if the
target file has not changed. This is very very useful!
Create a Main.hs, and compile with `ghc --make` twice, first time it
compiles, second time it does nothing.
Compile with `ghc --make -o file.exe` twice, first time it compiles,
second time it does nothing.
Compile with `ghc --make -o file` (note the absence of .exe). First time
it compiles as file.exe, second time and every time after it relinks.
This is the bug. On Windows `-o file` means `-o file.exe`, and I guess the
file "file" rather than "file.exe" is checked if it is up to date or
not.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.4.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Redundant re-link when \".exe\" omitted","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"(Reported by Neil Mitchell.)\r\n\r\nGHC 6.4.2 doesn't normally relink when invoked with --make if the\r\ntarget file has not changed. This is very very useful!\r\n\r\nCreate a Main.hs, and compile with {{{ghc --make}}} twice, first time it\r\ncompiles, second time it does nothing.\r\n\r\nCompile with {{{ghc --make -o file.exe}}} twice, first time it compiles,\r\nsecond time it does nothing.\r\n\r\nCompile with {{{ghc --make -o file}}} (note the absence of .exe). First time\r\nit compiles as file.exe, second time and every time after it relinks.\r\nThis is the bug. On Windows {{{-o file}}} means {{{-o file.exe}}}, and I guess the\r\nfile \"file\" rather than \"file.exe\" is checked if it is up to date or\r\nnot.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/791The program built with ghc 6.4.2 -prof hangs, without -prof works2019-07-07T19:16:54Zmblazevic@stilo.comThe program built with ghc 6.4.2 -prof hangs, without -prof worksTo reproduce the problem, download the attachment and do the following, assuming 6.4.2 is the version of the ghc executable in path:
```
tar xzf static.tar.gz
cd static
make
./gens 4 # works
./gens - <tests ...To reproduce the problem, download the attachment and do the following, assuming 6.4.2 is the version of the ghc executable in path:
```
tar xzf static.tar.gz
cd static
make
./gens 4 # works
./gens - <tests # works
./gens-prof 4 # hangs
```
Several points:
- ghc 6.4.1 works properly. That's what I'm using for profiling now.
- At first I thought the problem was with Edison libraries, but an
older version of the project, without Edison, behaves the same.
- Removing -auto-all and add -fasm made no difference. I guess that means GCC is not at fault.
By the way, I'm running Gentoo Linux with an Athlon CPU. Let me know if you have trouble reproducing the problem.6.6Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/792add viewMin/Max2019-07-07T19:16:53Zjpbernardyadd viewMin/MaxHave a function to get min/max element, remove it from the collection, and tolerate an empty collection (fail in a monad).
It will probably be added to the Map class.
refs:
http://www.haskell.org//pipermail/libraries/2006-June/005446.h...Have a function to get min/max element, remove it from the collection, and tolerate an empty collection (fail in a monad).
It will probably be added to the Map class.
refs:
http://www.haskell.org//pipermail/libraries/2006-June/005446.html
http://www.eecs.tufts.edu/\~rdocki01/docs/edison/Data-Edison-Assoc.html
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.5 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"add viewMin/Max","status":"New","operating_system":"Unknown","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.5","keywords":["collections"],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Task","description":"Have a function to get min/max element, remove it from the collection, and tolerate an empty collection (fail in a monad).\r\n\r\nIt will probably be added to the Map class.\r\n\r\nrefs:\r\nhttp://www.haskell.org//pipermail/libraries/2006-June/005446.html\r\nhttp://www.eecs.tufts.edu/~rdocki01/docs/edison/Data-Edison-Assoc.html","type_of_failure":"OtherFailure","blocking":[]} -->6.6https://gitlab.haskell.org/ghc/ghc/-/issues/793Use gcc's libffi to replace Adjustor.c and ByteCodeFFI.hs?2019-07-07T19:16:53ZSimon MarlowUse gcc's libffi to replace Adjustor.c and ByteCodeFFI.hs?`libffi` is a library that comes with gcc and provides FFI functionality (dynamic calls, closures) for a wide range of platforms. It has a liberal license that is compatible with GHC's.
`libffi` could replace Adjustor.c in the RTS and t...`libffi` is a library that comes with gcc and provides FFI functionality (dynamic calls, closures) for a wide range of platforms. It has a liberal license that is compatible with GHC's.
`libffi` could replace Adjustor.c in the RTS and the ByteCodeFFI module in GHCi. The benefits would be:
- It works on more platforms than we currently support, and it
handles more of the dark corners than we do (eg. struct returns?).
- It would ease the task of porting GHC
- Replaces a wad of very difficult non-portable code in GHC with code
written and actively maintained by others.
On the other hand, it is possible that our Adjustor.c code is faster, because it is more specialised to the task.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.4.1 |
| Type | Task |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Runtime System |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"Use gcc's libffi to replace Adjustor.c and ByteCodeFFI.hs?","status":"New","operating_system":"Unknown","component":"Runtime System","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.1","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Task","description":"{{{libffi}}} is a library that comes with gcc and provides FFI functionality (dynamic calls, closures) for a wide range of platforms. It has a liberal license that is compatible with GHC's.\r\n\r\n{{{libffi}}} could replace Adjustor.c in the RTS and the ByteCodeFFI module in GHCi. The benefits would be:\r\n\r\n * It works on more platforms than we currently support, and it\r\n handles more of the dark corners than we do (eg. struct returns?).\r\n\r\n * It would ease the task of porting GHC\r\n\r\n * Replaces a wad of very difficult non-portable code in GHC with code\r\n written and actively maintained by others.\r\n \r\nOn the other hand, it is possible that our Adjustor.c code is faster, because it is more specialised to the task.","type_of_failure":"OtherFailure","blocking":[]} -->6.10.1Simon MarlowSimon Marlowhttps://gitlab.haskell.org/ghc/ghc/-/issues/794System.Random: StdGen's genRange doesn't match its next2019-07-07T19:16:53Zrturk@science.uva.nlSystem.Random: StdGen's genRange doesn't match its next```
> g <- getStdGen
> length $ filter (<0) $ take (10^6) $ unfoldr (Just . next) g
0
> genRange g
(-2147483648,2147483647)
```
Apparently, `StdGen`'s `next` only returns non-negative values.
Also, `StdGen` doesn't override de default m...```
> g <- getStdGen
> length $ filter (<0) $ take (10^6) $ unfoldr (Just . next) g
0
> genRange g
(-2147483648,2147483647)
```
Apparently, `StdGen`'s `next` only returns non-negative values.
Also, `StdGen` doesn't override de default method `genRange`. However, the System.Random docs (http://haskell.org/ghc/docs/latest/html/libraries/base/System-Random.html\#v%3Anext) promise:
*The next operation returns an Int that is uniformly distributed in the range returned by genRange (including both end points), and a new generator.*
Thus, `StdGen`'s `next` violates the uniform distribution requirement.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | -------------- |
| Version | 6.4.2 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | libraries/base |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"System.Random: StdGen's genRange doesn't match its next","status":"New","operating_system":"Unknown","component":"libraries/base","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.4.2","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"{{{\r\n> g <- getStdGen\r\n> length $ filter (<0) $ take (10^6) $ unfoldr (Just . next) g\r\n0\r\n> genRange g\r\n(-2147483648,2147483647)\r\n}}}\r\n\r\nApparently, {{{StdGen}}}'s {{{next}}} only returns non-negative values.\r\nAlso, {{{StdGen}}} doesn't override de default method {{{genRange}}}. However, the System.Random docs (http://haskell.org/ghc/docs/latest/html/libraries/base/System-Random.html#v%3Anext) promise:\r\n\r\n''The next operation returns an Int that is uniformly distributed in the range returned by genRange (including both end points), and a new generator.''\r\n\r\nThus, {{{StdGen}}}'s {{{next}}} violates the uniform distribution requirement.","type_of_failure":"OtherFailure","blocking":[]} -->https://gitlab.haskell.org/ghc/ghc/-/issues/795ghc-6.5.20060607: panic! (the 'impossible' happened) ... initC: srt2019-07-07T19:16:53Zravi@bluespec.comghc-6.5.20060607: panic! (the 'impossible' happened) ... initC: srtI got the error above while compiling some of my code with the ghc 2006-06-07 snapshot.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version ...I got the error above while compiling some of my code with the ghc 2006-06-07 snapshot.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"ghc-6.5.20060607: panic! (the 'impossible' happened) ... initC: srt","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"I got the error above while compiling some of my code with the ghc 2006-06-07 snapshot.","type_of_failure":"OtherFailure","blocking":[]} -->6.6https://gitlab.haskell.org/ghc/ghc/-/issues/796Literate pre-processor fails to see end of code in LaTeX2019-07-07T19:16:52ZAdamLiterate pre-processor fails to see end of code in LaTeXUsing the code environment in a LaTeX document to place Haskell source, if trying to read the file, the Literate pre-processor fails to see the \\end{code} tag, as in the following example:
```
\begin{code}
> module Main where
> main = ...Using the code environment in a LaTeX document to place Haskell source, if trying to read the file, the Literate pre-processor fails to see the \\end{code} tag, as in the following example:
```
\begin{code}
> module Main where
> main = do
> someStuff
\end{code}
```https://gitlab.haskell.org/ghc/ghc/-/issues/797nofib tests fail on Windows due to different EOL convention in output files2019-07-07T19:16:52ZSimon Marlownofib tests fail on Windows due to different EOL convention in output filesFixed in 307ae61121a99f6ffd3d5fa56e5d37b1b91a492b
```
This allows nofib to run on Windows using `msys`.
Also deprecates the old `cygwin` stuff.
Test Plan: make clean && make
Reviewers: bgamari
Reviewed By: bgamari
Subscribers: Ryan...Fixed in 307ae61121a99f6ffd3d5fa56e5d37b1b91a492b
```
This allows nofib to run on Windows using `msys`.
Also deprecates the old `cygwin` stuff.
Test Plan: make clean && make
Reviewers: bgamari
Reviewed By: bgamari
Subscribers: RyanGlScott, #ghc_windows_task_force
Differential Revision: https://phabricator.haskell.org/D3030
```8.4.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/798Ix{Int}.index: Index (402849792) out of range ((0,100))2019-07-07T19:16:52Zstepan@golosunov.pp.ruIx{Int}.index: Index (402849792) out of range ((0,100))While building ghc HEAD pulled 2006-06-21 I got the following:
```
../../compiler/ghc-inplace -H16m -O -cpp -Iinclude -ignore-package HGL -O -Rghc-timing -fgenerics -package base -package X11 -fgenerics -split-objs -hisuf p_hi -hcsuf ...While building ghc HEAD pulled 2006-06-21 I got the following:
```
../../compiler/ghc-inplace -H16m -O -cpp -Iinclude -ignore-package HGL -O -Rghc-timing -fgenerics -package base -package X11 -fgenerics -split-objs -hisuf p_hi -hcsuf p_hc -osuf p_o -prof -c Graphics/HGL/Draw/Font.hs -o Graphics/HGL/Draw/Font.p_o -ohi Graphics/HGL/Draw/Font.p_hi
ghc-6.5: panic! (the 'impossible' happened)
(GHC version 6.5 for i386-unknown-linux):
Ix{Int}.index: Index (402849792) out of range ((0,100))
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
<<ghc: 46532900 bytes, 12 GCs, 4062821/8300368 avg/max bytes residency (3 samples), 19M in use, 0.02 INIT (0.00 elapsed), 0.55 MUT (0.75 elapsed), 0.55 GC (0.58 elapsed) :ghc>>
make[3]: *** [Graphics/HGL/Draw/Font.p_o] Ошибка 1
make[2]: *** [all] Ошибка 1
make[1]: *** [all] Ошибка 1
make[1]: Leaving directory `/home/stepan/projects/darcs.haskell.org/ghc/libraries'
make: *** [stage1] Ошибка 2
```
I used ghc 6.2.2 for bootstrapping
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | |
| Architecture | |
</details>
<!-- {"blocked_by":[],"summary":"Ix{Int}.index: Index (402849792) out of range ((0,100))","status":"New","operating_system":"","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.5","keywords":[],"differentials":[],"test_case":"","architecture":"","cc":[""],"type":"Bug","description":"While building ghc HEAD pulled 2006-06-21 I got the following:\r\n\r\n{{{\r\n../../compiler/ghc-inplace -H16m -O -cpp -Iinclude -ignore-package HGL -O -Rghc-timing -fgenerics -package base -package X11 -fgenerics -split-objs -hisuf p_hi -hcsuf p_hc -osuf p_o -prof -c Graphics/HGL/Draw/Font.hs -o Graphics/HGL/Draw/Font.p_o -ohi Graphics/HGL/Draw/Font.p_hi\r\nghc-6.5: panic! (the 'impossible' happened)\r\n (GHC version 6.5 for i386-unknown-linux):\r\n Ix{Int}.index: Index (402849792) out of range ((0,100))\r\n\r\nPlease report this as a GHC bug: http://www.haskell.org/ghc/reportabug\r\n\r\n<<ghc: 46532900 bytes, 12 GCs, 4062821/8300368 avg/max bytes residency (3 samples), 19M in use, 0.02 INIT (0.00 elapsed), 0.55 MUT (0.75 elapsed), 0.55 GC (0.58 elapsed) :ghc>>\r\nmake[3]: *** [Graphics/HGL/Draw/Font.p_o] Ошибка 1\r\nmake[2]: *** [all] Ошибка 1\r\nmake[1]: *** [all] Ошибка 1\r\nmake[1]: Leaving directory `/home/stepan/projects/darcs.haskell.org/ghc/libraries'\r\nmake: *** [stage1] Ошибка 2\r\n\r\n}}}\r\n\r\nI used ghc 6.2.2 for bootstrapping","type_of_failure":"OtherFailure","blocking":[]} -->6.6https://gitlab.haskell.org/ghc/ghc/-/issues/799runtime error when using par/seq in a monad2019-07-07T19:16:52Zmafuchs@microsoft.comruntime error when using par/seq in a monadThe following version of parfib dies with the following message, but the version after the error message works:
```
parfib 0 = return 1
parfib 1 = return 1
parfib n = do
n1 <- parfib (n - 1)
n2 <- parfib (n -...The following version of parfib dies with the following message, but the version after the error message works:
```
parfib 0 = return 1
parfib 1 = return 1
parfib n = do
n1 <- parfib (n - 1)
n2 <- parfib (n - 2)
n3 <- (n1 `par` (n2 `seq` (return (n1 + n2 + 1))))
return n3
```
```
sh-2.04$ ./Main +RTS -N4 -sstderr
c:\msys\1.0\ghc6.5\bin\Main.exe +RTS -N4 -sstderr
Main.exe: internal error: evacuate: strange closure type 8208
(GHC version 6.5.20060619 for i386_unknown_mingw32)
Please report this as a GHC bug: http://www.haskell.org/ghc/reportabug
```
This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
This version of parfib works
```
parfib 0 = return 1
parfib 1 = return 1
parfib n = do
n1 <- parfib (n - 1)
n2 <- parfib (n - 2)
return (n1 `par` (n2 `seq` (n1 + n2 + 1)))
```https://gitlab.haskell.org/ghc/ghc/-/issues/800GHC 6.5 enforces "-x c" option in the Cc phase making it impossibble to compi...2019-07-07T19:16:51Zkyra@veernet.ruGHC 6.5 enforces "-x c" option in the Cc phase making it impossibble to compile C++ files with ghc driverGHC 6.4.x enforces "-x c" option ONLY for HCc phase. This makes possible to use GHC driver to compile C++ files.
GHC 6.5 enforces "-x c" option ALSO for Cc phase. Now ANY file compiled with "-x c" option is treated as "c" file, regardle...GHC 6.4.x enforces "-x c" option ONLY for HCc phase. This makes possible to use GHC driver to compile C++ files.
GHC 6.5 enforces "-x c" option ALSO for Cc phase. Now ANY file compiled with "-x c" option is treated as "c" file, regardless of extension.
<details><summary>Trac metadata</summary>
| Trac field | Value |
| ---------------------- | ------------ |
| Version | 6.5 |
| Type | Bug |
| TypeOfFailure | OtherFailure |
| Priority | normal |
| Resolution | Unresolved |
| Component | Compiler |
| Test case | |
| Differential revisions | |
| BlockedBy | |
| Related | |
| Blocking | |
| CC | |
| Operating system | Unknown |
| Architecture | Unknown |
</details>
<!-- {"blocked_by":[],"summary":"GHC 6.5 enforces \"-x c\" option in the Cc phase making it impossibble to compile C++ files with ghc driver","status":"New","operating_system":"Unknown","component":"Compiler","related":[],"milestone":"","resolution":"Unresolved","owner":{"tag":"Unowned"},"version":"6.5","keywords":[],"differentials":[],"test_case":"","architecture":"Unknown","cc":[""],"type":"Bug","description":"GHC 6.4.x enforces \"-x c\" option ONLY for HCc phase. This makes possible to use GHC driver to compile C++ files.\r\n\r\nGHC 6.5 enforces \"-x c\" option ALSO for Cc phase. Now ANY file compiled with \"-x c\" option is treated as \"c\" file, regardless of extension.","type_of_failure":"OtherFailure","blocking":[]} -->6.6.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>https://gitlab.haskell.org/ghc/ghc/-/issues/801random list from randomseed ... amd64 differs2019-07-07T19:16:51Zcaaadarrandom list from randomseed ... amd64 differsI have the following:
```
> randomList::Int->[Double]
> randomList seed = randoms (mkStdGen seed)::[Double]
```
randomList 2342 on Linux/amd64 differs from Linux/x86 and Mac/PPC (all i were able to find out)
on Linux/x86 it is the sam...I have the following:
```
> randomList::Int->[Double]
> randomList seed = randoms (mkStdGen seed)::[Double]
```
randomList 2342 on Linux/amd64 differs from Linux/x86 and Mac/PPC (all i were able to find out)
on Linux/x86 it is the same as on Mac/PPC.
is that a bug? `mkStdGen` should produce proper (reproduceable) Pseudorandomnumbers but they are not inter-OS-reproduceable6.8.1Ian Lynagh <igloo@earth.li>Ian Lynagh <igloo@earth.li>