Activity for Denis HUGONNARD-ROCHE
-
Denis HUGONNARD-ROCHE posted a comment on discussion GnuCOBOL
Hi Ralph in fact the first + of the ++ expression is the addition operation . The second plus is interpreted as the sign of the field ie positive here a little program to illustrate that . IDENTIFICATION DIVISION. PROGRAM-ID . testplus . *>---------------------------------------------------------------- *> ENVIRONMENT DIVISION. DATA DIVISION . WORKING-STORAGE SECTION. 01 I PIC S9(04) BINARY . 01 J PIC S9(04) BINARY . 01 K PIC S9(04) BINARY . 01 Z PIC S9(04) BINARY . PROCEDURE DIVISION . *> MOVE 1...
-
Code coverage error on Ubuntu 24.04
-
Constant folding does not handle big numbers
-
Hi Simon Found another case IF NOT (NOT () ) THEN Denis
-
Here is another test that fail and the generated C program What is strange is that in the File initialization code the assign field ie f0 is the same than the move statement field h_SYSUT2_FILE->assign = COB_SET_FLD (f0, 4095, b_64, &a_1); / Line: 68 : MOVE : test_5.cbl / cob_set_packed_int (COB_SET_FLD (f0, 3, b_54 + 650, &a_2), 3); Denis IDENTIFICATION DIVISION. PROGRAM-ID. test_5. ENVIRONMENT DIVISION. CONFIGURATION SECTION. SOURCE-COMPUTER. IBM-PC. OBJECT-COMPUTER. IBM-PC. SPECIAL-NAMES. INPUT-OUTPUT...
-
Hi Simon I digged a little Please find here a test program the prgramm is executed without error But if you uncomment one of the move that are marked with "Generate Error" if will produce the 31 bad file status on open Denis IDENTIFICATION DIVISION. PROGRAM-ID. AVARYSEQ4. ENVIRONMENT DIVISION. CONFIGURATION SECTION. SOURCE-COMPUTER. IBM-PC. OBJECT-COMPUTER. IBM-PC. SPECIAL-NAMES. INPUT-OUTPUT SECTION. FILE-CONTROL. SELECT SYSUT2-FILE ASSIGN TO SYSUT2 ORGANIZATION IS SEQUENTIAL FILE STATUS IS SYSUT2-STATUS....
-
Hi Ralph By modifying the SELECT CLAUSE the program is working fine. just change ASSIGN TO SYSUT2 to ASSIGN TO "SYSUT2" It may be a bug regarding the different ways GnuCobol assign clause is handled following the used dialect (ibm , mf or default) Denis
-
Hi Ralph , Hi Simon I have tested avaryseq4.cbl program : When i used this compilation command line cobc -x avaryseq4.cbl Running the program produces SYSUT2 OPEN 2 FAILED STATUS=:31 When compile with cobc -x -std=mf avaryseq4.cbl SYSUT2 OPEN 2 FAILED STATUS=:35 When compile with cobc -x -std=ibm avaryseq4.cbl no error the SYSUT2 file is populated Denis
-
Hi Simon I have sent the PR, first time i use Github ... hope it's ok :-) PR #182 Denis
-
Hum difficult to push separates PR as i have deeply modified the cob_decimal_pow function
-
Hi Simon Here is an example. I have a hudge patch that include bug fixes #924, #925, #989 and a full testing suite for power compute. I will send it as a pull request to the ocaml repository . Denis IDENTIFICATION DIVISION. PROGRAM-ID . tstpow . *>---------------------------------------------------------------- *> *> *> *>---------------------------------------------------------------- *> ENVIRONMENT DIVISION. DATA DIVISION . WORKING-STORAGE SECTION. 01 EXPONENT PIC 9(38) COMP-3 . 01 FIELD-01 PIC...
-
yes i'm working on it :-)
-
Power
-
Hi Simon Yes . This case is solved. But while testing i found another case that produce a core dumped. Here it is : IDENTIFICATION DIVISION. PROGRAM-ID. test. * DATA DIVISION. * WORKING-STORAGE SECTION. *-----------------------* * * PROCEDURE DIVISION. *------------------* * A00-MAINLINE. *------------* *> IF NOT (+) THEN display 'ok' . *> GOBACK. *> i'll try to find other cases and give you an update PS : did you have time to have a look at the last version of 'cob_decimalèpow' and the cordic ln...
-
Hi Klaus I understood that it was not a critic . Challenging while remaining positive is the best way to move the project forward and that's what you did ;-) Denis
-
Great !!! -)
-
Hi Simon I have been very busy with my job and also wanted to find a solution that really satisfied me for the cob_decimal_pow function. The previous patch that I sent wasn't yet good enough for my taste. I think I achieved what I wanted for this feature. Attached you will find the patch which contains the source code as well as all the associated test programs The principles of the modifications are as follows: 0) to calculate a^b we immediately transform a into mpt_t type to use the mpf_pow_ui...
-
Hi Test xdamcnt_3.cbl with simon last optim (replacing multiply) For the range 1 14 C version --> 2s.45 GC 3.2 --> 31s GC 4 --> 2s.99 With GC 4 results are almost as good as C version ;-) Denis
-
HI Simon Here is a patch that solves #924 and #933 tickets with the associated tests . One thing is not yet handled : the case with hudge exponent as for example *> Case not handled at this time * MOVE 1.0001 TO FIELD-02 . * MOVE 18446744073709551619 TO EXPO-INT . * COMPUTE RESULT-HUDGE = FIELD-02 ** EXPO-INT * ON SIZE ERROR * CONTINUE * NOT ON SIZE ERROR * IF RESULT-HUDGE NOT = 340282366920938463574055071874025521161 * THEN * DISPLAY * '6: Result <' RESULT-HUDGE * '> != 340282366920938463574055071874025521161'...
-
Thank you Mickey Gmp doesn't have to be fixed. We have to fix gnu cobol
-
Hello Mickey I do not think so. I think due to the differences in environments, your Mingw version does not take the "optimized" branches of cob_decimal_pow and calculates using the gmp float type instead of the gmp integer type. Could you please compile and run this program on the two environments you mentioned your testing on and give the outputs? #include <stdio.h> int main(void) { printf("size of int %ld\n",sizeof(int)) ; printf("size of long %ld\n",sizeof(long)) ; return 0; } gcc the_program.c...
-
Hi It's seems that when the platform has a 8 bytes binary-c-long something is going wrong with some gmp functions used in gnucobol to compute exponent .
-
Hi Mickey What are the math libraries you use on both tests ? MPIR ? GMP ? Denis
-
Hi Simon Here is a second patch proposal including the associated tests. This patch allows the compiler not to generate a move if and only the name of the two variables are identical All tests are ok (make check and make test) In a second I would try to deal with the fact that both variables are "redefines", but I need to increase my level of knowledge of GnuCobol for that ;-) But the current patch allows, in my opinion, to cover the majority of cases
-
OK i'll do that this week Denis
-
The patch
-
Simon Here is a patch proposal It passes all the test (make check , make test) I add a test program
-
I guess it's there in codegen.c case CB_PERFORM_UNTIL: v = CB_PERFORM_VARYING (CB_VALUE (p->varying)); if (v->name) { output_move (v->from, v->name); We have to check that from and name are different to output_move
-
Hi Simon I will try to find the solution by digging in the code and propose a patch. I will surely have questions ;-)
-
PERFORM INLINE OPTIMIZATIONS
-
Hi Klaus Could you test this version on your old PC ? Thxs Denis
-
Hi Simon Thank you ! We can discuss yes of course !
-
Hi Klaus Yes often compute is much more heavy as it may be difficult to optimize In this case, as all variables are in the same type , replacing compute by basic operations is efficient as it can generate move that are only memcpy . Denis
-
Hi I made some test with GC 3.3 and GC 4.0 on my desktop (AMD 5800X , suse linux tumbleweed on a virtualbox machine) The results are in the pdf GCC 4 is much more efficient for this program But with some optimizations it's possible to decrease elapsed time for GC 3.3 Denis
-
Hi Simon In the programmer's guide float-decimal-16 and float-decimal-34 limits are respectively 10^384 and 10^6144. I wrote this little program the results are (Last GnuCobol 3.3 commit) : SIZE ERROR FLOAT-DECIMAL-16 : 00371 SIZE ERROR FLOAT-DECIMAL-34 : 06113 Is my program a good test case ? If so, there is a difference between what is described in the documentation and the expected result . Denis.
-
Hi Simon Thank you i understand. You can find attached two programs allowing the increase of the test coverage of the common.c file, in particular the second which is extracted from the NIST NC219A program and covers the common_cmpc function that was not tested to date
-
Ok I thought that for example we could generate a direct call to cob_move_alphanum_to_alphanum (src, dst) by determining at compile time that both fields were COB_TYPE_GROUP .
-
Hi Simon I ask myself the following question. Can't this piece of code in the cob_move function be removed and processed during the compilation step ? Denis if (COB_FIELD_TYPE (src) == COB_TYPE_ALPHANUMERIC_ALL) { cob_move_all (src, dst); return; } /* Non-elementary move */ if (COB_FIELD_TYPE (src) == COB_TYPE_GROUP || COB_FIELD_TYPE (dst) == COB_TYPE_GROUP) { cob_move_alphanum_to_alphanum (src, dst); return; } opt = 0; if (COB_FIELD_TYPE (dst) == COB_TYPE_NUMERIC_BINARY) { if (COB_FIELD_BINARY_TRUNC...
-
Compiler Segmentation Fault
-
ok great . thank you
-
Yes i know My question may not be relevant and probably linked to my lack of knowledge of svn. If I add several programs in run_fundamental.at for example, and at some point, I want to perform an svn update... will my file be replaced by the file from the svn update and delete the programs that I had inserted? I was thinking about the possibility of adding custom tests without being disturbed by updating from repository. Denis
-
Hi Simon Is it possible do add a file called 'custom_test.at' in the distribution testsuite.src directory that will have - an 'empty program' (just goback) - that will be not be managed by svn ? Denis
-
Hi Simon Regarding the cob_decimal_pow function, I think we can't rely on mpz_pow_ui. When the exponent is large and the number to be raised to the power contains a long decimal part, this can lead to calculating a number that is too large for the mpz_pow_ui function Example : 1.000000001 ^ 4294967297 leads to compute 1000000001 ^ 4294967297 I continued working on the cob_decimal_pow function. The attached version passes all test cases (make check, make test)
-
Hi Simon Sorry, there was an error in the previous run_power.at i sent. Please find here the correct one . I add the o modified version of cob_decimal_pow . this version fixes the bug #924 and the core dumped linked to the bug #925 But the last test of the file fails du to bad precision . Denis
-
Hi Simon Here is a file containing 2 programs to tests the cob_decimal_pow function One program for exception cases One program for normal cases I'm also working on a modified cob_decimal_pow function that solves bugs 924 and 925 Denis
-
Core Dump When Compte Power
-
Wrong power Calculus with comp-3 : 0 power X should raise error when X < 0
-
Yes, it,s a new program not included in the 3.2 release. I will send you this we when all the cases will be covered .
-
Hi Simon I'm writing a test program for the decimal_piw function in intrinsic.c file One of the test case is the following one the program compute 0 power -5 . This should raise un size error IDENTIFICATION DIVISION. PROGRAM-ID . test_power . *>---------------------------------------------------------------- *> *> *> *>---------------------------------------------------------------- *> ENVIRONMENT DIVISION. DATA DIVISION . WORKING-STORAGE SECTION. 01 ALL-SRC . 05 EXPONENT PIC S9(09)V99 COMP-3 . 05...
-
Documentation regarding adis key values can be found here https://www.microfocus.com/documentation/object-cobol/oc41books/uiadis.htm and espacially the chapter 4.2.9.2.4
-
Simon It appears that the gcc '-Wtype-limits' option detects this kind of potential type mismatch. Perhaps we could include this warning in the standard compilation options. Here is the result using this option to compile GnuCobol. Denis numeric.c:1573:26: attention: la comparaison d'une expression non signée « < 0 » est toujours fausse [-Wtype-limits] 1573 | if (diff < 0) { | ^ replace.c:614:25: attention: la comparaison est toujours fausse en raison de la gamme limitée du type de données [-Wtype-limits]...
-
Hi Simon I wrote a function that reproduce the X'AF' 26 function from MF Cobol. This function is described here https://www.microfocus.com/documentation/reuze/60d/rhcall6z.htm Sources in attachment . X_AF.cbl --> Wrapper X_AF_26.c --> The c code for the function Do you think it could be integrated to GnuCobol ? Regards. Denis
-
Hi Simon. My C level is no longer as good as I would like, having not practiced for a long time :-) I have a question regarding this piece of code in numeric.c file As diff is const size_t type, wouldn't it always be positive and tehrefore the test diff < 0 never true ? Regards. if (fsize > COB_MAX_BINARY) { char *p = mpz_get_str (NULL, 10, d->value); const size_t size = strlen (p); const size_t diff = fsize - size; if (diff < 0) { /* Overflow */ if ((opt & COB_STORE_NO_SIZE_ERROR) == 0) { cob_set_exception...
-
Hi This type of data is designated as external floating point in the IBM Cobol Language Reference and Gnucobol seems to handle it as if you look at the cb_build_picture function in tree.c file you can see this piece of code case 'E': if (p[1] == '+') { category |= PIC_NUMERIC_FLOATING | PIC_NUMERIC_EDITED; p++; break; } I have never used this type of picture ... So i'am not sure about de behaviors of move from and to this type picture ...but it seems that the compiler handle this type of picture...
-
Hi Simon I begin to write a program for edited field with exponant and mantissa Here is the program : IDENTIFICATION DIVISION. PROGRAM-ID. prog. DATA DIVISION. WORKING-STORAGE SECTION. 01 FLD-1 PIC +9(2).9(2)E+99 . 01 FLD-2 PIC 9(2)V9(2) . PROCEDURE DIVISION. display 'lenght of FLD-1 = ' length of FLD-1 . display 'value of FLD-1 = <' FLD-1 '>' . *> move 12.34 TO FLD-2 . display 'value of FLD-2 = <' FLD-2 '>' . *> move FLD-2 TO FLD-1 . display 'value of FLD-1 = <' FLD-1 '>' . *> GOBACK . The result...
-
Hi Chuck. It is the program contained in run_fundamental.at file : AT_SETUP([MOVE to edited item (3)]) AT_KEYWORDS([fundamental editing]) You can see in the paragraph TEST-RUNNER that DST-FIELD-12 is repeated two times (bad copy/paste)... The second one have to be modified to DST-FIELD-13 in each move and consequently this working-section line 01 EXPT-FIELD-13 CONSTANT AS '/00' . have to be modified as followed 01 EXPT-FIELD-13 CONSTANT AS '/56' . TEST-RUNNER. *> done twice to already check for later...
-
Hi Chuck Sorry for the delay ... I was in vacation. thx a lot for integrating the programs. I understant for MoveAlphanumToDisplay as i was not sur about expected results ... The program has bee writtent to cover the code of the C corresponding function... I just have tried on a ibm for linux cobol compiler trial, but no results as the compiled progam produced a core dumped with this compiler even with all the debug options... Regarding the programs thta had been integrated by Simon before ... we...
-
Hi Simon I'll have som others tests programs that i will be able to send until end of July for c api move.c functions. I 'have begun to work on test programs for class clause and swith. Regarding class clause, the following programs does not compile , i'm not sur that this is a "normal" compilation error. IDENTIFICATION DIVISION. PROGRAM-ID. tstclass. ENVIRONMENT DIVISION. CONFIGURATION SECTION . SPECIAL-NAMES . CLASS HEXA IS '0' THRU '9' 'A' THRU 'F' . CLASS ODD IS '1' '3' '5' '7' '9' . CLASS EVEN...
-
Hi All I'd like to know if there is a way to dynamically change attributes of fields contained in screen section : as color , required or not, askip ... Denis
-
Hi Rocco I think it's a bug in the condition parsing that is not related to boolean . The same error is occurring with this program (pic 9 fields) : IDENTIFICATION DIVISION. PROGRAM-ID. CHECKCOND. DATA DIVISION. WORKING-STORAGE SECTION. 01 VAR1 PIC 9(04) VALUE 1. 01 VAR2 PIC 9(04) VALUE 2. 01 VAR3 PIC 9(04) VALUE 3. 01 VAR4 PIC 9(04) VALUE 4. PROCEDURE DIVISION. MAIN-PROGRAM SECTION. INIZIO. IF VAR1 NOT = (VAR2 AND VAR3 AND VAR4) DISPLAY "TRUE" UPON STDERR ELSE DISPLAY "FALSE" UPON STDERR END-IF...
-
Hi Simon Please find here the following programs to enhanced the MOVE statement tests (Some i have already sent to you) MoveAlphanumToDisplay.cbl Move_Basic_P_Pic.cbl MoveDeEditing_2.cbl MoveDeEditing_3.cbl MoveDeEditing_4.cbl MoveDeEditing_5.cbl MoveDeEditing.cbl MoveEditedToDisplay.cbl MoveJustified.cbl MoveOtherCases.cbl MoveTestCobMove.cbl MoveToEditedZero.cbl Compilation status : All compile without warning with -Wall excepted Move_Basic_P_Pic.cbl Move_Basic_P_Pic.cbl : This program contains...
-
Yes it's ok with COB_MODULE_PTR->module_name Thx
-
Hi Simon A question .. How could I insert in some libcob source file, a instruction that prints the current cobol program running ? IS there a macro or a function that could do the job ? Regards
-
hi Simon Here is a patch for run_fundamental test It contains - a fix for one of the program i sent you and you had integrated - a fix that correct one of the program that FAILED if compile with -fdefaultbyte=0 Regards
-
Hi Vincent I don't know if it's good or bad cobol ;-) I currently try to extend the move statement test cases This move from binary-c-long to comp-3 is allowed in the code . So i wrote a test for this case. Note that if you change the destination field with a display type , it works
-
sorry again i forgot to post the modified test ... is it normal that when i move a variable that type is binary-c-long and value 1 to a s(09)V99 COMP -3 variable the comp-3 variable contains 000000000.01
-
Sorry if it is not clear ... i modified the program ...
-
move to comp-3 instead of comp-2 in the title
-
Move from binary-c-long to comp-2
-
Compute decimal with 31 digits with constants
-
Bug in display statement with P picture
-
Hi Simon Did you received my previous poist with new programs. ? Denis. Regards
-
Hi Simon Here is a patch taht contains nex tests programs and a correction of one that is already included With this patch we increase move.c coverage from 67.7 to 72.2 Denis
-
Hi Simon , i have been quiet busy these last weeks. But i have finished some complementayr cases tests for move statement. I'll send you on a svn patch format this evening Denis
-
Sorry my message was not complete , if y modify 05 SRC-FIELD PIC 99999999.BBB by 05 SRC-FIELD PIC 99999999.BB9 i get 12345
-
Hi Serge , i'm not sure it's an explication of the result if i modify the picture i get the "good result" in dst-field ie 12345
-
hi Simon I wrote a test and the result seems strange to me. Seems like a bug to me, but could you check on MF if it is. I don't understant why the result is not equal to 12345. Denis Here is the test. IDENTIFICATION DIVISION. PROGRAM-ID. test. ENVIRONMENT DIVISION. DATA DIVISION. WORKING-STORAGE SECTION. 01 EDITED-FIELD . 05 SRC-FIELD PIC 99999999.BBB . * 01 DISPLAY-FIELD . 05 DST-FIELD PIC 9(10)V9(04) . * PROCEDURE DIVISION. *>------------------- *> move 12345 TO src-field move src-field to dst-field...
-
Hi Simon I keep going on digging move statement . In order to have the best test coverage, I ran the test suite with defaultbyte=none. With defaultbyte=init , gnucobol generates cob_move to initialize fields. These cob_moves generate code coverage that does not correspond to explicit tests: for example with defaultbyte=none the cob_move_edited_to_display c function is not covered at all, and is therefore not the subject of an explicit test. Hope i will finished during this week-end with the move...
-
Hi Simon In the run_fundamental.at file there is an error in the program "MOVE to edited item (3)" we need to change the following things : 01 EXPT-FIELD-13 CONSTANT AS '/00' . have to be changed to 01 EXPT-FIELD-13 CONSTANT AS '/56' . in the two move, DST-FIELD-12 is repeated twice an DST-FIELD-13 is not moved , so replace DST-FIELD-12 by DST-FIELD-13. I'm actually run the testsuite with defaultbyte=none in order to not generate cob_move in the initialization c code, several errors occurs on differents...
-
With the attached filed ;-) I think there are some c code that can't be reached is the cob_move function. When a source and destination are exactly the same type, gnucobol generates directly a memcpy instead of a call to cob_move function, then the switch case where src type = dest type cannot be reached .
-
Simon here are the files to integrate
-
Oups forgot to attach files .. Here they are I have a doutbt about the result of the last test of MoveOtherCases.cbl, if you could check it on MF that's would be useful
-
Hi Simon Here is 4 programs to complete move.c coverage , excluding c convenience functions i get 92.8% of lines coverage.
-
I have tested several pictures with PP99 99PP .... each tima i have this warning expect when moving 0 .. Yes it seems there are some issues .. I skip P picture for now and get back to it later
-
Hi Simon I try to play with P picture ... I have this little program . When i compile with -Wall i have this warning : test.cbl:18: warning: value does not fit the picture string [-Wtruncate] test.cbl:13: note: 'SRC-NUM-3' defined here as PIC PP99 [-Wtruncate] I don't clearly understand why as the receiving field length is 2. IDENTIFICATION DIVISION. PROGRAM-ID . TEST . *>---------------------------------------------------------------- *> Additional test cases for MOVE statement *> Testing move edited...
-
Ok ! Thank's
-
Is does not compile on MF ?
-
Simon Just a question ... I had a rapid glance to the parser regarding conditions .. On gnucobol this form of abbreviated condition does not compile IF A ( = B OR > C ) which for me means IF A = B OR A > C . Could you check if i'am wrong on another compiler ? PS another case that seems valid to me but does not compile on gnucobol IF A = B AND ( > C OR < D )
-
Hi Simon Great ! ;-) Yes , i work actually on move statements as several cases related to numeric edited are not yet covered ans some cases with P in pictures. Once finished, i intend to work by order of "priorities" on the folowing items - numeric.c - call.c - fileio.c Please let me know if those "priorities" have to be modified ...
-
Hi Simon Please find here a test program that cover the C function cob_move_alphanum_to_edited that hit count is 0 in the code coverage . This program tests the move statement from display to alphanumeric edited. I guess we could include this test in the run fundamental.at file that contains already two cases 483: MOVE to edited item (1) 484: MOVE to edited item (2) and name it 'Move to edited item(3)'
-
Regarding others cobol compilers , i have no longer access to another compiler like MF or others Do you know if there are cloud offers for that ? It's quiet useful to ba able to compare some results with others compilers .
-
Should it be good to group all the tests for each statement in one test program and rationalize them ?
-
OK, i''ll do that
-
Simon Here are two programs test : one corresponding to the inspect statement we have just talk about the second allow to cover the cob_div_quotient c function that was not tested and complet either the divide_statement parsing cases
-
Great ! ;-) Thank you . I finish this test case and send back to you
-
Hi Simon , it's clear now regarding the is_marked function I wrote this program that cover all the cases i wanted to , but there is one result i'm not able to explain if it's good or not . After execution, res-idx-1 is 19 . Is it the right value ? IDENTIFICATION DIVISION. PROGRAM-ID . prog . DATA DIVISION . WORKING-STORAGE SECTION. 01 INSP-STRING PIC X(26) VALUE 'ABCDEFGHIJKLMNOPQRSTUVWXYZ' . 01 EXPTD-RESULT CONSTANT AS 'A22222111111111122222222YZ'. 01 RES-IDX PIC 9(04) BINARY . 01 RES-IDX-1 PIC...
-
Hi Simon I have run the nist test as your advises to get the code coverage . You can find the result in the html file includes in this post. The last table shows for each files what the NIST test suite improves and therefore what we may be should add some testcase in the GnuCobol test suite. Regarding move.c .. there are several functions that are made for c programs to access cobol data . May be it would be useful to put them in a separate file ? I wrote today a mail to assign@gnu.org ... as you...
-
Simon Another program to improve strings.c code coverage (cobol string statement) (87,7% --> 91%) Line coverage 87,7% ---> 91% It remains some code in the cob_inspect_characters to complete. Hope i will have some time next week ...as i begin a new job ... and i have received all the stuffs that i ordered to built my DIY NAS :-) Regards
-
Ok , i'll try :-)
1 >