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 0A57B3858C35; Thu,  5 Oct 2023 20:28:36 +0000 (GMT)
DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0A57B3858C35
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org;
	s=default; t=1696537717;
	bh=MZ452NRT2ZGEg31xiKn1ODBQdyJpelGInuLEWcNfEJo=;
	h=From:To:Subject:Date:In-Reply-To:References:From;
	b=Z5l/nDR1nYxCHuxGV98HnyY/W8WDsQO4myjwtG+UEAO3YjlARtrjFWbO9GaMv1s8t
	 M+9lmvSH6jJJLtqhn0ydIzuzIkhGTAjPKpUy+cA3wJ5SBQAjbcHmLWDLw2lgzklWbV
	 7hXQ7XeGU5wrV1UPN+hNpUc3asGrU18Yn8+6AHmY=
From: "nicolas.werner at hotmail dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/100135] [modules] ICE when using constants in a module
Date: Thu, 05 Oct 2023 20:28:35 +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: 11.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: nicolas.werner at hotmail dot de
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution: 
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags: 
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-100135-4-WABYV3UtCd@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-100135-4@http.gcc.gnu.org/bugzilla/>
References: <bug-100135-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=3D100135

Nicolas Werner <nicolas.werner at hotmail dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nicolas.werner at hotmail =
dot de

--- Comment #1 from Nicolas Werner <nicolas.werner at hotmail dot de> ---
A more minimal example of the issue here, I think:

export module internalname;

constexpr int radix_16 =3D 16;

export {
  int foo(int in =3D 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 funct=
ion
arguments, you can trigger the same issue with templates:

export module internalname;

constexpr int radix_16 =3D 16;

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

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

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