https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119883
James K. Lowden <jklowden at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|WAITING |NEW Assignee|rdubner at gcc dot gnu.org |jklowden at gcc dot gnu.org --- Comment #2 from James K. Lowden <jklowden at gcc dot gnu.org> --- The issue appears to boil down to YYLTYPE and YDFLTYPE, which are identical, being defined differently somehow, somewhere. A clue perhaps: in gcc/cobol/util.cc, we have void cbl_field_t::report_invalid_initial_value(const YYLTYPE& loc) const which appears to be the source of the complaint about the "type itself" in warn_odr. In the util.o, there are 4 definitions: 00000000000025d0 T cbl_field_t::report_invalid_initial_value(YYLTYPE const&) const 0000000000002524 t cbl_field_t::report_invalid_initial_value(YYLTYPE const&) const::{lambda(char)#2}::operator()(char) const 0000000000002548 t cbl_field_t::report_invalid_initial_value(YYLTYPE const&) const::{lambda(char)#3}::operator()(char) const 00000000000024f0 t cbl_field_t::report_invalid_initial_value(YYLTYPE const&) const::{lambda(char)#1}::operator()(char) const I don't know what const::{lambda(char)#1}::operator()(char) refers to. The sole call to this function is from parse.y:3755 $field->report_invalid_initial_value(@data_clauses);