PATCH: PR target/34001: Incorrect x86 fastcall behavior

[Jan Hubicka]

> On Nov 27, 2007 3:41 AM, H.J. Lu <hjl@lucon.org> wrote:
> 
> > > It depends on how you see it. To me, the current behavior is binary
> > > incompatible with MS compilers, for which this feature is designed
> > > for. My patch makes it binary incompatible with older gcc, but
> > > makes the new gcc binary compatible with all assembly codes and
> > > object files which conform to gcc document as well as MS compilers.
> > >
> >
> > We have changed the i386 fastcall abi between gcc 3.4 and gcc 4.0:
> >
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34001#c7
> >
> > I think we should fix it for gcc 4.3. Jan, Uros, can you take a look
> > at it?
> 
> Jan is an expert for ABI issues, so IMO he should have the last word.

I was participating in the x86-64 ABI decisions so I can give some
insight there, but i386 well predates me :)

My understanding is that fastcall was invented for compatibility with
"standard" conventions used by MS and Watcom compilers, so we should
follow what they do (ie not pass aggregates in registers) more if it
actually is documented in our texinfo.

I don't like much the idea of changing behaviour for Windows targets
only, it seems like good trap for code trying to be portable across
both.  So I personally would vote for changing default behaviour and
documenting it in NEWS document as suggested.

I would not expect much fallout - it is uncommon to pass little
aggregates to assembly code and using fastcall in library API would be
quite silly.

Honza
> 
> Uros.