Conference turris::decc_bugs

1289.0. "Bad code: DEC C V5.6-058 on Digital UNIX X4.0 (Rev. 698)" by DCETHD::BUTENHOF (Dave Butenhof, DECthreads) Mon Apr 28 1997 11:24

During some experimentation with floating point context switch (on Digital
UNIX 4.0-5, "more or less"), I tried to compile DECthreads with -O4. It
simply didn't run -- the library initialization failed badly. With -O3,
initialization worked fine and I got the numbers I was looking for. After, I
went back to figure out what happened with the -O4.

Compiler -V:

DEC C V5.6-058 on Digital UNIX X4.0 (Rev. 698)

The problem is that an initialization loop is being generated incorrectly.
It's a simple loop, and the problem shows up in a small standalone program,
which I've called dspinit.c, with the init loop and a few definitions.

The array (65 elements) comprises doubly-linked queue headers, which are to
be initialized as "empty" -- that is, flink and blink fields both contain the
address of the header.

To capture the effects, I tried to print the array in the test program, but
it appears that some of the corrupted memory breaks printf, and it crashes
with an instruction fault before printing anything. So I modified the test to
allocate an array 3 times as large as the real one and initialize the middle.

The results show that it's "initializing" array elements [-5] through [-2] as
if they were [0] through [3]. Interestingly, half of element [-1] (blink, the
second pointer) is initialized, but [-1].flink is left 0 -- while [4].flink
is set correctly but [4].blink gets the address of [9]. And so forth. At the
other end, elements [55] through [58] are left uninitialized and element [59]
is incorrectly initialized. No memory is written after element [64], however.

If there's anything "questionable" about the source code, it's certainly not
obvious to me, so I'm tempted to suggest that the compiler is tearing
something while it unrolls the loop.

The source, dspinit.c, a binary, dspinit, a machine code listing file,
dspinit.lis, and sample output, dspinit.out, can be found in ~butenhof/public
in the sdtYP NIS domain. (Which means it ought to be accessible to GEM folk:
if not, let me know.)

The program was built with
    cc -o dspinit -O4 -g3 dspinit.c

	/dave

Dave,
	I've copied your source and reproduced the behavior you describe.  Very
strange indeed.  I'll let you know what I find out.
							-Kevin

Dave,
	This definitely appears to be a GEM bug, I reported it in their bugs
conference and we are tracking it as number 4318 in the C/C++ bugs database.
We'll let you know when they give us a diagnosis.
									-Kevin

Thanks, Kevin. I suspect the explanation (assuming it's not so deep in GEM
code movement routines as to be incomprehensible to mere mortals) will be
intriguing!

	/dave

Dave,
	I talked to the GEM developer about this today.  It found a subtle
problem with the GEM pipeliner code, having to do with using the values as both
data and addresses.  Apparently the fix is non-trivial and needs to be
extensively tested before being released, so it won't be in a compiler near
you very soon.  However, you can work around it by turning down the optimization
level.  Let us know if that workaround is inadequate.
							-Kevin

Interesting.

The "workaround" is certainly adequate. We'd only used the default
optimization level until I got into this set of experiments. I reported the
bug more to be a "good citizen" than because it was an immediate problem for
us. (Of course I would now like to consider shipping DECthreads with a higher
optimization level -- but -O3 will be fine at least until this is fixed.)

	/dave