On Mon, 2014-10-06 at 20:55 -0400, Jason Merrill wrote: > On 10/06/2014 08:50 PM, Siva Chandra wrote: > > On Sat, Oct 4, 2014 at 11:14 AM, Jason Merrill <ja...@redhat.com> wrote: > >> On 10/03/2014 05:41 PM, Siva Chandra wrote: > >>> > >>> I understand that knowing whether a copy-ctor or a d-tor has been > >>> explicitly defaulted is not sufficient to determine the parameter > >>> passing ABI. However, why is it not necessary? I could be wrong, but > >>> doesn't the example I have given show that it is necessary? > >> > >> An implicitly declared 'tor can also be trivial. > > > > But, the question is whether it is required to determine the parameter > > passing ABI. If there is no special marker to indicate that the user > > declared 'tor is explicitly defaulted, then GDB could (in the absence > > of other properties which make the 'tor non-trivial) incorrectly > > conclude that the the 'tor is user defined, and hence not-trivial. > > I've been thinking that we should just mark the 'tor as trivial or not > directly rather than hint at it. Does GDB have enough information to > determine triviality if we just add defaulted info?
To be honest my original patches for a deleted/defaulted markers on special member functions was really just meant to give the consumer a way to know why GCC produced a declaration in the first place. Which I still think is useful information for the consumer to have, but certainly not enough to solve the abi problem with inferior function calls Siva was seeing. Maybe GDB has enough information/smarts, but I don't think other consumers have. So an explicit "trivial/non-trivial" marker on special member functions seems like a good idea. But looking at the definition of trivial copy constructor and trivial destructor they do look more like class concepts instead of individual constructor/destructor concepts (since they rely on properties of other members and the base class). Currently GCC doesn't output declarations unless the user declares them. So an implicit copy constructor or destructor doesn't get a DWARF class member declaration. But I don't think a consumer can conclude just from that fact that the copy constructor or destructor is trivial. Nor can it asssume they are non-trivial just because they are are respresented in DWARF. So should we always output them and add a flag value to indicate (non-trivialness). Or should we add attributes on the class itself? Taking a step back and looking at the actual function that is causing the trouble because abi/calling convention seems unclear. Which makes me wonder if the issue isn't actually with the DWARF declaration of the function that has special calling conventions. I am slightly surprised the special return value passed in rule isn't expressed in the mangling of the function name (or is it?). So the calling convention needs to be interpreted from the DWARF representation. We already add a synthetic formal parameter for "this" if necessary to be passed in. Why don't we just add a similar synthetic "return" formal parameter if that is how the function is really being invoked? That seems like a more direct way to solve the inferior function call issue. Cheers, Mark
