Fix conversions for built-in operator overloading candidates.
authorJason Merrill <jason@redhat.com>
Tue, 5 Nov 2019 23:53:53 +0000 (18:53 -0500)
committerJason Merrill <jason@gcc.gnu.org>
Tue, 5 Nov 2019 23:53:53 +0000 (18:53 -0500)
commitb63566a4045e9cc27f739c89f863dbfb9dbe7860
tree58847b80e23df24201c3f3e8327814203bd625f8
parent6fda5f4981f1d249813c124576b037b12f6e8a61
Fix conversions for built-in operator overloading candidates.

While working on C++20 operator<=>, I noticed that build_new_op_1 was doing
too much conversion when a built-in candidate was selected; the standard
says it should only perform user-defined conversions, and then leave the
normal operator semantics to handle any standard conversions.  This is
important for operator<=> because a comparison of two different unscoped
enums is ill-formed; if we promote the enums to int here, cp_build_binary_op
never gets to see the original operand types, so we can't give the error.

I'm also disabling -Wmaybe-uninitialized for expmed.c to avoid the bootstrap
failure from the last time I applied this patch.

* call.c (build_new_op_1): Don't apply any standard conversions to
the operands of a built-in operator.  Don't suppress conversions in
cp_build_unary_op.
* typeck.c (cp_build_unary_op): Do integral promotions for enums.

PR tree-optimization/91825
* expmed.c: Reduce -Wmaybe-uninitialized to warning.

From-SVN: r277864
gcc/ChangeLog
gcc/cp/ChangeLog
gcc/cp/call.c
gcc/cp/typeck.c
gcc/expmed.c