james@bigtex.cactus.org (James Van Artsdalen) (10/16/88)
Has anyone been able to compile 1.30 with itself? I have been unable to make 1.30 work. Fortunately 1.28 and 1.30 produce fairly similar code and I have spotted on problem in the assembly produced by yylex() in c-parse.tab.c. Here's a piece of a diff between what 1.28 did and 1.30: *************** *** 11631,11640 **** cmpl $39,-116(%ebp) jg .L701 movl -116(%ebp),%eax sall $2,%eax - movl -116(%ebp),%edx - sall $3,%edx - leal (%edx,%eax),%eax movl reswords(%eax),%eax movl -108(%ebp),%edi movb (%eax),%bl --- 11616,11625 ---- cmpl $39,-116(%ebp) jg .L701 movl -116(%ebp),%eax + sall $1,%eax + movl -116(%ebp),%edi + leal (%edi,%eax),%eax sall $2,%eax movl reswords(%eax),%eax movl -108(%ebp),%edi movb (%eax),%bl My guess is that the reswords offset is being calculated incorrectly: it appears that 1.28 is getting 12 bytes per entry (correct) and 1.30 gets only 6 bytes. I don't know where precisely in the source this assembly comes from: is_reserved_word()'s inlining makes this unclear to me. As an aside, how difficult would it be to have the labels that gcc generates be independent of the sequence of labels within a file? For example, could the labels be made dependent upon a source line number and a sequence within that line? The reason for this is that it would make diffs between compiler outputs (like the one above) much more effective, since labels would not depend on a newer revision of the compiler generating all labels that previous compilers generated. -- James R. Van Artsdalen james@bigtex.cactus.org "Live Free or Die" Home: 512-346-2444 Work: 338-8789 9505 Arboretum Blvd Austin TX 78759
zeeff@b-tech.ann-arbor.mi.us (Jon Zeeff) (10/16/88)
I haven't been able to get anything later than 1.28 to work on the '386 either. -- Jon Zeeff Branch Technology, umix!b-tech!zeeff zeeff@b-tech.ann-arbor.mi.us