* [Bug target/45000] RX signed extened unsigned char or short return value.
2010-07-20 9:07 [Bug target/45000] New: RX signed extened unsigned char or short return value kazuhiro dot inaoka dot ud at renesas dot com
@ 2010-07-22 9:43 ` nickc at redhat dot com
2010-07-28 7:19 ` kazuhiro dot inaoka dot ud at renesas dot com
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: nickc at redhat dot com @ 2010-07-22 9:43 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug target/45000] RX signed extened unsigned char or short return value.
2010-07-20 9:07 [Bug target/45000] New: RX signed extened unsigned char or short return value 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
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: kazuhiro dot inaoka dot ud at renesas dot com @ 2010-07-28 7:19 UTC (permalink / raw)
To: gcc-bugs
------- Comment #2 from kazuhiro dot inaoka dot ud at renesas dot com 2010-07-28 07:19 -------
(In reply to comment #1)
Hi Nick
Thank you for your reply.
Your example is OK.
But I'm not clear.
> extension being performed. Eg:
> int bar (int a) { return a < func(); }
If the func() is external function, output code is the following.
_bar:
push.l r7
mov.L r1, r7
bsr _func
mouv.B r1, r1
cmp r7, r1
scgt.L r1
rtsd #4, r7-r7
If the return value is zero exteneded,
"movu.B r1, r1" code can be removed.
Is the explanation san integer conversion rank?
> PS. See section 6.3.1.1 of the ISO C99 standard for more information about this
> behaviour
I think that my request is depend on rx cpu target like sh, m32r not m32c.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45000
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug target/45000] RX signed extened unsigned char or short return value.
2010-07-20 9:07 [Bug target/45000] New: RX signed extened unsigned char or short return value 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
2010-08-03 9:33 ` kazuhiro dot inaoka dot ud at renesas dot com
4 siblings, 0 replies; 6+ messages in thread
From: nickc at redhat dot com @ 2010-07-28 13:55 UTC (permalink / raw)
To: gcc-bugs
------- Comment #3 from nickc at redhat dot com 2010-07-28 13:55 -------
Created an attachment (id=21338)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=21338&action=view)
Force functions that return small unsigned values to use zero-extension
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45000
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug target/45000] RX signed extened unsigned char or short return value.
2010-07-20 9:07 [Bug target/45000] New: RX signed extened unsigned char or short return value kazuhiro dot inaoka dot ud at renesas dot com
` (2 preceding siblings ...)
2010-07-28 13:55 ` nickc at redhat dot com
@ 2010-07-28 14:05 ` nickc at redhat dot com
2010-08-03 9:33 ` kazuhiro dot inaoka dot ud at renesas dot com
4 siblings, 0 replies; 6+ messages in thread
From: nickc at redhat dot com @ 2010-07-28 14:05 UTC (permalink / raw)
To: gcc-bugs
------- 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
^ permalink raw reply [flat|nested] 6+ messages in thread
* [Bug target/45000] RX signed extened unsigned char or short return value.
2010-07-20 9:07 [Bug target/45000] New: RX signed extened unsigned char or short return value kazuhiro dot inaoka dot ud at renesas dot com
` (3 preceding siblings ...)
2010-07-28 14:05 ` nickc at redhat dot com
@ 2010-08-03 9:33 ` kazuhiro dot inaoka dot ud at renesas dot com
4 siblings, 0 replies; 6+ messages in thread
From: kazuhiro dot inaoka dot ud at renesas dot com @ 2010-08-03 9:33 UTC (permalink / raw)
To: gcc-bugs
------- Comment #5 from kazuhiro dot inaoka dot ud at renesas dot com 2010-08-03 09:32 -------
(In reply to comment #4)
Hi Nick,
My request seems to depend on Renesas callee/caller-extension spec.
> May I also suggest that you contact Matt Newsome <Matt.Newsome@renesas.com> at
> Renesas who is also concerned with this particular problem.
OK.
Please close this ticket.
Best Regards,
Kazuhiro Inaoka
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45000
^ permalink raw reply [flat|nested] 6+ messages in thread