On Fri, Jan 25, 2019 at 10:55:55AM -0600, Tim Song wrote: > On Thu, Jan 24, 2019 at 4:14 PM Jason Merrill <ja...@redhat.com> wrote: > > > > On 1/24/19 2:16 PM, Marek Polacek wrote: > > > This test ICEs since r159006 which added > > > > > > type = ENUM_UNDERLYING_TYPE (type); > > > > > > to type_promotes_to. In this test ENUM_UNDERLYING_TYPE is null because we > > > haven't yet parsed '}' of the enum and the underlying type isn't fixed, > > > and > > > so checking TYPE_UNSIGNED crashed. > > > > > > I've added some checks to the test to see if the types seem to be OK; > > > clang++ > > > agrees. > > > > > > Bootstrapped/regtested on x86_64-linux, ok for trunk/8/7? > > > > > > 2019-01-24 Marek Polacek <pola...@redhat.com> > > > > > > PR c++/89024 - ICE with incomplete enum type. > > > * cvt.c (type_promotes_to): Check if prom is non-null. > > > > 9.6/6: An enumeration whose underlying type is not fixed is an > > incomplete type from its point of declaration to immediately after the > > closing } of its enum-specifier, at which point it becomes a complete type. > > > > So the conversion is ill-formed. > > > > Jason > > But the conversion in the example (in > decltype(__test_aux<_To1>(declval<_From1>()))) > is in a SFINAE context, so shouldn't it gracefully fall back to the > `(...)` overload?
I think so, and clang++ and icc also compile the testcase fine (and we used to too, before r159006). Marek
