From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5540 invoked by alias); 29 Dec 2014 05:29:26 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 5530 invoked by uid 89); 29 Dec 2014 05:29:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mail-oi0-f51.google.com Received: from mail-oi0-f51.google.com (HELO mail-oi0-f51.google.com) (209.85.218.51) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 29 Dec 2014 05:29:24 +0000 Received: by mail-oi0-f51.google.com with SMTP id e131so27904086oig.10 for ; Sun, 28 Dec 2014 21:29:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=GgES4pGcLi6x6dccWhoUKFwQwoR64utLpH0MlndxGGo=; b=ggnCdXURffRxEG05lz3SRU7pZEiCBqv6s7SasVZGUhXCtO2VUyWF6VIWCBfHMUXd+r xZ2bXAEaUXH2vM0iFGhaEkH67V8B2aa0NlEBC4nlwHwVKBu/3pWsvQZyTVxfpmQan5Sw YSL+VLGyaFDs5DJUrDaVjftYnauTgccCIIjs6lR1CxJy4aett/Ro7fbGjhZeIQScrFv6 xBZ+MGXx90pnxkTVPeD5CGnvZsIEDKacVyh58DaamvcU/zuOdMhy1qIShxNDjmXTACAz +f/fgp6dh9usMTMdsX/9HqQLefH2le47S6dmLYaz/tXU8RI6Lvz+3VrbFdr+QpETbavD 9ANg== X-Gm-Message-State: ALoCoQm6q6kGY+Wo9mZe8ZBOzMU9Kj4v1oT8yEfiXVWFbqTn0mM6t4JedP2DkoHeFHVQE/Ofn0+J MIME-Version: 1.0 X-Received: by 10.182.148.98 with SMTP id tr2mr7119110obb.28.1419830962386; Sun, 28 Dec 2014 21:29:22 -0800 (PST) Received: by 10.182.222.98 with HTTP; Sun, 28 Dec 2014 21:29:22 -0800 (PST) In-Reply-To: <87d273w2gl.fsf@codesourcery.com> References: <1419815569-21854-1-git-send-email-yao@codesourcery.com> <20141229030659.GB2123@adacore.com> <87d273w2gl.fsf@codesourcery.com> Date: Mon, 29 Dec 2014 05:29:00 -0000 Message-ID: Subject: Re: [PATCH] Clear upper bits during sign extension From: Doug Evans To: Yao Qi Cc: Joel Brobecker , gdb-patches Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2014-12/txt/msg00654.txt.bz2 On Sun, Dec 28, 2014 at 7:37 PM, Yao Qi wrote: > Joel Brobecker writes: > >> I think you can simplify the above with just: >> >> value &=3D ((LONGEST) 1 << bit) - 1; >> >> ? I don't know if the cast to LONGEST is really necessary, but we use >> it for signbit, so I did the same for the mask... > > Yeah, that is better, or even we can left shift signbit by one. > > -- > Yao (=E9=BD=90=E5=B0=A7) > > gdb: > > 2014-12-29 Yao Qi > > * utils.c (gdb_sign_extend): Clear bits from BIT in VALUE. > > diff --git a/gdb/utils.c b/gdb/utils.c > index 47adb67..61873f7 100644 > --- a/gdb/utils.c > +++ b/gdb/utils.c > @@ -3032,6 +3032,9 @@ gdb_sign_extend (LONGEST value, int bit) > { > LONGEST signbit =3D ((LONGEST) 1) << (bit - 1); > > + /* Clear upper bits from bit BIT. */ > + value &=3D (signbit << 1) - 1; > + > value =3D (value ^ signbit) - signbit; > } It's not immediately clear to this reader that undefined behaviour is avoided here. E.g., what if sizeof (LONGEST) =3D=3D 8 && bit =3D=3D 64. There's an assert at the beginning of the function that bit could be 64.