From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-bugzilla@gcc.gnu.org>
Received: by sourceware.org (Postfix, from userid 48)
	id 8A577385841E; Tue, 25 Oct 2022 17:41:56 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8A577385841E
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1666719716;
	bh=pooAHS6JxdWVhzI4fRhxne1h6gAMiue1Hq/X0aYpUak=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=vW9HHH0LbCLXFPrutKv/o6ZKHlB63NN0cDOvd4HRsl6OeDd94khRKZypxMyqW+YM1
	 UOL/6Ipna6URsoa9IECRS+yhsel4eaRAZAuTZ+h5/Cz/5KJSsS7+fc1Kgpw1pV1X6R
	 GZ4py41OZUyZYWh2ehWMjTe7rQnwgrwpgu6qlgzc=
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/106848] ICE when compiling module interface file with -g:
 error: type variant differs by TYPE_MAX_VALUE
Date: Tue, 25 Oct 2022 17:41:55 +0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 13.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: cvs-commit at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: ppalka at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: 
Message-ID: <bug-106848-4-bJgxxKBPlu@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-106848-4@http.gcc.gnu.org/bugzilla/>
References: <bug-106848-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
List-Id: <gcc-bugs.sourceware.org>

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D106848

--- Comment #2 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Patrick Palka <ppalka@gcc.gnu.org>:

https://gcc.gnu.org/g:15d67c11ac0479b08e3badcafdee7e0a6f062349

commit r13-3491-g15d67c11ac0479b08e3badcafdee7e0a6f062349
Author: Patrick Palka <ppalka@redhat.com>
Date:   Tue Oct 25 13:41:18 2022 -0400

    c++ modules: enum TYPE_MIN/MAX_VALUE streaming [PR106848]

    In the frontend, the TYPE_MIN/MAX_VALUE of ENUMERAL_TYPE is the same as
    that of the enum's underlying type (see start_enum).  And the underlying
    type of an enum is always known, even for an opaque enum that lacks a
    definition.

    But currently, we stream TYPE_MIN/MAX_VALUE of an enum only as part of
    its definition.  So if the enum is declared but never defined, the
    ENUMERAL_TYPE we stream in will have empty TYPE_MIN/MAX_VALUE fields
    despite these fields being non-empty on stream out.

    And even if the enum is defined, read_enum_def updates these fields only
    on the main variant of the enum type, so for other variants (that we may
    have streamed in earlier) these fields remain empty.  That these fields
    are unexpectedly empty for some ENUMERAL_TYPEs is ultimately the cause
    of the below two PRs.

    This patch fixes this by making us stream TYPE_MIN/MAX_VALUE directly
    for each ENUMERAL_TYPE rather than as part of the enum's definition, so
    that we naturally also stream these fields for opaque enums (and each
    enum type variant).

            PR c++/106848
            PR c++/102600

    gcc/cp/ChangeLog:

            * module.cc (trees_out::core_vals): Stream TYPE_MAX_VALUE and
            TYPE_MIN_VALUE of ENUMERAL_TYPE.
            (trees_in::core_vals): Likewise.
            (trees_out::write_enum_def): Don't stream them here.
            (trees_in::read_enum_def): Likewise.

    gcc/testsuite/ChangeLog:

            * g++.dg/modules/enum-9_a.H: New test.
            * g++.dg/modules/enum-9_b.C: New test.
            * g++.dg/modules/enum-10_a.H: New test.
            * g++.dg/modules/enum-10_b.C: New test.
            * g++.dg/modules/enum-11_a.H: New test.
            * g++.dg/modules/enum-11_b.C: New test.=