From: Alejandro Colomar <alx.manpages@gmail.com>
To: Joseph Myers <joseph@codesourcery.com>
Cc: gcc@gcc.gnu.org, GNU C Library <libc-alpha@sourceware.org>,
Yann Droneaud <ydroneaud@opteya.com>
Subject: Re: stdc_bit_ceil(3) and wrapping
Date: Fri, 30 Dec 2022 21:46:40 +0100 [thread overview]
Message-ID: <9b662ccd-0f9d-963b-e1f6-d225c5a9c902@gmail.com> (raw)
In-Reply-To: <8e45df-4b3e-e648-e14-b5d7ce15311f@codesourcery.com>
[-- Attachment #1.1: Type: text/plain, Size: 2648 bytes --]
Hi Joseph,
On 12/30/22 21:38, Joseph Myers wrote:
> On Fri, 30 Dec 2022, Alejandro Colomar via Gcc wrote:
>
>> I was wondering if there was any reason to make that UB in the standard, when
>> unsigned wrapping has always been well-defined, and this is a case that is
>> likely to be implemented with some operation that wraps around, right? I
>
> It's likely to be implemented by a shift, that might be by the number of
> bits in the argument in the overflow case, and shift by the width of the
> argument is undefined behavior; some architectures wrap the shift count
> modulo the width (do you actually want 1 or 0 as the result of
> stdc_bit_ceil?), some wrap the shift count modulo a larger value (e.g.
> treating 1 << 32 as 0 but 1 << 64 as 1) and for some architectures the
> result depends on the particular shift instruction used (meaning undefined
> behavior on the form of the result of an integer expression possibly
> comparing unequal to itself because the compiler duplicated the expression
> and then used different instructions to compute it in different places).
For the C standard, shifts have wrap around semantics for unsigned types:
C2x(N3054)::6.5.7p4:
"
The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated bits are
filled with zeros. If E1 has an unsigned type, the value of the result is E1 ×
2E2, wrapped around. [...]
"
Which reminds me that I forgot to use 1ul << ...
Since the <stdbit.h> functions are only provided for unsigned types, there
should be no problems, right?
>
>> Would you consider either or both of being more generous in the GNU
>> implementation and guarantee wrap around, and/or suggest that the standard
>> guarantees the wrap around?
>
> The CD ballot has closed, and this doesn't appear to be one of the 338
> comments raised on that ballot, and I don't really expect time at next
> month's meeting to deal with additional technical comments not on that
> list, when we have only 15 hours to deal with 338 comments. Once we have
> an issue tracking process for the C standard again (hopefully involving an
> issue tracker that the public can readily submit issues in),
Hopefully. And a public git repository and mailing list would be awesome :)
*comes back to reality*
> I'd suggest
> raising such concerns there (unless there's a CD2 ballot; technical
> comments are best avoided at a DIS ballot if possible).
Ahh, no problem. If it's something to be suggested for C3x or for a small C2y
fix (like C17 was), that would be fine.
Cheers,
Alex
>
--
<http://www.alejandro-colomar.es/>
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2022-12-30 20:46 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-30 19:53 Alejandro Colomar
2022-12-30 20:18 ` Yann Droneaud
2022-12-30 20:33 ` Alejandro Colomar
2022-12-30 22:33 ` Alejandro Colomar
2023-01-06 20:08 ` Alejandro Colomar
2022-12-30 20:47 ` Alejandro Colomar
2022-12-30 20:38 ` Joseph Myers
2022-12-30 20:46 ` Alejandro Colomar [this message]
2022-12-30 20:56 ` Joseph Myers
2022-12-30 21:01 ` Alejandro Colomar
2022-12-30 21:06 ` Alejandro Colomar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9b662ccd-0f9d-963b-e1f6-d225c5a9c902@gmail.com \
--to=alx.manpages@gmail.com \
--cc=gcc@gcc.gnu.org \
--cc=joseph@codesourcery.com \
--cc=libc-alpha@sourceware.org \
--cc=ydroneaud@opteya.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).