4 ms·

Right now, clang is missing several features that I care about, but most of the industry doesn't[1]. Clang is a 90% or maybe 95% solution, and my use cases are

Right now, clang is missing several features that I care about, but most of the industry doesn't[1]. Clang is a 90% or maybe 95% solution, and my use cases aren't covered. So I don't use it. That said, I am grateful for the competition: GCC has definitely been getting better thanks to clang. [1] Namely, -Wdouble-promotion, big-endian ARM interrupt handlers, -fstack-usage, -Og, -fno-delete-null-pointer-checks, -falign-functions

beeforpork 11y ago
+1 for -fno-delete-null-pointer-checks But actually, what I'd rather like is -fno-optimise-based-on-undefined-behaviour.
- brandmeyer 11y ago
  -fno-delete-null-pointer-checks In my particular case, I'm programming in a microcontroller environment where there is ordinary RAM at the NULL address. Dereferencing NULL therefore doesn't halt the program at all.
  - teddyh 11y ago
    Your compiler, or rather your architecture definition supplied to the compiler, is broken. NULL should be an invalid pointer value — it need not actually be memory address 0. (The explicit constant 0 in a pointer context should be automatically translated by the compiler into this special invalid pointer value.) There have been several such architectures already, so this should not present an insurmountable problem.
  - yrro 11y ago
    AIUI, this code is not affected: X *foo = ...; if (foo) foo->bar(); But this code will be: X *foo = ...; foo->bar(); if (foo) { ... } Since foo is dereferenced unconditionally, the compiler is allowed to assume that it will not be null in the above code, and therefore the test on the third line to determine whether foo is null or not is useless and can be omitted.
    - iso-8859-1 11y ago
      Since this code is broken, wouldn't it be better to emit a warning and let the programmer fix it?
      - caf 11y ago
        The real case where it matters is where the "if (foo) { ... }" test happens in a function that's been inlined into the caller, but not all the callers do the foo->bar() dereference. So it's only being removed in some cases.
      - brandmeyer 11y ago
        There used to be a fairly broad warning (-Wunreachable-code), but it caused so many false positives and false negatives that it was removed.
  - Kristine1975 11y ago
    Same thing in say the Linux kernel, where gcc removing a NULL pointer check actually created a vulnerability: http://lwn.net/Articles/342330/ http://lwn.net/Articles/342330/
    - brandmeyer 11y ago
      Yep. In fact, it was this very vulnerability that brought my attention to this issue in embedded systems.
- astrange 11y ago
  Try "-fno-strict-overflow -fno-strict-aliasing -fno-delete-null-pointer-checks" and then see if your program gets slower. That won't nearly get everything, but loop optimization in C relies on undefined behavior a lot of the time, so you'll get to see how much you need it.

beeforpork 11y ago

+1 for -fno-delete-null-pointer-checks But actually, what I'd rather like is -fno-optimise-based-on-undefined-behaviour.

brandmeyer 11y ago
-fno-delete-null-pointer-checks In my particular case, I'm programming in a microcontroller environment where there is ordinary RAM at the NULL address. Dereferencing NULL therefore doesn't halt the program at all.
- teddyh 11y ago
  Your compiler, or rather your architecture definition supplied to the compiler, is broken. NULL should be an invalid pointer value — it need not actually be memory address 0. (The explicit constant 0 in a pointer context should be automatically translated by the compiler into this special invalid pointer value.) There have been several such architectures already, so this should not present an insurmountable problem.
- yrro 11y ago
  AIUI, this code is not affected: X *foo = ...; if (foo) foo->bar(); But this code will be: X *foo = ...; foo->bar(); if (foo) { ... } Since foo is dereferenced unconditionally, the compiler is allowed to assume that it will not be null in the above code, and therefore the test on the third line to determine whether foo is null or not is useless and can be omitted.
  - iso-8859-1 11y ago
    Since this code is broken, wouldn't it be better to emit a warning and let the programmer fix it?
    - caf 11y ago
      The real case where it matters is where the "if (foo) { ... }" test happens in a function that's been inlined into the caller, but not all the callers do the foo->bar() dereference. So it's only being removed in some cases.
    - brandmeyer 11y ago
      There used to be a fairly broad warning (-Wunreachable-code), but it caused so many false positives and false negatives that it was removed.
- Kristine1975 11y ago
  Same thing in say the Linux kernel, where gcc removing a NULL pointer check actually created a vulnerability: http://lwn.net/Articles/342330/ http://lwn.net/Articles/342330/
  - brandmeyer 11y ago
    Yep. In fact, it was this very vulnerability that brought my attention to this issue in embedded systems.
astrange 11y ago
Try "-fno-strict-overflow -fno-strict-aliasing -fno-delete-null-pointer-checks" and then see if your program gets slower. That won't nearly get everything, but loop optimization in C relies on undefined behavior a lot of the time, so you'll get to see how much you need it.