thr3ads.net - llvm dev - [llvm-dev] Commit 93af05e03e05d2f85b5a7e20ec3a3a543584d84f causes warning [Jun 2019]

If this information is useful, please help other people find it:
Share via:

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>

David Blaikie via llvm-dev

2019-May-31 20:16 UTC

head link

[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/20190531/4553d70f/attachment.html>

Bakhvalov, Denis via llvm-dev

2019-Jun-03 18:57 UTC

head link

[llvm-dev] Commit 93af05e03e05d2f85b5a7e20ec3a3a543584d84f causes warning

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>

llvm dev - Jun 2019 - Commit 93af05e03e05d2f85b5a7e20ec3a3a543584d84f causes warning

[llvm-dev] Commit 93af05e03e05d2f85b5a7e20ec3a3a543584d84f causes warning

[llvm-dev] Commit 93af05e03e05d2f85b5a7e20ec3a3a543584d84f causes warning

[llvm-dev] Commit 93af05e03e05d2f85b5a7e20ec3a3a543584d84f causes warning