Bakhvalov, Denis via llvm-dev
2019-May-31 17:54 UTC
[llvm-dev] Commit 93af05e03e05d2f85b5a7e20ec3a3a543584d84f causes warning
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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190531/3302267b/attachment.html>
Lang Hames via llvm-dev
2019-May-31 19:40 UTC
[llvm-dev] Commit 93af05e03e05d2f85b5a7e20ec3a3a543584d84f causes warning
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. > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190531/3a2360e3/attachment.html>
Reid Kleckner via llvm-dev
2019-May-31 20:05 UTC
[llvm-dev] Commit 93af05e03e05d2f85b5a7e20ec3a3a543584d84f causes warning
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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190531/d3b217bd/attachment.html>
Possibly Parallel Threads
- Commit 93af05e03e05d2f85b5a7e20ec3a3a543584d84f causes warning
- Assertion triggered when running simple hello-world code on iOS device using ORC/LLLazyJIT
- ORC Assertion failure
- Assertion triggered when running simple hello-world code on iOS device using ORC/LLLazyJIT
- ORC JIT - different behaviour of ExecutionSession.lookup?