From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2797 invoked by alias); 28 Jul 2010 14:05:24 -0000 Received: (qmail 1568 invoked by uid 48); 28 Jul 2010 14:05:07 -0000 Date: Wed, 28 Jul 2010 14:05:00 -0000 Message-ID: <20100728140507.1567.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug target/45000] RX signed extened unsigned char or short return value. In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "nickc at redhat dot com" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2010-07/txt/msg03092.txt.bz2 ------- Comment #4 from nickc at redhat dot com 2010-07-28 14:05 ------- Hi Kazuhiro-san, > If the func() is external function, output code is the following. > bsr _func > mouv.B r1, r1 > If the return value is zero exteneded, > "movu.B r1, r1" code can be removed. Not really. The problem is that the compiler cannot guarantee the behaviour of the func function, since it is external to the compilation unit. It might not actually return an unsigned byte value. > Is the explanation san integer conversion rank? I am not sure what you mean here. The simplest thing that I can say is that the code produced by gcc is what is required by the ISO C99 standard. If the RX ABI requires a different behaviour then it is not compatible with the ISO C99 standard. That said I have uploaded a patch which offers a compromise. It makes functions which return small unsigned values insert a zero-extend instruction into their epilogues. This is less efficient than the change that you were requesting (using MOVU.B to load the value from memory in the first place), but it does mean that the code produced by gcc will work both with other code produced by gcc and with code produced by Renesas's own compiler. May I also suggest that you contact Matt Newsome at Renesas who is also concerned with this particular problem. Cheers Nick -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45000