From owner-svn-src-all@FreeBSD.ORG Wed May 23 09:34:38 2012 Return-Path: Delivered-To: svn-src-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id C3D9D1065673; Wed, 23 May 2012 09:34:38 +0000 (UTC) (envelope-from brde@optusnet.com.au) Received: from mail08.syd.optusnet.com.au (mail08.syd.optusnet.com.au [211.29.132.189]) by mx1.freebsd.org (Postfix) with ESMTP id 5576E8FC21; Wed, 23 May 2012 09:34:38 +0000 (UTC) Received: from c122-106-171-232.carlnfd1.nsw.optusnet.com.au (c122-106-171-232.carlnfd1.nsw.optusnet.com.au [122.106.171.232]) by mail08.syd.optusnet.com.au (8.13.1/8.13.1) with ESMTP id q4N9YX1n008435 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 23 May 2012 19:34:35 +1000 Date: Wed, 23 May 2012 19:34:33 +1000 (EST) From: Bruce Evans X-X-Sender: bde@besplex.bde.org To: Marcel Moolenaar In-Reply-To: Message-ID: <20120523193428.V902@besplex.bde.org> References: <201205221818.q4MII7lk019626@svn.freebsd.org> <20120523050739.H3621@besplex.bde.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed Cc: mdf@FreeBSD.org, src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, "David E. O'Brien" , Bruce Evans , svn-src-head@FreeBSD.org Subject: Re: svn commit: r235797 - head/contrib/gcc X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 May 2012 09:34:38 -0000 On Tue, 22 May 2012, Marcel Moolenaar wrote: > On May 22, 2012, at 2:07 PM, mdf@FreeBSD.org wrote: > >> On Tue, May 22, 2012 at 1:05 PM, Bruce Evans wrote: >>> On Tue, 22 May 2012, David E. O'Brien wrote: >>> >>>> Log: >>>> Do not incorrectly warn when printing a quad_t using "%qd" on 64-bit >>>> platforms. >>> >>> I think I like this, since it is technically correct, and will find a >>> different set of type mismatches. >> >> We run with the following at Isilon, which is somewhat bogus because >> it allows a bit of sloppiness in types, but is also terribly >> convenient since it means no casting on printf arguments is needed: Without casts, the code will be unportable (sideways and future). >> --- contrib/gcc/c-format.c 2012-05-22 14:08:23.538266746 -0700 >> +++ /data/sb/head/src/contrib/gcc/c-format.c 2012-05-16 >> 12:59:40.937016702 -0700 >> @@ -2298,10 +2570,20 @@ check_format_types (format_wanted_type * >> equivalent but the above test won't consider them equivalent. */ >> if (wanted_type == char_type_node >> && (!pedantic || i < 2) >> && char_type_flag) >> continue; >> + >> + /* Isilon: FreeBSD defines int64_t (and others) as one type (e.g. long >> + long) on i386 and another type (e.g. long) on amd64. This prevents >> + the use of a common format specifier. Treat equal sized integer types >> + as equivalent. */ >> + if (TREE_CODE (wanted_type) == INTEGER_TYPE >> + && TREE_CODE (cur_type) == INTEGER_TYPE >> + && int_size_in_bytes (wanted_type) == int_size_in_bytes (cur_type)) >> + continue; >> + >> /* Now we have a type mismatch. */ >> format_type_warning (types->name, format_start, format_length, >> wanted_type, types->pointer_count, >> types->wanted_type_name, orig_cur_type, arg_num); >> } >> >> >> If there's no objections, I (or David or anyone else) can commit to >> the FreeBSD repository. > > I think such would make support for external (i.e. non-FreeBSD) toolchains > even more problematic. Our format extensions are a big hurdle already. I > think we should not tweak the compiler. I certainly object. It breaks the warning, without even an option to control this. The current checking gives some chance of detecting type mismatches in printf formats without compiling all on arches. It is only for some 64-bit types and formats that the warnings don't correspond to runtime bugs on any currently supported arch. This is because 64 bits is the largest integer size on all supported arch. All of %ll, %q and %j are specified to have >= 64 bits and limited by this, so they have precisely 64 bits and there are no runtime incompatibilities. However, %l doesn't give 64 bits on 32-bit arches, and the compile time warning for using %l to print an int64_t value on a 64-bit system is useful on currently supported arches for preventing unportabilty to 32-bit systems, although %l is correct for this on 64 bit systems. Bruce