[vsipl++] compiler warnings

[Mark Mitchell]

Stefan Seefeld wrote:

> These, as well as map.hpp:413, map.hpp:509, map.hpp:458.

Those three are going to cause warnings with almost all compilers when
using -DNDEBUG, i.e., when assert is an empty macro.  In that case, most
compilers will think that you're "falling off" the switch, and,
therefore, the function.

One way to fix this would be to use a single return (with a local
variable to store the value), and then it would be obvious to all
compilers that there was no problem, e.g.:

  subblocks_type s;

  assert (d < VSIP_MAX_DIMENSION);

  switch(d) {
    case 0: s = dist0._num_subblocks();
    case 1: s = dist1._num_subblocks();
    case 2: s = dist2._num_subblocks();
    default: assert(false);
  }

  return s;

However, that could result in a warning about s being uninitialized, so
you'll probably need to write "s = 0" first.  And, that's bad, because
the compiler will not eliminate that assignment when optimizing because
it will not know that d is smaller than VSIP_MAX_DIMENSION, because the
assert will be gone.  It also won't work if the variable has no default
constructor.

Some compilers (but, not yet, GCC) have a magic __builtin_assert
function.  You can use this like so:

  __builtin_assert (d < VSIP_MAX_DIMENSION);

In debug mode, this is like an ordinary assert -- but in optimized mode
it tells the optimizer that the condition is always true.  So, the
compiler would know that the default case was unreachable, and could
eliminate the unreachable case.

Here is the trick I would use:

  switch(d) {
    default: assert(false);
    case 0: return dist0_.num_subblocks();
    case 1: return dist1_.num_subblocks();
    case 2: return dist2_.num_subblocks();
  }

That way, when the assert is gone, you'll just fall into the "0" case,
which is OK, because you never expect it to happen, but the compiler
will see that you never fall off the end of the switch.

-- 
Mark Mitchell
CodeSourcery, LLC
mark at codesourcery.com
(916) 791-8304