Re: RFA: xscale-elf -mstrict-prototypes

[Richard Earnshaw <rearnsha at arm dot com>]

> On Tue, 2004-03-02 at 20:29, Mark Mitchell wrote:
> > > I am trying to avoid the overhead of conditioning a shorter-than-int
> > > parameter in the callee.  
> > 
> > Yes -- but I believe that is exactly the case that will be fixed in 
> > AACPS.  I might be wrong, though.
> I looked at the AAPCS last week with this in mind.  I didn't see
> anything that would relate to conditioning of procedure parameters /
> arguments.  Nor did I see anything in the ATPCS.
> It's possible I missed it though.
> 

AAPCS section 5.5 rule B.2.  Since the caller is required to extend the 
value, there is clearly no need for the callee to do so.

Even the ATPCS (and the APCS before that) had a similar requirement, 
though expressed differently.  The fact that GCC has been overly 
conservative is a bug that I've long wanted to fix.

> > > 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.
> > 
> > We don't have to worry about that case, since, as you say, its invalid.
> OK.  I wasn't sure how conservative we should be.

GCC has promoted arguments in the caller now for so long, that I see no 
need to worry about backwards compatibility problems.

> 
> > I believe that GCC is doing the conditioning at both the caller and 
> > callee currently.  It should be necessary to do it on only one side or 
> > the other.  Therefore, I think that we should eliminate that 
> > duplication, rather than add -mstrict-prototypes.
> So you're suggesting that I reduce my patch to something like the
> following?
> config/arm/arm.c:
> -#define TARGET_PROMOTE_PROTOTYPES hook_bool_tree_true
> +#define TARGET_PROMOTE_PROTOTYPES hook_bool_tree_false
> 

Provided this doesn't also inhibit the caller-side promotion, yes.

R.