From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22240 invoked by alias); 22 Jul 2010 09:43:06 -0000 Received: (qmail 21318 invoked by uid 48); 22 Jul 2010 09:42:44 -0000 Date: Thu, 22 Jul 2010 09:43:00 -0000 Message-ID: <20100722094244.21317.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/msg02341.txt.bz2 ------- Comment #1 from nickc at redhat dot com 2010-07-22 09:42 ------- Hi Kazuhiro-san, This is not a bug, it is the expected behaviour. What is happening is that the return value from func() is being promoted to "signed int" (and not "unsigned int" as you might expect). Thus since the MOV.B instruction performs a sign extension it is a sufficient instruction for the load operation. Note - if you try using the result of calling func() then you will see a zero extension being performed. Eg: int bar (int a) { return a < func(); } results in: mov.L #_uA, r14 movu.B [r14], r14 cmp r1, r14 sclt.L r1 rts with inlining, or: push.l r7 mov.L r1, r7 bsr _func movu.B r1, r1 cmp r7, r1 sclt.L r1 rtsd #4, r7-r7 without. Cheers Nick Clifton PS. See section 6.3.1.1 of the ISO C99 standard for more information about this behaviour -- nickc at redhat dot com changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |nickc at redhat dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45000