From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from spam02.hesby.net (spam01.hesby.net [81.29.32.152]) by sourceware.org (Postfix) with ESMTP id 31F423858402 for ; Fri, 24 Sep 2021 11:30:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 31F423858402 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=hesbynett.no Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=hesbynett.no Received: from [192.168.0.63] (unknown [79.161.10.130]) by spam02.hesby.net (Halon) with ESMTPSA id ddbecf1d-1d2a-11ec-8d7a-506b8dfa0e58; Fri, 24 Sep 2021 13:30:48 +0200 (CEST) Subject: Re: Can gcc.dg/torture/pr67828.c be an infinite loop? To: Aldy Hernandez , Richard Biener Cc: GCC Mailing List References: <88e1b98b-083b-4e2f-01ba-895dae16c58e@redhat.com> <3d8e40f3-20e8-f265-85d8-d667aa65052a@redhat.com> From: David Brown Message-ID: <7e81cf0f-e173-cd54-6da7-f18bbe0833cd@hesbynett.no> Date: Fri, 24 Sep 2021 13:30:48 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <3d8e40f3-20e8-f265-85d8-d667aa65052a@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3032.6 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Sep 2021 11:30:53 -0000 On 24/09/2021 10:59, Aldy Hernandez via Gcc wrote: > > > On 9/24/21 10:08 AM, Richard Biener wrote: >> On Fri, Sep 24, 2021 at 10:04 AM Aldy Hernandez via Gcc >> wrote: >>> >>> Is this correct, or did I miss something? >> >> Yes, 'c' will wrap to negative SHORT_MIN and terminate the loop via >> the c>=0 test. > > Huh, so SHORT_MAX + 1 = SHORT_MIN?  I thought that was an overflow, and > therefore undefined. > C and C++ don't do arithmetic on "short" (or "char"). They are immediately promoted to "int" (or "unsigned int", as appropriate). So if short is smaller than int, the code behaviour is well defined (as Richard described below). If short is the same size as int (such as on the 16-bit mspgcc port of gcc), however, then SHORT_MAX + 1 /would/ be an overflow and the compiler can assume it does not happen - thus giving you an infinite loop. With more common 32-bit int and 16-bit short, the loop should execute 32768 times. (At least, that is my understanding.) > >> >> Mind c++ is really (short)(((int)c)++) and signed integer truncation >> is implementation >> defined. >> >> Richard. >> >>> Aldy >>> >> > >