dno@cvl.UUCP (David Oskard) (07/26/85)
[Eat my line!]
On our Sun, the following C code gives an "illegal address"
error:
if (*bp++)
...
where bp is float *bp = SOMEARRAY[WHATEVER];
It has something to do with the evaluation of the conditional
expression (it works fine in regular expressions). I haven't tried
to reproduce it with other variable types, but it may or may not be
type independent. Has anybody out there fixed this bug? Replies would
be greatly appreciated. Please respond by mail. I'll post the results.
Incidentally, the bug can be avoided by doing
if (*bp) { .... } bp++;
David Oskard
seismo!rlgvax!cvl!dno
dno@cvl.arpa
University of Maryland
Center For Automation Researchchris@umcp-cs.UUCP (Chris Torek) (07/26/85)
Speaking of Sun C compiler bugs, how about
struct bug {
struct { int field:4; } array[128];
};
f()
{
register struct bug *p;
register int i;
p->array[i].field;
}
which generates
movl d7,d0
asll #1,d0
moveq #0,d0 ; sorry, guys, ya blew it
movb a5@(0,d0:l),d0
lsrl #4,d0
andb #0xf,d0
The code is just fine except for the minor fact that it is using
the same temp for both the subscript operation and the dereference.
Makes all references to "register pointer to array of bitfield"
access the 0th element, always. (The problem doesn't occur with
arrays of anything else, nor with pointers to bitfields.)
Without the compiler sources, of course, I can't provide a fix
(hint hint :-) ). Note however that the problem goes away if one
simply does not clear the destination of a move for a FLD reference,
since the result will be masked anyway....
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251)
UUCP: seismo!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: chris@marylandchris@umcp-cs.UUCP (Chris Torek) (07/26/85)
Your example works if "bp" is not a register. If it is (minimal
bug code: "f(){register float *p;if(*p++)"), I get
HEY! cookie = SCC
node1) U*, float, NOPREF, SU = (0,0)
node2) ++, PTR float, NOPREF, SU = (1,0)
node3) REG a5, PTR float, NOPREF, SU = (0,0)
node4) ICON #4, int, NOPREF, SU = (0,0)
, line 2: compiler error: floatcode got a tree it didn't expect
which clearly indicates that the floating point code generator
doesn't handle INCR nodes. (Nor ASG MINUS, by the way.) Of course
these occur only on "float *", not "double *"....
(I like the error message; it shows exactly what the problem is.
Now if only we had the source....)
--
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 4251)
UUCP: seismo!umcp-cs!chris
CSNet: chris@umcp-cs ARPA: chris@maryland