meyering@CS.UTEXAS.EDU (12/20/88)
gcc-1.31 on sun4-os4 failed to compile dfa.c of the grep-1.2 distribution when using the -O option. (worked fine without -O) The first problem lay with a bitfield r-value. Gcc generated incorrect assembly code -- involved "255<<21" which 'as' said wasn't in the range -4096,4095. If you care, I'll send the whole mess, but a week or two ago, I think I saw a bug report in which a very similar error message was generated by as. I replaced all bitfields by ints. Then, at least, the thing compiled without errors. However, I then got memory faults at execution. Tracking that down pointed a finger at the first use (a definition) of 'follows' in regstate(). After a bit of fooling around, I came up with a fix that should help you guys localize the problem with the optiimizer, and that permits me to get a correct egrep running, finally (although sun's cc compiled and worked 99% of the time, it failed a single test, spencers #36 in the regression suite). ------------- To successfully "make" grep-2.1 with gcc -O on a sun4-os4 make the following changes: (I'm using an off-the-shelf sparc gcc-1.31) 1) change all bitfields to ints (there are 6 in dfa.h), and 2) give `regstate`follows the volatile storage attribute. The problem arose in optimizing the code from MALLOC(follows.elems, _position, r->nleaves); Seems to have to do with register allocation -- the very next line (identical, but with "tmp" instead of "follows") causes no trouble whatsoever when placed before the offending one. Don't know much more than that. Oh, replacing bitfields with ints didn't help sun4:/bin/cc -O. (they don't seem to have anything that recognizes volatile, though I suppose I could have taken it's address to get the same effect) That one still flunks spencer's #36. ...Just tried it, but no luck. Could be that since my address-taking had no side-effects, it was simply removed as dead code, and "follows" was stuck in a register nonetheless. Then again, maybe their compiler has other, different problems. Jim