[cfe-dev] [llvm-dev] Unsigned Bitwise Shift for Bit-field Structure

[陳韋任 via cfe-dev]

Then I think the bugzilla [1] you mentioned before should be updated? After
all, it's not a bug,
it's undefined behavior. If so, would you mind to update the link?

[1] https://bugs.llvm.org/show_bug.cgi?id=17299

Regards,
chenwj


2017-04-21 15:59 GMT+08:00 Shiva Chen via cfe-dev <cfe-dev at lists.llvm.org>:

> Hi Hubert and Liu Hao,
>
> Thanks for your guidance and make the question more clear.
> When the value is not stored back into the bit-field member, it will
> involve integer promotion.
> The integer promotion rule for bit-filed defined in C99 6.3.1.1/2.
> However, the integer promotion rule for other implementation-defined
> bit-field type
> (width wider than int such as unsigned long long bit field type) was not
> clear.
> So the question become should the implementation-defined bit-field
> type do the promotion.
> GCC choose not to and Clang will.
> There is some discussion in
> http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_315.htm
> As Hubert said, the answer will determine until the C standard mention
> the rule for implementation-defined bit-field type.
>
> 2017-04-21 2:47 GMT+08:00 Hubert Tong <hubert.reinterpretcast at gmail.com>:
> > On Thu, Apr 20, 2017 at 10:41 AM, Liu Hao <lh_mouse at 126.com> wrote:
> >>
> >> On 2017/4/20 19:20, Hubert Tong wrote:
> >>>
> >>> It is hardly clear that the rvalue is of type unsigned long long (and
> >>> not some special bit-field type).
> >>> See http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1260.htm.
> >>> I have been unable to find further discussion of the issue after
> >>> http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1270.pdf.
> >>
> >>
> >> You are right. Let's assume such an implementation exists, and despite
> >> that type, the result doesn't change: The (indeterminate) value is
> merely
> >> truncated earlier, yielding the same value after it is stored into the
> >> bit-field member.
> >
> > Where the implementation divergence occurs is when the value is not
> stored
> > back into the bit-field member.
> >
> >>
> >>
> >> I also doubt the existence of such an implementation: 6.7.2.1/4 doesn't
> >> say bit-field types need exist. Their occurrence also lead to problems:
> >> Would people benefit from it? What will happen if such an rvalue is
> passed
> >> to a function taking variable arguments? What will `sizeof(it+1)` where
> `it`
> >> has a bit-field type?
> >
> > I agree that it leads to problems. This is the reason why I had the cast
> to
> > unsigned long long in my code example (which does demonstrate the
> existence
> > of such an implementation, namely GCC): because, without the cast, the
> > argument may not match with the conversion specification.
> >
> > I think answering these questions is a job for WG 14 (the C committee).
> >
> >>
> >>
> >>
> >> --
> >> Best regards,
> >> LH_Mouse
> >>
> >
> _______________________________________________
> cfe-dev mailing list
> cfe-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>



-- 
Wei-Ren Chen (陳韋任)
Homepage: https://people.cs.nctu.edu.tw/~chenwj
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170421/613de634/attachment.html>