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);