Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!cis.ohio-state.edu!tut.cis.ohio-state.edu!ucbvax!DRAGONFLY.WRI.COM!leland From: leland@DRAGONFLY.WRI.COM Newsgroups: comp.sys.apollo Subject: Optimiser problems with Apollo compilers; nfs 2.2 comments Message-ID: <9105121951.AA07989@hera.wri.com> Date: 12 May 91 19:51:53 GMT Sender: daemon@ucbvax.BERKELEY.EDU Organization: The Internet Lines: 61 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; <> 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