Re: Orca/C 2.0 problems

[gdesroch@slate.mines.colorado.edu (DESROCHERS GARY FREDERIC)]

John Mills (mills@MAX.EE.LSU.EDU) wrote:

    Before I start let me give you a couple of hints in using ORCA/C 2.0

1)  If you use any optimization use optimize 7 or 15.  There are some
    nasty bugs in the loop optimization.  You may never see them so you 
    could turn them on but if you see them then you may regret it.

2)  use compile -I or turn off the sym file generation using pragma's.
    Mike knows about the sym file problem and has several examples of it.
    He is trying to fix it.  It happens only half the time.(I think half of
    my time that is.:-) )

3)  If you are trying to use the large memory module (most of the times
    only needed for large array programs like full graphics programs.)
    Call Byteworks and ask for the library fix.  There is a problem with
    the output library.

4)  Be careful of using myint = secondint = 0;  This an optimization
    problem as well.  Just use myint = 0; secondint = 0;(stz sta problem)

5)  There is no such thing as an unsigned bit field.

6)  Make sure you use (long)0 in conditional expressions if you really want
    it to be long instead of just 0.

: I've been working with Orca's latest C compiler since it finally arrived
: the other week. Have any of you guys had the following problems...
:   o no distinction between stdout & stderr. In order to print a list
:     of errors, all output must be printed.

   I don't know if you are using the large memory module but if not I have
never had this problem.

   Could you give an example of this?  Could it have somthing to do with
buffering?  Are you saying that:

     /* lets say myint is 12 */
     fprintf(stdout,"My value is %d.",myint);
     fprintf(stderr,"A bad value. It should be %d.\n",(int)20);
     exit(1);

   doesn't produce:

A bad value. It should be 20.
My value is 12.

  Instead it produces:

My value is 12.A bad value. It should be 20.


   I haven't tried it.  Maybe I will tonight.  It should produce the first.
They are suppose to be seperate console files.  See if you can send the
outputs to different places with:

myprog > mystdout >& myerrout

:   o compiler does not save any functions after the first one with
:     an error (even if they are good ones - ie. no errors). No ~GLOBALS
:     are saved either. 
:     To test this problem, try playing with the following code. Move the
:     bad function around to different places in the file, compile, then 
:     do a dumpobj (I used dumpobj -x -o). It'll show that only those
:     functions processed BEFORE the bad one are actually saved.

    Why is this a problem?  I will agree it is unusual that ORCA/C saves any
code at all instead of deleting the whole object file but you shouldn't,
IMHO, be trying to use a object file created when there was an error in the
compile?  I think the reason that ORCA/C does not create anymore in the
object file is because to do that it would need to continue on in the full
process.(including optimization)  Why would anyone want to run a link on a
program that didn't fully compile anyways?  Personally I think the only
problem with what ORCA/C does here, is that it doesn't delete the object 
file if there is an error.

Gary
-- 
Gary F. Desrochers
garyd@windipc.nrel.gov

I be gone in 1.5 months.  Anyone know a good internet site in New Hampshire.