[Bug c++/108080] New: ICE: in core_vals, at cp/module.cc:6262 with -fmodule-header

[Bug c++/108080] New: ICE: in core_vals, at cp/module.cc:6262 with -fmodule-header

[zsojka at seznam dot cz]

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

            Bug ID: 108080
           Summary: ICE: in core_vals, at cp/module.cc:6262 with
                    -fmodule-header
           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: zsojka at seznam dot cz
  Target Milestone: ---
              Host: x86_64-pc-linux-gnu
            Target: x86_64-pc-linux-gnu

Created attachment 54077
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54077&action=edit
reduced testcase

Maybe related to PR107083

Compiler output:
$ x86_64-pc-linux-gnu-g++ -fmodule-header testcase.C 
testcase.C: internal compiler error: in core_vals, at cp/module.cc:6262
0x7083ca trees_out::core_vals(tree_node*)
        /repo/gcc-trunk/gcc/cp/module.cc:6262
0xf3ea44 trees_out::tree_node_vals(tree_node*)
        /repo/gcc-trunk/gcc/cp/module.cc:7216
0xf3ea44 trees_out::tree_value(tree_node*)
        /repo/gcc-trunk/gcc/cp/module.cc:9081
0xf3a8b1 trees_out::tree_node(tree_node*)
        /repo/gcc-trunk/gcc/cp/module.cc:9279
0xf3bba0 trees_out::core_vals(tree_node*)
        /repo/gcc-trunk/gcc/cp/module.cc:6170
0xf3939a trees_out::tree_node_vals(tree_node*)
        /repo/gcc-trunk/gcc/cp/module.cc:7216
0xf3939a trees_out::decl_value(tree_node*, depset*)
        /repo/gcc-trunk/gcc/cp/module.cc:7795
0xf409e2 depset::hash::find_dependencies(module_state*)
        /repo/gcc-trunk/gcc/cp/module.cc:13326
0xf41171 module_state::write_begin(elf_out*, cpp_reader*, module_state_config&,
unsigned int&)
        /repo/gcc-trunk/gcc/cp/module.cc:17893
0xf42574 finish_module_processing(cpp_reader*)
        /repo/gcc-trunk/gcc/cp/module.cc:20235
0xed1912 c_parse_final_cleanups()
        /repo/gcc-trunk/gcc/cp/decl2.cc:5148
0x10fd190 c_common_parse_file()
        /repo/gcc-trunk/gcc/c-family/c-opts.cc:1266
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.

$ x86_64-pc-linux-gnu-g++ -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest/bin/x86_64-pc-linux-gnu-g++
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r13-4610-20221212132425-g14d0f82cab3-checking-yes-rtl-df-extra-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=x86_64-pc-linux-gnu
--with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r13-4610-20221212132425-g14d0f82cab3-checking-yes-rtl-df-extra-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20221212 (experimental) (GCC)

[Bug c++/108080] ICE: in core_vals, at cp/module.cc:6262 with -fmodule-header

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Most likely exactly the same:
#pragma GCC optimize("Og")

[Bug c++/108080] ICE: in core_vals, at cp/module.cc:6262 with -fmodule-header

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #1)
> Most likely exactly the same:
> #pragma GCC optimize("Og")

That is from the other bug report.

[Bug c++/108080] ICE: in core_vals, at cp/module.cc:6262 with -fmodule-header

[doko at gcc dot gnu.org]

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

Matthias Klose <doko at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |doko at gcc dot gnu.org

--- Comment #3 from Matthias Klose <doko at gcc dot gnu.org> ---
seen with trunk 20230718:

$ cat foo.ii
module;
# 1 "" 1 3
namespace std {
template <typename> struct hash;
}
typedef long unsigned size_t;
namespace std {
template <typename, typename> struct pair {
  int second;
  template <typename..., size_t, typename..., size_t> constexpr pair();
};
template <typename _T1, typename _T2>
void operator>(pair<_T1, _T2>, pair<_T1, _T2>);
template <typename> struct __new_allocator {
  allocate___n() { allocate___n > this; }
};
template <typename _Tp> using __allocator_base = __new_allocator<_Tp>;
template <typename> struct allocator : __allocator_base<int> {
  __attribute__allocator() {}
};
template class allocator<wchar_t>;
template <size_t> struct array;
void get(array<1>);
template <class _T1, class _T2>
template <typename..., size_t, typename..., size_t>
constexpr pair<_T1, _T2>::pair() : second(get) {}
struct vector {
  friend hash<vector>;
};
void swap(vector);
template <typename> struct __uniq_ptr_impl {
  swap() { std::swap; }
};
template <typename = int> struct unique_ptr {
  __uniq_ptr_impl<int> pointer;
};
struct shared_ptr {
  operator=(unique_ptr<>);
};
struct __shared_ptr {
  friend shared_ptr;
};
void operator==(__shared_ptr, __shared_ptr);
template <unsigned long> struct array {
  size() { size == 0; }
};
} // namespace std
#pragma GCC optimize ""
namespace std {
struct id {
  friend operator>(id, id);
};
struct hash<id>;
} // namespace std
# 7 "" 2
export module spdlog_wrapper;

$ /usr/lib/gcc-snapshot/bin/g++ -std=c++20 -fmodules-ts -Wall -c foo.ii
foo.ii:7:8: internal compiler error: in core_vals, at cp/module.cc:6262
    7 | namespace std {
      |        ^~~~~~
0x11e5613 trees_out::core_vals(tree_node*)
        ../../src/gcc/cp/module.cc:6262
0x11e6353 trees_out::tree_node_vals(tree_node*)
        ../../src/gcc/cp/module.cc:7218
0x11ec349 trees_out::tree_value(tree_node*)
        ../../src/gcc/cp/module.cc:9083
0x11e8faf trees_out::tree_node(tree_node*)
        ../../src/gcc/cp/module.cc:9281
0x11e59be trees_out::core_vals(tree_node*)
        ../../src/gcc/cp/module.cc:6171
0x11e6353 trees_out::tree_node_vals(tree_node*)
        ../../src/gcc/cp/module.cc:7218
0x11e6cb7 trees_out::decl_value(tree_node*, depset*)
        ../../src/gcc/cp/module.cc:7797
0x11ee50d depset::hash::find_dependencies(module_state*)
        ../../src/gcc/cp/module.cc:13328
0x11eea54 module_state::write_begin(elf_out*, cpp_reader*,
module_state_config&, unsigned int&)
        ../../src/gcc/cp/module.cc:17895
0x79f4e7 finish_module_processing(cpp_reader*)
        ../../src/gcc/cp/module.cc:20237
0x1bc5fd5 c_parse_final_cleanups()
        ../../src/gcc/cp/decl2.cc:5184
0x21034b1 c_common_parse_file()
        ../../src/gcc/c-family/c-opts.cc:1274
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.

[Bug c++/108080] ICE: in core_vals, at cp/module.cc:6262 with -fmodule-header

[doko at gcc dot gnu.org]

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

--- Comment #4 from Matthias Klose <doko at gcc dot gnu.org> ---
the original attached test case also fails

[Bug c++/108080] ICE: in core_vals, at cp/module.cc:6262 with -fmodule-header

[yagreg7 at gmail dot com]

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

Gregory Dushkin <yagreg7 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |yagreg7 at gmail dot com

--- Comment #5 from Gregory Dushkin <yagreg7 at gmail dot com> ---
I have a similar issue with GCC 13.2.1. The weird part about it is that it
seems to depend on the exact value of some compiler flags rather than the
actual source file content. I'm trying to use g++ to compile {fmt} as a module
and this is what I get:

When building with CMake the {fmt} itself (go to repository, `mkdir build; cd
build; cmake .. -DFMT_MODULE=ON && make`, the command
```
/usr/bin/c++ 
-I/home/greg/.cpm/fmt/c85658eda638008e7e9290fcd31836ed9f7be1a4/include -O3
-DNDEBUG -std=gnu++20 -fvisibility=hidden -fvisibility-inlines-hidden
-fmodules-ts -MD -MT CMakeFiles/fmt.dir/src/fmt.cc.o -MF
CMakeFiles/fmt.dir/src/fmt.cc.o.d -o CMakeFiles/fmt.dir/src/fmt.cc.o -c
/home/greg/.cpm/fmt/c85658eda638008e7e9290fcd31836ed9f7be1a4/src/fmt.cc

```
executes successfully and the compilation is OK.

However, when compiling {fmt} as a CMake subproject, the command is a little
different:
```
cd /home/greg/projects/cpp/4seudo/build/_deps/fmt-build && /usr/bin/c++ 
-I/home/greg/.cpm/fmt/c85658eda638008e7e9290fcd31836ed9f7be1a4/include
-std=c++20 -fmodules-ts -MD -MT _deps/fmt-build/CMakeFiles/fmt.dir/src/fmt.cc.o
-MF CMakeFiles/fmt.dir/src/fmt.cc.o.d -o CMakeFiles/fmt.dir/src/fmt.cc.o -c
/home/greg/.cpm/fmt/c85658eda638008e7e9290fcd31836ed9f7be1a4/src/fmt.cc
```

And _this_ command fails with an ICE:
```
$ cd /home/greg/projects/cpp/4seudo/build/_deps/fmt-build && /usr/bin/c++ 
-I/home/greg/.cpm/fmt/c85658eda638008e7e9290fcd31836ed9f7be1a4/include
-std=c++20 -fmodules-ts -MD -MT _deps/fmt-build/CMakeFiles/fmt.dir/src/fmt.cc.o
-MF CMakeFiles/fmt.dir/src/fmt.cc.o.d -o CMakeFiles/fmt.dir/src/fmt.cc.o -c
/home/greg/.cpm/fmt/c85658eda638008e7e9290fcd31836ed9f7be1a4/src/fmt.cc
-freport-bug

/home/greg/.cpm/fmt/c85658eda638008e7e9290fcd31836ed9f7be1a4/src/fmt.cc:73:8:
internal compiler error: in core_vals, at cp/module.cc:6262
   73 | export module fmt;
      |        ^~~~~~
0x1ad33c8 internal_error(char const*, ...)
        ???:0
0x6b7b63 fancy_abort(char const*, int, char const*)
        ???:0
0x7c98b7 trees_out::tree_value(tree_node*)
        ???:0
0x7c763d trees_out::tree_node(tree_node*)
        ???:0
0x7c8806 trees_out::core_vals(tree_node*)
        ???:0
0x7c8d64 trees_out::tree_node_vals(tree_node*)
        ???:0
0x7c616b trees_out::decl_value(tree_node*, depset*)
        ???:0
0x7cb47f depset::hash::find_dependencies(module_state*)
        ???:0
0x7cc422 module_state::write_begin(elf_out*, cpp_reader*, module_state_config&,
unsigned int&)
        ???:0
0x7dc105 finish_module_processing(cpp_reader*)
        ???:0
0x7714fd c_parse_final_cleanups()
        ???:0
0x9444b4 c_common_parse_file()
        ???:0
Please submit a full bug report, with preprocessed source.
Please include the complete backtrace with any bug report.
See <https://bugs.archlinux.org/> for instructions.
Preprocessed source stored into /tmp/ccoSmHEM.out file, please attach this to
your bugreport.
```

Maybe there is an error in arguments parsing?

I will be attaching ccoSmHEM.out to this issue now.

[Bug c++/108080] ICE: in core_vals, at cp/module.cc:6262 with -fmodule-header

[yagreg7 at gmail dot com]

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

--- Comment #6 from Gregory Dushkin <yagreg7 at gmail dot com> ---
Created attachment 55734
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55734&action=edit
Preprocessed source file /tmp/ccoSmHEM.out (gzip compressed)

[Bug c++/108080] ICE: in core_vals, at cp/module.cc:6262 with -fmodule-header

[yagreg7 at gmail dot com]

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

--- Comment #7 from Gregory Dushkin <yagreg7 at gmail dot com> ---
Sorry for splitting the comments, but the issue indeed appears to be tied to
optimization options. When manually specifying -Og, -O1, -O2, -O3, -Os the
compilation is successful. I only observe the ICE with -O0 or no optimization
options.

[Bug c++/108080] ICE: in core_vals, at cp/module.cc:6262 with -fmodule-header

[ppalka at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |karl.weber99 at gmx dot net

--- Comment #8 from Patrick Palka <ppalka at gcc dot gnu.org> ---
*** Bug 107083 has been marked as a duplicate of this bug. ***

[Bug c++/108080] ICE: in core_vals, at cp/module.cc:6262 with -fmodule-header

[ppalka at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ppalka at gcc dot gnu.org
   Last reconfirmed|                            |2024-03-06
     Ever confirmed|0                           |1
             Status|UNCONFIRMED                 |NEW

--- Comment #9 from Patrick Palka <ppalka at gcc dot gnu.org> ---
We don't implement OPTIMIZATION_NODE and TARGET_OPTION_NODE streaming:

    case OPTIMIZATION_NODE:
    case TARGET_OPTION_NODE:
      // FIXME: Our representation for these two nodes is a cache of
      // the resulting set of options.  Not a record of the options
      // that got changed by a particular attribute or pragma.  Should
      // we record that, or should we record the diff from the command
      // line options?  The latter seems the right behaviour, but is
      // (a) harder, and I guess could introduce strangeness if the
      // importer has set some incompatible set of optimization flags?
      gcc_unreachable ();
      break;

[Bug c++/108080] ICE: in core_vals, at cp/module.cc:6262 with -fmodule-header

[ppalka at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           See Also|https://gcc.gnu.org/bugzill |
                   |a/show_bug.cgi?id=111785    |
                 CC|                            |mends-sputter.0z at icloud dot com

--- Comment #10 from Patrick Palka <ppalka at gcc dot gnu.org> ---
*** Bug 111785 has been marked as a duplicate of this bug. ***