I've implemented this LRU cache sample from HackerRank. It includes 500,000 test cases for the cache in the main function. When I try to compile it with
g++ -Wall -std=c++17 cache.cpp -o cache
it fails with this message:
g++: internal compiler error: Segmentation fault signal terminated program cc1plus
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-9/README.Bugs> for instructions.
Memory usage during compilation was decent, far away from any limits. My g++ version is
me#vie:$ g++ --version
g++ (Ubuntu 9.3.0-11ubuntu0~18.04.1) 9.3.0
Copyright (C) 2019 Free Software Foundation, Inc.
How do do I find out more what exactly is causing the compiler to fail? I've seen similar questions and comments saying this is a bug but before I submit an issue I'd like to doublecheck if this isn't just some bad design on my end.
Related
I'm trying to setup my vscode to debug C++ programs using gdb from WSL. But I faced problem with gdb on my WSL 1 (Ubuntu 22.04 LTS). Whenever I try set a breakpoint and run a program, I get the following error:
Starting program: /mnt/d/Informatics/vscode/test/a.out
warning: opening /proc/PID/mem file for lwp 7674.7674 failed: No such file or directory (2)
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x10e0
The contents of the program don't matter, always getting the error. Code is compiled using the following line:
g++ -Wall -pedantic-errors -O2 -std=c++23 -ggdb3 -fdiagnostics-color=always /mnt/d/Informatics/vscode/test/*.cpp
gdb version: GNU gdb (Ubuntu 12.0.90-0ubuntu1) 12.0.90
g++ version: 12.0.1 (also tried with 11.2.0 - no difference)
On windows with g++ and gdb from MinGW the problem doesn't exist, so this should mean I'm not using the gdb debugger wrong.
Edit: tried compiling gdb 11.2 from source as suggested in comments, but this did not fix the problem. Only difference is that it's not showing /proc/PID/mem warning now.
Starting program: /mnt/d/Informatics/vscode/test/a.out
Warning:
Cannot insert breakpoint 1.
Cannot access memory at address 0x10e0
Edit 2: Compiled gdb 10.2 from source and it works, the problem does not appear. I don't know why it doesn't work with any version above 10.2. Is it gdb bug or WSL bug?
Here's the code:
main() {}
On gcc.godbolt.org, both GCC 10.1 and Clang 10 (with -Wall -Wextra -pedantic-errors -std=c++20) refuse to compile this.
GCC: error: ISO C++ forbids declaration of 'main' with no type [-Wpedantic]
Clang: error: C++ requires a type specifier for all declarations
But on my local machine, MinGW GCC happily accepts this code without any errors or warnings (with the same flags). This is not something new; this specific peculiarity was there for years.
Why does MinGW GCC behave differntly from the regular GCC in this case? Are there any flags to make it diagnose this error?
I got my GCC from MSYS2. It identifies as
# g++ --version
g++.exe (Rev3, Built by MSYS2 project) 10.1.0
Copyright (C) 2020 Free Software Foundation, Inc.
Clang 10 on the same machine does reject the code (the official binary, using libstdc++ from this GCC).
As noted by #ssbssa, MinGW GCC enables -fms-extensions by default, and it's one of the effects of that flag.
Compile with -fno-ms-extensions to fix that.
I am trying to compile a large group of codes for solving a physics problem. I usually use gfortran. There is no compile time error. My gfortran compiler statement is
gfortran -fdefault-real-8 -O -Waliasing -Wampersand -Wconversion -Wsurprising -Wintrinsics-std -Wintrinsic-shadow -Wline-truncation -Wreal-q-constant
When executed, I get a runtime error
Program received signal SIGBUS: Access to an undefined portion of a memory object.
But this runtime error does not occur, when I compile with the debugging flag -g or with Intel compiler ifort.
Even with gfortran without the -g flag, sometime this error does not occur! I know that this can be caused by some undefined array or unallocated array or something like this. My problem is that I can not seem to find out where is problem as apparently, I have no compile-time error.
So, is there a compiler flag for gfortran or for ifort which can help me detect this error?
Thanks
Madhurjya
I am working on a game and recently made the transition from SDL 1.2 to SDL2 (kinda late to the party but heh). Despite having no compilation or linking error whatsoever, the program crashed on launch while stating (translated from French) "The application failed to start up correctly". At first I thought it was my own fault, but then I got suspicious and put together a quick SDL2 test, which indeed after flawless compilation crashed on launch.
Here is the code I've been using for this example (you can't make it more simple) :
#include <SDL.h>
int main(int argc, char *argv[])
{
return 0;
}
And the compilation line is g++ main.cpp -ISDL2-2.0.4\x86_64-w64-mingw32\include\SDL2 -LSDL2-2.0.4\x86_64-w64-mingw32\lib -lmingw32 -lSDL2main -lSDL2 -otest.exe -fpermissive -std=c++11 -Wno-write-strings -Wno-overflow
For what it's worth :
> g++ --version
g++ (x86_64-win32-seh, Built by MinGW-W64 project) 6.1.0
Copyright (C) 2016 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
I'm running MinGW-w64 on Windows, as you can see. The OS is Windows 8.1.
Welp. I actually used the wrong SDL2.dll. I feel dumb now.
I'm trying to use cilkscreen to detect some race conditions in a code.
I'm compiling my code using
g++-5 -g foo.cpp -fcilkplus -std=c++14 -lcilkrts -ldl -O2
However, when I launch cilkscreen I get the following error message:
cilkview ./a.out
Cilkview: Generating scalability data
Cilkview Scalability Analyzer V2.0.0, Build 4421
1100189201
Error: No Cilk code found in program
Should I add some more option to g++ ? Or does cilkscreen only works with code compiled with icc ?
FWIW: I'm using
gcc version 5.3.1 20160301 [gcc-5-branch revision 233849] (SUSE Linux)
Cilkscreen/cilkview works only with icc/icpc.