-Wbitwise-op-mismatch and enums of a matching type

[jcurtiss8086]

Currently, if a variable of type bit[31:0] is used in a bitwise-operation with an enum that is also defined as type bit[31:0], then -Wbitwise-op-mismatch will flag a warning, e.g.

file.svh:272:33: warning: bitwise operation between operands of different types ('bit[31:0]' and 'MyEnum_t') [-Wbitwise-op-mismatch]
        addr_offset &= ~64BYTE_ALIGNED;
        ~~~~~~~~~~~ ^~ ~~~~~~~~~~~~~~~~

And the enum is defined as

typedef enum bit [31:0] {
    ...
} MyEnum_t;

Do you think it's reasonable to request a relaxation for enum bitwise operations where the enum type matches? Or is there a reason that someone might still want this to flag a warning?

[MikePopoloski]

I suppose I can think of scenarios where you'd want to that to warn; like if the enum is not designed to be used as a mask / flags and the code accidentally uses the wrong enum, you'd want the warning to flag it. Like for example:

enum bit [31:0] {
   OPT_A = 1, OPT_B = 2, OPT_C = 3
} opt;
enum bit [31:0] {
  FLAG_A = 1 << 0, FLAG_B = 1 << 1, FLAG_C = 1 << 2
} flag;

some_flagset &= ~OPT_B; // should be FLAG_B, but happen to result in same values so will actually run just fine, but if they had used OPT_C it would cause a bug. Either way you'd probably want a warning.

But I'd say I'm personally ambivalent. These warnings were originally added at user request because they wanted to get way more warnings about any expressions where the types were even a bit different, but I don't know how they'd react to this particular case and I do find them to be overly noisy already, so I wouldn't mind relaxing it for this case.

[jcurtiss8086]

Your example is a good point. I do find bitwise-op-mismatch to be a useful warning and it has found a small number of real bugs. Will think through this a bit more.