[open-cobol-list] Forthcoming CVS update

[Roger While]

Some notes about what is coming within the next few days.
Off-list, we discovered a problem on powerpc.
It appears that "char" is unsigned on this platform.
(Although there is a "-fsigned-char" option)
This leads to all manner of problems.
I think I have it sorted out but time will see.
(methinks I have to persuade my company to get one of these)

On a side note related to the above, OC test 62 (and possibly 46) fail on
a big endian box. Any idea how we can do this compatibly ?

I have implemented "NUMBER-OF-CALL-PARAMETERS" as an internal
register. The internal count is available to C programs as 
"cob_call_params".
If anybody objects to the Cobol name, we can easily change it.

As a precursor to nested programs, I noticed we have a problem with stacked
imperatives thus :
CALL ... ON EXCEPTION
  ADD .....
    ON SIZE ERROR
       .....
    NOT ON SIZE ERROR
 NOT EXCEPTION

This is tricky as the parser has only 1 token look-ahead.
I delved into GLR but gave that up.
So I moved some syntax back into the lexxer.
Should be OK, however there may be some more corner cases.

Also as a precursor to nested programs, I noticed we had a problem with
multiple sources on the command line.
We should be able to do :
cobc -m P1.CBL P2.CBL
or
cobc -C P1.CBL P2.CBL
Well, now we can. This involved some fiddling around with global variables.
I think it is OK although at the moment I am not releasing allocated memory 
so
that a "cobc -m *.CBL" is more than likely to blow.
There is still a problem with :
cobc P1.CBL P2.CBL
It compiles both as main programs and fails miserably when it tries to link
both together.
Question - What should we do here ?
Should we interpret both as main progs or should we interpret the first as 
a main
prog and the second (and subsequent) as modules ?

There is a fix for duplcate paragraph names (Thanks Keisuke!) which funnily
enough I have been unable to reproduce in a test program. I can only 
reproduce this
with the customer program. Weird.

Did some optimization stuff in codegen like :
Push the error handlers to the bottom of the routine code.
Only generate the routine entry "swtich" if there is more than 1 entry.
If we have gcc and gcc >= 3 then we can use "__builtin_expect"
(when optimizing with -O, Os, O2)
eg. For the "!initialized" path and for the test if a called program was 
not found
amongst others.
Rather interesting that per default the expect only bites with "-O2"; 
however I
I discovered that adding "-freorder-blocks" activates it for "-Os" "-O" as 
well.
If you are compiling OC generated C code seperately AND you use gcc >= 3
then you may/should add :
-finline-functions -fno-gcse -freorder-blocks
to your compile options

Noticed that we were initializing RETURN-CODE twice.

Changed a load of definitions discovered with "-Wconversion".

For the tests (OC's "make check" and the 85 NIST) I changed the
"-fruntime-inlining" to "-O" as we are now doing more compiler oriented 
things.

Well that's enough for now. I should be committing within the next couple 
of days.


Roger