[llvm-dev] Commit 93af05e03e05d2f85b5a7e20ec3a3a543584d84f causes warning

Bakhvalov, Denis via llvm-dev llvm-dev at lists.llvm.org
Mon Jun 3 11:57:59 PDT 2019


Hello Lang,

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

Best regards,
Denis Bakhvalov.

From: David Blaikie [mailto:dblaikie at gmail.com]
Sent: Friday, May 31, 2019 1:17 PM
To: Reid Kleckner <rnk at google.com>
Cc: Lang Hames <lhames at gmail.com>; llvm-dev at lists.llvm.org; Bakhvalov, Denis <denis.bakhvalov at intel.com>
Subject: Re: [llvm-dev] Commit 93af05e03e05d2f85b5a7e20ec3a3a543584d84f causes warning

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

On Fri, May 31, 2019 at 1:06 PM Reid Kleckner via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
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.

On Fri, May 31, 2019 at 12:40 PM Lang Hames via llvm-dev <llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>> wrote:
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?

Cheers,
Lang.

On Fri, May 31, 2019 at 10:54 AM Bakhvalov, Denis <denis.bakhvalov at intel.com<mailto:denis.bakhvalov at intel.com>> wrote:
Hello,

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: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61414
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:
http://lab.llvm.org:8011/builders/ubuntu-gcc7.1-werror

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.

_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
_______________________________________________
LLVM Developers mailing list
llvm-dev at lists.llvm.org<mailto:llvm-dev at lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190603/fa82826e/attachment.html>


More information about the llvm-dev mailing list