3

This isn't quite the minimum possible reproduction, but hopefully illustrates the issue well while being bite-sized.

#include <iostream>

int main(int, char **)
{
  int i;
  std::cin >> i;

  switch(i)
  {
      case 0:

        break;
        std::cout << "too small" << std::endl;

      case 1:
        break;
    
      default:
        std::cout << "too large" << std::endl;
        break;
  }

  return 0;
}

The problem here, of course, is that the user has added code to a switch statement after the break instead of before it. (Of course in a real example there would have been preexisting code prior to the break statement)

clang is able to detect this with the -Wunreachable-code flag, and MSVC is able to detect it with /Wall, but I haven't found a way to get g++ to warn about this.

g++ does have a flag -Wswitch-unreachable, but that only catches code that appears prior to the first switch label, so it's of no help here.

Daniel McLaury
  • 4,047
  • 1
  • 15
  • 37
  • You can see the GCC warnings available by doing `g++-12 -Q --help=warning` – Eljay Sep 27 '22 at 21:36
  • 2
    Looks like GCC's `-Wunreachable-code` was made less aggressive or perhaps disabled entirely back in 2015. The flag was not removed though. False sense of security. – Eljay Sep 27 '22 at 21:43
  • 1
    Related: https://stackoverflow.com/questions/17249934/why-does-gcc-not-warn-for-unreachable-code – Jerry Jeremiah Sep 27 '22 at 21:55
  • Just a note, and not completely sure, but it might be removed by the optimizer anyways. – cs1349459 Sep 27 '22 at 23:30
  • 1
    I think the real answer here is to not rely on a single compiler. Running your code through both gcc _and_ clang is a good practice. – Taekahn Sep 27 '22 at 23:33
  • Have a read through https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#Warning-Options - there are multiple options related to `switch` statements. – Jesper Juhl Sep 28 '22 at 03:11
  • External tools/linters might have that check too. – Jarod42 Sep 28 '22 at 09:01
  • @Eljay you want to add that as an answer so I can close out the question? that seems to pretty definitely settle things. – Daniel McLaury Sep 28 '22 at 15:07
  • It's an unsatisfactory answer. I hope the GCC folks fix the problem and re-implement the functionality, and it's unfortunate the prior implementation was deemed too problematic and stubbed out. (I know, GCC is a volunteer effort. "If you want a feature: implement it and send them a pull request." is the usual response I've gotten.) – Eljay Sep 28 '22 at 15:26
  • @Eljay I'm tempted to submit a patch just reverting that commit... – Daniel McLaury Sep 28 '22 at 18:48

1 Answers1

1

This is basically resolved in the comments by Eljay and Jerry Jeremiah, but for the sake of closing the question out, it looks like gcc silently removed unreachable code detection back in 2014 because it gave different results at different optimization levels.

This seems like a remarkably stupid justification for removing one of the most basic and important features every compiler is supposed to have, but what do I know?

From the gcc mailing list:

The -Wunreachable-code has been removed, because it was unstable: it relied on the optimizer, and so different versions of gcc would warn about different code. The compiler still accepts and ignores the command line option so that existing Makefiles are not broken. In some future release the option will be removed entirely.

Source: https://gcc.gnu.org/legacy-ml/gcc-help/2011-05/msg00360.html

Daniel McLaury
  • 4,047
  • 1
  • 15
  • 37