The product-group I work for is currently using gcc 3.4.6 (we know it is ancient) for a large low-level c-code base, and want to upgrade to a later version. We have seen performance benefits testing different versions of gcc 4.x on all hardware platforms we tested it on. We are however very scared of c-compiler bugs (for a good reason historically), and wonder if anyone has insight to which version we should upgrade to.
Are people using 4.3.2 for large code-bases and feel that it works fine?
The best quality control for gcc is the linux kernel. GCC is the compiler of choice for basically all major open source C/C++ programs. A released GCC, especially one like 4.3.X, which is in major linux distros, should be pretty good.
GCC 4.3 also has better support for optimizations on newer cpus.
When I migrated a project from GCC 3 to GCC 4 I ran several tests to ensure that behavior was the same before and after. Can you just run a run a set of (hopefully automated) tests to confirm the correct behavior? After all, you want the "correct" behavior, not necessarily the GCC 3 behavior.
I don't have a specific version for you, but why not have a 4.X and 3.4.6 installed? Then you could try and keep the code compiling on both versions, and if you run across a show-stopping bug in 4, you have an exit policy.
Use the latest one, but hunt down and understand each and every warning -Wall gives. For extra fun, there are more warning flags to frob. You do have an extensive suite of regression (and other) tests, run them all and check them.
GCC (particularly C++, but also C) has changed quite a bit. It does much better code analysis and optimization, and does handle code that turns out to invoke undefined bahaviiour differently. So code that "worked fine" but really did rely on some particular interpretation of invalid constructions will probably break. Hopefully making the compiler emit a warning or error, but no guarantee of such luck.
If you are interested in OpenMP then you will need to move to gcc 4.2 or greater. We are using 4.2.2 on a code base of around 5M lines and are not having any problems with it.
I can't say anything about 4.3.2, but my laptop is a Gentoo Linux system built with GCC 4.3.{0,1} (depending on when each package was built), and I haven't seen any problems. This is mostly just standard desktop use, though. If you have any weird code, your mileage may vary.
Related
My professor is using automated scoring program for my programming assignment. It is C programming handling some file stuff.
He asks students to use Ubuntu version 18.xx and gcc 7.xx. and I asked him if I can use the later version of those, which are 20.xx, 9.xx respectively. and he's not so sure about it with saying that might not be the problem but just in case use the exact version.
I don't want to delete the current Ubuntu, gcc and re-downloaded the exact version he mentioned, because it might take some time and I have to keep using this laptop for many more assignments from other classes. I want to use the later version (seems like quite a big gap between 18.xx, 7.xx and 20.xx, 9.xx)!
Are there any potential problems for using my current version?
It would also be possible to check the default standard of the gcc version used by your teacher and use the corresponding std flag : "-std=c11" for example.
(I'm unfortunately in a rush and can't check it yet but when I have more time, I can try to look it up if you still didn't get the information)
It may also be possible that he already uses a specific standard, in that case it's better to ask him.
Bugs might arise but I think it would be pretty negligible if you use the same standard.
Otherwise if you are using a Debian based distro you can also install his gcc version alongside your actual one and use them with "update-alternatives".
If not you can use a Docker container.
Something to look for is also if you are going to use OS specific library or functions : For example Windows is not POSIX compliant so I had to use WSL but linux (and mac aswell if I remember correctly) are.
I heard that GCC actually assumes registers, and requires CPU to have them to work.
What work should be done to remove this dependency, and port GCC to some register-less non-Von Neuman arch, like Multiclet?
Did somebody tried this? Is there some project and experience one can use if wants to work on this ?
If not, is there some other FOSS compiler that can be ported to something like Multiclet. LLVM has pretty much the same requirements like GCC, and it is unsuitable for me since I don't know C++. So it needs to be plain C. I hear that GCC is also adding C++ code now. But I can use some older version as starting point.
Multiclet's C99 compiler is not closed source. Sources are available at their community suite. One may google it by name 'multiclet mcc lime'.
I've downloaded a Linux C SDK that comes with a bunch of static and dynamic libraries. The Readme has this to say:
This SDK was compiled with the gcc version 4.5.1 .
You SHOULD NOT mix this SDK binaries with other gcc versions, because
your application will end up in loading two different libcs, which
results in two different heaps. Mixing heaps will lead to application
crashes, when trying to free memory that was allocated by another
heap.
I've never heard of anything like this and a search on the web hasn't turned up any confirmation for it. What I did find, was something about the ABI, but as I understand it, this just means, that the libraries might be incompatible to my GCC version in the sense that they don't run at all. This has nothing to do with libc versions or the heap.
So, is it true what the Readme says? Or, in more general terms: Should I never try to use libraries I downloaded off the internet with another GCC version than the one they were compiled with?
What if I want to use several libraries that were compiled with different GCC versions?
Thanks everyone,
Moritz
It might be due to the optimisations used to build the SDK. Highly optimised binary has more chances of crashing if mixed.
The built in atomic operations were introduced in gcc-4.1.2. However, I am using gcc on OpenIndiana which only has gcc 3.4.3. Now my question is how to use atomic operations in gcc 3.4.3? Moreover I have tried to use gcc 4.6.1 in OpenIndiana but it doesnt work, as it complains about some runtime libraries. If anyone has successfully used it, kindly let me know.
I would suggest you to upgrade your GCC compiler. A GCC 3 is an ancient thing.
If you cannot install a newer version of GCC, you should try compiling a GCC 4.6.1 compiler from its source code. (don't forget to compile it in a build tree outside of the source tree, and don't forget all the dependencies).
You did not mention or explained why your compilation of GCC 4.6.1 failed. What runtime libraries did it complain about? Did you run ldconfig after installing it?
GCC has great inline assembly support, so you could just use __asm to make your own variant of the various atomic ops. It'll be specific to your target platform however, so you'll need some good macros to switch to the right versions.
To add to existing answers - have you looked at Spec Files Extra Repository? I never used it myself but it seems like it offers gcc 4.6 compiler package.
On Solaris, the alternative could be to fall back to libc atomic_ops(3C) interfaces. These might or might not get inlined, but they're guaranteed always available (and always behave in the same way) no matter which compiler you use.
Beyond that, I second the suggestion to either upgrade your gcc, and/or to get the SunStudio 12.2 compilers (they're royalty-free; even if you only use it for testing, code quality tends to go up if it's made to work with more than one compiler ...). Yes, it'll install/run on OpenSolaris-based distributions as well.
Hey everybody, i am deploying my code from a cluster running on ubuntu onto a cluster with identical hardware, but with red hat and as it seems older gfortran compiler. The source is actually compiled by ifort, but since it is not installed on the red had cluster, i may have to switch to gfortran.
Now the problem is that the code does not compile. There is this thing with "allocatable" inside a type that i could fix in my portion of the code, but there are also other contributions by other people not as ready to adapt their code to the older standard.
My question :
How do i deploy nonetheless onto the other system, hopefully without changing much?
What other surprised wait for me when using the compile from the same version, just different subversion?
How do i enforce that something like this does not happen again? The code should be deployable onto a variety of systems without resorting to violence.
Thanks for your advice and cheers
gfortran started with version 4.0. Versions 4.1 and 4.2 are old and missing many features and may have bugs. You may run into additional missing features that are used by your code. I suggest, if at all possible, getting the compiler upgraded to the current stable version, which is 4.5.
Supporting all versions of gfortran will lead to many restrictions on your code. It might be better to identify the earliest version that works and add that information to the documentation. For my code, that version is 4.3 since I make extensive use of the ISO C Binding.
The gfortran wiki, http://gcc.gnu.org/wiki/GFortran, has a changelog by version that might help you identify which version you need. The only sure way is to test.
If you want to enforce a version requirement, you can test from within Fortran. You could run a small test program as part of the make process and abort if the gfortran version is too early.
The following code fragment shows two ways of outputting the gfortran version number from a Fortran program. Name the program with filetype ".F90" so that gfortran will invoke the preprocessor.
#ifdef __GFORTRAN__
write (*, '( "gfortran" )' )
write (*, '( I0, ".", I0 )' ) __GNUC__, __GNUC_MINOR__
! Merged version number:
#define GCC_VERSION (__GNUC__ * 10000 + __GNUC_MINOR__ * 100 + __GNUC_PATCHLEVEL__)
write (*, '( I0 )' ) GCC_VERSION
#endif
I think you have 3 choices:
Cross-compilation: ie compile on
your development machine for
execution on your deployment
machine; I don't know if this is
possible with your setup but it is
worth investigating if you haven't
already done so.
Program to the set of Fortran features implemented in all your compilers -- which would mean re-writing the code to take out whatever features 4.2.3 implements that 4.1.2 doesn't.
Upgrade the compiler on your deployment machine to match the one on your development machine.
Of these I think that (1) might be difficult; if it is then I'd go for (3). If that is not possible, then it has to be (2) -- I don't see any other options.
Now to answer your questions:
Answered above.
Not sure, but the release notes for Gfortran should tell you what Fortran language features 4.2.3 implements which 4.1.2 doesn't.
Only program with the version of Fortran for which you can compile on your target platforms.