From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id d8lON1bsjl+YbQAAWB0awg (envelope-from ) for ; Tue, 20 Oct 2020 09:55:34 -0400 Received: by simark.ca (Postfix, from userid 112) id D68271EFC1; Tue, 20 Oct 2020 09:55:34 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.0 required=5.0 tests=MAILING_LIST_MULTI autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 2505B1EF48 for ; Tue, 20 Oct 2020 09:55:34 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 73C33385782C; Tue, 20 Oct 2020 13:55:33 +0000 (GMT) Received: from rock.gnat.com (rock.gnat.com [205.232.38.15]) by sourceware.org (Postfix) with ESMTP id CAEFF3857C7B for ; Tue, 20 Oct 2020 13:55:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org CAEFF3857C7B Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=adacore.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=tromey@adacore.com Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 96C19117994; Tue, 20 Oct 2020 09:55:31 -0400 (EDT) X-Virus-Scanned: Debian amavisd-new at gnat.com Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id bUOpWie5KZ5r; Tue, 20 Oct 2020 09:55:31 -0400 (EDT) Received: from murgatroyd (75-166-102-113.hlrn.qwest.net [75.166.102.113]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by rock.gnat.com (Postfix) with ESMTPSA id 390E71177A7; Tue, 20 Oct 2020 09:55:31 -0400 (EDT) From: Tom Tromey To: Luis Machado Subject: Re: [PATCH] Don't inherit range-type signed-ness from underlying type References: <20201019193330.3242805-1-tromey@adacore.com> X-Attribution: Tom Date: Tue, 20 Oct 2020 07:55:30 -0600 In-Reply-To: (Luis Machado's message of "Mon, 19 Oct 2020 18:28:24 -0300") Message-ID: <87blgxknn1.fsf@tromey.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: gdb-patches@sourceware.org, Tom Tromey Errors-To: gdb-patches-bounces@sourceware.org Sender: "Gdb-patches" >> This passed testing -- but unfortunately, additional testing at >> AdaCore showed that this change was incorrect. GNAT, at least, can >> emit an unsigned range type whose underlying type is signed. Luis> Is this correct compiler behavior though? It sounds inconsistent. If Luis> the compiler wants an unsigned type for a range, intuitively it should Luis> use an unsigned base type, no? Good question. I'll update the comment in the patch with the answer. The test case shows the problem -- it has a type whose range is 0..65535 (inclusive), but whose underlying type is a signed integer. Also, the program requests that values of this range type be stored in 16 bits. This is fine because the range of values fits. However, if the type inherits the sign from the underlying type, if we fetch such a value, it will be incorrectly sign-extended. I do think it's the case, though, that if the underlying type is unsigned then the range type must be. We could consider adding that. Tom