Please adjust the text, there are too many people claiming NIST passing, but in
case of gcobol - that's not true even if you ignore modules that are now
obsolete or archaic.
See my mail on how to run NIST with the GnuCOBOL setup - still too many
failures.
I hope that statement may be true in a
with GCC 15.1 in sight... ping on
gcobc wrapper fixes and additions:
https://gcc.gnu.org/pipermail/gcc-patches/2025-April/680218.html
(note: obviously it would be good if -Wall [1] would work (the "global"
PR for -Wall was postponed to GCC16, so possibly add to gcobol as
intermediate?), then
> You're right: seems to be all about COBOL function names. No idea
what value is appropriate/required here, though.
if this is about COBOL internal function names: ISO says and GnuCOBOL
therefore defines
/* Maximum length of COBOL words */
#define COB_MAX_WORDLEN 63
Note that _extern
Shouldn't that be
--- a/gcc/cobol/parse.y
+++ b/gcc/cobol/parse.y
@@ -337,7 +337,7 @@
%token INVALID
%token NUMBER NEGATIVE
%token NUMSTR"numeric literal"
-%token OVERFLOW
+%token OVERFLOW_kw "OVERFLOW"
%token COMPUTATIONAL
? Otherwise biso
just stumbled over this and only have a mail client running, so...
patch as text. The change is in all those cases: change _ (likely parsed
from the parser or similar) to -.
Kind regards,
Simon
-BASECONVERT BIT_OF BIT_TO_CHAR BOOLEAN_OF_INTEGER BYTE_LENGTH
+BASECONVERT BIT-OF BIT-TO-CHAR BOO
Note that there's still an index.html missing, compare
https://gcc.gnu.org/onlinedocs/gfortran/index.html
and
https://gcc.gnu.org/onlinedocs/gcobol/index.html (not found)
Simon
Am 07.04.2025 um 09:36 schrieb Jakub Jelinek:
On Mon, Apr 07, 2025 at 09:30:59AM +0200, Richard Biener wrote:
On Mon, Apr 7, 2025 at 9:00 AM Simon Sobisch wrote:
My question stands on integrating COBOLworx' UAT as-is for now
(Copyright is all on FSF; built automatically [it is autoconf,
Am 07.04.2025 um 09:30 schrieb Richard Biener:
On Mon, Apr 7, 2025 at 9:00 AM Simon Sobisch wrote:
My question stands on integrating COBOLworx' UAT as-is for now
(Copyright is all on FSF; built automatically [it is autoconf, which is
a requirement for VCS checkouts], possibly also h
My question stands on integrating COBOLworx' UAT as-is for now
(Copyright is all on FSF; built automatically [it is autoconf, which is
a requirement for VCS checkouts], possibly also hooked into the current
test target) - with the goal to get rid of UAT later (next GCC version,
not GCC 15).
T
> Now a question on COBOL:
>
> 77 var8 PIC 999V9(8) COMP-5
>
> what precision/digits does this specify? When then doing
>
> add 0.0001 TO var555 giving var8 rounded
>
> what's the precision/digit specification for the literal floating
> point values and how does that or that of var55
Nice that you have that covered, and thanks for sharing your way there.
I just want to offer an additional thing to consider: different
environments have a different byte-size for the return code (most common
on COBOL for PC is 4, but 2 and 8 also exist).
Micro Focus COBOL and GnuCOBOL have a
cobol-dbg/bin/gcobc COBOL_FLAGS="-fixed -g -Q
-rpath -Q /usr/local/gcobol-dbg/lib64"
(the -fixed is necessary as current gcobol does not deduce the
fixed-format in NIST correctly)
Kind regards,
Simon
From 187bffd7ac3fb6097d99fe54e28853bd7aeda637 Mon Sep 17 00:00:00 2001
From: Simo
Am 20.03.2025 um 21:50 schrieb James K. Lowden:
On Mar 13, 2025, at 8:04 AM, Simon Sobisch wrote:
exit() allows us to "pass to the operating system" directly; but it doesn't directly say
"success" or "fail".
Obviously the statements
STOP RUN WI
Thanks, I agree that the explicit include of library headers from
frontend should include the library folder explicitly.
+cobol/charmaps.cc cobol/valconv.cc: cobol/%.cc: $(LIB_SOURCE)/%.cc
+ -l='ec\|common-defs\|io\|gcobolio\|libgcobol\|gfileio\|charmaps'; \
+ l=$$l'\|valconv\|exceptl'; \
+ sed -e '/^#include/s,"\('$$l'\)\.h","../../libgcobol/\1.h",' $^ > $@
The proposed rule is much better than
> Section 8.3.3.3 of the ISO spec defines both fixed- and floating-point
> numeric literals.
>
> "A fixed-point numeric literal is a character-string whose
> characters are selected from the digits '0' through '9', the plus
> sign, the minus sign, and the decimal point. The implementor shall
> all
> > Implicit criticism about tests accepted. I have 679 UAT tests, and
> > now I've got the bit in my teeth, and I am creating a process that
> > will convert as many as I can to DejaGnu. However: the autom4te and
> > DejaGnu principles, practices, and philosophies are almost, but not
> > quite,
> Secondly, using Windows code page 1252 as a default seems overly
restrictive.
>-static const char standard_internal[] = "CP1252//";
>+static const char standard_internal[] =
>+#if __APPLE__
>+"ISO8859-1";
>+#else
>+"CP1252//";
>+#endif
I'd highly suggest to go with ISO8859-15 in general (=drop
Am 21.03.2025 um 11:50 schrieb Jose E. Marchesi:
Am 20.03.2025 um 21:50 schrieb James K. Lowden:
On Mar 13, 2025, at 8:04 AM, Simon Sobisch wrote:
exit() allows us to "pass to the operating system" directly; but it doesn't directly say
"success" or "fai
Is there a compelling reason for all this output?
As a rule of thumb I'd suggest to only output if the data has an unexpected
value or if the test is about DISPLAY.
... maybe the compiler is expected (and already capable?) to know the data
values and optimize all comparisons away - in this case
Am 17.03.2025 um 18:25 schrieb James K. Lowden:
On Sun, 16 Mar 2025 21:07:39 +0100
Simon Sobisch wrote:
This gives three reference-formats: "fixed" "free" and "extended". For
two of those we have seen the flags -ffixed-form and -ffree-form, so
I'd _gues
> Fixed-form, known as "reference format", is still more-or-less
> required by IBM. Forced in gcobol with the option "-ffixed-form".
> Can be controlled inside a source code file with the compiler
> directive ">> SOURCE FORMAT IS FREE"
>
> Columns 1-6 ignored
> Column7 * for comment, - for
Am 13.03.2025 um 21:35 schrieb David Malcolm:
On Thu, 2025-03-13 at 12:11 +0100, Simon Sobisch wrote:
Thanks for your work on adding a testsuite. Can you please explain
why
you do this when a complete testsuite exists in autoconf (autotest)
format (which roots back to decade of work in
Am 13.03.2025 um 12:49 schrieb Richard Biener:
On Thu, 13 Mar 2025, Sam James wrote:
Simon Sobisch writes:
Thanks for your work on adding a testsuite. Can you please explain why
you do this when a complete testsuite exists in autoconf (autotest)
format (which roots back to decade of work
> Earlier in this discussion of a testsuite, the question came up about
> generating an error return in COBOL source code.
>
> In COBOL, "GOBACK ERROR 1." is the equivalent of a C "return 1;".
> When executed in the initial "top-level" program-id, it results in
> the value 1 being passed back to
Thanks for your work on adding a testsuite. Can you please explain why
you do this when a complete testsuite exists in autoconf (autotest)
format (which roots back to decade of work in GnuCOBOL, with all
copyrights for that already with the FSF)?
Is the existence of this in upstream [1] just u
Hi David - and thanks for posting an outline for libdiagnostics at
https://gcc.gnu.org/wiki/libdiagnostics
Currently this shows both libdiagnosts and libdiagnostics-sarif-dump
integrated into GCC. Is this the plan or would those be available as a
top-level project (the program as an example for
Thank you for your efforts.
Having the wiki page to track this definitely is useful!
I'll have a look at the "real patch" later, likely next week.
But for patch 4+5 which look quite clean: can we get an early
improvement and inclusion into GCC for those?
They only adjust internals and should be
Am 07.11.2023 um 15:59 schrieb David Malcolm:
On Tue, 2023-11-07 at 08:54 +0100, Simon Sobisch wrote:
Thank you for our work and providing this patch.
GCC related questions:
Is it planned to change GCC diagnostics to use libdiagnostic itself?
No. GCC uses C++ internally, and the
Thank you for our work and providing this patch.
GCC related questions:
Is it planned to change GCC diagnostics to use libdiagnostic itself?
Is it planned to "directly" add features or would the result for GCC be
identical (apart from build changes)?
So far it looks like it wouldn't be possi
Thank you very much for this proof-of-concept use!
Inspecting it raises the following questions to me, both for a possible
binutils implementation and for the library use in general:
* How should the application set the relevant context (often lines are
shown before/after)?
* Should it be po
Am 27.05.22 um 20:31 schrieb Eric Gallager:
On Fri, May 27, 2022 at 3:17 AM Simon Sobisch via Gcc-patches
wrote:
[...] the first question is: is it reasonable to add support for
GnuCOBOL?
* How would the demangler know it is to be called? Just "best match"
(GnuCOBOL modules always
;we" or I start?
Thank you for taking the time to read and possibly answer,
Simon Sobisch
Maintainer GnuCOBOL
OpenPGP_0x13E96B53C005604E.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
33 matches
Mail list logo
