[Bug cobol/119520] cobol1: internal compiler error: Segmentation fault (use of field with unknown TYPEDEF)

[simonsobisch at gnu dot org via Gcc-bugs]

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

Simon Sobisch  changed:

   What|Removed |Added

 Resolution|WORKSFORME  |FIXED

--- Comment #2 from Simon Sobisch  ---
checking with the given example program and gcobol debian package from
yesterday "directly":

TYPEDEF.cob:5:37: error: USAGE TYPENAME is not ISO syntax, requires -dialect mf
5 |01  SOME-GID   USAGE INT   VALUE ZERO.
  | ^
TYPEDEF.cob:8:8: error: cannot MOVE '77' (FldLiteralN) to 'SOME-GID' (Fld)
8 |move 77 to some-gid.
  |^
cobol1: error: failed compiling TYPEDEF.cob

For improved error handling I'd recommend to leave the first error in, but to
internally still apply the typedef - which would prevent strange follow-up
errors like the second one (there are likely much more in bigger programs).


The example though is something else: it is when dropping the TYPEDEF line. And
this does not abort any more (same result w/wo the dialect):

TYPEDEF.cob:5:37: error: DATA-ITEM 'INT' not found
5 |01  SOME-GID   USAGE INT   VALUE ZERO.
  | ^
TYPEDEF.cob:8:8: error: cannot MOVE '77' (FldLiteralN) to 'SOME-GID' (Fld)
8 |move 77 to some-gid.
  |^
cobol1: error: failed compiling TYPEDEF.cob


To improve error handling here (that will help for a lot of other cases as
well!): look at the VALUE clause, if numeric then fallback to UNSIGNED
BINARY-DOUBLE, if alpanumeric/national/utf8 then PIC X/N/U of necessary size.


... and speaking of that (@jklowden you may want to move some or all of those
suggestions out to a feature request ticket of the priority you think is
reasonable): when dropping the definition for some-gid the result is:

TYPEDEF.cob:8:19: error: DATA-ITEM 'some-gid' not found
8 |move 77 to some-gid.
  |   ^
TYPEDEF.cob:8:19: error: invalid receiving operand
TYPEDEF.cob:9:11: error: DATA-ITEM 'SOME-GID' not found
9 |if SOME-GID = 77 then
  |   ^
TYPEDEF.cob:12:32: error: DATA-ITEM 'some-gid' not found
   12 |  display "the GID is " some-gid ", boo!".
  |^
cobol1: error: failed compiling TYPEDEF.cob

cc1 would only error the first time, then stays silent about that identifier
(and don't calculate it in -fmax-errors).

One way to do this is to internally create a data-item with that name, similar
to the one above; that still allows checking for type mismatches later on, for
example, and would also work around other issues like the following:

TYPEDEF.cob:8:19: error: DATA-ITEM 'some-gid' not found
8 |move 77 to some-gid.
  |   ^
TYPEDEF.cob:8:19: error: invalid receiving operand
compilation terminated due to -fmax-errors=2.

(that is one error, but currently counted as two)

[Bug cobol/119520] cobol1: internal compiler error: Segmentation fault (use of field with unknown TYPEDEF)

[jklowden at gcc dot gnu.org via Gcc-bugs]

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

James K. Lowden  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jklowden at gcc dot 
gnu.org
 CC||jklowden at gcc dot gnu.org
 Resolution|--- |WORKSFORME
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from James K. Lowden  ---
"This program uses several typedefs", did you intend to provide this program? 
:-)

typedef is barely tested, lacking examples.  But perhaps this PR is actually
solved because it's rooted in CDF >>DEFINE, which (I hope) has been corrected.  

This small program works, 

   PROGRAM-ID. "TYPEDEF".
   DATA DIVISION.
   WORKING-STORAGE SECTION.
   77  INT PIC 9(8) is typedef.
   01  SOME-GID   USAGE INT   VALUE ZERO.

   PROCEDURE DIVISION.
   move 77 to some-gid.
   if SOME-GID = 77 then
 display "the GID is 77"
   else
 display "the GID is " some-gid ", boo!".

   $ gcobol -dialect mf typedef.cbl && ./a.out
   the GID is 77

Marking resolved until further notice.