public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Joseph Myers <joseph@codesourcery.com>
To: Alejandro Colomar <alx.manpages@gmail.com>
Cc: <gcc@gcc.gnu.org>, GNU C Library <libc-alpha@sourceware.org>
Subject: Re: stdc_bit_ceil(3) and wrapping
Date: Fri, 30 Dec 2022 20:38:11 +0000	[thread overview]
Message-ID: <8e45df-4b3e-e648-e14-b5d7ce15311f@codesourcery.com> (raw)
In-Reply-To: <d6a6bcc1-2b65-8449-9379-1990a0840c58@gmail.com>

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).

> 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), I'd suggest 
raising such concerns there (unless there's a CD2 ballot; technical 
comments are best avoided at a DIS ballot if possible).

-- 
Joseph S. Myers
joseph@codesourcery.com

  parent reply	other threads:[~2022-12-30 20:38 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 [this message]
2022-12-30 20:46   ` Alejandro Colomar
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=8e45df-4b3e-e648-e14-b5d7ce15311f@codesourcery.com \
    --to=joseph@codesourcery.com \
    --cc=alx.manpages@gmail.com \
    --cc=gcc@gcc.gnu.org \
    --cc=libc-alpha@sourceware.org \
    /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).