I have this c++ code:
#include <iostream>
using namespace std;
int main () {
char chr[] = "111111111111";
int pop = 9999;
cout << chr << (pop+1) << endl;
}
when I do in the shell (64 bit linux) g++ -S hello.cpp I get assembly code :
when I use on it nasm hello.s it says it contains a lot of errors such as:
instruction needed
expression syntax error
symbol `popq' redefined
maybe it is because it is 64bit? how can I compile the .s I created with the g++?
The assembler generated by GCC is using what is known as AT&T syntax, which differs from the Intel-syntax used by nasm. You have to use the GCC assembler (as) to compile GCC generated assembler files.
See e.g. http://en.wikipedia.org/wiki/GNU_Assembler#Criticism.
For more information about the GNU assembler syntax, see http://en.wikibooks.org/wiki/X86_Assembly/GAS_Syntax.
There are several assembler syntaxes for x86. In particular, nasm and gas (the assembler inside binutils) have different syntaxes.
Very often, GCC is configured to emit assembly code using gas syntax. You could find out what GCC is doing with eg g++ -O -v -c yourcode.cc and you can learn how GCC was configured with gcc -v or g++ -v alone.
And you might invoke GCC as g++ -S -fverbose-asm yourcode.cc to get a more readable yourcode.s
Related
Will there ever be a case where C++ code compiles with no errors in Ubuntu 18.04 and not compile in Xubuntu 19.04. My original guess was no but then a professor told me about there being some linker issues that may cause that. Also let me also add that the code is compiled using the same std and using g++.
Will there ever be a case where C++ code compiles with no errors in Ubuntu 18.04 and not compile in Xubuntu 19.04.
Possibly, but it only arises in corner cases. Most C++ code won't be affected.
I think it depends on GCC version. Around that time GCC started enabling PIE by default, and it caused some linking issues. See, for example, Initial SUPERCOP Haswell results for round 2. From the mailing list message:
... The rest of this message explains the -fPIC -fPIE above. On
exactly the same long-term-support version of Ubuntu, with the
supposedly compatible system-provided versions of gcc and clang, if
you run
gcc -c x.c; clang -c y.c; gcc -o x x.o y.o
where x.c says
#include <stdio.h>
extern int thenumber(void);
int main() { printf("%d\n",thenumber()); return 0; }
and y.c says
static int myconstant = 5;
int thenumber(void) { return myconstant; }
then compilation fails, while doing
gcc -c x.c; clang -c y.c; clang -o x x.o y.o
or
gcc -c x.c; gcc -c y.c; gcc -o x x.o y.o
or
clang -c x.c; clang -c y.c; clang -o x x.o y.o
works fine. The underlying problem is compiler-writer mismanagement of
an ongoing transition to
-fPIC: compiling libraries as "position-independent code" (this is typically advertised as being important for shared libraries);
-fPIE: compiling main() etc. as position-independent code (this is typically advertised as being important for the claimed security
benefits of address-space layout randomization); and
-pie: linking position-independent executables.
Code that's compiled as position-independent code can be linked into
position-dependent executables or position-independent executables. A
correctly managed transition would have consisted of
turning on -fPIC and -fPIE by default,
issuing automatic warnings for any position-dependent code,
waiting a specified number of years for people to get rid of any previously compiled position-dependent code, and finally
turning on -pie by default.
What happened instead was gcc suddenly turning on -pie, clumsily
breaking all existing position-dependent code and even managing to
break compatibility with clang on the same system---clang still
produces position-dependent code, and then gcc fails to produce an
executable. This is also why gcc now breaks
crypto_kem/ntruhrss701/avx2.
I'm taking part in a programming contest and the requirement is that code will be compiled using following command:
g++ -std=c++11 -O2 -o a.out orienteering.cpp
How do I check if my code works for this command? (I use DevC++ for coding and it has automatic compilation).
Also compiler should be GCC 4.8.2 or later. What does this mean? Is my older GCC version (4.7.2) not suitable?
You check your code by placing it in a file named orienteering.cpp, and running this command in the same directory:
g++ -std=c++11 -O2 -o a.out orienteering.cpp
If the compiler spits out any messages at all then you have a problem. If the compiler is silent and creates a file named a.out, then all is well.
GCC 4.7.2 does not meet the criteria "GCC 4.8.2 or later".
Summary: llvm-ld has been removed from the LLVM 3.2 release. I am trying to figure out how to use clang in its place in my build system.
Note that I figured out the answer to my own question while writing it but I am still posting it in case it is useful to anyone else. Alternative answers are also welcome.
Details:
I have a build process which first generates bitcode using clang++ -emit-llvm. Then I take the bitcode files and link them together with llvm-link. Then I apply some standard optimization passes with opt. Then I apply another custom compiler pass with opt. Then I apply the standard optimization passes again using opt a third time. Finally I take the output from the last run of opt and use llvm-link to link with appropriate libraries to generate my executable. When I tried to replace llvm-link with clang++ in this process I get the error message: file not recognized: File format not recognized
To make this question more concrete I created a simplified example of what I am trying to do. First there are two files that I want to compile and link together
test1.cpp:
#include <stdio.h>
int getNum();
int main()
{
int value = getNum();
printf("value is %d\n", value);
return 0;
}
test2.cpp
int getNum()
{
return 5;
}
I executed the following sequence of commands:
clang++ -emit-llvm -c test1.cpp test2.cpp
llvm-link -o test.bc1 test1.o test2.o
opt test.bc1 -o test.bc2 -std-compile-opts
(Note that I am currently running llvm 3.1, but I'm trying to figure out the steps that will work for llvm 3.2. I assume that I should be able to make the LLVM 3.1 version work correctly using clang instead of llvm-ld)
Then if I run:
llvm-ld test.bc2 -o a.out -native
everything is fine and a.out prints out 5.
However, if I run:
clang++ test.bc2 -o a.out
Then I get the error message:
test.bc2: file not recognized: File format not recognized clang-3:
error: linker command failed with exit code 1 (use -v to see invocation)
Obviously I know that I can produce an executable file by running clang directly on the .cpp files. But I'm wondering what the best way to integrate clang with opt is.
The test case described in the question can be compiled using the following steps:
clang++ -emit-llvm -c test1.cpp test2.cpp
llvm-link -o test.bc1 test1.o test2.o
opt test.bc1 -o test.bc2 -std-compile-opts
llc -filetype=obj test.bc2 -o test.o
clang++ test.o
This produces a working a.out file.
It seems that llc is needed to convert from bitcode to machine code which can then be processed by clang as it normally would.
In general I've found that
llvm-ld x.bc y.bc
can be replaced with
llc x.bc
llc y.bc
clang x.s y.s
I have installed Clang by using apt-get in Ubuntu, and I can successfully compile C files using it. However, I have no idea how to compile C++ through it. What do I need to do to compile C++?
The command clang is for C, and the command clang++ is for C++.
I do not know why there is no answer directly addressing the problem. When you want to compile C++ program, it is best to use clang++, instead of using clang. For example, the following works for me:
clang++ -Wall -std=c++11 test.cc -o test
If compiled correctly, it will produce the executable file test, and you can run the file by using ./test.
Or you can just use clang++ test.cc to compile the program. It will produce a default executable file named a.out. Use ./a.out to run the file.
The whole process is a lot like g++ if you are familiar with g++. See this
post to check which warnings are included with -Wall option. This
page shows a list of diagnostic flags supported by Clang.
A note on using clang -x c++: Kim Gräsman says that you can also use
clang -x c++ to compile CPP programs, but that may not be always viable. For example, I am having a simple program below:
#include <iostream>
#include <vector>
int main() {
/* std::vector<int> v = {1, 2, 3, 4, 5}; */
std::vector<int> v(10, 5);
int sum = 0;
for (int i = 0; i < v.size(); i++){
sum += v[i]*2;
}
std::cout << "sum is " << sum << std::endl;
return 0;
}
clang++ test.cc -o test will compile successfully, but clang -x c++ will
not, showing a lot of undefined reference errors. So I guess they are not exactly equivalent. It is best to use clang++ instead of clang -x c++ when compiling c++ programs to avoid extra troubles.
clang version: 11.0.0
Platform: Ubuntu 16.04
Also, for posterity -- Clang (like GCC) accepts the -x switch to set the language of the input files, for example,
$ clang -x c++ some_random_file.txt
This mailing list thread explains the difference between clang and clang++ well: Difference between clang and clang++
Solution 1:
clang++ your.cpp
Solution 2:
clang your.cpp -lstdc++
Solution 3:
clang -x c++ your.cpp
I've had a similar problem when building Clang from source (but not with sudo apt-get install. This might depend on the version of Ubuntu which you're running).
It might be worth checking if clang++ can find the correct locations of your C++ libraries:
Compare the results of g++ -v <filename.cpp> and clang++ -v <filename.cpp>, under "#include < ... > search starts here:".
Open a Terminal window and navigate to your project directory. Run these sets of commands, depending on which compiler you have installed:
To compile multiple C++ files using clang++:
$ clang++ *.cpp
$ ./a.out
To compile multiple C++ files using g++:
$ g++ -c *.cpp
$ g++ -o temp.exe *.o
$ ./temp.exe
I'm trying to compile and strip a very simple programm in C++ with the g++ compiler (4.6.0 on Mac OSX). But while compiling i get an warning.
source code:
#include </usr/local/Cellar/gcc/4.6.0/gcc/include/c++/4.6.0/iostream>
int main(){
std::cout << ("Hello World\n") ;
}
Terminal code:
g++ hello.cc -Wall -std=c++0x -s
/* or an alternative: */
g++ hello.cc -Wall -std=c++0x -o test -Wl,-s
Compiler warning:
ld: warning: option -s is obsolete and being ignored
Somebody any idea's about this weird warning?
Edit:
The weird thing is the size does decrease when using the -s flag, the decreases from 9,216 bytes to 9,008.
However when i use the following the size decreases to 8,896 bytes.
cp hello hello_stripped
strip hello_stripped
The error message is from ld, not from gcc or g++. (The gcc and g++ commands are a drivers that invokes the compiler, the linker, and other tools.)
gcc passes the -s option to the linker, as documented in the gcc 4.6.1 manual; apparently the MacOS port of gcc still does that.
The GNU linker (GNU ld) still accepts the -s option with its usual meaning. But the MacOS linker (also called ld) ignores it, as documented in the MacOS ld manual:
-s Completely strip the output, including removing the symbol table.
This file format variant is no longer supported. This option is
obsolete.
And the MacOS gcc manual, unlike GNU's gcc manual, doesn't mention "-s".
Apparently the -s flag is obsolete. You can use the strip program instead though.