Greetings, and thanks for your *very helpful* reply! OK, now it is clear to me what is going on. I calling all functions through a variable declared to return a pointer, and some functions are returning a long.
I can fix the instances in the existing code fairly easily, but the issue is that the lisp compiler produces C code using these interchangeable declarations. At some point, I need to either have all compiled functions return the same union and use the existing function link helper functions (in funlink.c, et.al.), or to duplicate these functions to handle function variables returning long and modify the compiler to use these in the correct instances instead. As always, the implementation is much easier than the conception of the proper solution. Comments most welcome. As a very ugly temporary hack, I suppose I can define a macro specific to m68k which casts the function variable to long (*), and not use -fomit-frame-pointer, to be able to retrieve correct results from functions returning both long and pointer in actuality. Hate to do it, but its definitely the quickest way to restore the m68k build. Alternatively, I could leave everything the way it is if I could insert assembly copying the long destination register to the pointer destination register at each function close, but this does not sound likely. Take care, Richard Zidlicky <[EMAIL PROTECTED]> writes: > On Wed, Jul 31, 2002 at 02:51:25PM +0200, Andreas Schwab wrote: > > > |> 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.. > > > > Actually, this should not be a problem, because functions returning a > > pointer put the return value in both registers, to support broken > > programs. > > it is still possible to run into trouble by scrweing it up the other > way round: write a function that returns int and call it with a cast > to a pointer-returning function. > The compiler must expect the return value in a0 but int-returning > functions don't do that. > Broken beyond imagination but I have seen software doing this. > > > |> 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 don't think that -fomit-frame-pointer has any influence on this, but if > > it does, then only by chance. > > it has, the code to generate the extra a0->d0 move is in > FUNCTION_EXTRA_EPILOGUE which gets omitted with -fomit-frame-pointer > > Richard > > _______________________________________________ > Gcl-devel mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/gcl-devel > > -- Camm Maguire [EMAIL PROTECTED] ========================================================================== "The earth is but one country, and mankind its citizens." -- Baha'u'llah
