https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92789
Bug ID: 92789
Summary: Non-obvious ?: behaviour with structurally equivalent
types
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rsandifo at gcc dot gnu.org
Target Milestone: ---
Target: aarch64*-*-*
As noted in https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00128.html
build_conditional_expr_1 uses same_type_p to check whether the "then"
and "else" types are the same. If they are, it uses the "then"
type for the result.
However, same_type_p uses structural equality when
TYPE_STRUCTURAL_EQUALITY_P is true. This means that we can treat
two distinct but equivalent types as "the same" and use the "then"
type for the result. For example:
#include <arm_neon.h>
typedef uint8_t gnu_uint8_t __attribute__ ((vector_size (16)));
void f(gnu_uint8_t x) {}
void g(uint8x16_t y) {}
correctly mangles f as _Z1fDv16_h and g as _Z1g12__Uint8x16_t. But:
void h1(decltype(*(int *)nullptr ? *(gnu_uint8_t *)nullptr : *(uint8x16_t
*)nullptr)) {}
void h2(decltype(*(int *)nullptr ? *(uint8x16_t *)nullptr : *(gnu_uint8_t
*)nullptr)) {}
mangles h1 as _Z2h1RDv16_h and h2 as _Z2h2R12__Uint8x16_t.
See https://gcc.gnu.org/ml/gcc-patches/2019-12/msg00173.html for
Jason's comments on how this should work.
