Menu ▾ ▴

#931 codegen: sticky linkage "last_"-field undeclared

unclassified
open
nobody
None
5 - default
2023-11-23
2023-11-23
Chris G
No

It looks like there was a regression in the way the "last_b_000"-fields are generated, because the following used to work in GC3.1, but not in the recent 3.2:

       IDENTIFICATION DIVISION.
       PROGRAM-ID.  PARENT.
       DATA DIVISION.
       WORKING-STORAGE SECTION.
       01 WS-DATA PIC X(10).
       PROCEDURE DIVISION.
           CALL "CHILD" USING WS-DATA
           GOBACK.
       END PROGRAM PARENT.
      ******************************************************************
      ******************************************************************
       IDENTIFICATION DIVISION.
       PROGRAM-ID.  CHILD.
       DATA DIVISION.
       LINKAGE SECTION.
       01 LS-DATA PIC X(10).
       PROCEDURE DIVISION USING LS-DATA.
           DISPLAY LS-DATA.
           GOBACK.
       END PROGRAM CHILD.

Compiled with cobc -x -fsticky-linkage -fdump=LS bug.cbl, it aborts with

/tmp/cob1462_0.c: In function 'CHILD_':
/tmp/cob1462_0.c:402:12: error: 'last_b_35' undeclared (first use in this function)
  402 |     b_35 = last_b_35;
      |            ^~~~~~~~~
/tmp/cob1462_0.c:402:12: note: each undeclared identifier is reported only once for each function it appears in

Tracking down the problem, it seems two if-statements were mistakenly merged together, codegen.c#12056 used to be split up in two if statements:

// GC3.1 code:
if (prog->num_proc_params) {
    if (!cb_sticky_linkage && !prog->flag_chained) {
        ...
    )
    ... // generates "last_b_35"
}

became

// GC3.2 code:
if (prog->num_proc_params
    && !cb_sticky_linkage && !prog->flag_chained) {
    ... // generates "last_b_35"
}

Discussion


Log in to post a comment.