This is the mail archive of the
mailing list for the GCC project.
Re: gcc 3.0.1 & C++ ABI issues
- To: nathan at cs dot bris dot ac dot uk
- Subject: Re: gcc 3.0.1 & C++ ABI issues
- From: Jason Merrill <jason_merrill at redhat dot com>
- Date: 08 Aug 2001 11:08:58 +0100
- Cc: Joe Buck <jbuck at synopsys dot com>, Nathan Sidwell <nathan at codesourcery dot com>, Mark Mitchell <mark at codesourcery dot com>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>
- References: <200108080104.SAA16048@atrus.synopsys.com><3B70FFF6.firstname.lastname@example.org>
>>>>> "Nathan" == Nathan Sidwell <email@example.com> writes:
> Joe Buck wrote:
>> Our STL implementation has lots of code where a dummy argument whose type
>> is an empty class is used to specialize templates. Are we getting
>> pessimization because of this?
No, but thanks for checking.
> Jason's suggested fix to the copy ctor case, does not break the RVO.
> Specifically, where A is an empty class,
> return A ();
> will construct an A directly into the return object area.
> What I presume you mean, Joe, is (where T1 == random type, A = empty)
> void Foo (T1, A);
> Foo (obj1, A ())
Yes (where A is bidirectional_iterator_tag or some such). This is also
(copy-)initialization, and should be handled exactly like the return case
> The ABI specifies (that provided A is sufficiently POD like),
> passing a value parameter of size 1 where A goes. See the ABI doc
> 3.3 I think. G++ will construct a temporary A (which will be a NOP for
> a Pod-like A), and then constructs the (uninitialized) parameter.
The temporary should be elided into the parameter even for non-POD A. But
all the STL empty classes are PODs, so it doesn't really matter.
> So it should end up the same amount of work as if Foo was
> void Foo (T1, char);
> Foo (obj1, 0);
Or less, since we don't actually have to initialize the parameter.
> IIR, we did try passing no parameter for these things, but for some
> reason it was very difficult to do so. Mark knows why, more than me.
IIRC, Mark felt that the added complexity would not be worth the possible
gain. We don't actually have to pass the parameter, we just have to assign
it a location. Removing it entirely would require changes to FUNCTION_ARG