[comp.sys.apollo] Optimiser problems with Apollo compilers; nfs 2.2 comments

leland@DRAGONFLY.WRI.COM (05/13/91)

The following are the types of code the Apollo optimiser can't handle. Note
that this information is only correct as of the cc 6.7 release;
I have not fully worked through the new version.

Note that I'm only providing thumbnail sketches of code that is likely to fail. Obviously,
many of these problems are complex sensitive. Most only occur when more than one compiler
flag is used in conjunction with another.

1. If you use builtin string functions in the head of a for loop, the optimiser is
   likely to fail. This is especially true of multiple expressions in the initializer
   section of the loop. For example:

   char *s, *g;

   <<stuff>>

   for (i = strlen(s), j=strlen(g); i < 10;) {
       << stuff>>
       if (--i == 0) break;
       << stuff >>
   };

2. If you use a highly complex expression in the second clause of a for loop,
   you are likely to get incorrect results from the PRISM compiler. Here is an
   example:


for ( get_first(s, p); (p).more; 
    ((p).mode == 0) ? (*(*(p).field ? ++(p).field : (p).field) ? NULL : 
    ((p).more = 0), (p).field) : get_next(&p) ))

3. If you use too many gotos, you are likely to get either "bad block flow grap" or
   "compiler backend failure" (on the prism). The exact cause is still unknown; but
   the problem seems to be related to using goto's inside of deeply nested if structures.

------------------------------------------------------------------------------------

So far, there have been a few postings about nfs 2.2. Because of bugs, I regressed to nfs 2.1
a few hours after the install. If I were HP, I would stop ship this product now, or update the
documentation as to how to deal with these problems.

1. My home directory is on an nfs mounted filesystem. When I log in, /bin/csh (and/or /bin/ls)
   segmentation fault in the system subroutine "open_extended." These crashes only happen in
   csh; if I change the shell they go away.

2. nfs kills tcpd dead. The crash is in icmp_timeout. Even a fully loaded 4500 has to be
   rebooted every three or four hours with this problem.

3. There appears to be a memory leak in SR10.3 that nfs takes advantage of. The nfs crash is
   random, and sometime happens a few hours after startup, sometimes a day.

Lest you all think I am just complaining -- when nfs 2.2 runs it is significantly better
than 2.1. In particular, they fixed my favorite file trunction bug, improved the speed
considerably, and the Apollo seems much happier talking to the other machines via nfs.
However, a product that frequently crashes is just not a useable alternative. I hope patches
are soon available.

                                                Leland Ray
                                                Systems Administrator
                                                WRI, Inc.
                                                (217) 398-0700