C++: debug bus error - c++

I am trying to compile a c++ program in Linux, using the command in the shell
$ g++ -Wall *.cpp -o prog
and for some reason it keeps on giving me a weird error:
g++: Internal error: Bus error (program cc1plus) Please submit a full
bug report. See for
instructions.
I searched the net for this bus error, and it says that it has to do with something about accessing illegal memory.
Can someone maybe clarify things a bit more for me?

This error message is telling you that there's a bug in the g++ compiler itself.
Try to narrow it down by removing bits and pieces of your source file until the problem goes away. You're not trying to fix your program, you're just trying to find the part that is breaking the compiler. Once you've found it, you can either give a better bug description or you can change your code to work around it.
Or just download the latest version of the g++ compiler and hope that it's already fixed.

Your problem is not in your code, is the compiler (g++) that is crashing and producing that Bus Error, it's possible you have an outdated version of such compiler and need to update, or you're lucky and found a real bug in g++.
I would try compiling each source file separately, to check what part of the source code triggers the error.

Related

How to solve comiler error: 'v_bias' is not a namespace-name

Sort briefing what I am trying to do:
I want to use vnode-lp on my windows PC. I’ve installed MinGW. I’ve installed the necessary dependencies like LAPACK & BLAS libraries as well as Profil/BIAS. The installation of all libraries passed the make and make install process without errors. I hope (!) I’ve managed to install it correctly.
Now the Problem:
Now I’ve tried to get a simple program compiled with basically northing in it just an #include “vnode.h”. First I tried it with Microsoft Visual Studio. Since this gave me several errors I tried to compile it with g++ using MinGW. This gives me the same errors. It starts with
./matrix.w:90:17: error: ‘v_bias’ is not a namespace-name
The Question:
How to include vnodelp into an c++ program and compile it without errors under windows, am I missing something?
Off-topic:
I am trying to get this running for over a week now and don’t know what to do anymore.
C++ is most definitely not C, and packages designed for C++ will never compile and run as C code. So, what you're trying to do really can't be done unless you do some fancy stuff by creating a .dll or something like that, and even then I think you wouldn't get the functionality you want. Why not write your code in C++ and compile with g++ or a similar compiler?
I have managed to finally solve this issue. In case someone has the same problem here is the solution.
I have missed something in the call. Here is the full call that has worked for me:
g++ -o2 –Wall –Wno-deprecated –DNDEBUG – DPROFIL_VNODE – DMAXORDER=50 –I(path to profil bias)/include –I(path to profil bias)/include/BIAS –I(path to profil bias)/src/Base –I(path to vnodelp)/FADBAD++ -I../include –DNDEBUG –c –o (filename).o (filename).cc
g++ -L(path to profil bias)/lib –L(path to lapack)/lib –L../lib –o (filename) (filename).o –lvnode –lProfil –lBias –llr (path to lapack)/lib/liblapack.lib (path to lapack)/lib/libblas.lib –lstd++
funfact:
This also complies with gcc instead of g++

internal compiler error: in decode_addr_const, at varasm.c:2632

When I compile a project using cross compiler,I come across the following error:
internal compiler error: in decode_addr_const, at varasm.c:2632
Where can I find the varasm.c file?I searched the project directory and cross compiler directory,but I didn't find it.
Thanks for helpping,Light
The compiler maker has that file, and probably won't give it to you.
But as it seems to be an error in the compiler, you can either contact them / file a bug report, or try to avoid the error by changing your code a bit (which is a guessing game, as you don't know how you made it run into the error). Or use another compiler, if there are choices.

G++ Link-time optimisation on Mac - compiler/linker bug?

I have a project that uses OpenMP (which doesn't seem to be available in the current OS X default clang setup) but would also like to use LTO. I have sections of the code in SIMD intrinsics using SSE4 and found that G++ was unable to link this code without using the OS X provided clang linker (flag -Wa,-q). G++ 5.10 is installed via Homebrew and compiled with without multilib.
I can compile with LTO using clang but then I lose the parallel 'for's, when I add -flto to G++ I get:
lto1: internal compiler error: in add_symbol_to_partition_1, at lto/lto-partition.c:211
lto1: internal compiler error: Abort trap: 6
g++-5: internal compiler error: Abort trap: 6 (program lto1)
Please submit a full bug report,
with preprocessed source if appropriate.
See <https://github.com/Homebrew/homebrew/issues> for instructions.
lto-wrapper: fatal error: g++-5 returned 4 exit status
compilation terminated.
collect2: fatal error: lto-wrapper returned 1 exit status
compilation terminated.
This also occurs without -Wa,-q if I remove the intrinsics so that it can compile the remaining code.
I have tried a simple two file program that compiles fine with LTO in G++ so I'm not sure what the problem is. Whilst LTO doesn't seem to make a huge amount of difference to this code, in clang I've measured about 7% which is non-negligible as the program takes a while to run.
I know the error says to submit a bug report but I don't want to unless I know it's not just my own stupidity.
Does anyone have experience of this sort of problem, or have I actually run into a compiler bug? (haven't come across one before to my knowledge)
Cheers!
Compilers are never supposed to report ICEs. It's a bug. It may already be a reported bug, but it is most certainly a bug.

tao_idl returns with unspecified error when compiling using gcc

Hi I'm quite new to ACE ORB(TAO). My exisiting system compiles fine with xcc compiler in solaris. Now I got to use gcc compiler instead. When I try to compile my source code using gcc, I get the following error
/sbcimp/run/pd/ACE/6.0.7_x86/64Opt/bin/tao_idl: preprocessor "CC" returned with an error
xmake: /sbcimp/run/pd/ACE/6.0.7_x86/64Opt/bin/tao_idl: error 1 (0x1)
Why does tao_idl return this error? All I know is tao_idl compiles idl sources for ACE ORB. This error doesn't provide me any other clue regarding the reason behind this error.. Where can I find further details about this error?
I dont see much help in the net for tao_idl compiling. Can someone shed some light on this
TAO_IDL uses CC as preprocessor, do you have that available in your PATH when invoking TAO_IDL, just try to execute CC directly from the commandline.
In addition to #Johnny Willemsen's answer, I thoguht of adding a bit of more details so that it would be helpful for someone.
TAO_IDL uses an external pre processor.
If the macro TAO_IDL_PREPROCESSOR is defined, then it will use that.
Else if the macro ACE_CC_PREPROCESSOR is defined, then it will use that.
Otherwise, it will use "cc"
The problem that I had was that I was trying to use g++ as the precompiler, without setting any of the above macros. Hence TAO_IDL was always looking for cc.
Solution:
export TAO_IDL_PREPROCESSOR=/rtcigp/run/pd/gcc/32-bit/4.4.1/bin/g++
then include g++ binary into PATH
export PATH="$PATH:/rtcigp/run/pd/gcc/32-bit/4.4.1/bin"
This makes g++ as the preprocessor.

GCC- Invalid use of Register

I am compiling a project under VS2012 and GCC (CodeBlocks) for Windows.
On VS2012 everything works perfect. Under GCC I am obtaining the following compiling error:
C:\Users\Piotrek\AppData\Local\Temp\ccfdl0Ye.s|164|Error: invalid use of register|
C:\Users\Piotrek\AppData\Local\Temp\ccfdl0Ye.s|166|Error: invalid use of register|
C:\Users\Piotrek\AppData\Local\Temp\ccfdl0Ye.s|221|Error: invalid use of register|
||=== Build finished: 3 errors, 14 warnings (0 minutes, 0 seconds) ===|
I am using the compiler option -fpermissive - It should have nothing to do with the error.
I just can't understand why is it pointing to a temporary file under the Local Temp folder, and saying that I am using a wrong register??
Does anybody have any idea on what's happening?
It looks like you've encountered a bug in the compiler. The
error messages (judging from the "source" file name) are from
the assembler. The only time the assembler should generate an
error message is when there is something illegal in the
assembler, and the C++ compiler should never generate illegal
assembler; if it can't generate legal assembler, it should
output an error message and fail.
The real problem, when you get this sort of message, is to
figure out what in your code is triggering it. g++ has an
option which tells it to not delete any of the intermediate
files. Use this, then try and see what is going on in the
assember files at these lines. (When you ask g++ to output
assembler, it puts nice comments in to help finding the
corresponding source. I don't know if it also does this when
generating assembler as an intermediate file.) And then try
cutting code (if worse comes to worse, using binary search)
until you can get the error for a program of one or two lines.
Try to guess what's special about them, and change them to do
the same thing, in a different way.
And don't fail to report the error to g++.
Thanks to James Kanze's recommendation, I decided to tell to the compiler not to delete temporary files. This is done by the flag:
-save-temps
As James said, the assembler generates some nice comments which inform exactly which line on our C++ code is throwing the error. In my case, it looks like it is not accepting such instruction:
asm
(
".intel_syntax noprefix\n"
"lock dec [DWORD PTR eax]\n"
".att_syntax \n"
:
: "a" (data)
:
);
I don't know why he is not accepting Intel Syntax anymore, since it was working with previous GCC version, and now that I updated it it doesn't anymore.
Anyway, the solution for such problems is the one mentioned by James: Just dont delete intermediate files so that you can spy directly into Assembly code what's wrong.
About the problem of the INTEL syntax, any idea why it doesn't work anymore?