public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c++/106848] New: ICE when compiling module interface file with -g: error: type variant differs by TYPE_MAX_VALUE
@ 2022-09-06 13:40 redi at gcc dot gnu.org
  2022-10-13 14:23 ` [Bug c++/106848] " ppalka at gcc dot gnu.org
                   ` (2 more replies)
  0 siblings, 3 replies; 4+ messages in thread
From: redi at gcc dot gnu.org @ 2022-09-06 13:40 UTC (permalink / raw)
  To: gcc-bugs

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

            Bug ID: 106848
           Summary: ICE when compiling module interface file with -g:
                    error: type variant differs by TYPE_MAX_VALUE
           Product: gcc
           Version: 13.0
            Status: UNCONFIRMED
          Keywords: ice-on-valid-code
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: redi at gcc dot gnu.org
            Blocks: 103524
  Target Milestone: ---

$ cat std.cc
export module std;

import <bits/stdc++.h>;


Compiling the bits/stdc++.h works OK:

$ gcc -c -std=c++23 -fmodules-ts -x c++-system-header bits/stdc++.h


And compiling the module file works without -g:

$ ~/gcc/13/bin/gcc -c -std=c++23 -fmodules-ts std.cc


But with -g there's an ICE:

$ ~/gcc/13/bin/gcc -c -std=c++23 -fmodules-ts std.cc -g
std.cc:3:24: error: type variant differs by TYPE_MAX_VALUE
    3 | import <bits/stdc++.h>;
      |                        ^
 <enumeral_type 0x7feb36b08bd0 _TokenT
    type <integer_type 0x7feb3950e690 unsigned int asm_written public unsigned
type_6 SI
        size <integer_cst 0x7feb395101b0 constant 32>
        unit-size <integer_cst 0x7feb395101c8 constant 4>
        align:32 warn_if_not_align:0 symtab:931886976 alias-set -1
canonical-type 0x7feb3950e690 precision:32 min <integer_cst 0x7feb395101e0 0>
max <integer_cst 0x7feb39510198 4294967295>
        pointer_to_this <pointer_type 0x7feb39520540> reference_to_this
<reference_type 0x7feb35b1a7e0>>
    asm_written unsigned type_5 type_6 SI size <integer_cst 0x7feb395101b0 32>
unit-size <integer_cst 0x7feb395101c8 4>
    align:32 warn_if_not_align:0 symtab:877031008 alias-set -1 canonical-type
0x7feb36b08bd0 precision:32 min <integer_cst 0x7feb395101e0 0> max <integer_cst
0x7feb39510198 4294967295>
    values <tree_list 0x7feb3446b028
        purpose <identifier_node 0x7feb3445f2c0 _S_token_anychar
            normal local bindings <(nil)>>
        value <const_decl 0x7feb3494fc40 _S_token_anychar type <enumeral_type
0x7feb36b08bd0 _TokenT>
            readonly constant nonlocal VOID
/home/jwakely/gcc/13/include/c++/13.0.0/bits/regex_scanner.h:48:7
            align:1 warn_if_not_align:0 context <enumeral_type 0x7feb36b08bd0
_TokenT> initial <integer_cst 0x7feb3444f618 0> chain <const_decl
0x7feb3494fcb0 _S_token_ord_char>>
        chain <tree_list 0x7feb3446b050
            purpose <identifier_node 0x7feb3445f300 _S_token_ord_char
                normal local bindings <(nil)>> value <const_decl 0x7feb3494fcb0
_S_token_ord_char>
            chain <tree_list 0x7feb3446b078
                purpose <identifier_node 0x7feb3445f340 _S_token_oct_num
                    normal local bindings <(nil)>> value <const_decl
0x7feb3494fd20 _S_token_oct_num>
                chain <tree_list 0x7feb3446b0a0
                    purpose <identifier_node 0x7feb3445f380 _S_token_hex_num
                        normal local bindings <(nil)>> value <const_decl
0x7feb3494fd90 _S_token_hex_num>
                    chain <tree_list 0x7feb3446b0c8
                        purpose <identifier_node 0x7feb3445f3c0
_S_token_backref
                            normal local bindings <(nil)>> value <const_decl
0x7feb3494fe00 _S_token_backref>
                        chain <tree_list 0x7feb3446b0f0 purpose
<identifier_node 0x7feb3445f400 _S_token_subexpr_begin> value <const_decl
0x7feb3494fe70 _S_token_subexpr_begin> chain <tree_list 0x7feb3446b118>>>>>>>
context <record_type 0x7feb36b08b28 _ScannerBase>
    chain <type_decl 0x7feb36b00ab0 _TokenT>>
 <enumeral_type 0x7feb35f18540 _TokenT
    type <integer_type 0x7feb3950e690 unsigned int asm_written public unsigned
type_6 SI
        size <integer_cst 0x7feb395101b0 constant 32>
        unit-size <integer_cst 0x7feb395101c8 constant 4>
        align:32 warn_if_not_align:0 symtab:931886976 alias-set -1
canonical-type 0x7feb3950e690 precision:32 min <integer_cst 0x7feb395101e0 0>
max <integer_cst 0x7feb39510198 4294967295>
        pointer_to_this <pointer_type 0x7feb39520540> reference_to_this
<reference_type 0x7feb35b1a7e0>>
    readonly unsigned type_5 type_6 SI size <integer_cst 0x7feb395101b0 32>
unit-size <integer_cst 0x7feb395101c8 4>
    align:32 warn_if_not_align:0 symtab:877078960 alias-set -1 canonical-type
0x7feb35f18540 precision:32 context <record_type 0x7feb36b08b28 _ScannerBase>
reference_to_this <reference_type 0x7feb35f185e8>>
std.cc:3:24: internal compiler error: ‘verify_type’ failed
0x149aade verify_type(tree_node const*)
        /home/jwakely/src/gcc/gcc/gcc/tree.cc:14023
0xd936f3 gen_type_die_with_usage
        /home/jwakely/src/gcc/gcc/gcc/dwarf2out.cc:26117
0xd93a0b gen_type_die_with_usage
        /home/jwakely/src/gcc/gcc/gcc/dwarf2out.cc:26251
0xda82b3 gen_type_die
        /home/jwakely/src/gcc/gcc/gcc/dwarf2out.cc:26348
0xda82b3 gen_formal_types_die
        /home/jwakely/src/gcc/gcc/gcc/dwarf2out.cc:23083
0xd8cf96 gen_subprogram_die
        /home/jwakely/src/gcc/gcc/gcc/dwarf2out.cc:23927
0xd90919 gen_decl_die
        /home/jwakely/src/gcc/gcc/gcc/dwarf2out.cc:26964
0xd92bb5 gen_member_die
        /home/jwakely/src/gcc/gcc/gcc/dwarf2out.cc:25801
0xd92bb5 gen_struct_or_union_type_die
        /home/jwakely/src/gcc/gcc/gcc/dwarf2out.cc:25897
0xd92bb5 gen_tagged_type_die
        /home/jwakely/src/gcc/gcc/gcc/dwarf2out.cc:26098
0xd939d0 gen_tagged_type_die
        /home/jwakely/src/gcc/gcc/gcc/dwarf2out.cc:26052
0xd939d0 gen_type_die_with_usage
        /home/jwakely/src/gcc/gcc/gcc/dwarf2out.cc:26293
0xd9052b gen_type_die
        /home/jwakely/src/gcc/gcc/gcc/dwarf2out.cc:26348
0xd9052b gen_decl_die
        /home/jwakely/src/gcc/gcc/gcc/dwarf2out.cc:26987
0xd916db dwarf2out_decl
        /home/jwakely/src/gcc/gcc/gcc/dwarf2out.cc:27542
0xd919d8 dwarf2out_type_decl
        /home/jwakely/src/gcc/gcc/gcc/dwarf2out.cc:27260
0xd919d8 dwarf2out_type_decl
        /home/jwakely/src/gcc/gcc/gcc/dwarf2out.cc:27255
0x10b94e4 rest_of_type_compilation(tree_node*, int)
        /home/jwakely/src/gcc/gcc/gcc/passes.cc:339
0xaa7fc5 trees_in::read_class_def(tree_node*, tree_node*)
        /home/jwakely/src/gcc/gcc/gcc/cp/module.cc:12173
0xaa9b59 module_state::read_cluster(unsigned int)
        /home/jwakely/src/gcc/gcc/gcc/cp/module.cc:14957
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103524
[Bug 103524] [meta-bug] modules issue

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug c++/106848] ICE when compiling module interface file with -g: error: type variant differs by TYPE_MAX_VALUE
  2022-09-06 13:40 [Bug c++/106848] New: ICE when compiling module interface file with -g: error: type variant differs by TYPE_MAX_VALUE redi at gcc dot gnu.org
@ 2022-10-13 14:23 ` ppalka at gcc dot gnu.org
  2022-10-25 17:41 ` cvs-commit at gcc dot gnu.org
  2022-10-25 17:50 ` ppalka at gcc dot gnu.org
  2 siblings, 0 replies; 4+ messages in thread
From: ppalka at gcc dot gnu.org @ 2022-10-13 14:23 UTC (permalink / raw)
  To: gcc-bugs

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

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2022-10-13
           Assignee|unassigned at gcc dot gnu.org      |ppalka at gcc dot gnu.org
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |ASSIGNED
                 CC|                            |ppalka at gcc dot gnu.org

--- Comment #1 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Reduced:

$ cat 106848_a.H
typedef enum memory_order { memory_order_seq_cst } memory_order;

$ cat 106848_b.C
import "106848_a.H";

memory_order x;

$ g++ -fmodules-ts -g 106848_a.H 106848_b.C
106848_b.C:3:14: error: type variant differs by TYPE_MAX_VALUE

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug c++/106848] ICE when compiling module interface file with -g: error: type variant differs by TYPE_MAX_VALUE
  2022-09-06 13:40 [Bug c++/106848] New: ICE when compiling module interface file with -g: error: type variant differs by TYPE_MAX_VALUE redi at gcc dot gnu.org
  2022-10-13 14:23 ` [Bug c++/106848] " ppalka at gcc dot gnu.org
@ 2022-10-25 17:41 ` cvs-commit at gcc dot gnu.org
  2022-10-25 17:50 ` ppalka at gcc dot gnu.org
  2 siblings, 0 replies; 4+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-10-25 17:41 UTC (permalink / raw)
  To: gcc-bugs

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

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* [Bug c++/106848] ICE when compiling module interface file with -g: error: type variant differs by TYPE_MAX_VALUE
  2022-09-06 13:40 [Bug c++/106848] New: ICE when compiling module interface file with -g: error: type variant differs by TYPE_MAX_VALUE redi at gcc dot gnu.org
  2022-10-13 14:23 ` [Bug c++/106848] " ppalka at gcc dot gnu.org
  2022-10-25 17:41 ` cvs-commit at gcc dot gnu.org
@ 2022-10-25 17:50 ` ppalka at gcc dot gnu.org
  2 siblings, 0 replies; 4+ messages in thread
From: ppalka at gcc dot gnu.org @ 2022-10-25 17:50 UTC (permalink / raw)
  To: gcc-bugs

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

Patrick Palka <ppalka at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|ASSIGNED                    |RESOLVED
   Target Milestone|---                         |13.0

--- Comment #3 from Patrick Palka <ppalka at gcc dot gnu.org> ---
Should be fixed.

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2022-10-25 17:50 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-09-06 13:40 [Bug c++/106848] New: ICE when compiling module interface file with -g: error: type variant differs by TYPE_MAX_VALUE redi at gcc dot gnu.org
2022-10-13 14:23 ` [Bug c++/106848] " ppalka at gcc dot gnu.org
2022-10-25 17:41 ` cvs-commit at gcc dot gnu.org
2022-10-25 17:50 ` ppalka at gcc dot gnu.org

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