public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
From: "nickc at redhat dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/45000] RX signed extened unsigned char or short return value.
Date: Wed, 28 Jul 2010 14:05:00 -0000	[thread overview]
Message-ID: <20100728140507.1567.qmail@sourceware.org> (raw)
In-Reply-To: <bug-45000-19023@http.gcc.gnu.org/bugzilla/>



------- 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 <Matt.Newsome@renesas.com> at
Renesas who is also concerned with this particular problem.

Cheers
  Nick


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45000


  parent reply	other threads:[~2010-07-28 14:05 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-07-20  9:07 [Bug target/45000] New: " kazuhiro dot inaoka dot ud at renesas dot com
2010-07-22  9:43 ` [Bug target/45000] " nickc at redhat dot com
2010-07-28  7:19 ` kazuhiro dot inaoka dot ud at renesas dot com
2010-07-28 13:55 ` nickc at redhat dot com
2010-07-28 14:05 ` nickc at redhat dot com [this message]
2010-08-03  9:33 ` kazuhiro dot inaoka dot ud at renesas dot com

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20100728140507.1567.qmail@sourceware.org \
    --to=gcc-bugzilla@gcc.gnu.org \
    --cc=gcc-bugs@gcc.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).