https://gcc.gnu.org/bugzilla/show_bug.cgi?id=124200
--- Comment #10 from Nathaniel Shead <nshead at gcc dot gnu.org> --- (In reply to Thomas Berger from comment #9) > (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. Are you maybe looking at a different testcase? The testcase in comment #1 only used header units, there are no named modules involved, so everything should be OK. ...ah, I see, in the patch the testcase there used named modules instead of header units. Right, that makes sense then. I agree that if we end up with functions attached to different named modules (an adjustment of the testcase where we export different declarations) then this is IFNDR. And probably the most sensible approach in that case would be to just continue to consider as them different declarations, so don't do any extra attempts at merging.
