Re: Why does casting a function generate a run-time abort?

[Ziemowit Laski <zlaski at apple dot com>]

On 18 Jun 2004, at 18.41, Richard Henderson wrote:

> On Fri, Jun 18, 2004 at 06:01:10PM -0700, Ziemowit Laski wrote:
> > Since the standard does not define the semantics of the call,
> > we may as well let it through.  I believe that is standard-conforming.
>
> You're wrong.
>
> # 6.5.2.2:
> # 9 If the function is defined with a type that is not compatible with 
> the
> #   type (of the expression) pointed to by the expression that denotes 
> the
> #   called function, the behavior is undefined.

In other words, any behavior we choose for it is vacuously correct.  
Q.E.D. :-)

> > Just what exactly is wrong with the asm() trick I came up with?  I am,
> > of course, asking for technical arguments, not aesthetic ones.
>
> Technical argument?  How about needless creation of FUNCTION_DECLs.

Which you distinguish from "needful" FUNCTION_DECL creation (or, for 
that
matter, from the needless creation of your METHOD_EXPRs) how? :-)

> I'd have thought the aesthetic argument was good enough, however.

Hm... I can't really claim that I never consider aesthetics in my
hac^H^H^Hengineering activities, although technical considerations
always trump them, as they should.  I guess I'll just wait for your
METHOD_EXPR work, and then will decide which approach is more
disgusting. :-)

On an unrelated note, thanks for fixing the objc.dg/try-catch*.m 
DejaGNU failures.
I now only see two remaining failures, objc.dg/const-str[34].m.  
AFAICT, the
problem is that the inliner is creating... unnecessary temp variables, 
which
causes the string uniquing assumptions to be broken.  So it all comes 
back to
the inliner.  And yes, I now suepect that casting is somehow to blame 
as well. :-)

--Zem