public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* 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).