I'm currently using a stack script, and am wondering if this could be sped up by explicitly compiling it to an executable, or alternatively caching the object code so that stack will not recompile every time. Maybe it is already doing the latter - certainly it is for dependencies, just not sure about the object code of the script itself. In which case, I guess I just need to write faster code!
You can use stack exec ghc to call the ghc installed by stack. Example usage:
stack exec ghc --resolver lts-15.0 -- -o test Test.hs
Related
I am currently trying to write a GCC backend for a new architecture, but when I try to compile it I get the following error message:
xgcc: internal compiler error: Segmentation fault signal terminated program cc1
The build is configured with the following command:
../gcc/configure --prefix=--prefix=$HOME/GCC-10.0.1 --disable-bootstrap --target=arch_name --enable-languages=c
How would I go about fixing this error so that I can build my backend?
As far as I am aware, I have implemented the target macro's, functions and insn patterns required to get GCC to build.
Sorry that the question is a bit vague, I am not sure what extra information I can provide. If more specific information is needed please let me know and I will edit the question.
Thanks in advance.
How would I go about fixing this error so that I can build my backend?
Debug cc1.
xgcc is located in $builddir/gcc. Hence run $builddir/xgcc -B$builddir -v -save-temps <options-that-crash-cc1>.
xgcc -v ... will print the sub-commands it is calling, record the options it supplies to the crashing cc1 call.
Run a debugger against that cc1 call, supply the right options and put a breakpoint at abort (will be fancy_abort) actually.
Build the compiler without optimization. It's enough to run make in $builddir/gcc for that. You can supply additional option if you like, e.g. make -j4 cc1 CXXFLAGS='<flags-to-pass>'.
$builddir/gcc provides .gdbinit to augment gdb with additional hooks to improve debugging experience.
I'm trying to setup Haskell environment on my macbook (high sierra). I'm using stack 1.6.3 x86_64 hpack-0.20.0 and creating new project with default template (resolver is lts-10.5). If I run stack ghci without changing anything, I get the following warning I can not deal with.
The following GHC options are incompatible with GHCi and have not been passed to it: -threaded
Any ideas what is going wrong?
I'm not sure this is even a "warning," it's just informational. GHC and GHCi share a lot of the same options, so when Stack starts GHCi it just takes the GHC compiler options from package.yaml and passes them all as options to GHCi.
The default Stack template contains an executable that is compiled with the -threaded option (which you can see by looking in the package.yaml file that stack new generates). This isn't an option that is applicable to GHCi (it is a linker option that enables threading in the RTS, but it seems that threading is always enabled in the REPL regardless), so it's just letting you know that it doesn't have any effect. But it doesn't indicate a problem.
I'm looking for something like
$ stack ghci -- Main.hs +RTS -M20M
Cannot use 'stack ghci' with both file targets and build targets
As this workaround is not recommended (why?):
stack exec -- ghci Main.hs +RTS -M20M
Ah, that is indeed a very poor error message. I've created an issue for this - https://github.com/commercialhaskell/stack/issues/3342 - and implemented a fix, so that the next release of stack will instead say
The following errors occurred while parsing the build targets:
- Directory not found: +RTS
- Directory not found: -M20M
Note that to specify options to be passed to GHCi, use the --ghci-options flag
Instead running stack ghci Main.hs --ghci-options '+RTS -M20M' with released stack will yield:
ghc: unknown RTS option: -ghci-script=/tmp/ghci29580/ghci-script
Because the user arguments are not passed to the end. I've fixed that too. For now, you can use stack ghci Main.hs --ghci-options '+RTS -M20M -RTS'
I want to detect stack overflow or corruption in my code. Hence, i wrote a small program where stack overflow is simulated. I compiled it using the command:
gcc overflow.c -g -fstack-protector-all
However, upon executing the binary i got segmentation fault but no other information.
Can anybody please help me where did i go wrong?
If ulimit -c is set to a value much bigger than zero, a core dump named core is written; you can see the backtrace via running gdb program core and then typing backtrace at the prompt.
I have an existing fortran code which is compiled using mpif90. It compiles and runs successfully. But when i introduce -fopenmp option mpif90 compiler compiles the code successfully but the program fails to run to completion. It abruptly quits before entering a subroutine. Seems like the stack is full so the program quits abruptly. The manpages say that -fopenmp will allocate arrays on stack and it is like using -frecursive flag. How do I proceed with this problem and what -frecursive flag?
You need to increase the stack for both the master thread (on linux that would be with the limit or ulimit command) and for the slave threads (if you are using OpenMP V3.0, that would be through the environment variable OMP_STACKSIZE).