[Bug cobol/119215] -Wodr and -Wlto-type-mismatch issues in cobol

[harald at gigawatt dot nl]

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

--- Comment #22 from Harald van Dijk <harald at gigawatt dot nl> ---
(In reply to James K. Lowden from comment #21)
> (In reply to Harald van Dijk from comment #20)
> > (In reply to James K. Lowden from comment #18)
> > > A type that is not shared is not shared, and "another translation unit"
> > > cannot use it, whether or not by mistake.  
> > The C++ standard specifies in [basic.link]p4 that named enumerations have
> > linkage just like variables and functions do
> 
> Do you refer to 
> 
>    International Standard ISO/IEC 14882:2024(E) – Programming Language C++
> 
> ?

Essentially, yes, although when we're not talking about a specific version of
C++, I usually use https://eel.is/c++draft/, so in this case
https://eel.is/c++draft/basic.link and https://eel.is/c++draft/basic.def.odr.

> If I wrap one of the two yysymbol_kind_t in a namespace, anonymous or not,
> does that solve the problem?  

It does. I don't know Bison well enough to know whether that is easier or more
difficult as a workaround in GCC than a #define, but as a proper fix in Bison
that sounds like it would be easier.

> Would it be true then, that any two libraries in /usr/lib, if they are used
> in the same program, must not use the same name for an enumerated type?  If
> so, are they relying on UB that is exposed only under LTO?  

For C++ static libraries, yes. Shared libraries are not covered by the standard
and I am not sure whether there are relevant exceptions for that, and other
languages also go by different rules; if I recall correctly, C has no similar
restriction: it has no RTTI of any kind so it does not need it.

> Thank you for taking the time to patiently explain the issue.  I tried to be
> as concrete as possible so that you could see what I'm thinking.  Your
> concrete example and chapter-and-verse citing are helping me understand a
> feature that contradicts everything I know about C++ names.  I understand
> how one enum, shared between two TUs using the same header file, needs to be
> consistent across the program.  I don't understand how two enums used
> independently and not shared, can be confused by the compiler if they're not
> exposed to the linker.  It's a terrible predicament, but here we are.

Certainly for many of us, if we had designed C++ from scratch, the rules would
be different. I'm not a fan of it either, but as you say, here we are.