gcl-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gcl-devel] Re: (object (*)()) vs (long (*)())


From: Richard Zidlicky
Subject: [Gcl-devel] Re: (object (*)()) vs (long (*)())
Date: Wed, 31 Jul 2002 13:44:41 +0200
User-agent: Mutt/1.2.5i

cc'd linux-m68k as this seems more appropriate for ABI related
questions.

On Tue, Jul 30, 2002 at 01:42:17PM -0400, Camm Maguire wrote:
> Greetings!  I'm maintaining gcl, which, fortunately or not, relies on
> being able to cast function results back and forth from long to void
> *. 

this should not be a problem.

 (The 'object' above is a pointer to a union).  This works
> everywhere except on m68k, where I can stop at a certain point in a
> debugger, and get different results for (*f)(a,b), and 
> (object)(*(long (*)())f)(a,b), where f is declared object (*f)().  

Not quites sure form your code but I guess you hit the old function
return value thing.. what you are casting is not the function result
but the function declaration (changing result type in this case).
Could'nt you use the proper union-element instead of this cast?

Function return values must be declared (and used) properly on m68k, 
pointer values are returned in reg a0, ints d0. I would be surprised
if m68k was the only arch that gets broken by this..

> I hate to have to work around this on all architectures just because
> of m68k, as was apparently done in earlier gcl versions.  Is there a
> compiler switch, or function prototype declaration, or some other
> means whereby I can get the same results from the above two calls on
> this platform?

expecting 'long' result from pointer-returning functions would work
as long as you don't use -fomit-frame-pointer but is a horrible hack.

I assume some special gcc function attribute like 'return_result_in_d0'
could be implemented. Otoh why is gcl doing such strange things?

Richard



reply via email to

[Prev in Thread] Current Thread [Next in Thread]