https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119215
James K. Lowden <jklowden at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2025-05-23
Assignee|unassigned at gcc dot gnu.org |jklowden at gcc dot
gnu.org
--- Comment #7 from James K. Lowden <jklowden at gcc dot gnu.org> ---
Unfortunately ODR lto warnings are hard to diagnose because the system reports
only that two definitions exist in two TUs, but not which ones, nor how they
differ. It would seem to be an enhancement opportunity.
I am skeptical of the accuracy of the report. Everything seems to boil down to
YYLTYPE and YDFLTYPE, which are the same, and hard to get wrong:
typedef struct YYLTYPE YYLTYPE;
struct YYLTYPE
{
int first_line;
int first_column;
int last_line;
int last_column;
};
Normally those definitions are confined to the Bison header-file output, but
because locations are used in places that don't need (or can't use) those
headers, I copied them to dbldiag.h, as a convenience.
I'm no fan of the typedef line, which isn't needed in C++, but that text
appears verbatim in the Bison output for cdf.y and parse.y.
The best suggestion I've gotten so far is to trap on warn_odr and examine the
types in gdb. That seems like a commendable idea, skeptic or no.
