https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124200
--- Comment #9 from Thomas Berger <loki at loki dot codes> --- (In reply to Nathaniel Shead from comment #7) > Hm, why was this necessary? I would expect modules declarations to have > merged function decls and completely deduplicated them. This logic doesn't > seem to get hit by my testcase I assumed that was intended behavior, as there are other parts that deal with function overload resolution. But, i rechecked the current logic and the standard. I am not 100% certain on this, but your case should not compile. According to [basic.def.odr]: [...] 16 For any other definable item D with definitions in multiple translation units, (16.1) — if D is a non-inline non-templated function or variable, or (16.2) — if the definitions in different translation units do not satisfy the following requirements, the program is ill-formed; a diagnostic is required only if the definable item is attached to a named module and a prior definition is reachable at the point where a later definition occurs. Given such an item, for all definitions of D, or, if D is an unnamed enumeration, for all definitions of D that are reachable at any given program point, the following requirements shall be satisfied. (16.3) — Each such definition shall not be attached to a named module (10.1). [...] If i read this correctly, while all definitions have the same body, they are attached to a named module, and therefore violate the ODR. The logic in key_mergeable already flags namespace members that are attached to a module as unique and therefore unmergable in those cases, but we don't detect the collision currently, and do not issue an diagnostic.
