This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: RFA: xscale-elf -mstrict-prototypes
- From: James Lemke <jim at wasabisystems dot com>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: gcc-patches at gcc dot gnu dot org, rearnsha at arm dot com
- Date: Tue, 02 Mar 2004 11:29:27 -0500
- Subject: Re: RFA: xscale-elf -mstrict-prototypes
- References: <1077208368.11826.185.camel@mast.thelemkes.ca> <4039240E.5070109@codesourcery.com>
Sorry, schedules kept me from replying for a bit.
On Sun, 2004-02-22 at 16:50, Mark Mitchell wrote:
> James Lemke wrote:
>
> >Given this source (gcc/testsuite/arm-g4-1.c):
> >short int addhi3 (short int a, short int b) __attribute__ ((naked));
> >short int addhi3 (short int a, short int b)
> >{
> > return a + b + (short int)32;
> >}
> >
> >The assembler generated (xscale-elf-gcc -O2 -S) is rather poor:
> >
> I don't think we should add -mstrict-prototypes.
>
> This problem is mostly a consequence of the old ARM ABI, and I think
> will be fixed in the new ARM ABI.
I am trying to avoid the overhead of conditioning a shorter-than-int
parameter in the callee. But there is a problem when a call is made to
a function like above without a prototype, and with an argument too
large for the receiving parameter.
For example:
int
main (int argc, char *argv[])
{
return addhi3 (40000, -50000);
}
This call will pass out of range values to addhi3 which is incorrect but
may happen in existing code.
With -mstrict-prototypes addhi3 will not truncate and sign-extend the
values before use, so they will remain out of range. This may introduce
additional undesired behaviour, such as an exception that didn't occur
before.
Therefore, I added this functionality under control of an option.
> And, if we are going to add it, it should be a -f option and applicable
> to all architectures.
This may make sense, I haven't looked at the issue on other
architectures.
Jim.
--
James Lemke jim@wasabisystems.com Orillia, Ontario
http://www.wasabisystems.com