[PR88146] avoid diagnostics diffs if cdtor_returns_this
authorAlexandre Oliva <aoliva@redhat.com>
Thu, 17 Jan 2019 04:49:55 +0000 (04:49 +0000)
committerAlexandre Oliva <aoliva@gcc.gnu.org>
Thu, 17 Jan 2019 04:49:55 +0000 (04:49 +0000)
commitb25a37564938313a6deed3b6518d03552431c160
tree9b87c42a315e4470058f30f1c2a4753a656f98a1
parentb0dd8f37fa8a1c4d792513809605d8d715700f12
[PR88146] avoid diagnostics diffs if cdtor_returns_this

Diagnostics for testsuite/g++.dg/cpp0x/inh-ctor32.C varied across
platforms.  Specifically, on ARM, the diagnostics within the subtest
derived_ctor::inherited_derived_ctor::constexpr_noninherited_ctor did
not match those displayed on other platforms, and the test failed.

The difference seemed to have to do with locations assigned to ctors,
but it was more subtle: on ARM, the instantiation of bor's template
ctor was nested within the instantiation of bar's template ctor
inherited from bor.  The reason turned out to be related with the
internal return type of ctors: arm_cxx_cdtor_returns_this is enabled
for because of AAPCS, while cxx.cdtor_returns_this is disabled on most
other platforms.  While convert_to_void returns early with a VOID
expr, the non-VOID return type of the base ctor CALL_EXPR causes
convert_to_void to inspect the called decl for nodiscard attributes:
maybe_warn_nodiscard -> cp_get_fndecl_from_callee ->
maybe_constant_init -> cxx_eval_outermost_constant_expr ->
instantiate_constexpr_fns -> nested instantiation.

The internal return type assigned to a cdtor should not affect
instantiation (constexpr or template) decisions, IMHO.  We know it
affects diagnostics, but I have a hunch this might bring deeper issues
with it, so I've arranged for the CALL_EXPR handler in convert_to_void
to disregard cdtors, regardless of the ABI.

for  gcc/cp/ChangeLog

PR c++/88146
* cvt.c (convert_to_void): Handle all cdtor calls as if
returning void.

From-SVN: r268004
gcc/cp/ChangeLog
gcc/cp/cvt.c