From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 64270 invoked by alias); 1 Dec 2016 09:15:35 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 64225 invoked by uid 89); 1 Dec 2016 09:15:33 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.8 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=H*MI:sk:2016120 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 01 Dec 2016 09:15:32 +0000 Received: from int-mx10.intmail.prod.int.phx2.redhat.com (int-mx10.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A9653C04FF82; Thu, 1 Dec 2016 09:15:31 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-204-100.brq.redhat.com [10.40.204.100]) by int-mx10.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id uB19FTvX031557 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 1 Dec 2016 04:15:31 -0500 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id uB19FSJj004378; Thu, 1 Dec 2016 10:15:28 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id uB19FQMH004377; Thu, 1 Dec 2016 10:15:26 +0100 Date: Thu, 01 Dec 2016 09:15:00 -0000 From: Jakub Jelinek To: Martin Sebor Cc: Gcc Patch List Subject: Re: [PATCH] handle integer overflow/wrapping in printf directives (PR 78622) Message-ID: <20161201091526.GH3541@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <20161201072647.GF3541@tucnak.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161201072647.GF3541@tucnak.redhat.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-IsSubscribed: yes X-SW-Source: 2016-12/txt/msg00023.txt.bz2 On Thu, Dec 01, 2016 at 08:26:47AM +0100, Jakub Jelinek wrote: > Isn't this too simplistic? I mean, if you have say dirtype of signed char > and argmin say 4096 + 32 and argmax say 4096 + 64, (signed char) arg > has range 32, 64, while I think your routine will yield -128, 127 (well, > 0 as min and -128 as max as that is what you return for signed type). > > Can't you subtract argmax - argmin (best just in wide_int, no need to build > trees), and use what you have just for the case where that number doesn't > fit into the narrower precision, otherwise if argmin - (dirtype) argmin > == argmax - (dirtype) argmax, just use (dirtype) argmin and (dirtype) argmax > as the range, and in case that it crosses a boundary figure if you can do > anything than the above? Guess all cases of signed/unsigned dirtype and/or > argtype need to be considered. Richard noted that you could have a look at CONVERT_EXPR_CODE_P handling in extract_range_from_unary_expr. I think it is the || (vr0.type == VR_RANGE && integer_zerop (int_const_binop (RSHIFT_EXPR, int_const_binop (MINUS_EXPR, vr0.max, vr0.min), size_int (TYPE_PRECISION (outer_type))))))) part that is important here for the narrowing conversion. Jakub