public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Mike Frysinger <vapier@gentoo.org>
To: Joseph Myers <joseph@codesourcery.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] sim: warnings: disable -Wshift-negative-value
Date: Fri, 5 Jan 2024 02:40:00 -0500	[thread overview]
Message-ID: <ZZeyUGZWEiTtyiYK@vapier> (raw)
In-Reply-To: <9b592c16-dc57-1bb7-5438-26c794d61d1c@codesourcery.com>

[-- Attachment #1: Type: text/plain, Size: 1947 bytes --]

On 29 Dec 2023 00:52, Joseph Myers wrote:
> On Sun, 24 Dec 2023, Mike Frysinger wrote:
> > The sim expects left shift operations on negative values to have two's
> > compliment behavior, and right shift operations to sign extend.  In C89,
> > this was not explicitly mentioned.  In C90, this was changed to undefined
> > behavior.  In C23, this was settled as the behavior we want in N2412 [1].
> 
> No, there has been no change in C23 to the rules for which shifts are 
> undefined.  The change made was to make *representations* of integer types 
> defined as two's complement; there were no changes to semantics of 
> *operations* on such types.

thanks, i thought the meat of P0907 was adopted, albeit via a diff proposal.
not that the final thing adopted was only about twos compliment representation.

looking closer at the source of the warnings, it seems to all come from the
macro that creates a 64-bit value from 2 32-bit values, and specifically
when shifting a negative constant into the upper 32-bits.  but we don't need
to make the upper 32-bits signed before shifting since we're going to throw
away all of the initial upper 32-bits, so we can prob fix this with:
-#define MAKEDI(hi, lo) ((((int64_t)  (int32_t) (hi)) << 32) | ((uint64_t) (uint32_t) (lo)))
+#define MAKEDI(hi, lo) ((((int64_t) (uint32_t) (hi)) << 32) | ((uint64_t) (uint32_t) (lo)))

for clarity, i'm kind of inclined to do the operations only as unsigned,
rely on the types to do the appropriate truncation/extension, and then
convert to signed at the end.
#define MAKEDI(hi, lo) ( \
	(int64_t)( \
		((uint64_t)(hi) << 32)) | (uint32_t) (lo) \
	) \
)

there's prob more left shifting of negative values lurking in the tree, but
none that trigger compile-time warnings, so i'm inclined to not audit.  the
harder part would be implementing sign extension with right shifts, so
hopefully we never have to cross that bridge.
-mike

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2024-01-05  7:40 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-12-24  8:26 Mike Frysinger
2023-12-29  0:52 ` Joseph Myers
2024-01-05  7:40   ` Mike Frysinger [this message]
2024-01-07  4:45 ` [PATCH] sim: cgen: rework DI macros to avoid signed left shifts Mike Frysinger

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=ZZeyUGZWEiTtyiYK@vapier \
    --to=vapier@gentoo.org \
    --cc=gdb-patches@sourceware.org \
    --cc=joseph@codesourcery.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).