This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: ABI change for ports with byte-aligned functions.
> Cc: gcc-patches@gcc.gnu.org
> From: Alexandre Oliva <aoliva@redhat.com>
> Organization: GCC Team, Red Hat
> Date: 04 May 2001 16:07:06 -0300
> User-Agent: Gnus/5.090002 (Oort Gnus v0.02) XEmacs/21.1 (Cuyahoga Valley)
>
> On May 4, 2001, Geoffrey Keating <geoffk@thief.cygnus.com> wrote:
>
> > + bit of P. When FUNCTION_BOUNDARY is less than 16 (and so it might
> > + happen that the function pointer might naturally have the low bit
> > + set), the type is instead
>
> > + struct {
> > + __P __pfn;
> > + ptrdiff_t __delta;
> > + char __vflag;
> > + };
>
> > + and __pfn is a pointer to a method when __vflag is zero.
>
> Err... A proposal was made to the C++ ABI committee to use the lowest
> bit of the first field, as implemented in
> http://gcc.gnu.org/ml/gcc-patches/2001-04/msg00498.html
>
> Is there any reason you didn't use that patch?
I was unaware of it. Feel free to correct my patch, I just wanted
something that would work.
> Note that depending on FUNCTION_BOUNDARY alone is not right: it may be
> equal to or greater than 2 * BITS_PER_UNIT for performance reasons,
> even when the processor doesn't really demand it, and someone may
> rightfully define member functions in assembly that are not aligned
> according to the best-performance requirements.
No, changing FUNCTION_BOUNDARY for performance reasons is wrong. The
compiler will optimise bit operations on function pointers assuming
that FUNCTION_BOUNDARY is correct, so any change to FUNCTION_BOUNDARY
is an ABI change even in C.
I forgot about BITS_PER_UNIT. I should fix that.
--
- Geoffrey Keating <geoffk@geoffk.org>