[cfe-dev] Using a enum type for a bitfield

mats petersson via cfe-dev cfe-dev at lists.llvm.org
Thu Sep 3 09:19:30 PDT 2015


On 3 September 2015 at 17:05, Michael Hordijk via cfe-dev <
cfe-dev at lists.llvm.org> wrote:

> Yes, that's a good summary.  bug 11272 is the request for this type of
> documentation.  In general I think more people will be looking for this
> type of documentation such that the can determine how using this
> implementation will effect them.
>
> In the near term we need a direct answer as to whether clang supports
> implementation defined behavior under C11 6.7.2.1 P 5, specifically the use
> of enums as bit fields.
>
> We're starting to run into some issues that are indicating that it may not
> be supported, which is fine but we need to know the intentions for this
> behavior.
>
> I suppose that technically if the implementation does not define the
> behavior then the behavior is not supported/undefined.  If it's going to be
> supported we'd like to avoid unnecessary code churn.  On the flip side we
> could just go remove this behavior and we won't have to worry about it if
> we decide to use a different implementation.
>

Implemmentation defined behaviour that is not "defined" is not the same as
undefined behaviour. There is a distinct difference in that implementation
defined behaviour is supposed to "work" (do something reasonably
meaningful) or not compile, where UB is allowed to result in just about
anything [covering both "works as you expect" (whatever "expect" may
entail) and "crashes" or "fails to compile"].

Of course, the spec also states that IDB should be documented, so
technically, the clang compiler is not fulfilling the specifications in
this respect.

I suspect, however, that if you are seeing a behaviour where the code
compiles, but isn't behaving as you expect, it's quite possibly a compiler
bug, rather than "implementation is intended to behave this way".

If the compiler does not support this, I'd very much expect the compiler to
NOT accept the source code, so in that respect it's a bug either way. But
it probably requires a small test-case to show the problem behaviour.

--
Mats

>
> - michael
>
> On 8/26/15 4:38, mats petersson via cfe-dev wrote:
>
>> @Serge:
>>
>> I think the point of bug 11272 is to actually document [directly or
>> referring to some other documentation elsewhere] ALL of the clang
>> implementation defined behaviour, which includes the behaviour with
>> bitfields from enums (and I expect it is identical to gcc's behaviour,
>> but I don't KNOW that this is the case).
>>
>> --
>> Mats
>>
>> On 26 August 2015 at 11:27, Serge Pavlov
>> <sepavloff at gmail.com
>> <mailto:sepavloff at gmail.com>> wrote:
>>
>>     Hi,
>>
>>     Bug 11272 - document implementation-defined behavior
>>     <https://llvm.org/bugs/show_bug.cgi?id=11272> says nothing about bit
>>     fields.
>>
>>     Thanks,
>>     --Serge
>>
>>     2015-08-26 15:28 GMT+06:00 mats petersson via cfe-dev
>>     <cfe-dev at lists.llvm.org
>>     <mailto:cfe-dev at lists.llvm.org>>:
>>
>>         Bug number would be 11272 - the text has been mime-encoded to
>>         replace the = with =3D (since mime uses = as a special
>>         character, and =3D is the escaped = sign). Obviously, some step
>>         on the way didn't understand the encoding and left it as plain
>>         text without decoding it.
>>
>>         --
>>         Mats
>>
>>         On 26 August 2015 at 08:29, Csaba Raduly via cfe-dev
>>         <cfe-dev at lists.llvm.org
>>         <mailto:cfe-dev at lists.llvm.org>> wrote:
>>
>>             Hi.
>>
>>             On Mon, Aug 24, 2015 at 10:29 PM, Hordijk, Michael via
>>             cfe-dev  wrote:
>>             > The short question:
>>             >
>>             > Does clang support using an enum as a type for a bit-field?
>>             >
>>             > C11 (6.7.2.1 P 5):
>>             >
>>             > A bit-field shall have a type that is a qualified or
>> unqualified version
>>             > of _Bool, signed int, unsigned int, or some other
>> implementation-defined
>>             > type.
>>             ...
>>             > So I'm curious as to whether clang supports it.  I did find
>> this on
>>             > bugzilla:
>>             >
>>             >https://llvm.org/bugs/show_bug.cgi?id=3D11272
>>
>>             LLVM Bugzilla says:
>>
>>             '3D11272' is not a valid bug number.
>>
>>
>>             Csaba
>>             --
>>             GCS a+ e++ d- C++ ULS$ L+$ !E- W++ P+++$ w++$ tv+ b++ DI D++
>> 5++
>>             The Tao of math: The numbers you can count are not the real
>>             numbers.
>>             Life is complex, with real and imaginary parts.
>>             "Ok, it boots. Which means it must be bug-free and perfect.
>>             " -- Linus Torvalds
>>             "People disagree with me. I just ignore them." -- Linus
>> Torvalds
>>             _______________________________________________
>>             cfe-dev mailing list
>>             cfe-dev at lists.llvm.org
>>             <mailto:cfe-dev at lists.llvm.org>
>>             http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>>
>>
>>         _______________________________________________
>>         cfe-dev mailing list
>>         cfe-dev at lists.llvm.org
>>         <mailto:cfe-dev at lists.llvm.org>
>>         http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>>
>>
>>
>>
>> _______________________________________________
>> cfe-dev mailing list
>> cfe-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>
>>
>
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20150903/ef342c32/attachment.html>


More information about the cfe-dev mailing list