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 E3A7C3858403 for ; Fri, 24 Sep 2021 11:33:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E3A7C3858403 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 40abb2dd-1d2b-11ec-8d7a-506b8dfa0e58; Fri, 24 Sep 2021 13:33:34 +0200 (CEST) Subject: Re: Can gcc.dg/torture/pr67828.c be an infinite loop? To: Andrew Pinski , Aldy Hernandez Cc: GCC Mailing List References: <88e1b98b-083b-4e2f-01ba-895dae16c58e@redhat.com> From: David Brown Message-ID: <1daf0828-8680-8367-9d82-fbe7d6b35f16@hesbynett.no> Date: Fri, 24 Sep 2021 13:33:34 +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: Content-Type: text/plain; charset=utf-8 Content-Language: en-GB Content-Transfer-Encoding: 7bit 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:33:37 -0000 On 24/09/2021 11:38, Andrew Pinski via Gcc wrote: > On Fri, Sep 24, 2021 at 2:35 AM Aldy Hernandez wrote: >> >> >> >> On 9/24/21 11:29 AM, Andrew Pinski wrote: >>> On Fri, Sep 24, 2021 at 1:05 AM Aldy Hernandez via Gcc wrote: >>>> >>> Huh about c>=0 being always true? the expression, "c++" is really c= >>> (short)(((int)c)+1). So it will definitely wrap over when c is >>> SHRT_MAX. >> >> I see. >> >> Is this only for C++ or does it affect C as well? > > This is standard C code; promotion rules; that is if a type is less > than int, it will be promoted to int if all of the values fit into > int; otherwise it will be promoted to unsigned int. > But remember that for some gcc targets (msp430, AVR, and others), int is 16-bit and the same size as short. The short still gets promoted to int, but it will not longer wrap as SHORT_MAX + 1 is an int overflow. (I've no idea if this is relevant to the code in question, or if that code is only used on specific targets where short is smaller than int.)