GCC 7 Release Series – Changes, New Features, and Fixes
1–10 of 87 posts
Re: GCC 7 Release Series – Changes, New Features, and Fixes
#2If you compare (gcc7 and latest clang), how much in pair is gcc with clang in terms of compilation warnings? (One of the most valuable tool of a compiler). I'm really happy they are moving in the same direction; I've been worried about gcc.
Re: GCC 7 Release Series – Changes, New Features, and Fixes
#3If you compare (gcc7 and latest clang), how much in pair is gcc with clang in terms of compilation warnings? (One of the most valuable tool of a compiler). I'm really happy they are moving in the same direction; I've been worried about gcc.
For gcc-4.3 this was a no contest, clang was clearly better. However, gcc has made up a lot of ground over the years, to the point that I now consider gcc's template based error messaes better. It is very difficult to keep personal judgement and tastes out of the equation so ymmv.
If the error message of one is not very illuminating I often try the other compiler on the same piece of code. It is a good practice anyway and I should be doing more of that.
One claim that everyone will stand by is that the competition between the two has been a huge help.
Re: GCC 7 Release Series – Changes, New Features, and Fixes
#4On mainstream native platforms, Ada programs no longer require the stack to be made executable in order to run properly.
What does that even mean? I'm dabbling with Ada as of recently.
Also, woo!
Support for the RISC-V instruction set has been added.
On topic, I'm using GCC5 and 6 as well as experimenting with 7, and I also have Clang - all available to me via switch/simple shell functions. I always tend to have my junk work on all of those, so am in a kind of a simplistic position to compare each. From a daily user perspective, there's not much difference at all (clang and newer gcc). Clang's pretty warnings are almost in GCC now as well, speed is still on GCC's side (for me at least) and all is good in GCC and LLVM land. I'm leaning more towards GCC since I've been using it since it became united in late 90s. I believed in it, even though people thought of it, at the time, to be slow and shit. Look at it now! I'm using it on MacOS (yes), Windows and Linux. I'm sure more heavyweight users will find a lot of things GCC can improve upon though.
I know it might not be strictly in the scope of GCC's domain, but I would like to see some static analysis and linters (like MISRA, etc.) included out of the box with it. That would be swell.
Re: GCC 7 Release Series – Changes, New Features, and Fixes
#5On mainstream native platforms, Ada programs no longer require the stack to be made executable in order to run properly. What does that even mean? I'm dabbling with Ada as of recently. Also, woo! Support for the RISC-V instruction set has been added. On topic, I'm using GCC5 and 6 as well as experimenting with 7, and I also have Clang - all available to me via switch/simple shell functions. I always tend to have my j…
Re: GCC 7 Release Series – Changes, New Features, and Fixes
#6On mainstream native platforms, Ada programs no longer require the stack to be made executable in order to run properly. What does that even mean? I'm dabbling with Ada as of recently. Also, woo! Support for the RISC-V instruction set has been added. On topic, I'm using GCC5 and 6 as well as experimenting with 7, and I also have Clang - all available to me via switch/simple shell functions. I always tend to have my j…
>What does that even mean?
I know nothing about Ada but there is a feature called called 'executable bit' in pretty much all desktop processors since 1-2 decades. What this bit does is it marks certain regions of memory as not executable, i.e. you're not allowed to put the instruction pointer onto that region and let the CPU run the instructions. This is a hardware-level feature and can be disabled in BIOS/UEFI. Usually the stack is marked as not executable as a security feature, so buffer overruns can't just write code on the stack and then it is executed.
Why Ada needed this disabled is beyond me. Does it execute things on the stack?
Re: GCC 7 Release Series – Changes, New Features, and Fixes
#7If you compare (gcc7 and latest clang), how much in pair is gcc with clang in terms of compilation warnings? (One of the most valuable tool of a compiler). I'm really happy they are moving in the same direction; I've been worried about gcc.
They're both very good now. Sometimes the error messages of one are clearer than the other's, sometimes it's the other way around. If I don't immediately find the cause in a long templatey error, I'll just check the other compiler's message. Having both messages can be surprisingly helpful :)
Re: GCC 7 Release Series – Changes, New Features, and Fixes
#8On mainstream native platforms, Ada programs no longer require the stack to be made executable in order to run properly. What does that even mean? I'm dabbling with Ada as of recently. Also, woo! Support for the RISC-V instruction set has been added. On topic, I'm using GCC5 and 6 as well as experimenting with 7, and I also have Clang - all available to me via switch/simple shell functions. I always tend to have my j…
>What does that even mean? I know nothing about Ada but there is a feature called called 'executable bit' in pretty much all desktop processors since 1-2 decades. What this bit does is it marks certain regions of memory as not executable, i.e. you're not allowed to put the instruction pointer onto that region and let the CPU run the instructions. This is a hardware-level feature and can be disabled in BIOS/UEFI. Usua…
As usual, no-execute bits in the page table is something that trickles down. I think in x86 land AMD introduced it with AMD64. The RISCies (Sparc, Power, Alpha, hppa) had this earlier.
Re: GCC 7 Release Series – Changes, New Features, and Fixes
#9If you compare (gcc7 and latest clang), how much in pair is gcc with clang in terms of compilation warnings? (One of the most valuable tool of a compiler). I'm really happy they are moving in the same direction; I've been worried about gcc.
For gcc-4.3 this was a no contest, clang was clearly better. However, gcc has made up a lot of ground over the years, to the point that I now consider gcc's template based error messaes better. It is very difficult to keep personal judgement and tastes out of the equation so ymmv. If the error message of one is not very illuminating I often try the other compiler on the same piece of code. It is a good practice anywa…
> If the error message of one is not very illuminating I often try the other compiler on the same piece of code. It is a good practice anyway and I should be doing more of that.
It actually is a good idea to regularly build and test C/C++ codebases with both gcc and clang because not only error diagnostics are different but also warnings and optimizations, including crazy optimizations exploiting undefined behavior.
I discovered several bugs simply by compiling some code with different compilers and running the test suite each time.
Re: GCC 7 Release Series – Changes, New Features, and Fixes
#10If you compare (gcc7 and latest clang), how much in pair is gcc with clang in terms of compilation warnings? (One of the most valuable tool of a compiler). I'm really happy they are moving in the same direction; I've been worried about gcc.
Where clang now clearly leads is in terms of runtime security and debugging features. Both share asan (address sanitizer), ubsan (undefined behavior) and tsan (threads). But msan (memory sanitizer, finds uninitialized memory use) is only available in clang.
In terms of exploit mitigation clang now has control flow integrity and safestack, as far as I'm aware nothing like this is available in gcc.
msan may not be such a big deal, because you could use clang for testing and gcc for production. But I hope more people adopt stronger exploit mitigations like CFI, and if gcc doesn't deliver them clang will win - at least for security sensitive areas.