This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: i386 stack missalignment on main
- To: amylaar at redhat dot com
- Subject: Re: i386 stack missalignment on main
- From: mike stump <mrs at windriver dot com>
- Date: Tue, 31 Jul 2001 11:51:13 -0700 (PDT)
- Cc: aj at suse dot de, aoliva at redhat dot com, gcc-patches at gcc dot gnu dot org, gcc at gcc dot gnu dot org, jh at suse dot cz, rth at redhat dot com
> From: Joern Rennecke <amylaar@redhat.com>
> To: mrs@windriver.com (mike stump)
> Date: Tue, 31 Jul 2001 19:37:50 +0100 (BST)
> Cc: amylaar@redhat.com, aoliva@redhat.com, aj@suse.de, gcc-patches@gcc.gnu.org,
> gcc@gcc.gnu.org, jh@suse.cz, rth@redhat.com
> > I didn't exactly follow this, but if you mean what I think you mean,
> > this doesn't work for C++, sorry. (Or maybe someone has fixed the
> > basic problem, I might be out-of-date).
> I mean a possibly overlapping binary copy of the named arguments.
> On the x86, this could look something like this:
> before move: after move:
> unnamed arguments unnamed arguments
> ------------------ -----------------
> padding
> named arguments -----------------
> named arguemnts
> ------------------
> return address
> saved stack ptr -----------------
> return address
> saved stack ptr
> Is that a problem with C++ ? If so, why?
The backend doesn't know how to copy C++ objects. You cannot bcopy
them, a user defined copy constructor may need to be called. The
backend didn't (doesn't) know how to do this. The copying is
permitted by the rules, but not calling the dtor for the original
copy, and not calling the user defined copy ctor to make the copy
isn't permitted by the rules of the language. Also, anytime the
backend would want to do this, the permission would need to be
obtained from the language standard.
A copy is when when the address of the object changes.