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?
Related
I am attempting to compile a C++ library for a Tegra TK1. The library links to TBB, which I pulled using the package manager. During compilation I got the following error
/tmp/cc4iLbKz.s: Assembler messages:
/tmp/cc4iLbKz.s:9541: Error: thumb conditional instruction should be in IT block -- `strexeq r2,r3,[r4]'
A bit of googling and this question led me to try adding -mimplicit-it=thumb to CMAKE_CXX_FLAGS, but the compiler doesn't recognize it.
I am compiling on the tegra with kernal 3.10.40-grinch-21.3.4, and using gcc 4.8.4 compiler (thats what comes back when I type c++ -v)
I'm not sure what the initial error message means, though I think it has something to do with the TBB linked library rather than the source I'm compiling. The problem with the fix is also mysterious. Can anyone shed some light on this?
-mimplicit-it is an option to the assembler, not to the compiler. Thus, in the absence of specific assembler flags in your makefile (which you probably don't have, given that you don't appear to be using a separate assembler step), you'll need to use the -Wa option to the compiler to pass it through, i.e. -Wa,-mimplicit-it=thumb.
The source of the issue is almost certainly some inline assembly - possibly from a static inline in a header file if you're really only linking pre-built libraries - which contains conditionally-executed instructions (I'm going to guess its something like a cmpxchg implementation). Since your toolchain could well be configured to compile to the Thumb instruction set - which requires a preceding it (If-Then) instruction to set up conditional instructions - by default, another alternative might be to just compile with -marm (and/or remove -mthumb if appropriate) and sidestep the issue by not using Thumb at all.
Adding compiler option:
-wa
should solve the problem.
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.
It's a simple question really, and refers to Linux (as opposed to Windows or Mac).
How do you generate a warning message from the C or C++ compiler that must have the word 'suspicious' in it, and must refer to (-Wmain).
(update)
Thanks Boann - I got some of those Warnings, but I also got Error - error: ‘::main’ must return ‘int’.
The reason I'm asking this question is that a week ago my compiler (GCC 4.8.1) came out with this warning saying 'suspicious' and that it was caused by Wmain. So I put -Wno-main and the warning went away and it compiled fine. Just recently it has started complaining making it an actual Error and not compiling. So I'm kind of worried that somehow the mother ship has covertly updated my compiler over the internet, without me knowing, and changed it to treat it as error. (I was probably using 'int4' as the return type which I forever have typedef'd as signed long int.
I note there's -Wmain referenced in g++ man page so it must be for something, but what warning is there that isn't overruled by an error??
At offset 557284 (decimal) of the g++ executable I found "Warn about suspicious declarations of "main".
For what it's worth,
struct suspicious {};
int main(suspicious) {}
Output with g++ -Wall, GCC 4.8.2:
warning: first argument of 'int main(suspicious)' should be 'int' [-Wmain]
If you refer to the -Wmain parameter of GCC, you get the warning by giving main odd arguments, an odd return type, or giving it static linkage. This will do it:
static float main(float x) {
return 0;
}
Compiled with gcc -Wmain, it displays these warnings; they do not actually contain the word 'suspicious' though:
warning: return type of 'main' is not 'int'
warning: first argument of 'main' should be 'int'
warning: 'main' takes only zero or two arguments
warning: 'main' is normally a non-static function
I just downloaded the sources for gcc 4.8.1 and searched all relevant files for the word "suspicious".
There are a number of occurrences, but as far as I can tell, there's no way an error message for a C or C++ source file can contain the word "suspicious". It's possible but unlikely that there was a local modification.
Is it possible that you're mistaken about what the error message said? If you have a log containing the error message, please update your question to show the exact message your received.
If you're concerned that your compiler may have been updated without your knowledge, you might check the timestamp of the compiler executable and of any programs it invokes (use gcc -v to check that). But gcc itself doesn't automatically update itself. If you're using it on a system administered by someone else, automatic updates are to be expected. If you administer the system yourself, you may have configured it to update software without manual intervention; if so, that's not a gcc issue. I don't know what "mother ship" you're referring to.
I can get rid of the warnings in the build log by adding -std=c++0x to "other c++ flags", but they still show up in the side pane. I'm guessing that the other flags are not being passed to clang or whatever is responsible for parsing code for the gui...
Any ideas?
Update:
The warnings have mostly disappeared, but I'm not sure why. And every time I think they're gone, I get a few again. I suspect that forcing a build of every project in the workspace has some effect, but I'm really at a loss.
In any case, modifying "other c++ flags" does seem to affect the GUI warnings, contrary to my assumption when I asked this question. But it takes time. Ahh, Xcode.
Use a pragma instead of a command line switch, as described in the answer to "Is there a way to suppress warnings in Xcode?"
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.