6 ms·

If 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

by Bino 10y ago

If 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.

srean 10y ago
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.
- qb45 10y ago
  > 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.
  - joatmon-snoo 10y ago
    My first experience with UB: foo(bar(), bar()); (where bar() was stateful) Discovering that g++ and clang++ compiled to one that did what I wanted and one that didn't was an interesting experience.
    - qb45 10y ago
      It gets even funnier in OCaml where they nominally defined it UB in order to get the freedom to make the only existing implementation always 100% reliably evaluate right-to-left, which reportedly was better for performance or something :) And before somebody wonders about currying and eager evaluation, the problem is not functions but type constructors, which aren't curried.
      - ufo 10y ago
        The ocaml one is very annoying because the bytecode interpreter reliably evaluates arguments left-to-right but when you compile to native code it reliably evaluates right-to-left (or the other way around, I don't remember).
        deleted 10y ago
        [deleted]
        afrisch 10y ago
        I don't think so. Both bytecode and native evaluate right-to-left.
        ufo 10y ago
        I swear that I remember having programs that could behave differently in the bytecode and native compiler. Perhaps I'm remembering an older version of the compiler or another order-of-evaluation issue other than function parameters?
      - gravypod 10y ago
        The functions arguments are pushed onto the stack. From within the function you can think of the stack as an array. void test(a, b, c) stack[0] == a stack[1] == b stack[2] == c But to get the items in the stack in that order you have to... puch c push b push a If you wanted to do that, and still allow for left to right evaluation you could... temp_a = a temp_b = b temp_c = c push c puch b push a That would be 2x instructions for every (already expensive at that time) function call. Defining unordered evaluation as UB was to avoid having to do temp_a, temp_b, temp_c. Now compiles can do that and trivially optimize that sort of thing out.
    - ot 10y ago
      That's not UB. Argument evaluation order is unspecified, not undefined.
      - wyldfire 10y ago
        He meant unspecified behavior. ;)
    - greglindahl 10y ago
      The SGI compiler (now Open64) evaluates function arguments from right to left, unlike most other compilers. As a result we (PathScale) had to educate numerous users that the order is not guaranteed.
    - kirab 10y ago
      Starting with C++17 evaluation order in this case (and most other cases) is finally specified and standardized! This is the accepted proposal: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0145r3.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p014...
  - gumby 10y ago
    Yes! We have written a new package and compiling with the G++-6 -Wall -Werror .... and clang-++-4 -Weverything -Werror finds different bugs and different diagnostics. Although I have a long gcc bias I do use clang first as it is still faster to compile. Gcc still generates faster code for our codebase (and more importantly: faster where it matters to us) but they are pretty close and if I really had to decide between one and the other it would hardly matter. G++-7-not-quite-released appears to have better C++17 support. We may be the only people who care yet :-)
  - flamedoge 10y ago
    I'm a little mixed about having to run both compilers for more comprehensive result. DRY principle in me tells me that devs could have concentrated effort in one compiler to make it even better.
lorenzhs 10y ago
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 :)
hannob 10y ago
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.
- nn3 10y ago
  gcc has ubsan too, and various stack overflow checking mechanisms.
- loeg 10y ago
  My understanding (and empirical anecdote) is that Clang produces inferior debuginfo (eliding some locals' contents, even when their values are not actually lost) that makes it more difficult to debug than binaries produced by GCC. asan, ubsan, tsan, and msan are important debugging features, but for my every day use in core analysis, local variables in gdb are very important.
anon1385 10y ago
As far as I can tell GCC is still inferior when it comes to warning about uninitialized variables. Clang: https://godbolt.org/g/BVfy81 https://godbolt.org/g/BVfy81 GCC: https://godbolt.org/g/uIN1gG https://godbolt.org/g/uIN1gG See the famous and now 12 years old GCC bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501
- flamedoge 10y ago
  just curious, why can't one use use-def chains to detect uninitialized variables? Basically you want backward-all dataflow analysis with gen=use & kill=def...
mrich 10y ago
There is an important class of warnings which only gcc gets 100% right: Those about optimizing away checks for this != nullptr and &refobject != nullptr (because they will always be true). clang skips the warning inside macros. This is a big problem when you want to find and fix all occurrences before they bite you at runtime. Many warnings are available in both compilers and effort has been made to use the same names. Both compilers have some warnings exclusively. Clang prefers to raise warnings in the frontend only. Gcc in contrast will sometimes raise more warnings at higher optimization levels. If you can afford the overhead build with clang dbg, gcc O3 and MSVC.
- cperciva 10y ago
  I disagree about warnings inside macros. There are lots of functions like strtod which take an argument and say "if this is non-NULL, store a value into the pointed-to variable", so that you can write "foo(..., &x)" if you want the value and "foo(..., NULL)" if you don't. This is a recipe for a warning which gets disabled due to an excess of false positives. (I'd say that this warning could be explicitly disabled for the scope is the macro... but alas, GCC broke _Pragma inside macros.)

by Bino 10y ago

srean 10y ago

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.

qb45 10y ago
> 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.
- joatmon-snoo 10y ago
  My first experience with UB: foo(bar(), bar()); (where bar() was stateful) Discovering that g++ and clang++ compiled to one that did what I wanted and one that didn't was an interesting experience.
  - qb45 10y ago
    It gets even funnier in OCaml where they nominally defined it UB in order to get the freedom to make the only existing implementation always 100% reliably evaluate right-to-left, which reportedly was better for performance or something :) And before somebody wonders about currying and eager evaluation, the problem is not functions but type constructors, which aren't curried.
    - ufo 10y ago
      The ocaml one is very annoying because the bytecode interpreter reliably evaluates arguments left-to-right but when you compile to native code it reliably evaluates right-to-left (or the other way around, I don't remember).
      - deleted 10y ago
        [deleted]
      - afrisch 10y ago
        I don't think so. Both bytecode and native evaluate right-to-left.
        ufo 10y ago
        I swear that I remember having programs that could behave differently in the bytecode and native compiler. Perhaps I'm remembering an older version of the compiler or another order-of-evaluation issue other than function parameters?
    - gravypod 10y ago
      The functions arguments are pushed onto the stack. From within the function you can think of the stack as an array. void test(a, b, c) stack[0] == a stack[1] == b stack[2] == c But to get the items in the stack in that order you have to... puch c push b push a If you wanted to do that, and still allow for left to right evaluation you could... temp_a = a temp_b = b temp_c = c push c puch b push a That would be 2x instructions for every (already expensive at that time) function call. Defining unordered evaluation as UB was to avoid having to do temp_a, temp_b, temp_c. Now compiles can do that and trivially optimize that sort of thing out.
  - ot 10y ago
    That's not UB. Argument evaluation order is unspecified, not undefined.
    - wyldfire 10y ago
      He meant unspecified behavior. ;)
  - greglindahl 10y ago
    The SGI compiler (now Open64) evaluates function arguments from right to left, unlike most other compilers. As a result we (PathScale) had to educate numerous users that the order is not guaranteed.
  - kirab 10y ago
    Starting with C++17 evaluation order in this case (and most other cases) is finally specified and standardized! This is the accepted proposal: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0145r3.pdf http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p014...
- gumby 10y ago
  Yes! We have written a new package and compiling with the G++-6 -Wall -Werror .... and clang-++-4 -Weverything -Werror finds different bugs and different diagnostics. Although I have a long gcc bias I do use clang first as it is still faster to compile. Gcc still generates faster code for our codebase (and more importantly: faster where it matters to us) but they are pretty close and if I really had to decide between one and the other it would hardly matter. G++-7-not-quite-released appears to have better C++17 support. We may be the only people who care yet :-)
- flamedoge 10y ago
  I'm a little mixed about having to run both compilers for more comprehensive result. DRY principle in me tells me that devs could have concentrated effort in one compiler to make it even better.

lorenzhs 10y ago

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 :)

hannob 10y ago

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.

nn3 10y ago
gcc has ubsan too, and various stack overflow checking mechanisms.
loeg 10y ago
My understanding (and empirical anecdote) is that Clang produces inferior debuginfo (eliding some locals' contents, even when their values are not actually lost) that makes it more difficult to debug than binaries produced by GCC. asan, ubsan, tsan, and msan are important debugging features, but for my every day use in core analysis, local variables in gdb are very important.

anon1385 10y ago

As far as I can tell GCC is still inferior when it comes to warning about uninitialized variables. Clang: https://godbolt.org/g/BVfy81 https://godbolt.org/g/BVfy81 GCC: https://godbolt.org/g/uIN1gG https://godbolt.org/g/uIN1gG See the famous and now 12 years old GCC bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=18501

flamedoge 10y ago
just curious, why can't one use use-def chains to detect uninitialized variables? Basically you want backward-all dataflow analysis with gen=use & kill=def...

mrich 10y ago

There is an important class of warnings which only gcc gets 100% right: Those about optimizing away checks for this != nullptr and &refobject != nullptr (because they will always be true). clang skips the warning inside macros. This is a big problem when you want to find and fix all occurrences before they bite you at runtime. Many warnings are available in both compilers and effort has been made to use the same names. Both compilers have some warnings exclusively. Clang prefers to raise warnings in the frontend only. Gcc in contrast will sometimes raise more warnings at higher optimization levels. If you can afford the overhead build with clang dbg, gcc O3 and MSVC.

cperciva 10y ago
I disagree about warnings inside macros. There are lots of functions like strtod which take an argument and say "if this is non-NULL, store a value into the pointed-to variable", so that you can write "foo(..., &x)" if you want the value and "foo(..., NULL)" if you don't. This is a recipe for a warning which gets disabled due to an excess of false positives. (I'd say that this warning could be explicitly disabled for the scope is the macro... but alas, GCC broke _Pragma inside macros.)