From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21469 invoked by alias); 19 Jan 2016 15:25:43 -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 21455 invoked by uid 89); 19 Jan 2016 15:25:42 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=Fortune, Indeed X-HELO: mailapp01.imgtec.com Received: from Unknown (HELO mailapp01.imgtec.com) (195.59.15.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 19 Jan 2016 15:25:40 +0000 Received: from HHMAIL01.hh.imgtec.org (unknown [10.100.10.19]) by Websense Email Security Gateway with ESMTPS id 83CEDB30C5561; Tue, 19 Jan 2016 15:25:34 +0000 (GMT) Received: from [10.100.200.15] (10.100.200.15) by HHMAIL01.hh.imgtec.org (10.100.10.21) with Microsoft SMTP Server id 14.3.235.1; Tue, 19 Jan 2016 15:25:37 +0000 Date: Tue, 19 Jan 2016 15:25:00 -0000 From: "Maciej W. Rozycki" To: Matthew Fortune CC: Steve Ellcey , "gcc-patches@gcc.gnu.org" , "clm@codesourcery.com" Subject: RE: [Patch, MIPS] Remove definition of TARGET_PROMOTE_PROTOTYPES In-Reply-To: <6D39441BF12EF246A7ABCE6654B0235361D03859@LEMAIL01.le.imgtec.org> Message-ID: References: <9003b977-ba2d-4c32-9078-af164c7305c8@BAMAIL02.ba.imgtec.org> <1449875085.4788.106.camel@ubuntu-sellcey> <6D39441BF12EF246A7ABCE6654B0235361D03859@LEMAIL01.le.imgtec.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2016-01/txt/msg01432.txt.bz2 On Sat, 12 Dec 2015, Matthew Fortune wrote: > > > * config/mips/mips.c (mips_promote_function_mode): New function. > > > (TARGET_PROMOTE_FUNCTION_MODE): Define as above function. > > > (TARGET_PROMOTE_PROTOTYPES): Remove. > > I'm OK with this change on the basis that MIPS has been providing stronger > guarantees than required by the various standards. I.e. after this change > MIPS will have undefined behaviour for a mismatch in types between a > call to an un-prototyped function and its definition: Indeed this is exactly what the current ISO C language standard mandates -- if an unprototyped call is made to a function whose definition has been prototyped and the types of the arguments after promotion are incompatible with the types of the respective parameters, then behaviour is undefined. > extern void foo(); > > void caller(int a) > { > foo(a); > } > > -- > > void foo(short a) > { > // the value of 'a' can be out of range of a short because the caller > // did not get the right type for the argument. > } Which is exactly the case with the piece of code you quoted. Behaviour of this code would be defined if the `a' parameter of `foo' was of the `int' type. See Section 6.5.2.2 "Function calls", clause 6, for details. Maciej