This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug tree-optimization/16115] [3.5 regression] double-destruction problem with argument passing via temporary (breaks auto_ptr)


------- Additional Comments From mmitchel at gcc dot gnu dot org  2004-07-06 07:23 -------
This patch is incorrect, on several levels.

First, it changes the type of the PARM_DECL to be different from the type that
C++ assigns that declaration.  That is incorrect; the C++ front end's assignment
of types should match the language.  As we've discussed previously, for example,
it's a bug that we have expressions with REFERENCE_TYPE; the standard says that
no expressions have that type.  (Declarations can, of course, have
REFERENCE_TYPE -- but these parameters do not.)  We should be trying to minimize
the extent to which ABI details appear in the front end.

Furthermore, this test case:

  template <typename T>
  struct S {
    ~S();
  };
                                                                                
  struct T {
    T(S<int>);
                                                                                
    S<int> s_;
  };
                                                                                
  T::T(S<int> s) : s_(s) {
  }

now ICEs the compiler on (at least) powerpc-apple-darwin7.4.0 due to some
problem with cloned functions.

Also, this change is potentially pessimizing code in that it will no longer be
obvious to the optimizers that the static type of the parameter must in fact be
the declared type.  So, we may not be able to resolve virtual function invoked
on the parameter.

Finally, if we were going to make this change in the front end, the right place
would be in grokdeclarator (where the PARM_DECL is created) rather than in
grokparms, where we must then wastefully create a second PARM_DECL.

If the optimizers needs these parameters to have reference type, then that
change needs to happen after the front end processing is complete, in the course
of generating code for this function.  I'm not sure what the tradeoffs are vis a
vis (re)teaching the optimizers about TREE_ADDRESSABLE on types.

I've reverted this patch.  

I'll be happy to help with an alternate solution in whatever way I can.

(Parenthetically, I'm not sure the call1.C test is checking anything useful,
since it does not fail even after I reverted the patch.)

-- 
           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16115


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]