https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126821
--- Comment #2 from Peeter Joot <peeterjoot at protonmail dot com> ---
Thanks for looking at this.
First, a disclosure (I should have stated this originally):
I do not have access to a mainframe or to IBM Enterprise COBOL.
My report, and the corresponding implementation choice in a separate
(non-gcobol) COBOL translator I work on, are based on reading ISO/IEC
1989:2023 and the IBM Enterprise COBOL for z/OS 6.5 Language Reference
(SC27-8713-04), not on a measurement against a real IBM compiler.
Everything below is a reading of those two documents. If you consider that
insufficient grounds to change behaviour, that is a completely reasonable
position and I would rather this bug be closed. Should somebody with
Enterprise COBOL access confirm the hypothesis, the bug can be reopened
then.
With that said, here is why I think the case is narrower than "what should
DISPLAY do".
1. You are right about DISPLAY itself.
ISO 14.9.11.4 GR1 says "any conversion of data required between literal-1 or
the data item referenced by identifier-1 and the device is defined by the
implementor", and the standard's implementor-defined list carries it
explicitly as item 56, "DISPLAY statement (data conversion)", required to be
documented by the implementor. Items 57-59 delegate variable-length group
format, transfer size, and the standard display device as well. So "I am not
aware of solid documentation about DISPLAY" is an accurate description of
the DISPLAY statement's own text, and I should have granted that in the
original report.
2. But this case does not turn on the DISPLAY statement.
GR1 delegates *conversion*, and only where a conversion is required. PIC
999PPP with no USAGE clause is USAGE DISPLAY: already zoned characters,
nothing to convert. What governs is the PICTURE clause, and there both
documents are normative and say the same thing in the same words -- ISO
13.18.40.4 and IBM LR p.215 ("P symbol"):
> In certain operations that reference a data item whose PICTURE
> character-string contains the symbol P, the algebraic value of the data
> item is used rather than the actual character representation of the
> data item. [...] These operations are any of the following ones:
> - Any operation that requires a numeric sending operand
> - A MOVE statement where the sending operand is numeric and its
> PICTURE character-string contains the symbol P
> - A MOVE statement where the sending operand is numeric-edited and
> its PICTURE character-string contains the symbol P, and the
> receiving operand is numeric or numeric-edited
> - A comparison operation where both operands are numeric
>
> In all other operations, the digit positions specified with the symbol
> P are ignored and are not counted in the size of the operand.
DISPLAY is not one of the four. It requires nothing of the operand's
category -- the IBM LR's own DISPLAY description says identifier-1 "can
reference any data item" except pointer, function-pointer, object-reference
and index. So the operand DISPLAY transfers is three characters wide, and
GR1 has nothing to delegate about it.
That closing sentence is also the one that makes PICTURE 9P occupy one byte,
which gcobol already implements correctly -- NC202A and NC253A both depend
on it and both pass. I am not asking for a different rule here, only for the
same rule to reach DISPLAY.
3. The IBM LR is more specific than the standard on this.
The DISPLAY statement description (p.340) enumerates the conversions it
performs -- binary and internal decimal to zoned decimal, internal
floating-point to external floating-point, USAGE POINTER to PIC 9(10),
NATIONAL to EBCDIC when directed to CONSOLE -- and closes the list with "No
other categories of data require conversion." A USAGE DISPLAY item falls
under that last sentence, so its contents are what is transferred, and a P
position is not one of its contents.
4. On the dialect option.
Your -fdialect ibm offer sounds reasonable, but I'll defer to you to decide
if the specification text justifies doing that work.
Again -- I have no mainframe, this is all from reading documents, and
reality often differs from documented behaviour. Even where the LR reads
unambiguously (I think it does here, but am willing to admit uncertainty),
acting on that assumes that the implementation matches the docs, which
may not be the case.
