* C++ PATCH for c++/89024 - ICE with incomplete enum type @ 2019-01-24 19:19 Marek Polacek 2019-01-24 22:17 ` Jason Merrill 0 siblings, 1 reply; 12+ messages in thread From: Marek Polacek @ 2019-01-24 19:19 UTC (permalink / raw) To: Jason Merrill, GCC Patches 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 <polacek@redhat.com> PR c++/89024 - ICE with incomplete enum type. * cvt.c (type_promotes_to): Check if prom is non-null. * g++.dg/cpp0x/enum37.C: New test. diff --git gcc/cp/cvt.c gcc/cp/cvt.c index 82a44f353c7..665e75dd84b 100644 --- gcc/cp/cvt.c +++ gcc/cp/cvt.c @@ -1913,7 +1913,8 @@ type_promotes_to (tree type) int precision = MAX (TYPE_PRECISION (type), TYPE_PRECISION (integer_type_node)); tree totype = c_common_type_for_size (precision, 0); - if (TYPE_UNSIGNED (prom) + if (prom + && TYPE_UNSIGNED (prom) && ! int_fits_type_p (TYPE_MAX_VALUE (prom), totype)) prom = c_common_type_for_size (precision, 1); else diff --git gcc/testsuite/g++.dg/cpp0x/enum37.C gcc/testsuite/g++.dg/cpp0x/enum37.C new file mode 100644 index 00000000000..eae435c2591 --- /dev/null +++ gcc/testsuite/g++.dg/cpp0x/enum37.C @@ -0,0 +1,24 @@ +// PR c++/89024 +// { dg-do run { target c++11 } } + +template <class T, class U> struct same; +template <class T> struct same<T,T> {}; + +template<class T> T&& declval(); + +template<typename _To1> +void __test_aux(_To1); + +template<typename _From1, typename _To1, + typename = decltype(__test_aux<_To1>(declval<_From1>()))> +char __test(int); + +template<typename, typename> +int __test(...); + +enum E { + x = decltype(__test<E, int>(0))(0) +}; + +same<E,decltype(x)> s; +same<unsigned int,__underlying_type(E)> s2; ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: C++ PATCH for c++/89024 - ICE with incomplete enum type 2019-01-24 19:19 C++ PATCH for c++/89024 - ICE with incomplete enum type Marek Polacek @ 2019-01-24 22:17 ` Jason Merrill 2019-01-25 17:00 ` Tim Song 0 siblings, 1 reply; 12+ messages in thread From: Jason Merrill @ 2019-01-24 22:17 UTC (permalink / raw) To: Marek Polacek, GCC Patches 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 <polacek@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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: C++ PATCH for c++/89024 - ICE with incomplete enum type 2019-01-24 22:17 ` Jason Merrill @ 2019-01-25 17:00 ` Tim Song 2019-01-25 17:13 ` Marek Polacek 0 siblings, 1 reply; 12+ messages in thread From: Tim Song @ 2019-01-25 17:00 UTC (permalink / raw) To: Jason Merrill; +Cc: Marek Polacek, GCC Patches On Thu, Jan 24, 2019 at 4:14 PM Jason Merrill <jason@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 <polacek@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? ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: C++ PATCH for c++/89024 - ICE with incomplete enum type 2019-01-25 17:00 ` Tim Song @ 2019-01-25 17:13 ` Marek Polacek 2019-01-25 17:16 ` Jason Merrill 0 siblings, 1 reply; 12+ messages in thread From: Marek Polacek @ 2019-01-25 17:13 UTC (permalink / raw) To: Tim Song; +Cc: Jason Merrill, GCC Patches On Fri, Jan 25, 2019 at 10:55:55AM -0600, Tim Song wrote: > On Thu, Jan 24, 2019 at 4:14 PM Jason Merrill <jason@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 <polacek@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 ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: C++ PATCH for c++/89024 - ICE with incomplete enum type 2019-01-25 17:13 ` Marek Polacek @ 2019-01-25 17:16 ` Jason Merrill 2019-01-26 1:25 ` Marek Polacek 0 siblings, 1 reply; 12+ messages in thread From: Jason Merrill @ 2019-01-25 17:16 UTC (permalink / raw) To: Marek Polacek, Tim Song; +Cc: GCC Patches On 1/25/19 12:09 PM, Marek Polacek wrote: > On Fri, Jan 25, 2019 at 10:55:55AM -0600, Tim Song wrote: >> On Thu, Jan 24, 2019 at 4:14 PM Jason Merrill <jason@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 <polacek@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). Absolutely, the conversion being ill-formed means substitution fails, and we reject that candidate. I meant that we shouldn't get as far as type_promotes_to for an incomplete type. Jason ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: C++ PATCH for c++/89024 - ICE with incomplete enum type 2019-01-25 17:16 ` Jason Merrill @ 2019-01-26 1:25 ` Marek Polacek 2019-01-27 4:22 ` Jason Merrill 0 siblings, 1 reply; 12+ messages in thread From: Marek Polacek @ 2019-01-26 1:25 UTC (permalink / raw) To: Jason Merrill; +Cc: Tim Song, GCC Patches On Fri, Jan 25, 2019 at 12:14:07PM -0500, Jason Merrill wrote: > On 1/25/19 12:09 PM, Marek Polacek wrote: > > On Fri, Jan 25, 2019 at 10:55:55AM -0600, Tim Song wrote: > > > On Thu, Jan 24, 2019 at 4:14 PM Jason Merrill <jason@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 <polacek@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). > > Absolutely, the conversion being ill-formed means substitution fails, and we > reject that candidate. I meant that we shouldn't get as far as > type_promotes_to for an incomplete type. Makes sense. So here's another attempt: Bootstrapped/regtested on x86_64-linux, ok for trunk? 2019-01-25 Marek Polacek <polacek@redhat.com> PR c++/89024 - ICE with incomplete enum type. * call.c (standard_conversion): When converting an ARITHMETIC_TYPE_P to an incomplete type, return NULL. * g++.dg/cpp0x/enum37.C: New test. diff --git gcc/cp/call.c gcc/cp/call.c index 515a9420032..c74d1b4ebdf 100644 --- gcc/cp/call.c +++ gcc/cp/call.c @@ -1412,6 +1412,13 @@ standard_conversion (tree to, tree from, tree expr, bool c_cast_p, || (fcode == REAL_TYPE && !(flags & LOOKUP_NO_NON_INTEGRAL))) || SCOPED_ENUM_P (from)) return NULL; + + /* If we're parsing an enum with no fixed underlying type, we're + dealing with an incomplete type, which renders the conversion + ill-formed. */ + if (!COMPLETE_TYPE_P (from)) + return NULL; + conv = build_conv (ck_std, to, conv); /* Give this a better rank if it's a promotion. */ diff --git gcc/testsuite/g++.dg/cpp0x/enum37.C gcc/testsuite/g++.dg/cpp0x/enum37.C new file mode 100644 index 00000000000..6aa3d4015d7 --- /dev/null +++ gcc/testsuite/g++.dg/cpp0x/enum37.C @@ -0,0 +1,24 @@ +// PR c++/89024 +// { dg-do compile { target c++11 } } + +template <class T, class U> struct same; +template <class T> struct same<T,T> {}; + +template<class T> T&& declval(); + +template<typename _To1> +void __test_aux(_To1); + +template<typename _From1, typename _To1, + typename = decltype(__test_aux<_To1>(declval<_From1>()))> +char __test(int); + +template<typename, typename> +int __test(...); + +enum E { + x = decltype(__test<E, int>(0))(0) +}; + +same<E,decltype(x)> s; +same<unsigned int,__underlying_type(E)> s2; ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: C++ PATCH for c++/89024 - ICE with incomplete enum type 2019-01-26 1:25 ` Marek Polacek @ 2019-01-27 4:22 ` Jason Merrill 2019-01-28 9:48 ` Christophe Lyon 0 siblings, 1 reply; 12+ messages in thread From: Jason Merrill @ 2019-01-27 4:22 UTC (permalink / raw) To: Marek Polacek; +Cc: Tim Song, GCC Patches On Fri, Jan 25, 2019 at 6:22 PM Marek Polacek <polacek@redhat.com> wrote: > > On Fri, Jan 25, 2019 at 12:14:07PM -0500, Jason Merrill wrote: > > On 1/25/19 12:09 PM, Marek Polacek wrote: > > > On Fri, Jan 25, 2019 at 10:55:55AM -0600, Tim Song wrote: > > > > On Thu, Jan 24, 2019 at 4:14 PM Jason Merrill <jason@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 <polacek@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). > > > > Absolutely, the conversion being ill-formed means substitution fails, and we > > reject that candidate. I meant that we shouldn't get as far as > > type_promotes_to for an incomplete type. > > Makes sense. So here's another attempt: > > Bootstrapped/regtested on x86_64-linux, ok for trunk? > > 2019-01-25 Marek Polacek <polacek@redhat.com> > > PR c++/89024 - ICE with incomplete enum type. > * call.c (standard_conversion): When converting an > ARITHMETIC_TYPE_P to an incomplete type, return NULL. OK. Jason ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: C++ PATCH for c++/89024 - ICE with incomplete enum type 2019-01-27 4:22 ` Jason Merrill @ 2019-01-28 9:48 ` Christophe Lyon 2019-01-28 16:37 ` Marek Polacek 0 siblings, 1 reply; 12+ messages in thread From: Christophe Lyon @ 2019-01-28 9:48 UTC (permalink / raw) To: Jason Merrill; +Cc: Marek Polacek, Tim Song, GCC Patches On Sun, 27 Jan 2019 at 01:25, Jason Merrill <jason@redhat.com> wrote: > > On Fri, Jan 25, 2019 at 6:22 PM Marek Polacek <polacek@redhat.com> wrote: > > > > On Fri, Jan 25, 2019 at 12:14:07PM -0500, Jason Merrill wrote: > > > On 1/25/19 12:09 PM, Marek Polacek wrote: > > > > On Fri, Jan 25, 2019 at 10:55:55AM -0600, Tim Song wrote: > > > > > On Thu, Jan 24, 2019 at 4:14 PM Jason Merrill <jason@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 <polacek@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). > > > > > > Absolutely, the conversion being ill-formed means substitution fails, and we > > > reject that candidate. I meant that we shouldn't get as far as > > > type_promotes_to for an incomplete type. > > > > Makes sense. So here's another attempt: > > > > Bootstrapped/regtested on x86_64-linux, ok for trunk? > > > > 2019-01-25 Marek Polacek <polacek@redhat.com> > > > > PR c++/89024 - ICE with incomplete enum type. > > * call.c (standard_conversion): When converting an > > ARITHMETIC_TYPE_P to an incomplete type, return NULL. > > OK. > Hi, The new test fails on arm-eabi (with newlib, but passes on on arm*linux*): FAIL: g++.dg/cpp0x/enum37.C -std=c++14 (test for excess errors) FAIL: g++.dg/cpp0x/enum37.C -std=c++17 (test for excess errors) The log says: /gcc/testsuite/g++.dg/cpp0x/enum37.C:24:41: error: aggregate 'same<unsigned int, unsigned char> s2' has incomplete type and cannot be defined Christophe > Jason ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: C++ PATCH for c++/89024 - ICE with incomplete enum type 2019-01-28 9:48 ` Christophe Lyon @ 2019-01-28 16:37 ` Marek Polacek 2019-01-28 17:01 ` Jason Merrill 0 siblings, 1 reply; 12+ messages in thread From: Marek Polacek @ 2019-01-28 16:37 UTC (permalink / raw) To: Christophe Lyon; +Cc: Jason Merrill, Tim Song, GCC Patches On Mon, Jan 28, 2019 at 10:37:01AM +0100, Christophe Lyon wrote: > On Sun, 27 Jan 2019 at 01:25, Jason Merrill <jason@redhat.com> wrote: > > > > On Fri, Jan 25, 2019 at 6:22 PM Marek Polacek <polacek@redhat.com> wrote: > > > > > > On Fri, Jan 25, 2019 at 12:14:07PM -0500, Jason Merrill wrote: > > > > On 1/25/19 12:09 PM, Marek Polacek wrote: > > > > > On Fri, Jan 25, 2019 at 10:55:55AM -0600, Tim Song wrote: > > > > > > On Thu, Jan 24, 2019 at 4:14 PM Jason Merrill <jason@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 <polacek@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). > > > > > > > > Absolutely, the conversion being ill-formed means substitution fails, and we > > > > reject that candidate. I meant that we shouldn't get as far as > > > > type_promotes_to for an incomplete type. > > > > > > Makes sense. So here's another attempt: > > > > > > Bootstrapped/regtested on x86_64-linux, ok for trunk? > > > > > > 2019-01-25 Marek Polacek <polacek@redhat.com> > > > > > > PR c++/89024 - ICE with incomplete enum type. > > > * call.c (standard_conversion): When converting an > > > ARITHMETIC_TYPE_P to an incomplete type, return NULL. > > > > OK. > > > > Hi, > The new test fails on arm-eabi (with newlib, but passes on on arm*linux*): > FAIL: g++.dg/cpp0x/enum37.C -std=c++14 (test for excess errors) > FAIL: g++.dg/cpp0x/enum37.C -std=c++17 (test for excess errors) > > The log says: > /gcc/testsuite/g++.dg/cpp0x/enum37.C:24:41: error: aggregate > 'same<unsigned int, unsigned char> s2' has incomplete type and cannot > be defined Clearly the additional checking I added won't fly; Jason, can I commit this? Tested on x86_64-linux, ok for trunk? 2019-01-28 Marek Polacek <polacek@redhat.com> * g++.dg/cpp0x/enum37.C: Remove a check. diff --git gcc/testsuite/g++.dg/cpp0x/enum37.C gcc/testsuite/g++.dg/cpp0x/enum37.C index 6aa3d4015d7..e6539af762e 100644 --- gcc/testsuite/g++.dg/cpp0x/enum37.C +++ gcc/testsuite/g++.dg/cpp0x/enum37.C @@ -21,4 +21,3 @@ enum E { }; same<E,decltype(x)> s; -same<unsigned int,__underlying_type(E)> s2; ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: C++ PATCH for c++/89024 - ICE with incomplete enum type 2019-01-28 16:37 ` Marek Polacek @ 2019-01-28 17:01 ` Jason Merrill 2019-01-28 18:11 ` Marek Polacek 0 siblings, 1 reply; 12+ messages in thread From: Jason Merrill @ 2019-01-28 17:01 UTC (permalink / raw) To: Marek Polacek; +Cc: Christophe Lyon, Tim Song, GCC Patches On Mon, Jan 28, 2019 at 10:40 AM Marek Polacek <polacek@redhat.com> wrote: > On Mon, Jan 28, 2019 at 10:37:01AM +0100, Christophe Lyon wrote: > > On Sun, 27 Jan 2019 at 01:25, Jason Merrill <jason@redhat.com> wrote: > > > > > > On Fri, Jan 25, 2019 at 6:22 PM Marek Polacek <polacek@redhat.com> wrote: > > > > > > > > On Fri, Jan 25, 2019 at 12:14:07PM -0500, Jason Merrill wrote: > > > > > On 1/25/19 12:09 PM, Marek Polacek wrote: > > > > > > On Fri, Jan 25, 2019 at 10:55:55AM -0600, Tim Song wrote: > > > > > > > On Thu, Jan 24, 2019 at 4:14 PM Jason Merrill <jason@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 <polacek@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). > > > > > > > > > > Absolutely, the conversion being ill-formed means substitution fails, and we > > > > > reject that candidate. I meant that we shouldn't get as far as > > > > > type_promotes_to for an incomplete type. > > > > > > > > Makes sense. So here's another attempt: > > > > > > > > Bootstrapped/regtested on x86_64-linux, ok for trunk? > > > > > > > > 2019-01-25 Marek Polacek <polacek@redhat.com> > > > > > > > > PR c++/89024 - ICE with incomplete enum type. > > > > * call.c (standard_conversion): When converting an > > > > ARITHMETIC_TYPE_P to an incomplete type, return NULL. > > > > > > OK. > > > > > > > Hi, > > The new test fails on arm-eabi (with newlib, but passes on on arm*linux*): > > FAIL: g++.dg/cpp0x/enum37.C -std=c++14 (test for excess errors) > > FAIL: g++.dg/cpp0x/enum37.C -std=c++17 (test for excess errors) > > > > The log says: > > /gcc/testsuite/g++.dg/cpp0x/enum37.C:24:41: error: aggregate > > 'same<unsigned int, unsigned char> s2' has incomplete type and cannot > > be defined I imagine that this is because arm-eabi defaults to -fshort-enums; you can check for this in the testsuite with { target short_enums }. > Clearly the additional checking I added won't fly; Jason, can I commit > this? > > Tested on x86_64-linux, ok for trunk? > > 2019-01-28 Marek Polacek <polacek@redhat.com> > > * g++.dg/cpp0x/enum37.C: Remove a check. I'd prefer to make the check conditional. Jason ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: C++ PATCH for c++/89024 - ICE with incomplete enum type 2019-01-28 17:01 ` Jason Merrill @ 2019-01-28 18:11 ` Marek Polacek 2019-01-28 21:52 ` Jason Merrill 0 siblings, 1 reply; 12+ messages in thread From: Marek Polacek @ 2019-01-28 18:11 UTC (permalink / raw) To: Jason Merrill; +Cc: Christophe Lyon, Tim Song, GCC Patches On Mon, Jan 28, 2019 at 11:55:21AM -0500, Jason Merrill wrote: > > > The new test fails on arm-eabi (with newlib, but passes on on arm*linux*): > > > FAIL: g++.dg/cpp0x/enum37.C -std=c++14 (test for excess errors) > > > FAIL: g++.dg/cpp0x/enum37.C -std=c++17 (test for excess errors) > > > > > > The log says: > > > /gcc/testsuite/g++.dg/cpp0x/enum37.C:24:41: error: aggregate > > > 'same<unsigned int, unsigned char> s2' has incomplete type and cannot > > > be defined > > I imagine that this is because arm-eabi defaults to -fshort-enums; you > can check for this in the testsuite with { target short_enums }. Indeed, I wasn't aware of this. > > Clearly the additional checking I added won't fly; Jason, can I commit > > this? > > > > Tested on x86_64-linux, ok for trunk? > > > > 2019-01-28 Marek Polacek <polacek@redhat.com> > > > > * g++.dg/cpp0x/enum37.C: Remove a check. > > I'd prefer to make the check conditional. In which case, this. I think it's better than making the whole test conditional on short_enums. Tested on x86_64-linux, ok for trunk? 2019-01-28 Marek Polacek <polacek@redhat.com> * g++.dg/cpp0x/enum37.C: Add dg-error. diff --git gcc/testsuite/g++.dg/cpp0x/enum37.C gcc/testsuite/g++.dg/cpp0x/enum37.C index 6aa3d4015d7..b67720d5ea0 100644 --- gcc/testsuite/g++.dg/cpp0x/enum37.C +++ gcc/testsuite/g++.dg/cpp0x/enum37.C @@ -21,4 +21,4 @@ enum E { }; same<E,decltype(x)> s; -same<unsigned int,__underlying_type(E)> s2; +same<unsigned int,__underlying_type(E)> s2; // { dg-error "incomplete type" "" { target short_enums } } ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: C++ PATCH for c++/89024 - ICE with incomplete enum type 2019-01-28 18:11 ` Marek Polacek @ 2019-01-28 21:52 ` Jason Merrill 0 siblings, 0 replies; 12+ messages in thread From: Jason Merrill @ 2019-01-28 21:52 UTC (permalink / raw) To: Marek Polacek; +Cc: Christophe Lyon, Tim Song, GCC Patches On 1/28/19 12:29 PM, Marek Polacek wrote: > On Mon, Jan 28, 2019 at 11:55:21AM -0500, Jason Merrill wrote: >>>> The new test fails on arm-eabi (with newlib, but passes on on arm*linux*): >>>> FAIL: g++.dg/cpp0x/enum37.C -std=c++14 (test for excess errors) >>>> FAIL: g++.dg/cpp0x/enum37.C -std=c++17 (test for excess errors) >>>> >>>> The log says: >>>> /gcc/testsuite/g++.dg/cpp0x/enum37.C:24:41: error: aggregate >>>> 'same<unsigned int, unsigned char> s2' has incomplete type and cannot >>>> be defined >> >> I imagine that this is because arm-eabi defaults to -fshort-enums; you >> can check for this in the testsuite with { target short_enums }. > > Indeed, I wasn't aware of this. > >>> Clearly the additional checking I added won't fly; Jason, can I commit >>> this? >>> >>> Tested on x86_64-linux, ok for trunk? >>> >>> 2019-01-28 Marek Polacek <polacek@redhat.com> >>> >>> * g++.dg/cpp0x/enum37.C: Remove a check. >> >> I'd prefer to make the check conditional. > > In which case, this. I think it's better than making the whole test > conditional on short_enums. > > Tested on x86_64-linux, ok for trunk? > > 2019-01-28 Marek Polacek <polacek@redhat.com> > > * g++.dg/cpp0x/enum37.C: Add dg-error. > > diff --git gcc/testsuite/g++.dg/cpp0x/enum37.C gcc/testsuite/g++.dg/cpp0x/enum37.C > index 6aa3d4015d7..b67720d5ea0 100644 > --- gcc/testsuite/g++.dg/cpp0x/enum37.C > +++ gcc/testsuite/g++.dg/cpp0x/enum37.C > @@ -21,4 +21,4 @@ enum E { > }; > > same<E,decltype(x)> s; > -same<unsigned int,__underlying_type(E)> s2; > +same<unsigned int,__underlying_type(E)> s2; // { dg-error "incomplete type" "" { target short_enums } } > OK. Jason ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2019-01-28 21:51 UTC | newest] Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2019-01-24 19:19 C++ PATCH for c++/89024 - ICE with incomplete enum type Marek Polacek 2019-01-24 22:17 ` Jason Merrill 2019-01-25 17:00 ` Tim Song 2019-01-25 17:13 ` Marek Polacek 2019-01-25 17:16 ` Jason Merrill 2019-01-26 1:25 ` Marek Polacek 2019-01-27 4:22 ` Jason Merrill 2019-01-28 9:48 ` Christophe Lyon 2019-01-28 16:37 ` Marek Polacek 2019-01-28 17:01 ` Jason Merrill 2019-01-28 18:11 ` Marek Polacek 2019-01-28 21:52 ` Jason Merrill
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).