Michael, msys2 awaits a business case. The user with a need for it (especially the user who wants support for it) will get our attention. WSL has matured, shall we say, to the point that it should be possible to compile and run COBOL there, while running e.g. VSCodium on Windows for the UI experience. We want to work with a concrete case because for us "works on Windows" is a bit a conundrum. What does "works" mean? Surely users don't want to run COBOL applications on Windows. Already today you can...
GCC COBOL implements all intrinsic functions defined by ISO/IEC 1989:2023, plus a few others. With regard to ISO, most of what is unimplemented versus the current standand also remains unimplmented by other compilers. To my knowledge, for example, no compiler supports all Exception Conditions and some notable ones support none at all. Besides ISO we are adding support for IBM and MF dialects according to the needs of users. As the manual says, if it's missing and you need it, say so. Features are...
@dilodilo, sure, happy to help. Let me try to persuade you that you're making assumptions that are making your life difficult. I don't know the whole answer, but I do know it lies in another direction. You cannot in general "counteract" what TeX will do with your input. Anything you do will be easily overwhelmed by small changes in the TeX environment. You're furthermore complicating your life — and, if you ask me, doing a disservice to the reader — by using a stack of little brackets to represent...
Looking at SYN-Complete-Program-Info.texi, IMO the problem starts there. In general, typesetting tools don't want extra whitespace. If you want to line things up, you have to issue commands in terms of the output. If you're "getting away with it" by using verbatiminclude: @verbatiminclude SYN-\filetex\.texi then I would observe the input is already ragged, e.g. [ OBJECT-COMPUTER. Execution-Computer-Specification. ] [ ~~~~~~~~~~~~~~~ ] [ REPOSITORY. Prototype-Specification... . ] I don't know what's...
We may observe the problem is evident in the HTML, too. (It would be better if the TOC could link to "7. PROCEDURE DIVISION", but I never figured out how to do that.) To figure out what the solution to the issue might be, we need to know what causes it. That is, we need to examine the constructed TeX input, understand what's wrong with it, and then decide whether to change the .gen files that produce it, or the --help output that supplies the original input. Taking PROCEDURE DIVISION as an example,...
../../gcc/cobol/symbols.h:158:1: error: The one definition rule is violated, different classes/structs have the same name 'cbl_domain_elem_t' [ctuOneDefinitionRuleViolation] class cbl_domain_elem_t { ^ /home/jklowden/projects/3rd/gcc/parser/gcc/cobol/symbols.h:158:1: note: The one definition rule is violated, different classes/structs have the same name 'cbl_domain_elem_t' class cbl_domain_elem_t { ^ ../../gcc/cobol/symbols.h:158:1: note: The one definition rule is violated, different classes/structs...
const cdfval_base_t& cdfval_base_t::operator()( const YDFLTYPE& loc ) { static cdfval_t zero(0); return verify_integer(loc, *this) ? *this : zero; } report: ../../gcc/cobol/cdf.y:897:37: error: Reference to temporary returned. [returnTempReference] return verify_integer(loc, *this) ? *this : zero; Neither zero nor *this are temporary. cdfval_base_t is the public base class for cdfval_t.
trunk build failure