[Bug cobol/119454] New: gcobol: error: unrecognized command-line option ‘-save-all’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119454 Bug ID: 119454 Summary: gcobol: error: unrecognized command-line option ‘-save-all’ Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: cobol Assignee: unassigned at gcc dot gnu.org Reporter: simonsobisch at gnu dot org Target Milestone: --- The bug report page says to use -v -save-all - but gcobol tells us that this is not implemented (-v works fine). While this _may_ be related to Bug 119329 / PR 117009, this seems like an even more important part, given that the docs ask to use that.
[Bug cobol/119456] New: gcobol: huge codegen for use of reference-modification (and missing optimization)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119456 Bug ID: 119456 Summary: gcobol: huge codegen for use of reference-modification (and missing optimization) Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: cobol Assignee: unassigned at gcc dot gnu.org Reporter: simonsobisch at gnu dot org Target Milestone: --- Sample program: ~~~ PROGRAM-ID. STRMOV. DATA DIVISION. WORKING-STORAGE SECTION. 77 dat pic x. PROCEDURE DIVISION. move 'a' to dat (1:1) STOP RUN. ~~~ This program has a single byte data field and assigns a single-byte. While this assignment can easily be "inlined", it currently creates a temporary item and uses multiple calls into libgcobol. To reproduce: ~~~ gcobol -g STRMOV.cob gdb -batch -ex "set disassemble-next-line on" -ex "b STRMOV.cob:6" -ex run a.out ~~~ Result: ~~~ Breakpoint 1, strmov () at STRMOV.cob:6 6move 'a' to dat (1:1) => 0x004015d2 : 48 c7 85 20 ff ff ff 00 00 00 00 movq $0x0,-0xe0(%rbp) 0x004015dd : 48 8b 05 0c 0c 20 00mov 0x200c0c(%rip),%rax# 0x6021f0 0x004015e4 : 48 0d 00 00 04 00 or $0x4,%rax 0x004015ea : 48 89 05 ff 0b 20 00mov %rax,0x200bff(%rip)# 0x6021f0 0x004015f1 : 48 c7 85 18 ff ff ff 01 00 00 00 movq $0x1,-0xe8(%rbp) 0x004015fc : 48 c7 05 e9 11 20 00 01 00 00 00 movq $0x1,0x2011e9(%rip)# 0x6027f0 0x00401607 : 48 c7 85 10 ff ff ff 00 00 00 00 movq $0x0,-0xf0(%rbp) 0x00401612 : 0f b6 0d 47 11 20 00movzbl 0x201147(%rip),%ecx# 0x602760 <_literaln_1.1.0> 0x00401619 : 0f b6 c1movzbl %cl,%eax 0x0040161c : 48 89 c0mov%rax,%rax 0x0040161f : ba 00 00 00 00 mov$0x0,%edx 0x00401624 : 48 89 05 d5 11 20 00mov %rax,0x2011d5(%rip)# 0x602800 0x0040162b : 48 89 15 d6 11 20 00mov %rdx,0x2011d6(%rip)# 0x602808 0x00401632 : 0f b6 05 c2 10 20 00movzbl 0x2010c2(%rip),%eax# 0x6026fb <_intermediate__literaln_1_1.0.0+91> 0x00401639 : 0f be c0movsbl %al,%eax 0x0040163c : 89 05 ce 11 20 00 mov %eax,0x2011ce(%rip)# 0x602810 0x00401642 : 8b 05 c8 11 20 00 mov 0x2011c8(%rip),%eax# 0x602810 0x00401648 : f7 d8 neg%eax 0x0040164a : 89 c1 mov%eax,%ecx 0x0040164c : 48 8b 05 ad 11 20 00mov 0x2011ad(%rip),%rax# 0x602800 0x00401653 : 48 8b 15 ae 11 20 00mov 0x2011ae(%rip),%rdx# 0x602808 0x0040165a : 48 89 c6mov%rax,%rsi 0x0040165d : 48 89 d0mov%rdx,%rax 0x00401660 : 89 ca mov%ecx,%edx 0x00401662 : 48 89 f7mov%rsi,%rdi 0x00401665 : 48 89 c6mov%rax,%rsi 0x00401668 : e8 33 fa ff ff callq 0x4010a0 <__gg__scale_by_power_of_ten_2@plt> 0x0040166d : 48 89 05 8c 11 20 00mov %rax,0x20118c(%rip)# 0x602800 0x00401674 : 48 89 15 8d 11 20 00mov %rdx,0x20118d(%rip)# 0x602808 0x0040167b : c7 05 a3 11 20 00 00 00 00 00 movl $0x0,0x2011a3(%rip)# 0x602828 0x00401685 : 48 8b 05 74 11 20 00mov 0x201174(%rip),%rax# 0x602800 0x0040168c : 48 8b 15 75 11 20 00mov 0x201175(%rip),%rdx# 0x602808 0x00401693 : 48 89 05 46 11 20 00mov %rax,0x201146(%rip)# 0x6027e0 0x0040169a : 48 8b 05 3f 11 20 00mov 0x20113f(%rip),%rax# 0x6027e0 0x004016a1 : 48 89 05 40 11 20 00mov %rax,0x201140(%rip)# 0x6027e8 0x004016a8 : 48 8b 05 39 11 20 00mov 0x201139(%rip),%rax# 0x6027e8 0x004016af : 48 83 e8 01 sub$0x1,%rax 0x004016b3 : 48 89 05 2e 11 20 00mov %rax,0x20112e(%rip)# 0x6027e8 0x004016ba : 48 c7 85 08 ff ff ff 00 00 00 00 movq $0x0,-0xf8(%rbp) 0x004016c5 : 0f b6 0d 94 10 20 00movzbl 0x201094(%rip),%ecx# 0x602760 <_literaln_1.1.0> 0x004016cc : 0f b6 c1movzbl %cl,%eax 0x004016cf : 48 89 c0mov%rax,%rax 0x004016d2 : ba 00 00 00 00 mov$0x0,%edx 0x004016d7 : 48 89 05 22 11 20 00mov %rax,0x201122(%rip)# 0x602800 0x004016de : 48 89 15 23 11 20 00mov %rdx,0x201123(%rip)# 0x602808 0x004016e5 : 0f b6 05 0f
[Bug cobol/119521] gcc-cobol generated programs with memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119521 --- Comment #8 from Simon Sobisch --- Hm, sounds like an internal stack check or similar would be good here to circumvent this issue from another side... If it doesn't work then it would definitely better for gcc to abort compiling this code for now instead of producing something that is known to internally produce a loop. Maybe you want to mark this bug as fixed and create another one about this specific issue and/or DECLARATIVES in general?
[Bug cobol/119695] Incorrect diagnostic format specifiers in COBOL FE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119695 Simon Sobisch changed: What|Removed |Added CC||simonsobisch at gnu dot org --- Comment #1 from Simon Sobisch --- If those would crash, then there's something spot that was never run - I highly suggest trying to create test cases for that, and where not possible (the internal_error seem to not been expected) may even switch to an assert?
[Bug cobol/119682] reference-modification (temporary literal?) yields wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119682 --- Comment #1 from Simon Sobisch --- Created attachment 61038 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61038&action=edit original program showing the bug
[Bug cobol/119682] New: reference-modification (temporary literal?) yields wrong result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119682 Bug ID: 119682 Summary: reference-modification (temporary literal?) yields wrong result Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: cobol Assignee: unassigned at gcc dot gnu.org Reporter: simonsobisch at gnu dot org Target Milestone: --- I'd consider that a much worse than any SIGSEGV that may arise - as that is "basic COBOL". It is even more shocking that this was not found before, even with full UAT and "what ever part of NIST". Program to reproduce the issue: IDENTIFICATION DIVISION. PROGRAM-ID. bug. DATA DIVISION. WORKING-STORAGE SECTION. 01 N-D1 PIC 9(04). PROCEDURE DIVISION. MOVE '12' TO N-D1(2:2) IF N-D1(2:2) > '12' DISPLAY ' INVALID COMPARE ' N-D1(2:2) '!'. GOBACK. Note: works as expected when the data-definition is changed to 9(03).
[Bug cobol/119414] cobol driver unconditionally adds platform-specific command line options.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119414 Simon Sobisch changed: What|Removed |Added CC||simonsobisch at gnu dot org --- Comment #18 from Simon Sobisch --- Just to add: * explicit exported should be all ENTRY "abc". * PROGRAM-ID. "def". is the most common (internal) entry point, with the code starting in the first non-declarative procedure * PROGRAM-ID. GFH. and PROGRAM-id. gfh. should be handled identical = somehow exported, most environments export an uppercase variant for non-literals * FUNCTION-ID. "abc". needs to be somehow available, but how is implementation defined, and it it totally valid if this is only done via an "internal" external-repository - because function definitions _can_ be implemented 100% static - and their used name in COBOL is always case-insensitive (the actual exported entry point is an implementation internal definition) at least from COBOL CALLs the entry points should be available: * in nested programs (those don't need to be exported otherwise, but also be accessible inside via CALL var) * in the same binary * in linked objects (linker optimisation of "unused" symbols may apply, in which case the user may need to disable that) * in already loaded (COBOL) shared objects * in binaries resolved "implementor defined" - but for dynamic CALL "VAR" people will expect VAR.so (or var.so) to be loaded - COBOL requires to document this to the user It is _very_ useful to have an option to "pre-load" libraries somehow - because often multiple functions are in a single shared objects. An environment var similar to LD_PRELOAD (but portable and only applying to COBOL) is useful. Another option is to allow "pre-loading" by CALL "binary-name" (this is at least done in ACUCOBOL, but I think also in other COBOL environments).
[Bug cobol/119521] New: gcc-cobol generated programs with memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119521 Bug ID: 119521 Summary: gcc-cobol generated programs with memory leak Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: cobol Assignee: unassigned at gcc dot gnu.org Reporter: simonsobisch at gnu dot org Target Milestone: --- https://gcc.gnu.org/pipermail/gcc-patches/2025-March/677528.html EXEC85, as generated and executed like mentioned in the mailing list, raises the memory until it is killed by the operating system. Just reproduced with current HEAD.
[Bug cobol/119520] New: cobol1: internal compiler error: Segmentation fault (use of field with unknown TYPEDEF)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119520 Bug ID: 119520 Summary: cobol1: internal compiler error: Segmentation fault (use of field with unknown TYPEDEF) Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: cobol Assignee: unassigned at gcc dot gnu.org Reporter: simonsobisch at gnu dot org Target Milestone: --- This program uses several typedefs and because of another bug (acknowledged by James K. Lowden already who might file a bug on that: ">>IF CVAR IS NOT DEFINED" is always coming back true) the typedef "INT" is not defined. Therefore the compiler correctly finds at the time when that typedef is used: 01 SOPME-GID USAGE INT VALUE ZERO. raises DATA-ITEM 'INT' not found I _guess_ that the data-item which wanted to use this typedef is in some strange state afterwards and the internal use of this lead to the following error: cobol1: internal compiler error: Segmentation fault 0x250a63f internal_error(char const*, ...) /home/me/gcc-cobol/gcc/diagnostic-global-context.cc:517 0x10d910f crash_signal /home/me/gcc-cobol/gcc/toplev.cc:322 0xa68551 contains_struct_check(tree_node*, tree_node_structure_enum, char const*, int, char const*) /home/me/gcc-cobol/gcc/tree.h:3832 0xa68551 gg_get_address_of(tree_node*) /home/me/gcc-cobol/gcc/cobol/gengen.cc:1481 0xa3419d parser_free(unsigned long, cbl_refer_t*) /home/me/gcc-cobol/gcc/cobol/genapi.cc:6148 0xaa33db yyparse() /home/me/gcc-cobol/gcc/cobol/parse.y:5668 0xb07979 parse_file /home/me/gcc-cobol/gcc/cobol/util.cc:2179 0xb07979 cobol_parse_files(int, char const**) /home/me/gcc-cobol/gcc/cobol/util.cc:2240
[Bug cobol/119332] New: cobol frontend does not support version dump options specified in --help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119332 Bug ID: 119332 Summary: cobol frontend does not support version dump options specified in --help Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: cobol Assignee: unassigned at gcc dot gnu.org Reporter: simonsobisch at gnu dot org Target Milestone: --- gcobol --help shows them: -dumpspecs Display all of the built in spec strings. -dumpversion Display the version of the compiler. -dumpmachine Display the compiler's target processor. but when using them it always complains about missing input file - it works as expected with gcc/cpp/g++/... gcobol -dumpversion is especially important for potential use in scripts
[Bug cobol/119295] cobol, libcobol uses random_r which is GLIBC specific
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119295 Simon Sobisch changed: What|Removed |Added CC||simonsobisch at gnu dot org --- Comment #4 from Simon Sobisch --- > Does COBOL even have threads...? Directly only with vendor extensions. But people do use both C/C++ "main" or Java (via JNI) to spawn multiple COBOL threads (which can have multiple issues, depending on the implementation of the COBOL modules and library).
[Bug cobol/119329] New: cobol frontend does not support -Walll
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119329 Bug ID: 119329 Summary: cobol frontend does not support -Walll Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: cobol Assignee: unassigned at gcc dot gnu.org Reporter: simonsobisch at gnu dot org Target Milestone: --- cobol1: warning: command-line option ‘-Wall’ is valid for Ada/AdaSCIL/AdaWhy/C/C++/D/Fortran/Go/Modula-2/ObjC/ObjC++/Rust but not for Cobol (note: in this case COBOL should be all upper-case, similar to the "SCIL" part in this message) Users will very likely expect a new frontend to have a working -Wall.
[Bug cobol/119335] New: cobol frontend ignores -M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119335 Bug ID: 119335 Summary: cobol frontend ignores -M Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: cobol Assignee: unassigned at gcc dot gnu.org Reporter: simonsobisch at gnu dot org Target Milestone: --- touch def.h cat test.c #include "def.h" gcc -M test.c test.o: test.c /usr/include/stdc-predef.h def.h touch def.cob cat test.cob COPY "def.cob". gcc -M test.cob gcobol -M test.cob --> the COBOL frontend accepts -M, but ignores it. Ideally this function (possibly with related -M options) should be implemented, otherwise at least raise a warning.
[Bug cobol/119337] New: cobol: gcobc wrapper should deduce output name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119337 Bug ID: 119337 Summary: cobol: gcobc wrapper should deduce output name Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: cobol Assignee: unassigned at gcc dot gnu.org Reporter: simonsobisch at gnu dot org Target Milestone: --- gcobol default to an output name of a.out, which is totally fine. cobc defaults to an output name of * basename from first source file * extension matching the other command line options: -C -> basename.$OBJEXT, -x basename$EXEEXT, -m basename.$DLLEXT, -S basename.s [that last part also works with cobol1/gcobc] * only exception: if the first source is stdin "-", then the output name is "a.out" (and of course: any given -o overrides the default) To be able to swap cobc with gcobc, the driver script needs to deduce the output -name the same way.
[Bug cobol/119336] New: cobol: missing copybooks break parser
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119336 Bug ID: 119336 Summary: cobol: missing copybooks break parser Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: cobol Assignee: unassigned at gcc dot gnu.org Reporter: simonsobisch at gnu dot org Target Milestone: --- The following program compiles and works as expected: ~~~ *> COPY "notthere". IDENTIFICATION DIVISION. PROGRAM-ID. 'prog'. PROCEDURE DIVISION. 00. DISPLAY '1'. EX. STOP RUN. ~~~ As soon as the COPY statement is uncommented, gcobol raises test.cob:1:13: error: could not open copybook file for '"notthere"' 1 |COPY "notthere". | ^ which is fine (the duplicated quotes may be removed from the message and the full literal be ~ underlined, but those are only side issues). The problem: the parser is broken test.cob:2:23: error: syntax error, unexpected invalid token, expecting IDENTIFICATION DIVISION or PROGRAM-ID 2 |IDENTIFICATION DIVISION. | ^ while the rest of the program should be parsed without any problems (not sure why cobol1 shows an error at the second word, asking for the double-word token).
[Bug cobol/119331] New: cobol: unimplemented exceptions abort compilation - even if requested to NOT use them
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119331 Bug ID: 119331 Summary: cobol: unimplemented exceptions abort compilation - even if requested to NOT use them Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: cobol Assignee: unassigned at gcc dot gnu.org Reporter: simonsobisch at gnu dot org Target Milestone: --- The COBOL standard defines a good amount of exception handling. If the user does not enable them (via >> TURN directive or an implementor specific extension), then the behaviour is "undefined". The implementor specific extension from GnuCOBOL is as follows: -fec= enable code generation for , see --list-exceptions for the possible values, sets -fsource-location -fno-ec= disable code generation for the one from gcobol: -fcobol-exceptions exception [,exception...] By default, no exception condition is enabled (including fatal ones), and by the ISO standard exception conditions are enabled only via the CDF TURN directive. This option enables one or more exception conditions by default, as though TURN had appeared at the top of the first source code file. This option may also appear more than once on the command line. The value of exception is a Level 1, 2, or 3 exception condition name, as described by ISO/IEC 1989:2023. ‘EC-ALL’ means enable all exceptions. The -fno-cobol-exceptions form turns off exception, just as though >>TURN exception CHECKING OFF had appeared. Not all exception conditions are implemented. Any that are not produce a warning message. Given the following command line gcobol -fcobol-exceptions=EC-ALL -fno-cobol-exceptions=EC-DATA-INCOMPATIBLE -fno-cobol-exceptions=EC-PROGRAM-ARG-MISMATCH -fno-cobol-exceptions=EC-PROGRAM-ARG-OMITTED test.cob (explanation: all exceptions are enabled with the level1, then specific level3 exceptions are disabled [because of expected runtime penalty / "legacy coding"] there are three possible issues here: 1 - bug: in case of unknown exceptions, the compilation stops and the compiler exits with 1 cobol1: sorry, unimplemented: exception 'EC-DATA-INCOMPATIBLE' cobol1: sorry, unimplemented: exception 'EC-PROGRAM-ARG-MISMATCH' cobol1: sorry, unimplemented: exception 'EC-PROGRAM-ARG-OMITTED' --> the documentation says "Any that are not produce a warning message." (I think it should have a normal warning group and be able to suppress/increase to an error using -Werror) 2 - design issue: exceptions that are _disabled_ - like all of the ones above should possible not get a warning at all, similar like -Wbanana = error, -Wno-banana = no message at all. 3 - to be considered (and possibly ignored): gcobol is free to do anything, but given GnuCOBOL's usage, wouldn't it be reasonable to name the option identical in gcobol as it is in cobc [the wrapper gcobc already does the translation, but still]?
[Bug cobol/119694] Excessive getenv uses in cobol FE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119694 Simon Sobisch changed: What|Removed |Added CC||simonsobisch at gnu dot org --- Comment #9 from Simon Sobisch --- If you have access to the memory of the process you can adjust the return value from time functions before they are used. If you start the process you can most often do LD_PRELOAD - and return another timestamp. If you have admin rights or run the program in a container, you can adjust the system time... And you likely know about SOURCE_DATE_EPOCH - a variable that's globally used to produce reproducible timestamps and therefore binaries... At least these were my main thoughts when considering the addition of COB_CURRENT_DATE to GnuCOBOL. Note: if that's implemented on your side similar to how libcob does, then it can also be used to "fake" the right timezone or nanoseconds, especially on ancient systems that don't support them - but then... other than GnuCOBOL you may not need to build on those.
[Bug cobol/119777] [15 Regression] COBOL '-fsyntax-only', 'RejectNegative'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119777 Simon Sobisch changed: What|Removed |Added CC||simonsobisch at gnu dot org --- Comment #1 from Simon Sobisch --- I don't understand completely what you mean apart from "should definitely be handled 'common'"... Do you say there should be a -fno-syntax-only?` ... makes me wonder what gcc -fsyntax-only -o some.out some.c other.c does (I _think_ that should at least be valid - if also "partially duplicate" when -E is added as well).
[Bug cobol/119771] New: FE (parser): CONSTANT AS LENGTH OF does not error - but result in length of zero
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119771 Bug ID: 119771 Summary: FE (parser): CONSTANT AS LENGTH OF does not error - but result in length of zero Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: cobol Assignee: unassigned at gcc dot gnu.org Reporter: simonsobisch at gnu dot org Target Milestone: --- To reproduce: IDENTIFICATION DIVISION. PROGRAM-ID. Usage-Lengths. DATA DIVISION. WORKING-STORAGE SECTION. 01 BANANA CONSTANT AS LENGTH OF BANANA. PROCEDURE DIVISION. DISPLAY BANANA goback. No error during compile (should error because of self-reference, when using LENGTH OF BANANA2 instead it should error because of missing data-item). Result: 0
[Bug cobol/119772] New: FE: COBOL2025/2026 (original GnuCOBOL extension) LENGTH OF usage-specification missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119772 Bug ID: 119772 Summary: FE: COBOL2025/2026 (original GnuCOBOL extension) LENGTH OF usage-specification missing Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: cobol Assignee: unassigned at gcc dot gnu.org Reporter: simonsobisch at gnu dot org Target Milestone: --- Before the next COBOL standard (or: before GnuCOBOL added this extension back in the old OpenCOBOL days) the way to get the length of a usage-specification was to first define an unused data item with that specification. 01 D-BINARY-CHARUSAGE BINARY-CHAR. 01 Len-BINARY-CHAR CONSTANT AS LENGTH OF D-BINARY-CHAR. With the new standard/gnucobol the following may be coded instead 01 Len-BINARY-CHAR CONSTANT AS LENGTH OF BINARY-CHAR. which currently raises > error: syntax error, unexpected COMPUTATIONAL This should be at least supported for -dialect gnu (GnuCOBOL) as it used there as a replacement of the sizeof operator in C. As the upcoming COBOL standard added this (it is part of the working draft, which sadly is only available via national standard body or when working in the COBOL development group) and does not conflict with anything else you possibly want to support that independent from the dialect. I _think_ that should be an easy addition.
[Bug cobol/119770] New: FLOAT-DECIMAL support + "cannot MOVE '_stack1'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119770 Bug ID: 119770 Summary: FLOAT-DECIMAL support + "cannot MOVE '_stack1'" Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: cobol Assignee: unassigned at gcc dot gnu.org Reporter: simonsobisch at gnu dot org Target Milestone: --- Sample program showing these issues this: IDENTIFICATION DIVISION. PROGRAM-ID. floating. DATA DIVISION. WORKING-STORAGE SECTION. 01 D-FLOAT-DECIMAL-16 USAGE FLOAT-DECIMAL-16. 01 D-FLOAT-DECIMAL-34 USAGE FLOAT-DECIMAL-34. PROCEDURE DIVISION. MOVE FUNCTION PI TO D-FLOAT-DECIMAL-16 D-FLOAT-DECIMAL-34 * DISPLAY D-FLOAT-DECIMAL-16 DISPLAY D-FLOAT-DECIMAL-34 * goback. floating.cbl:6:38: sorry, unimplemented: USAGE type: FLOAT_DECIMAL 6 |01 D-FLOAT-DECIMAL-16 USAGE FLOAT-DECIMAL-16. | ^ floating.cbl:6:38: error: syntax error, unexpected FLOAT-DECIMAL floating.cbl:7:38: sorry, unimplemented: USAGE type: FLOAT_DECIMAL 7 |01 D-FLOAT-DECIMAL-34 USAGE FLOAT-DECIMAL-34. | ^ floating.cbl: error: cannot MOVE '_stack1' (FldFloat) to 'D-FLOAT-DECIMAL-16' (Fld) cobol1: error: failed compiling floating.cbl Note: other types (FLOAT-BINARY-..., FLOAT-...) seem to be supported, at least they don't raise an error. I consider this a less important issue, but would suggest to: * now: fix that MOVE '_stack1' part * now/soon: change "sorry, unimplemented: USAGE type: FLOAT_DECIMAL" to "sorry, unimplemented: USAGE type FLOAT-DECIMAL" (or just a plain error) * someday: implement them
[Bug cobol/119331] cobol: unimplemented exceptions abort compilation - even if requested to NOT use them
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119331 --- Comment #1 from Simon Sobisch --- Side note: there's a working patch for gcobc at https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680218.html which improves it in general - but this part was explicit left out
[Bug cobol/119809] New: FE internal_error internal compiler error: in digits_from_float128, at cobol/genapi.cc:15293 (bit data items)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119809 Bug ID: 119809 Summary: FE internal_error internal compiler error: in digits_from_float128, at cobol/genapi.cc:15293 (bit data items) Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: cobol Assignee: unassigned at gcc dot gnu.org Reporter: simonsobisch at gnu dot org Target Milestone: --- bacxktrace 0x25f146f internal_error(char const*, ...) /home/so/gcc-cobol/gcc/diagnostic-global-context.cc:517 0xa83577 fancy_abort(char const*, int, char const*) /home/so/gcc-cobol/gcc/diagnostic.cc:1749 0xaead7c digits_from_float128 /home/so/gcc-cobol/gcc/cobol/genapi.cc:15293 0xaf0593 initial_from_float128 /home/so/gcc-cobol/gcc/cobol/genapi.cc:15654 0xaf0593 parser_symbol_add(cbl_field_t*) /home/so/gcc-cobol/gcc/cobol/genapi.cc:16778 0xbd20f7 symbols_update(unsigned long, bool) /home/so/gcc-cobol/gcc/cobol/symbols.cc:1853 0xb0df8d data_division_ready /home/so/gcc-cobol/gcc/cobol/parse_ante.h:3231 0xb15168 yyparse() /home/so/gcc-cobol/gcc/cobol/parse.y:1380 0xbdd639 parse_file /home/so/gcc-cobol/gcc/cobol/util.cc:2130 0xbdd639 cobol_parse_files(int, char const**) /home/so/gcc-cobol/gcc/cobol/util.cc:2191 to reproduce just try to compile identification division. program-id. fbug. data division. working-storage section. 01 fld1. 05 fxx pic 1(1) value 0. procedure division. goback .
[Bug cobol/119364] building a cobol cross compiler on i686-linux-gnu targeting x86_64-linux-gnu fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119364
Simon Sobisch changed:
What|Removed |Added
CC||simonsobisch at gnu dot org
--- Comment #22 from Simon Sobisch ---
(In reply to Matthias Klose from comment #21)
> the attached patch doesn't apply anymore for the 15.1.0 release, and the
> build on i686 fails with
>
> In file included from ../../src/gcc/cobol/cdf.y:37:
> ../../src/gcc/cobol/../../libgcobol/common-defs.h:186:23: error: enumerator
> value '4294967296' is outside the range of underlying type 'size_t' {aka
> 'unsigned int'}
> 186 | depends_on_e = 0x01, // A group hierachy contains a
> DEPENDING_ON
> | ^~~~
> ../../src/gcc/cobol/../../libgcobol/common-defs.h:187:23: error: enumerator
> value '8589934592' is outside the range of underlying type 'size_t' {aka
> 'unsigned int'}
> 187 | initialized_e = 0x02, // Don't call parser_initialize
> from parser_symbol_add
> | ^~~~
At least that one would be easily solvable by applying the last part of Jakub's
original patch:
--- libgcobol/common-defs.h.jj 2025-04-05 15:37:29.439058824 +0200
+++ libgcobol/common-defs.h 2025-04-05 15:38:05.024579514 +0200
@@ -146,7 +146,7 @@ enum cbl_field_type_t {
* A field is padded (in the unjustified direction) either with 0 or SPC.
* (But maybe the fill character should just be an explicit character.)
*/
-enum cbl_field_attr_t : size_t {
+enum cbl_field_attr_t : uint64_t {
@Bob: is there a reason to not apply the rebased patch from Jakub, even if
32bit is currently explicit out of scope?
[Bug cobol/119790] New: FE (parser): CONSTANT AS figurative-constant broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119790 Bug ID: 119790 Summary: FE (parser): CONSTANT AS figurative-constant broken Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: cobol Assignee: unassigned at gcc dot gnu.org Reporter: simonsobisch at gnu dot org Target Milestone: --- This also applies to the common extension level 78 01 const-figurative-1 constant as space. 78 const-figurative-2 value space. error: syntax error, unexpected SPACES 186 |01 const-figurative-1 constant as space. | ^ error: syntax error, unexpected SPACES 187 |78 const-figurative-2 value space. | ^ same for low-value and others, so most likely a minor parser issue with bigger effect.
[Bug cobol/119805] New: COMP-5 / COMP-X issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119805 Bug ID: 119805 Summary: COMP-5 / COMP-X issues Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: cobol Assignee: unassigned at gcc dot gnu.org Reporter: simonsobisch at gnu dot org Target Milestone: --- program-id. cx. data division. working-storage section. 77 varcomp-x pic x(08). procedure division. move 1230 to var goback . this code does not compile 4:29: error: cannot set USAGE of var to Alphanumeric (from NumericBin5) 4 |77 varcomp-x pic x(08). | ^ it should compile with -dialect mf and gnu; when changing to comp-5 it does compile with dialect mf but should also compile with dialect gnu; in all cases those define an 8 byte machine-native numeric binary (=binary truncation/overflow/max-val) COMP-X may only be positive, PIC X is always positive.
[Bug cobol/119759] LICENSE file in gcc/cobol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119759 --- Comment #3 from Simon Sobisch --- Note "Copyright (c) 2021-2025 Symas Corporation" is also part of several files, for example gcc/gcobol/parse.y
[Bug cobol/119759] New: LICENSE file in gcc/cobol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119759 Bug ID: 119759 Summary: LICENSE file in gcc/cobol Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: cobol Assignee: unassigned at gcc dot gnu.org Reporter: simonsobisch at gnu dot org Target Milestone: --- As far as I know this file should be deleted.
[Bug cobol/119825] gcobol XML generate forces bug report
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119825 --- Comment #2 from Simon Sobisch --- looks like the error comes from name resolution and is also reproducible with a much more simple Program-id. NofBug. Data division. Working-storage section. 01 billTo. 10 name pic x(30). Procedure division. m. Move 'Robert Smith' to name of billTo Goback . Can someone please change the bug title to "SIGSEGV when using qualified names" and increase importance (that's a core part of the language)?
[Bug cobol/119825] gcobol XML generate forces bug report
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119825 Simon Sobisch changed: What|Removed |Added CC||jklowden at gcc dot gnu.org --- Comment #3 from Simon Sobisch --- OK, no need to increase importance (other than possibly because of the SIGSEGV) as that only happens if the variable qualified is named "NAME" (guess: "NAME OF" is parsed somewhere else).
[Bug cobol/119777] [15 Regression] COBOL '-fsyntax-only', 'RejectNegative'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119777 --- Comment #6 from Simon Sobisch --- Looks good to me (and yes, --include should be possible multiple times), but I haven't tested this or am a maintainer for gcobol... Seems -Wall and --verbose (or -v only?) are different beasts, then.
[Bug cobol/119793] New: FR FE (parser): addition of BASED-STORAGE SECTION (Fujitsu)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119793 Bug ID: 119793 Summary: FR FE (parser): addition of BASED-STORAGE SECTION (Fujitsu) Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: cobol Assignee: unassigned at gcc dot gnu.org Reporter: simonsobisch at gnu dot org Target Milestone: --- This section defines (apart from constants) only BASED storage items with an explicit pointer reference. If used, then it has to be defined as first section in the DATA DIVISION. The pointers may be defined anywhere. ISO COBOL, for example in WORKING-STORAGE section: 01 SOME-VAR-MAY-BE-A-HUGE-RECORD BASED. 05 FILLER PIC X. 01 my-data-ptr POINTER. Then _before the first use_: SET ADDRESS OF SOME-VAR-MAY-BE-A-HUGE-RECORD TO my-data-ptr Side-note: a common _extension_ is allowing to SET the address of any record in LINKAGE section (ISO allows this only if it is explicit BASED) Fujitsu allows _additional_: BASED-STORAGE 01 SOME-VAR-MAY-BE-A-HUGE-RECORD BASED ON my-data-ptr. 05 FILLER PIC X. WORKING-STORAGE (or LINKAGE or wherever) 01 my-data-ptr POINTER. then using the data-item "directly"
[Bug cobol/119632] section segments (cobol85) not implemented, "ignored" -> raising compile error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119632 --- Comment #5 from Simon Sobisch --- @Bob, what do you think of committing that patch as it waits on one of the COBOL maintainers (and later or work on supporting that - at least as "ignored")?
[Bug cobol/119821] New: FE (parser): CONFIGURATION SECTION rejects valid code - empty paragraphs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119821 Bug ID: 119821 Summary: FE (parser): CONFIGURATION SECTION rejects valid code - empty paragraphs Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: cobol Assignee: unassigned at gcc dot gnu.org Reporter: simonsobisch at gnu dot org Target Milestone: --- Given the following COBOL source: program-id. empty. environment division. configuration section. source-computer. object-computer. a compile complains about source-computer not specifying a name (but that's optional): empty.cob:5:4: error: syntax error, unexpected OBJECT COMPUTER, expecting NAME 5 |object-computer. |^ even worse if line 5 is commented out: empty.cob:2:25: error: syntax error, unexpected end of file, expecting NAME 2 |environment division. | ^ I gave adjusting the parser a quick try, but my change had no effect, so I'll need to see once how this is done :-)
[Bug cobol/119810] New: FE: -include does not unset "included from"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119810 Bug ID: 119810 Summary: FE: -include does not unset "included from" Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: cobol Assignee: unassigned at gcc dot gnu.org Reporter: simonsobisch at gnu dot org Target Milestone: --- Given the following COBOL source: PROGRAM-ID. TBUG. DATA DIVISION. and execution of $> echo "">empty $> gcobol -include empty tbug.cob yields In file included from empty:128: tbug.cob:3:10: error: syntax error, unexpected DATA, expecting end of file cobol1: error: failed compiling tbug.cob Obviously the specified source is not included in the one specified via -include but somehow: * there is a line of 128 ?!? * as this line does not exist one cannot see the error in the output (drop the -include and you see the correct position and therefore the text) * somehow there is an include relation * bonus bug (either fix or move out to a separate bug): that code is a valid "program-definition" as there is no mandatory element in data-division and the procedure-division is optional, the compiler should not error but provide an empty function in the resulting object
[Bug cobol/119768] New: FE: parsing PIC N and NAT is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119768 Bug ID: 119768 Summary: FE: parsing PIC N and NAT is broken Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: cobol Assignee: unassigned at gcc dot gnu.org Reporter: simonsobisch at gnu dot org Target Milestone: --- The sample program shows all of those issues: PROGRAM-ID. "NAT". DATA DIVISION. WORKING-STORAGE SECTION. 01 nat pic N(10). PROCEDURE DIVISION. DISPLAY nat GOBACK. nbug.cbl:4:23: error: invalid picture for Alphanumeric-edited 4 |01 nat pic N(10). | ^ nbug.cbl:6:16: error: syntax error, unexpected NAT 6 |DISPLAY nat goback. |^ I _think_ that's a parser only-issue, but for a compiler that targets COBOL2023 a quite severe one.
[Bug cobol/119769] New: FE: GnuCOBOL extension BINARY-C-LONG missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119769 Bug ID: 119769 Summary: FE: GnuCOBOL extension BINARY-C-LONG missing Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: cobol Assignee: unassigned at gcc dot gnu.org Reporter: simonsobisch at gnu dot org Target Milestone: --- The sample program shows this: PROGRAM-ID. "NAT". DATA DIVISION. WORKING-STORAGE SECTION. 01 c-long USAGE BINARY-C-LONG VALUE 1. PROCEDURE DIVISION. DISPLAY c-long GOBACK. > error: DATA-ITEM 'BINARY-C-LONG' not found This should be at least supported for -dialect gnu (GnuCOBOL) as it is commonly used there to write portable code that defines it identical to GCC (or other compiler's) definition of the C data type "long int". I _think_ that should be an easy addition.
[Bug cobol/119883] New: codegen: recursive user-defined functions don't run recursive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119883 Bug ID: 119883 Summary: codegen: recursive user-defined functions don't run recursive Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: cobol Assignee: unassigned at gcc dot gnu.org Reporter: simonsobisch at gnu dot org Target Milestone: --- Code example: IDENTIFICATION DIVISION. FUNCTION-ID. foo. DATA DIVISION. WORKING-STORAGE SECTION. 01 ttl PIC 9 VALUE 1. LOCAL-STORAGE SECTION. 01 num PIC 9. LINKAGE SECTION. 01 arg PIC 9. 01 ret PIC 9. PROCEDURE DIVISION USING arg RETURNING ret. IF arg < 5 ADD 1 TO arg GIVING num END-ADD MOVE FUNCTION foo (num) TO ret ELSE MOVE arg TO ret END-IF DISPLAY "Step: " ttl ", Arg: " arg ", Return: " ret END-DISPLAY ADD 1 to ttl END-ADD GOBACK. END FUNCTION foo. IDENTIFICATION DIVISION. PROGRAM-ID. prog. ENVIRONMENT DIVISION. CONFIGURATION SECTION. REPOSITORY. FUNCTION foo. DATA DIVISION. WORKING-STORAGE SECTION. 01 num PIC 9 VALUE 1. PROCEDURE DIVISION. DISPLAY "Return value '" FUNCTION foo (num) "'" WITH NO ADVANCING END-DISPLAY GOBACK. END PROGRAM prog. result (-expected +current head) -Step: 1, Arg: 5, Return: 5 -Step: 2, Arg: 4, Return: 5 -Step: 3, Arg: 3, Return: 5 -Step: 4, Arg: 2, Return: 5 -Step: 5, Arg: 1, Return: 5 -Return value '5' +Return value '0'
[Bug cobol/119886] New: runtime-switches are not documented / implemented (and don
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119886 Bug ID: 119886 Summary: runtime-switches are not documented / implemented (and don Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: cobol Assignee: unassigned at gcc dot gnu.org Reporter: simonsobisch at gnu dot org Target Milestone: ---
[Bug cobol/119885] New: libgcobol: SQRT wrong argument check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119885 Bug ID: 119885 Summary: libgcobol: SQRT wrong argument check Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: cobol Assignee: unassigned at gcc dot gnu.org Reporter: simonsobisch at gnu dot org Target Milestone: --- The following code works as expected as long as runtime exceptions are not enabled: program-id. sqbug. procedure division. IF FUNCTION SQRT (0) = 0*>IF4034.2 DISPLAY 'OK' ELSE DISPLAY 'BAD'. GOBACK. Compiling with -fcobol-exceptions=EC-ALL raises the following runtime error, though: sqbug.cob:3:FUNCTION EC-ARGUMENT-FUNCTION (Function argument error) While the standard defines > The value of argument-1 shall be zero or positive
[Bug cobol/119887] New: runtime-switches are not documented / implemented (and don't pass NC211A and others)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119887 Bug ID: 119887 Summary: runtime-switches are not documented / implemented (and don't pass NC211A and others) Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: cobol Assignee: unassigned at gcc dot gnu.org Reporter: simonsobisch at gnu dot org Target Milestone: --- Switches are a feature defined in COBOL 2023. The implementor-defined list (annex A) says that the imlementor should defined the supported switch-names as well as if they are able to be toggled via SET and how they may be set otherwise (GnuCOBOL uses an environment variable, other compilers use switches to the module-runner - which gcobol does not have). NIST tests in NC the support for some switches explicit (if I remember correctly their names can be changed via configuration). The GnuCOBOL config for NIST85 use the commonly available names SWITCH-1 to SWITCH-9 (supporting and documenting much more, including the RM/COBOL / ACUCOBOL SWITCH-A...-Z. gcobol.1 should document what is supported, and it is likely very reasonable to support at least SWITCH-0 to SWITCH-9 (and possibly provide a way outside of COBOL to set those switches). Example from NC211A 003500 SPECIAL-NAMES. NC2114.2 003600 SWITCH-1 NC2114.2 003700 IS WRK-SWITCH-1 NC2114.2 003800 ON STATUS IS ON-WRK-SWITCH-1 NC2114.2 003900 OFF STATUS IS OFF-WRK-SWITCH-1 NC2114.2 004000 SWITCH-2 NC2114.2 004100 IS WRK-SWITCH-2 NC2114.2 004200 OFF STATUS IS OFF-WRK-SWITCH-2. NC2114.2 currently leading to NC211A.CBL:36:12: error: is not a device name 36 | 003600 SWITCH-1 NC2114.2 |^ NC211A.CBL:38:12: error: syntax error, unexpected ON, expecting '.' 38 | 003800 ON STATUS IS ON-WRK-SWITCH-1 NC2114.2 |^ cobol1: error: failed compiling NC211A.CBL
[Bug cobol/119521] gcc-cobol generated programs with memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119521 --- Comment #3 from Simon Sobisch --- Note: some people will argue that the program should only abort, because/when exception checking is on. At least if it is, libgcobol needs to save the location, statement, file and exception that happened (for later query with related intrinsic, if it isn't enabled then internally the io status, which should be part of the internal file structure, is enough). Maybe the exception parts effectively do a malloc instead of realloc (you'll possibly memcpy if already allocated, of course)?
[Bug cobol/119521] gcc-cobol generated programs with memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119521 --- Comment #4 from Simon Sobisch --- Am 28. März 2025 15:40:49 GMT-12:00 schrieb "rdubner at gcc dot gnu.org" : >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119521 > >--- Comment #2 from Robert Dubner --- >Additional: The leaking memory is because exception checking is turned on. >Still looking... > Note: one could argue that the program should only abort because/when exception checking is on. At least if it is, libgcobol needs to save the location, statement, file and exception that happened (for later query with related intrinsic, if it isn't enabled then internally the io status, which should be part of the internal file structure, is enough). Maybe the exception parts effectively do a malloc instead of realloc (you'll possibly memcpy if already allocated, of course)?
[Bug other/113168] ABOUT-NLS seems way out of date
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113168 Simon Sobisch changed: What|Removed |Added CC||simonsobisch at gnu dot org --- Comment #2 from Simon Sobisch --- So... should ABOUT-NLS be updated for GCC15? If I read the git log correctly the current file was installed by Zack Weinberg 21 years old and therefore includes http links and a "status" of the translation project which is more than outdated. Bruno Haible adjusted the file within gettext in 2019 to the link-only, see https://git.savannah.gnu.org/gitweb/?p=gettext.git;a=commit;h=6b40c1fa79d8d593f77120444dc3aa22293b5bcb Maybe CC both (not sure how that is done in the interface) to get to a "final decision"?
[Bug cobol/119455] New: gcobol: needs optimization for direct assignments (don't call into runtime)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119455 Bug ID: 119455 Summary: gcobol: needs optimization for direct assignments (don't call into runtime) Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: cobol Assignee: unassigned at gcc dot gnu.org Reporter: simonsobisch at gnu dot org Target Milestone: --- Sample program: ~~~ PROGRAM-ID. STRMOV. DATA DIVISION. WORKING-STORAGE SECTION. 77 dat pic x. PROCEDURE DIVISION. move 'a' to dat STOP RUN. ~~~ This program has a single byte data field and assigns a single-byte. While this assignment can easily be "inlined", it currently uses a call into libgcobol. To reproduce: ~~~ gcobol -g STRMOV.cob gdb -batch -ex "set disassemble-next-line on" -ex "b STRMOV.cob:6" -ex run a.out ~~~ Result: ~~~ Breakpoint 1, strmov () at STRMOV.cob:6 6move 'a' to dat => 0x00401572 : 48 c7 85 20 ff ff ff 00 00 00 00 movq $0x0,-0xe0(%rbp) 0x0040157d : 48 c7 85 18 ff ff ff 00 00 00 00 movq $0x0,-0xe8(%rbp) 0x00401588 : 48 8b 85 18 ff ff ffmov -0xe8(%rbp),%rax 0x0040158f : 41 b9 01 00 00 00 mov $0x1,%r9d 0x00401595 : 41 b8 36 17 40 00 mov $0x401736,%r8d 0x0040159b : b9 07 00 00 00 mov$0x7,%ecx 0x004015a0 : ba 01 00 00 00 mov$0x1,%edx 0x004015a5 : 48 89 c6mov%rax,%rsi 0x004015a8 : bf a0 21 60 00 mov$0x6021a0,%edi 0x004015ad : e8 0e fa ff ff callq 0x400fc0 <__gg__move_literala@plt> ~~~
[Bug cobol/119457] New: gcobol: big codegen for simple STRING plus malloc/free (and missing optimization)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119457 Bug ID: 119457 Summary: gcobol: big codegen for simple STRING plus malloc/free (and missing optimization) Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: cobol Assignee: unassigned at gcc dot gnu.org Reporter: simonsobisch at gnu dot org Target Milestone: --- Sample program: ~~~ PROGRAM-ID. STRMOV. DATA DIVISION. WORKING-STORAGE SECTION. 77 dat pic x. PROCEDURE DIVISION. STRING 'a' INTO dat STOP RUN. ~~~ This program has a single byte data field and overwrites its first byte by a literal. While this assignment can easily be handled as in internal MOVE (because it overwrites all storage and as it is a single-byte item that's even an easily inlined assignment), it currently does a lot of stuff (presumably preparation for the complex STRING verb which can do a lot - just not doing it in that case) before calling into libgcobol, surrounded by allocating a temporary item using malloc/free. To reproduce: ~~~ gcobol -g STRMOV.cob gdb -batch -ex "set disassemble-next-line on" -ex "b STRMOV.cob:6" -ex run a.out ~~~ Result: ~~~ Breakpoint 1, strmov () at STRMOV.cob:6 6string 'a' into dat => 0x004016e2 : bf 10 00 00 00 mov$0x10,%edi 0x004016e7 : e8 f4 fa ff ff callq 0x4011e0 0x004016ec : 48 89 05 1d 11 20 00mov %rax,0x20111d(%rip)# 0x602810 0x004016f3 : 48 8b 05 16 11 20 00mov 0x201116(%rip),%rax# 0x602810 0x004016fa : ba 00 00 00 00 mov$0x0,%edx 0x004016ff : 48 01 d0add%rdx,%rax 0x00401702 : 48 c7 00 01 00 00 00movq $0x1,(%rax) 0x00401709 : 48 8b 05 00 11 20 00mov 0x201100(%rip),%rax# 0x602810 0x00401710 : ba 08 00 00 00 mov$0x8,%edx 0x00401715 : 48 01 d0add%rdx,%rax 0x00401718 : 48 c7 00 01 00 00 00movq $0x1,(%rax) 0x0040171f : 48 8b 05 9a 10 20 00mov 0x20109a(%rip),%rax# 0x6027c0 <__gg__treeplet_1f> 0x00401726 : ba 00 00 00 00 mov$0x0,%edx 0x0040172b : 48 01 d0add%rdx,%rax 0x0040172e : 48 c7 00 a0 21 60 00movq $0x6021a0,(%rax) 0x00401735 : 48 c7 85 20 ff ff ff 00 00 00 00 movq $0x0,-0xe0(%rbp) 0x00401740 : 48 8b 05 81 10 20 00mov 0x201081(%rip),%rax# 0x6027c8 <__gg__treeplet_1o> 0x00401747 : ba 00 00 00 00 mov$0x0,%edx 0x0040174c : 48 01 c2add%rax,%rdx 0x0040174f : 48 8b 85 20 ff ff ffmov -0xe0(%rbp),%rax 0x00401756 : 48 89 02mov%rax,(%rdx) 0x00401759 : 48 8b 05 30 10 20 00mov 0x201030(%rip),%rax# 0x602790 <__gg__treeplet_1s> 0x00401760 : ba 00 00 00 00 mov$0x0,%edx 0x00401765 : 48 01 d0add%rdx,%rax 0x00401768 : 48 c7 00 01 00 00 00movq $0x1,(%rax) 0x0040176f : 48 8b 05 4a 10 20 00mov 0x20104a(%rip),%rax# 0x6027c0 <__gg__treeplet_1f> 0x00401776 : ba 08 00 00 00 mov$0x8,%edx 0x0040177b : 48 01 d0add%rdx,%rax 0x0040177e : 48 c7 00 00 00 00 00movq $0x0,(%rax) 0x00401785 : 48 8b 05 3c 10 20 00mov 0x20103c(%rip),%rax# 0x6027c8 <__gg__treeplet_1o> 0x0040178c : ba 08 00 00 00 mov$0x8,%edx 0x00401791 : 48 01 d0add%rdx,%rax 0x00401794 : 48 c7 00 00 00 00 00movq $0x0,(%rax) 0x0040179b : 48 8b 05 ee 0f 20 00mov 0x200fee(%rip),%rax# 0x602790 <__gg__treeplet_1s> 0x004017a2 : ba 08 00 00 00 mov$0x8,%edx 0x004017a7 : 48 01 d0add%rdx,%rax 0x004017aa : 48 c7 00 00 00 00 00movq $0x0,(%rax) 0x004017b1 : 48 8b 05 08 10 20 00mov 0x201008(%rip),%rax# 0x6027c0 <__gg__treeplet_1f> 0x004017b8 : ba 10 00 00 00 mov$0x10,%edx 0x004017bd : 48 01 d0add%rdx,%rax 0x004017c0 : 48 c7 00 00 00 00 00movq $0x0,(%rax) 0x004017c7 : 48 8b 05 fa 0f 20 00mov 0x200ffa(%rip),%rax# 0x6027c8 <__gg__treeplet_1o> 0x004017ce : ba 10 00 00 00 mov$0x10,%edx 0x004017d3 : 48 01 d0add%rdx,%rax 0x004017d6 : 48 c7 00 00 00 00 00movq $0x0,(%rax) 0x004017dd : 48 8b 05 ac 0f 20 00mov 0x200fac(%rip),%rax# 0x602790 <__gg__treeplet_1s> 0x004017e4 : ba
[Bug cobol/119632] New: section segments (cobol85) not implemented, "ignored" -> raising compile error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119632 Bug ID: 119632 Summary: section segments (cobol85) not implemented, "ignored" -> raising compile error Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: cobol Assignee: unassigned at gcc dot gnu.org Reporter: simonsobisch at gnu dot org Target Milestone: --- testing NIST (executed from gnucobol source tree, using a modified gcobc and manually adjusting EXEC85 to allow newcob.val to be found) showed that gcobol _knows_ about section segments, but currently cannot ignore it (which it should, with a warning message): lib/OBIC2A.CBL:130:24: sorry, unimplemented: SECTION segment 30. was ignored 130 | 013000 SECT-IC219-0001 SECTION 30. OBIC24.2 |^ lib/OBIC2A.CBL:144:24: sorry, unimplemented: SECTION segment 60. was ignored 144 | 014400 SECT-IC219-0002 SECTION 60. OBIC24.2 |^ lib/OBIC2A.CBL:199:24: sorry, unimplemented: SECTION segment 80. was ignored 199 | 019900 SECT-IC219-0003 SECTION 80. OBIC24.2 |^ Unexpected status 256 for module lib/OBIC2A.CBL The message already says "ignored" and there should be a warning option for that (either that specific or a general "-Wignored" one) which allows to raise that to an error - but it shouldn't default to an error (not sure what the return value of 256 means).
[Bug cobol/119637] New: link error for LINAGE-COUNTER
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119637 Bug ID: 119637 Summary: link error for LINAGE-COUNTER Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: cobol Assignee: unassigned at gcc dot gnu.org Reporter: simonsobisch at gnu dot org Target Milestone: --- /usr/bin/ld: /tmp/ccYvTtCh.o: in function `sq201m': /home/simon/gnucobol-build/3.x/tests/cobol85/SQ/SQ201M.CBL:317:(.text+0xbf2e): undefined reference to `__gg__linage_counter' /usr/bin/ld: /home/simon/gnucobol-build/3.x/tests/cobol85/SQ/SQ201M.CBL:327:(.text+0xca15): undefined reference to `__gg__linage_counter' /usr/bin/ld: /home/simon/gnucobol-build/3.x/tests/cobol85/SQ/SQ201M.CBL:357:(.text+0xe74f): undefined reference to `__gg__linage_counter' /usr/bin/ld: /home/simon/gnucobol-build/3.x/tests/cobol85/SQ/SQ201M.CBL:367:(.text+0xf236): undefined reference to `__gg__linage_counter' /usr/bin/ld: /home/simon/gnucobol-build/3.x/tests/cobol85/SQ/SQ201M.CBL:380:(.text+0xfcc2): undefined reference to `__gg__linage_counter' /usr/bin/ld: /tmp/ccYvTtCh.o:/home/simon/gnucobol-build/3.x/tests/cobol85/SQ/SQ201M.CBL:390: more undefined references to `__gg__linage_counter' follow collect2: error: ld returned 1 exit status
[Bug cobol/119521] gcc-cobol generated programs with memory leak
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119521 --- Comment #6 from Simon Sobisch --- I wanted to originally say that's fixed (the memory leak in EXEC85 is), but running NIST DB105A still produces the same issue. heaptrack shows 34,4GB leaked, most allocations (256+63) come from allocate in lbgcobol.so.1 and its flamegraph say that nearly all come from __gg__pseudo_return_path
[Bug cobol/119633] New: compile error for debug-module USE FOR DEBUGGING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119633 Bug ID: 119633 Summary: compile error for debug-module USE FOR DEBUGGING Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: cobol Assignee: unassigned at gcc dot gnu.org Reporter: simonsobisch at gnu dot org Target Milestone: --- As shown in NIST DB303M DB303M.CBL:33:37: error: syntax error, unexpected NAME, expecting PROCEDURES 33 | 003300 USE FOR DEBUGGING ON ALL REFERENCES OF FREC. DB3034.2 | ^ DB303M.CBL:33:8: error: missing END DECLARATIVES or SECTION name 33 | 003300 USE FOR DEBUGGING ON ALL REFERENCES OF FREC. DB3034.2 |^ cobol1: error: failed compiling DB303M.CBL If it _should_ work (the feature was already obsolete in COBOL85 and dropped with COBOL2002), then the parser needs to be updated. If the feature is not planned to be supported, then the parser should consume and warn/error. If that specific test should be passed then gcobol needs an option to flag obsolete and archaic items (ideally for COBOL85, for COBOL2002, ...). I suggest to fix the parser error via this bug report, then open a new one with the decision which way further to take (things like flagging obsolete per standard can definitely be added with a later release, a possible implementation of that feature as well).
[Bug cobol/119638] New: WRITE FROM x BEFORE Y raises compile error (SQ207M)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119638 Bug ID: 119638 Summary: WRITE FROM x BEFORE Y raises compile error (SQ207M) Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: cobol Assignee: unassigned at gcc dot gnu.org Reporter: simonsobisch at gnu dot org Target Milestone: --- SQ207M.CBL:36:12: error: is not a device name 36 | 003600 FORMFEED SQ2074.2 |^ SQ207M.CBL:325:46: error: syntax error, unexpected end of file 325 | 037300 WRITE PRINT-REC FROM BEFORE-MSG-1 BEFORE ADVANCING SQ2074.2 | ^ SQ207M.CBL:326:12: warning: could not resolve paragraph (or section) 'WRITE-TEST-LINE' at line 324 326 | 037400 MNEMONIC-NAME. SQ2074.2 |^ SQ207M.CBL:326:12: warning: SQ207M calls external symbol ':ambiguous:' cobol1: error: failed compiling SQ207M.CBL that mnemonic name and that strange external are other cases, but I leave inspecting / opening bug reports for those to others.
[Bug cobol/119254] ICE on unterminated cobol string due to use of cbl_internal_error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119254 Simon Sobisch changed: What|Removed |Added CC||simonsobisch at gnu dot org --- Comment #1 from Simon Sobisch --- the same issue, just with another stack, happens in NIST SM101A
[Bug cobol/119639] New: runtime switches in SPECIAL NAMES not recognised (parser issue)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119639 Bug ID: 119639 Summary: runtime switches in SPECIAL NAMES not recognised (parser issue) Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: cobol Assignee: unassigned at gcc dot gnu.org Reporter: simonsobisch at gnu dot org Target Milestone: --- In file included from SM203A.CBL:38: ../copy/K3SNB:37:99: error: is not a device name ../copy/K3SNB:2:12: error: syntax error, unexpected ON, expecting '.' 2 | 000200 IS DUMMY-SW-1 K3SNB4.2 |^ cobol1: error: failed compiling SM203A.CBL
[Bug cobol/119634] New: compile error: sorry, unimplemented: Global declarative _DECLARATIVES_EVAL1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119634 Bug ID: 119634 Summary: compile error: sorry, unimplemented: Global declarative _DECLARATIVES_EVAL1 Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: cobol Assignee: unassigned at gcc dot gnu.org Reporter: simonsobisch at gnu dot org Target Milestone: --- As seen in NIST IC233A, IC234A and IC401M: warning: --debug implies -fstack-check: ignored IC234A.CBL:482:12: sorry, unimplemented: Global declarative _DECLARATIVES_EVAL1 for IC234A 482 | 048400 ADD 2 TO DILFRAP. IC2344.2 |^ IC234A.CBL:606:12: sorry, unimplemented: Global declarative _DECLARATIVES_EVAL1 for IC234A 606 | 060800 ADD 4 TO DILFRAP. IC2344.2 |^ IC234A.CBL:726:8: sorry, unimplemented: Global declarative _DECLARATIVES_EVAL1 for IC234A 726 | 072800 SECT-IC234A-3-001 SECTION. IC2344.2 |^ IC234A.CBL:728:16: sorry, unimplemented: Global declarative _DECLARATIVES_EVAL1 for IC234A 728 | 073000 OPENINPUT TEST-FILE. IC2344.2 |^ IC234A.CBL:729:20: sorry, unimplemented: Global declarative _DECLARATIVES_EVAL1 for IC234A 729 | 073100 READTEST-FILE. IC2344.2 |^ IC234A.CBL:730:17: sorry, unimplemented: Global declarative _DECLARATIVES_EVAL1 for IC234A 730 | 073200 EXIT PROGRAM. IC2344.2 | ^ IC234A.CBL:732:81: sorry, unimplemented: Global declarative _DECLARATIVES_EVAL1 for IC234A 732 | 073400 END PROGRAM IC234A-3. IC2344.2 | ^ looks like an internal compiler bug.
[Bug cobol/119636] New: compile error: gcobol1 does not find file descriptions in case of obsolete FD phrases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119636 Bug ID: 119636 Summary: compile error: gcobol1 does not find file descriptions in case of obsolete FD phrases Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: cobol Assignee: unassigned at gcc dot gnu.org Reporter: simonsobisch at gnu dot org Target Milestone: --- IX302M.CBL:15:19: error: line 19: TFIL lacks a file description 15 | 001500 SELECT TFIL ASSIGN IX3024.2 | ^ cobol1: error: failed compiling IX302M.CBL The code from NIST in question is: 003300 DATA DIVISION. IX3024.2 003400 FILE SECTION. IX3024.2 003500 FD TFIL IX3024.2 003600 LABEL RECORDS STANDARD IX3024.2 003700*Message expected for above statement: OBSOLETE IX3024.2 003800 IX3024.2 003900 VALUE OF IX3024.2 004000 OCLABELID IX3024.2 004100 IS IX3024.2 004200 "OCDUMMY" IX3024.2 004300*Message expected for above statement: OBSOLETE IX3024.2 004400 IX3024.2 004500 DATA RECORDS ARE FREC. IX3024.2 004600*Message expected for above statement: OBSOLETE IX3024.2 004700 IX3024.2 004800 01 FREC. IX3024.2 004900 03 RKEY PIC X(8). IX3024.2 So "obviously" FD TFIL has a lot of noise, but it still should be recognised. Why is that important: old code was not changed and still has this (at least expect that in mainframe code).
[Bug cobol/119769] FE: GnuCOBOL extension BINARY-C-LONG missing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119769 Simon Sobisch changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED |--- --- Comment #2 from Simon Sobisch --- I agree that this provides a good fix in general and something that may be useful to fix this bug - but this bug is still open: * if "-dialect gnu" is used, then there should be no additional line needed * at least if the gcobc wrapper script is used, that should not be necessary (I'd prefer that to be implemented via -dialect, not via a hack that uses --include binary-c-long.cpy with the code suggested) * the suggested workaround only works correctly for 64bit gcc environments, in 32bit it would equate to BINARY-LONG (not sure if conditional compilation works again in gcobol and I haven't checked its manpage for implicit defined compiler constants that can be used to check for 32bit OS which may be used here)
[Bug cobol/119335] cobol frontend ignores -M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119335 --- Comment #2 from Simon Sobisch --- That's totally fine if those are _really_ the files read-in as copybooks (if they were opened with an extension, then of course this should be in).
[Bug cobol/119632] section segments (cobol85) not implemented, "ignored" -> raising compile error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119632 --- Comment #7 from Simon Sobisch --- I think https://gitlab.cobolworx.com/COBOLworx/gcc-cobol/-/commit/9c2fcd3606662e550aea6173b06bc2a500b2ac52 is the right approach (adding a warning later, syntax-check if not iso, otherwise abort). But it should really do that - and allow it for _any_ other standard, not only ibm.
[Bug cobol/119636] compile error: gcobol1 does not find file descriptions in case of obsolete FD phrases
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119636 --- Comment #4 from Simon Sobisch --- Please reopen as this is not about doing anything with the obsolete code in any way, but ignoring = "parse in the water". The main issue is that the FD is not recognized any more, and yes, there are a lot of existing code bases (MF and others raise a warning "ignored", if you enable those warnings) that have "VALUE OF" and "LABEL RECORDS" in, some also that include "DATA RECORDS". The important stuff is still recognised correctly with other compilers: 003300 DATA DIVISION. 003400 FILE SECTION. 003500 FD TFIL. 004800 01 FREC. 004900 03 RKEY PIC X(8). while gcobol 15.1 complains about the missing FD definition for TFIL.
[Bug target/120417] gcc -m32 -O1 codegen error, leading to SIGSEGV, workaround -fno-tree-coalesce-vars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120417 --- Comment #9 from Simon Sobisch --- Checked -fstack-reuse=none - same abort. The main issue here is the language this C code has to cover: COBOL allows for any trailing arguments to be "left out". If the COBOL compiler knows about the parameters (via program prototypes, a COBOL2002 "= relative young and not supported by all other compilers"), it adds NULL arguments on the call. The compiler cobc _could_ deduce that as it has one call with 4 arguments, and use that for NULL parameters (this way the numbers are at least identical in the same generated C program, w/wo prototypes). ... of course this may only make recognizing the issue harder (in the case the call comes from two different programs). Would you otherwise suggest to always use -fno-tree-coalesce-vars in the compile (and have an idea how to `possibly do that specific in the architectures that need that)?
[Bug target/120417] gcc -m32 -O1 codegen error, leading to SIGSEGV, workaround -fno-tree-coalesce-vars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120417 --- Comment #7 from Simon Sobisch --- UB may be necessary to trigger that (and with GCC+libc that _does_ work on all environments but GNU/Linux 32bit [in theory it could also be multiarch -m32, but I think that should not make a difference]) :-/
[Bug target/120417] gcc -m32 -O1 codegen error, leading to SIGSEGV, workaround -fno-tree-coalesce-vars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120417 --- Comment #4 from Simon Sobisch --- @sjames: What do you mean with "needs reduction"? And do you intend to do it on your own? [Note: I've reduced the original program that was generated from as much as possible, then also reduced the amount of C code passed to GCC] In any case: can someone please confirm this issue so we have a reasonable status (as noted: two people were already able to reproduce it in different environments using GCC versions 9-12 + 14)? It also would be interesting to see if trunk still has this issue (I guess "yes")...
[Bug target/120417] gcc -m32 -O1 codegen error, leading to SIGSEGV, workaround -fno-tree-coalesce-vars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120417 --- Comment #3 from Simon Sobisch --- Created attachment 61511 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61511&action=edit save-temps: preprocessed and assembly
[Bug cobol/119809] FE internal_error internal compiler error: in digits_from_float128, at cobol/genapi.cc:15293 (bit data items)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119809 --- Comment #4 from Simon Sobisch --- Looking forward to have a compiler targetting ISO COBOL to support that one day :-) Note: in C this would be a struct with int : 1, included, I think.
[Bug cobol/119810] FE: -include does not unset "included from"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119810 --- Comment #3 from Simon Sobisch --- Current GCC only raises that error if there is no NL after the final (which seems an interesting bug as well), so you won't see that error with the code example. Just use DATA DIVI. (= a syntax error), maybe you see the error then.
[Bug cobol/119632] section segments (cobol85) not implemented, "ignored" -> raising compile error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119632 --- Comment #9 from Simon Sobisch --- Note: GnuCOBOL also support that, just in case a paying customer comes around :-) To not break NIST85 gcobol should set -std=cobol85 to -dialect ibm, with the current implementation. (Note: "stacking" -dialect is something that not a single COBOL compiler I'm aware of does; but I also think something like -std=gnu85 -std=gnumf would be more reasonable)
[Bug cobol/119634] compile error: sorry, unimplemented: Global declarative _DECLARATIVES_EVAL1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119634 --- Comment #1 from Simon Sobisch --- rechecked with today's debian package (now gcc 16), the result is identical, also with -dialect ibm Note: current versions still document the USE statement for procedures https://www.ibm.com/docs/en/cobol-zos/6.4.0?topic=statement-debugging-declarative#LSH-DEBUGGING but as I said before it would also be much better if the parser would be able to understand that (even it it places these parts into the "Sorry" bin) and can go on parsing.
[Bug cobol/119638] WRITE FROM x BEFORE Y raises compile error (SQ207M)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119638 --- Comment #2 from Simon Sobisch --- Ooops - current debian package results in gcobol tests/cobol85/SQ/SQ207M.CBL (null):0: confused by earlier errors, bailing out That seems like a sever bug (@jklowden: feel free to create a new one for this or just fix it apart from this issue)
[Bug cobol/119883] codegen: recursive user-defined functions don't run recursive
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119883 Simon Sobisch changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Simon Sobisch --- It is correct now. Old result: Return value '0' Current result, as expected: Step: 1, Arg: 5, Return: 5 Step: 2, Arg: 4, Return: 5 Step: 3, Arg: 3, Return: 5 Step: 4, Arg: 2, Return: 5 Step: 5, Arg: 1, Return: 5 Return value '5'
[Bug cobol/119821] FE (parser): CONFIGURATION SECTION rejects valid code - empty paragraphs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119821 Simon Sobisch changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Simon Sobisch --- resolved with current debian package
[Bug cobol/119805] FE: COMP-5 / COMP-X issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119805 --- Comment #1 from Simon Sobisch --- still failing with today's package
[Bug cobol/119768] FE: parsing PIC N and NAT is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119768 --- Comment #1 from Simon Sobisch --- still happens; note: for improved error handling the "guessed Alphanumeric-edited" could be used to internally define nat, for example as plain PIC X, that would prevent the second error
[Bug cobol/119520] cobol1: internal compiler error: Segmentation fault (use of field with unknown TYPEDEF)
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/120401] New: gcobol allows arithmetic on alphanumeric fields
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120401 Bug ID: 120401 Summary: gcobol allows arithmetic on alphanumeric fields Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: cobol Assignee: unassigned at gcc dot gnu.org Reporter: simonsobisch at gnu dot org Target Milestone: --- A PIC XX. *> alphanumeric B PIC XBX. *> alphanumeric-edited C PIC 99. COMPUTE B = C * C COMPUTE A = C * C should error, but compiles with gcobol Same may be true with national/national-edited/utf8.
[Bug cobol/119805] FE: COMP-5 / COMP-X issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119805 --- Comment #2 from Simon Sobisch --- ... no, only fails without dialect; with gnu/ibm now compiles
[Bug c/120402] New: gcobol does not check precedence of PIC characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120402 Bug ID: 120402 Summary: gcobol does not check precedence of PIC characters Product: gcc Version: 13.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: simonsobisch at gnu dot org Target Milestone: --- see ISO's table for that; note: U is nearly identical to N for example gcobol currently allows XX.XX while it should only allow for XXBXX.
[Bug cobol/119638] WRITE FROM x BEFORE Y raises compile error (SQ207M)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119638 --- Comment #1 from Simon Sobisch --- ping @jklowden
[Bug cobol/119256] Capture source ranges for tokens in gcobol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119256 Simon Sobisch changed: What|Removed |Added CC||simonsobisch at gnu dot org --- Comment #5 from Simon Sobisch --- Yes, the range is off by one. @jklowden: Is there any reason to not merge the range part in?
[Bug cobol/119332] cobol frontend does not support version dump options specified in --help
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119332 --- Comment #3 from Simon Sobisch --- Instead of "/dev/null" you can also write "banana", it doesn't matter. Seems like the option parsing is broken "somewhere".
[Bug c/120417] New: gcc -m32 -O1 codegen error, leading to SIGSEGV, workaround -fno-tree-coalesce-vars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120417 Bug ID: 120417 Summary: gcc -m32 -O1 codegen error, leading to SIGSEGV, workaround -fno-tree-coalesce-vars Product: gcc Version: 14.2.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: simonsobisch at gnu dot org Target Milestone: --- Created attachment 61501 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61501&action=edit generated sources, cleaned up, showing this issue This was validated to also happened with gcc-9 to gcc-12 and validated to haopen on multiple cpus and operating systems. If compiled with -O1 -fno-tree-coalesce-vars the program runs as expected and returns zero. If ran with only -O1 the following result is seen (this is linked against libcob from GnuCOBOL 3.2+, but the problematic code is all in the attached code) caller.cob:4: attempt to reference invalid memory address (signal SIGSEGV) The reason is that the second command reorders the executions and executes line 152 (which accesses cob_glob_ptr), then does some init, then 163 (where the cob_glob_ptr is unset -> SIGSEGV). It seems that's an issue with multiple optimizations as -O0 -ftree-coalesce-vars does not show the error. The biggest problem here is that -FORTIFY_SOURCE=2 needs -O1 on many setups and therefore "fortification breaks codegen" :-/ valgrind with -fno-tree-coalesece-vars runs through; if not used ==127523== Memcheck, a memory error detector ==127523== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==127523== Using Valgrind-3.22.0 and LibVEX; rerun with -h for copyright info ==127523== Command: ./a.out ==127523== ==127523== Invalid write of size 4 ==127523==at 0x1093C9: caller_ (caller.c:163) ==127523==by 0x109581: caller (caller.c:60) ==127523==by 0x1095B1: main (caller.c:42) ==127523== Address 0x40 is not stack'd, malloc'd or (recently) free'd ==127523== caller.cob:5: attempt to reference invalid memory address (signal SIGSEGV) Test setuo: * get the attached files * get GnuCOBOL 3.3 dev (either from VCS checkout or a pre-built tarball [1]) * configure/make, then either * install and gcc -m32 -O1 caller.c callee.c -g -lcob && ./a.out * or: gcc -m32 -O1 caller.c callee.c -g libcob/.libs/libcob.so && ./a.out as noted, the error vanishes if either -O1 is not used or -fno-tree-coalesce-vars is added Side note: if you see a better way of code-generation: feel free to send me a direct mail. [1]: https://ci.appveyor.com/api/projects/GitMensch/gnucobol-3-x/artifacts/gnucobol-3.3-dev.tar.gz?job=Image:%20Ubuntu2204
[Bug cobol/119454] gcobol: error: unrecognized command-line option ‘-save-temps’
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119454 --- Comment #3 from Simon Sobisch --- The "how to create a bug report" is identical for all GCC frontends (so far). It is documented at https://gcc.gnu.org/bugs/#detailed > In general, all the information we need can be obtained by collecting the > command line below, as well as its output and the preprocessed file it > generates. > >gcc -v -save-temps all-your-options source-file Using it leads to the expected output to stdout, but there are no intermediate files created. Compare that to plain "gcc" on a C file which creates source.i source.s source.o
[Bug cobol/120402] gcobol does not check precedence of PIC characters
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120402 --- Comment #2 from Simon Sobisch --- Yes, U as per currently IBM (the COBOL Development group is in the process of adding it for the next standard). To handle the precedence - feel free to copy GnuCOBOL's implementation in cobc/tree.c, especially (valid_char_order) + (cb_build_picture), also handling U and GCOS' extension L.
[Bug cobol/119633] compile error for debug-module USE FOR DEBUGGING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119633 --- Comment #2 from Simon Sobisch --- Nearly agreed. As long as there is no "WITH DEBUGGING" active (which you can warn or even error on) an indicator D is, just as a * or a / an indicator defining that the line has no executable code. It can also "overlook" the USE FOR DEBUGGING paragraphs, only executing them on explicit PERFORM, that would solve the parser issue and let existing programs be compiled without a recode.
[Bug cobol/119457] gcobol: big codegen for simple STRING plus malloc/free (and missing optimization)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119457 --- Comment #2 from Simon Sobisch --- I tend to disagree as the referenced one is explicit about MOVE (and of course using matching type assignments and functions, possibly split like for strings using memcpy+memset for space is most reasonable because COBOL programs have huge amounts of those), while this is for STRING. This _specific_ STRING can internally be handled as MOVE (because type and length for source and dest are identical), which may be an optimization that can be done before GIMPLE is involved (a follow-up optimisation would be finding if this is also true for one or multiple fixed-length sources that can be handled as multiple MOVE with ref-mod to dest). If the parser internally transfers them, then those will be optimized whenever alphanumeric MOVEs are optimized (possibly Bob's task). The "internal split for fixed-size source to MOVEs" may be branched out to a separate issue (which also doesn't need to be done now [I guess I still haven't implemented that for GC :-)]. Again to this issue: that was about how STRING is handled - there are a lot of malloc/free which may be an easy replace with local storage instead. I suggest to keep this open up for this specific part (and possibly handle that "a bit earlier").
[Bug target/120417] gcc -m32 -O1 codegen error, leading to SIGSEGV, workaround -fno-tree-coalesce-vars
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120417 --- Comment #2 from Simon Sobisch --- I'll provide the result of --save-temps later, so you see both the .i and .s files. Note that to link and run the code you'd have to have a matching GnuCOBOL installation (linked tarball has 5MB and only libgmp-dev dependency, binaries would be 4MB).
