sverre@lev.Seri.GOV (Sverre Froyen) (03/18/91)
>Has anyone found away to compile /usr/src/lib/ansi/strtol.c ?? >ie.: > as: line 124, value too large for displacement > Probably the answer you do not want to hear: It compiles just fine for me and, I suspect, for several others (since the 1.5 upgrade has been out for a while). I do vaguely remember some error message like the one above. Could it be that you are running an old version of the compiler, or not using the new include files, or ... Sverre
culberts@hplwbc.hpl.hp.com (Bruce Culbertson) (03/20/91)
>Has anyone found away to compile /usr/src/lib/ansi/strtol.c ?? >ie.: > as: line 124, value too large for displacement > GCC has a predicate which answers the question: can a given expression be calculated using an some addressing mode of the CPU? When the answer is yes, GCC emits a single instruction; when it is no, GCC emits instructions to simplify the expression and then calls the predicate again. This is the mechanism through which GCC takes advantage of fancy addressing modes on CISC CPU's like the 32532. A bug is this code causes GCC to occasionally output a single instruction which includes a constant which is too big to represent in the appropriate addressing mode. The assembler correctly complains. If you are using GCC 1.35 (the compiler I distributed) and you see this problem, drop the -O option if you were using it, or add -O if you weren't. This work-around has always allowed me to compile files which exposed this bug. Someone (Ian?) posted a fix to gnu.gcc.bug which may have been incorporated into later versions of the compiler.
ian@sibyl.eleceng.ua.oz.au (03/22/91)
Bruce Culbertson writes: > >Has anyone found away to compile /usr/src/lib/ansi/strtol.c ?? > >ie.: > > as: line 124, value too large for displacement > > > > GCC has a predicate which answers the question: can a given expression > be calculated using an some addressing mode of the CPU? When the > answer is yes, GCC emits a single instruction; when it is no, GCC > emits instructions to simplify the expression and then calls the > predicate again. Actually, this is not the problem (it was where I looked first though). As far as I can tell, this predicate works fine. The problem is in the code for the add3si (?) pseudo instruction. I have supplied a patch to fix it and it ended up in the 1.38 distribution. Unfortunately, I had the idea right but had a case of brain fade when I actually typed it in. Basically, the ns32k can't do 3 operand addition in a single instruction except by using the addr instruction in which case one of the arguments has to be representable as a displacement and must be in the range [-2^29, 2^29 - 1], if not it should use two instructions. (Which it didn't do). The brain fade was to check for the wrong range [-2^30, 2^30 - 1]. I told RMS about my mistake and it may have been fixed for version 1.39 (which I haven't had time to examine). Ian