Commit 93af05e03e05d2f85b5a7e20ec3a3a543584d84f causes warning


After commit 93af05e03e05d2f85b5a7e20ec3a3a543584d84f we have new warning but only if compiled with GCC:

In file included from /path/to/llvm/include/llvm/ExecutionEngine/Orc/ExecutionUtils.h:19:0,

from /path/to/llvm/lib/ExecutionEngine/Orc/OrcMCJITReplacement.h:23,

from /path/to/llvm/lib/ExecutionEngine/Orc/OrcMCJITReplacement.cpp:9:

/path/to/llvm/include/llvm/ExecutionEngine/Orc/Core.h:690:25: warning: ‘llvm::orc::JITDylib::SymbolTableEntry::State’ is too small to hold all values of ‘enum class llvm::orc::JITDylib::SymbolState’

SymbolState State : 6;

There is no GCC option for disabling this warning:

The issue is that now LLVM is not buildable with GCC and ‘-Werror’ enabled.

In addition, LLVM gcc-werror buildbot seems to be offline since May 9th:

I understand that changing the code to satisfy GCC requirements might not be desired, but I think this is something that we should do.

Best regards,
Denis Bakhvalov.

Hi Denis,

It is unfortunate that GCC has added such an aggressive warning with no way to disable it. I would definitely make a comment on their bug tracker that you have hit this.

We could work around this by changing the field type to uint8_t and adding casts, but I’m not sure whether we want to work around warnings in other compilers as a matter of policy.

Anyone else have thoughts on style here?


Generally it is preferable to store bitfields using plain integer types because MSVC has surprising behavior when packing bitfields of differing type. MSVC, for example, will not back this into one byte:
bool a : 1;
uint8_t b : 2;
bool c : 1;
So, for LLVM or any other cross platform project, I recommend storing enums as some integer type, using the same type for all bitfields, and adding accessors to do the casts.

Isn’t there something weird with signedness of bitfields-of-enums in particular in MSVC too?

Hello Lang,

Given the replies from David and Reid are you ok with changing the code?

Best regards,
Denis Bakhvalov.

Given the replies from David and Reid are you ok with changing the code?

Yes – especially in light of MSVC’s behavior. (Thanks for the tip Reid!)

Fixed in r362450.

– Lang.