[llvm-dev] Commit 93af05e03e05d2f85b5a7e20ec3a3a543584d84f causes warning

[Lang Hames via llvm-dev]

>
> 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.

On Mon, Jun 3, 2019 at 11:58 AM Bakhvalov, Denis <denis.bakhvalov at intel.com>
wrote:

> 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> 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> 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> 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
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> _______________________________________________
> LLVM Developers mailing list
> 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/a37849c0/attachment.html>