GCC
(GNU-cc) is the most flexible, most powerful and most portable C
,C++, FORTRAN and Java compiler. Together with its
libraries, it constitutes the ideal platform to write bugfree (bugsparse ?)
and fast code which is still portable to almost all computer platforms,
from handhelds to supercomputers. GCC runs under the GNU license which, in
practical terms, means that it is free.
GCC is a pseudo-user. So you can look around in its home directory ~gcc. GCC and all related goodies are automatically accessible if your path includes /freeware/bin.
Unless absolutely necessary, always use the latest version. You can select old versions by using the
-V flag. Old versions are kept
online typically two months after the release of a minor update, and six
months after a major updated. If you need ancient versions or versions for
no longer supported architectures, you can ask me, as I keep some on CD's.
On each platform, the compiler is build for the oldest version of the
operating system still in use at ESAT, and for the oldest processor type
running that operating system. This means:
| Platform | Operating System | Processor type | |
|---|---|---|---|
| alpha | Tru64 5.1 | EV4, 21064 | |
| mips | Ultrix 4.4 | MIPS R3000 | |
| hppa | HP-UX 11.00 | HPPA 1.2 | |
| sol2 | Sol 2.8 | v7, Cypress IPC | |
| sgi | IRIX 6.5.22 | MIPS R10000, N32 | |
| linux-i386 | Fedora Core 3 | Pentium 3 | |
| linux-x86_64 | Fedora Core 3 | Opteron |
You have to make sure that both /freeware/bin/gnu-tools and /freeware/bin are in your path. That should do it. This will assure that the correct version of the compiler is run, and that the appropriate low-level libraries are found. It is your job though, to make sure that the compiler finds your own include files and/or libraries. An example of a ksh-script for compiling code on any platform can be found in ~deknuydt/compile.
GCC has a real panoply of options and flags, that it is easy to get confused. In general, I'd advise the following:
| Warning options: | |
|---|---|
| -Wall | Switches on all but a few warnings. Strongly recommended |
| -Wpointer-arith | Switches on dubious pointer manipulations. Recommended, especially for porting from 32 bit to 64 bit platforms. |
| -Weffc++ | C++ only. Emit warnings for syntactically correct, but inefficient constructs. |
| Optimization options: | |
| -O3 | Switch an average mix of high optimization flags, including function inlining |
| -s | Strip all unneeded symbols from an executable (or shared library). Improves startup time and reduces executable size but prevents all debugging. |
| -fomit-frame-pointer | Remove the stack frame pointer in leaf procedures. May prevent debugging. |
| -ffast-math | Make a few plausible mathematical assumptions, like sqrt(x) being non-negative. May violate IEEE floating point rules. Usually safe to use. |
| -funroll-loops and -funroll-all-loops | Forcefully unroll loops, especially useful for image processing code. |
| -fnonnull-objects | C++ only. Assume all object references not to be NULL. |
| -felide-constructors | C++ only. Eliminate superfluous constructor/copy combinations. |
| Debug options: | |
| -O0 | Switch off all optimization. Recommended, but not needed, for debugging. |
| -g | Include debugging information (in native format) in the executable. |
| -g3 -gstabs++ | Include the maximum of debugging information gdb can handle. |
| Funny options: | (really existing) |
| -Wsurprising | Fortran only. Warn about "suspicious" constructs that are interpreted by the compiler in a way that might well be surprising to someone reading the code. |
| -fugly-assumed | Fortran only. Assume any dummy array with a final dimension specified as `1' is really an assumed-size array, as if `*' had been specified for the final dimension instead of `1'. |
| -fonetrip | Fortran only. Executable iterative DO loops are to be executed at least once each time they are reached. |
| -fpermissive | Be sloppy. |
GCC and related goodies are documented extensively (hundreds of pages) in the online info files, located in /freeware/info. If you use the Emacs editor (strongly recommended), then you should be able to access them by simply pressing the 'Help' key. Otherwise, invoke info, a simple info-file reader
There is also a WWW-version of all other documentation
Try this. It compiles Luci and Tcl (C), Luci+ and VTK (C++) programs, on all supported platforms.
If you don't speak C, you can start with Introduction to C Programming. The text, illustrated with examples, presupposes knowledge of another procedural computer language like Pascal or FORTRAN.
If you already speak (some) C, you can try the Understanding C++: An Accelerated Introduction course, which is rather good, but presupposes you are really fluent in C.
For Java, I can recommend An Introduction to Java
Take a careful
and critical look at your code, and compile it with the -Wall
option, and don't ignore even the smallest warning. Gcc only emits warnings
for dubious and/or unportable things.
Read the
relevant Info pages with your Emacs editor.
Read the
relevant FAQ
Take a look
at the gnu.gcc.bug,
gnu.g++.bug, gnu.g++.lib.bug,
gnu.gcc.help, gnu.g++.help news groups.
If you are
subscribed, then you can pose your problem to the EGCC
mailing list. Please try to keep your message as short as possible
and as clear as possible at the same time.
Send mail,
describing the problem in short, to the local gcc manager deknuydt@esat.kuleuven.be.
If you want full IEEE floating point conformance (like NaN's), you should add -mieee to your compile line. This slows down normal floating point calculations.
If you want to generate executables or libraries, which run on all HP's at esat, you should stick to the 1.1 processor architecture. This is the configured default.
Use the GNU version of the archiver ar, the assembler as and the stripper strip. There are all in /freeware/bin/gnu-tools Don't use the GNU loader for making shared archives though.
If you want to generate executables or libraries, which run on all SGI's at esat, you should stick to the N32 abi, the mips4 isa, and the R10000 processor. This is the configured default.
Gcc requires the use of the GNU version of both as and ld; the only supported version resides at /freeware/bin/gnu-tools.
The -s stripping flag is sometimes ignored. If need be, you can strip by hand.
Warnings of the native loader on missing sectons (sic!), are harmless. Anyhow, you are supposed to use the GNU loader.
Make sure you do not use the local, RPM installed version of gcc. This can lead to versioning problems, as you depend on local libraries, which might have other versions, or even not be available at all, on other Linux machines.
For general information on shared libraries and system specific details, take a look at a detailed this description
You should subscribe to the ESAT gcc mailing list, by sending a mail with a single line sub EGCC <your real name> to the list server. This list is the forum to ask (cite specific) questions, make suggestions and remain informed on changes and upcoming changes to the local versions of GCC.
GCC is currently maintained by B. DeKnuydt.
It's a drop-in library, replacing
malloc(), calloc(), free() etc. with debugging versions. The
debugging output can provide you with more specific information than the
laconic Segmentation fault, as it (almost always), knows where
and when you access uninitialized memory, use freed data, exceed the amount
of memory you allocated etc.
Dmalloc is documented in the online info files, located in /freeware/info. If you use the Emacs editor (strongly recommended), then you should be able to access them by simply pressing the 'Help' key. Otherwise, invoke info, a simple info file reader.
You can also take a look at the Dmalloc home page.
Debug malloc was written by Gray Watson. It is maintained at ESAT by B. DeKnuydt.