* 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).