This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Why does casting a function generate a run-time abort?
On 18 Jun 2004, at 16.08, Richard Henderson wrote:
On Fri, Jun 18, 2004 at 03:53:04PM -0700, Ziemowit Laski wrote:
Because at least you know what you're calling, instead of having to
talk
back to the front-end du jour to find out.
We know what we're calling -- a method. It's the details of how
to find out exactly that method's address that's private to the
front end.
A front-end deciding on an address of a method? Doesn't the linker
usually
do this? :-)
Because you're NOT WRITING C. Because you're ALREADY outside the
semantics of the C language, and so ...
for it guarantees
that ObjC is as portable as the C language underneath it.
... this says that you CAN NOT do what you're trying to do.
Except that I _did_ do it, using a code fragment you described as
"overly complicated". :-)
No, you did NOT. You wrote something that looked like C, but
was not semantically valid C. Thus you did not write in C.
It was not strict standard-conforming C, I'll give you that. But it
definitely was GNU C (which, of course, the compiler we're both working
on supports). Of course, the original cast _was_ standard-conforming...
Do you really want to continue arguing about this?
No. :-)
You're not the
one that has to work on the optimizers, after all.
No, not usually, but the reason I started this thread is to find a way
to solve
the temp variable bloat that we're getting hit with in ObjC. And I
think I
found it. :-) In the future, if/when you implement your METHOD_EXPR
doomsday
machine, I'll happily take a look at it, but right now we really need
to reduce the ObjC code bloat we're seeing with gcc 3.5.
Thanks,
--Zem