4 ms·

Am I the only one unable to keep pace with compiler development? For some code on x86/64 I'm still using gcc 4.7, and a cursory test with gcc 5 (or even gcc 4.9

Am I the only one unable to keep pace with compiler development? For some code on x86/64 I'm still using gcc 4.7, and a cursory test with gcc 5 (or even gcc 4.9) resulted in compile-time errors I hadn't time to look into. Maybe it's just a compiler or linker flag, which tbh is something that's gone out of control. Given the intimacy gcc has with glibc and the Linux kernel, in turn, what are folks using for a stable build environment that just doesn't need to change all the time because the software does what it's supposed to do, and doesn't need, nor benefits from high-energy agility? I know there are occasionally new targets and optimizations, but wasn't C a language supposed to be easy for writing a compiler for in a couple months? Well ok the same could said about a Unix kernel I guess. I mean I appreciate the gcc project for providing backports, but the new gcc versioning scheme makes release numbering kindof arbitrary, and can be interpreted to give a finger to older software especially in C-land.

klodolph 7y ago
Do you use -Werror? Upgrades generally produce new warnings but (usually) no new errors. I use -Werror and I have to make some changes every major compiler version across my code bases, but if I just need to compile something, I'll turn -Werror off.
wahern 7y ago
Without seeing the errors it's difficult to say. GCC 4.7 is really old (2012), and there are only a few areas I can think of off the top of my head that might trigger such problems, mostly related to C11 support and buggy feature detection or erroneous usages by older code, such as static_assert definitions or tests, possibly directly or indirectly related to older glibc headers. Interestingly, most of the C-related changes from 4.7 to 4.9 are related to C11. GCC has been less aggressive compared to clang in adding diagnostics to -Wall that trigger on correct code; -Wno-missing-field-initializers and -Wno-override-init come to mind, but those predate 4.7. -Wexpansion-to-defined is super annoying, but that came much later (GCC 8?), and strictly speaking it triggers on undefined behavior--it's just that the undefined behavior was extremely convenient, pre-dated GCC, reliably supported (at least for the most common and possibly only usages) on almost all if not all major compilers, and is the only possible approach for writing lazy feature detection macros that can be defined in library headers without include'ing possibly unused headers, polluting the namespace.
FrozenVoid 7y ago
Are you using gcc 5.5? This is the oldest version on my machine.
nwallin 7y ago
Not to be trite, but I doubt particularly many people have trouble with this. GCC 4.7 is a very long time to have gone without updates. Note that GCC 5 switched from c99 by default to c11 by default. This isn't "just" a compiler flag, and it's not a GCC problem either, you'll have the same problem in clang or ICC. Try upgrading and compiling with -std=c99. (or -std=gnu99 if that's your thing) You might find that gcc-9 works if you feed it the right standard of C. Compiler updates occasionally remove certain definitions from headers that aren't supposed to contain those definitions. For instance, lots of headers contain the definition for size_t, but only stddef.h is required to. Occasionally an update will hit that removes it from I dunno, rand.h or whatever. This is a good thing; headers shouldn't contain a bunch of extra crap in then. In those cases, it's because your code was always broken, not that the compiler upgrade broke it. Blaming the compiler in that case is like blaming QA. Which, to be fair, it was QA's fault.
tannhaeuser 7y ago
Appreciate the answers and tips (though I checked some of your suggestions already). In our case, it's third-party software partially generating C code with less-than-ideal test coverage and it's a huge time sink to fix. It's been a while, but as I recall, gcc 4.9 would compile ok, only the generated executable would crash, and would also generate double-frees with glibc and stuff (with one-shot command-line programs not app servers, so this isn't as scary as it sounds). This after heavy modifications on my part to get it even running. Note our own code, OTOH, has almost 100% coverage, and I'm considering replacing the old third-party libs/tools for the next release. However, this is a huge time sink when the code works just fine otherwise, and in any case needs to be maintained, so I'm looking for a canned gcc installation (maybe a Docker image or self-compiled gcc chain which I used to use a couple years ago, but stopped bootstrapping on eg newer Ubuntu hosts by now). As build servers so far, I'm using older distros (CentOS 6, Debian 8.6) with native gcc 4.7 or gcc 4.7 packages on newer distros with success, and also an old Mac OS box with gcc 4.7 installed from MacPorts at a time when it wasn't yet broken. My intent wasn't to criticize gcc, but I think 7 years is not that long of a life-time for non-trivial software.

klodolph 7y ago

Do you use -Werror? Upgrades generally produce new warnings but (usually) no new errors. I use -Werror and I have to make some changes every major compiler version across my code bases, but if I just need to compile something, I'll turn -Werror off.

wahern 7y ago

Without seeing the errors it's difficult to say. GCC 4.7 is really old (2012), and there are only a few areas I can think of off the top of my head that might trigger such problems, mostly related to C11 support and buggy feature detection or erroneous usages by older code, such as static_assert definitions or tests, possibly directly or indirectly related to older glibc headers. Interestingly, most of the C-related changes from 4.7 to 4.9 are related to C11. GCC has been less aggressive compared to clang in adding diagnostics to -Wall that trigger on correct code; -Wno-missing-field-initializers and -Wno-override-init come to mind, but those predate 4.7. -Wexpansion-to-defined is super annoying, but that came much later (GCC 8?), and strictly speaking it triggers on undefined behavior--it's just that the undefined behavior was extremely convenient, pre-dated GCC, reliably supported (at least for the most common and possibly only usages) on almost all if not all major compilers, and is the only possible approach for writing lazy feature detection macros that can be defined in library headers without include'ing possibly unused headers, polluting the namespace.

FrozenVoid 7y ago

Are you using gcc 5.5? This is the oldest version on my machine.

nwallin 7y ago

Not to be trite, but I doubt particularly many people have trouble with this. GCC 4.7 is a very long time to have gone without updates. Note that GCC 5 switched from c99 by default to c11 by default. This isn't "just" a compiler flag, and it's not a GCC problem either, you'll have the same problem in clang or ICC. Try upgrading and compiling with -std=c99. (or -std=gnu99 if that's your thing) You might find that gcc-9 works if you feed it the right standard of C. Compiler updates occasionally remove certain definitions from headers that aren't supposed to contain those definitions. For instance, lots of headers contain the definition for size_t, but only stddef.h is required to. Occasionally an update will hit that removes it from I dunno, rand.h or whatever. This is a good thing; headers shouldn't contain a bunch of extra crap in then. In those cases, it's because your code was always broken, not that the compiler upgrade broke it. Blaming the compiler in that case is like blaming QA. Which, to be fair, it was QA's fault.

tannhaeuser 7y ago

Appreciate the answers and tips (though I checked some of your suggestions already). In our case, it's third-party software partially generating C code with less-than-ideal test coverage and it's a huge time sink to fix. It's been a while, but as I recall, gcc 4.9 would compile ok, only the generated executable would crash, and would also generate double-frees with glibc and stuff (with one-shot command-line programs not app servers, so this isn't as scary as it sounds). This after heavy modifications on my part to get it even running. Note our own code, OTOH, has almost 100% coverage, and I'm considering replacing the old third-party libs/tools for the next release. However, this is a huge time sink when the code works just fine otherwise, and in any case needs to be maintained, so I'm looking for a canned gcc installation (maybe a Docker image or self-compiled gcc chain which I used to use a couple years ago, but stopped bootstrapping on eg newer Ubuntu hosts by now). As build servers so far, I'm using older distros (CentOS 6, Debian 8.6) with native gcc 4.7 or gcc 4.7 packages on newer distros with success, and also an old Mac OS box with gcc 4.7 installed from MacPorts at a time when it wasn't yet broken. My intent wasn't to criticize gcc, but I think 7 years is not that long of a life-time for non-trivial software.