[Bug c++/111710] New: [modules] ICE when compiling module where a lambda is assigned to a field in an exported class

[nicolas.werner at hotmail dot de via Gcc-bugs]

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

Bug ID: 111710
   Summary: [modules] ICE when compiling module where a lambda is
assigned to a field in an exported class
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nicolas.werner at hotmail dot de
  Target Milestone: ---

Created attachment 56063
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56063&action=edit
Patch which prevents the ICE when assigning a lambda to a field inside an
exported entity

Reduced minimal example:

export module argparse;

export {

  struct Argument {
int (*i)(int) = 
  [](int value) { return value; };
  };

}


When compiling this example with "g++ -std=c++23  -fmodules-ts  -x c++ -o
argparse.ixx.o -c argparse.ixx" it produces the following crash:

0x5583c3e758bb crash_signal
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231001/gcc-14-20231001/gcc/toplev.cc:314
0x7f2a9658041f ???
   
/usr/src/debug/sys-libs/glibc-2.38-r5/glibc-2.38/signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x5583c3627ea5 trees_out::key_mergeable(int, merge_kind, tree_node*,
tree_node*, tree_node*, depset*)
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231001/gcc-14-20231001/gcc/cp/module.cc:10651
0x5583c36220e8 trees_out::decl_value(tree_node*, depset*)
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231001/gcc-14-20231001/gcc/cp/module.cc:7786
0x5583c362abd2 depset::hash::find_dependencies(module_state*)
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231001/gcc-14-20231001/gcc/cp/module.cc:13328
0x5583c362ba29 module_state::write_begin(elf_out*, cpp_reader*,
module_state_config&, unsigned int&)
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231001/gcc-14-20231001/gcc/cp/module.cc:17895
0x5583c362d0b4 finish_module_processing(cpp_reader*)
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231001/gcc-14-20231001/gcc/cp/module.cc:20241
0x5583c35af85d c_parse_final_cleanups()
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231001/gcc-14-20231001/gcc/cp/decl2.cc:5255
0x5583c381d2fd c_common_parse_file()
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231001/gcc-14-20231001/gcc/c-family/c-opts.cc:1296

This is because the lambda is treated as a field by trees_out::get_merge_kind,
but the corresponding case in trees_out::key_mergeable can't find such a field
and then runs over the end of the linked list and dereferences a nullptr.

I am not sure, what the proper mergeable kind is for such a lambda. I tried
changing it to be MK_unique, which seems to fix the crash, but I don't know
what the consequences of that would be. I would assume MK_keyed to be the right
value, however I couldn't make that work. Alternatively possibly the
key_mergeable needs to be adapted to handle such fields properly, but since
this is my first time touching the gcc codebase, I find that part of the code
to be a bit hard to wrap my head around.

I have attached the patch, which changes the mergekind  to demonstrate the
problem area as well as included a test case in that patch. Maybe that can help
solving that issue properly.

I tested this with 13.2.1_p20230826 and 14.0.0_pre20231001.

[Bug c++/111710] [modules] ICE when compiling module where a lambda is assigned to a field in an exported class

[nicolas.werner at hotmail dot de via Gcc-bugs]

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

--- Comment #2 from Nicolas Werner  ---
I don't really have sufficient knowledge to push this patch forward, since that
currently exceeds my skillset. As such I have no confidence this patch is
actually doing something beneficial, which is why I didn't submit it to the
mailing list, so that I could gather either more knowledge about that issue or
someone else might know how to fix it. Should I still submit it to the mailing
list in this case?

[Bug c++/100135] [modules] ICE when using constants in a module

[nicolas.werner at hotmail dot de via Gcc-bugs]

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

Nicolas Werner  changed:

   What|Removed |Added

 CC||nicolas.werner at hotmail dot 
de

--- Comment #1 from Nicolas Werner  ---
A more minimal example of the issue here, I think:

export module internalname;

constexpr int radix_16 = 16;

export {
  int foo(int in = radix_16) {
return in;
  }
}

I *think* this is legal module code and MSVC as well as clang do accept it.
However it is a weird edge case. This also isn't exclusive to default function
arguments, you can trigger the same issue with templates:

export module internalname;

constexpr int radix_16 = 16;

template 
inline auto do_from_chars() -> T {
  if (Param > 4) {
return 5;
  }
  else {
return 4;
  }
}

export {
  template  struct parse_number {
auto operator()() -> T {
  return do_from_chars();
}
  };
}

Specifically gcc seems to be overly strict here in how it handles internal
linkage entities, that are required on the call site for default parameters or
template instantiations.

[Bug c++/100135] [modules] ICE when using constants in a module

[nicolas.werner at hotmail dot de via Gcc-bugs]

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

--- Comment #2 from Nicolas Werner  ---
Possibly the gcc behaviour here is correct. There is a clang bug open for it
not rejecting calls to functions with default parameters, when the default
parameter is not exported: https://github.com/llvm/llvm-project/issues/57459

However possibly that should only be an error at the call site instead of when
compiling the module with that function declaration, when the function
parameter can be legally specified at the call site. For example for foo(int i
= unexported_constant) a call to foo(5) could be legal, even if only foo but
not unexported_constant is exported? Not sure what the standard says on that,
it sounds similar to CWG2631.