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

Reply via email to