Date: Wed, 23 May 2012 19:34:33 +1000 (EST) From: Bruce Evans <brde@optusnet.com.au> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: mdf@FreeBSD.org, src-committers@FreeBSD.org, svn-src-all@FreeBSD.org, "David E. O'Brien" <obrien@FreeBSD.org>, Bruce Evans <brde@optusnet.com.au>, svn-src-head@FreeBSD.org Subject: Re: svn commit: r235797 - head/contrib/gcc Message-ID: <20120523193428.V902@besplex.bde.org> In-Reply-To: <D1A149E0-523C-4BBC-AE82-BFD1BEB7788F@xcllnt.net> References: <201205221818.q4MII7lk019626@svn.freebsd.org> <20120523050739.H3621@besplex.bde.org> <CAMBSHm-C7YdU0uPa7aJ6FxDWhZzQiD0_uTj=f1nhV2k5SZ5%2B_A@mail.gmail.com> <D1A149E0-523C-4BBC-AE82-BFD1BEB7788F@xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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 <brde@optusnet.com.au> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20120523193428.V902>