🚀 go-pugleaf

I just spent the better part of a day figuring out why the
module glob.c from GNU make 3.71 (and some previous versions)
bombs if compiled with -O using pcc on AT&T System V/386 R3.2.

It bombs in function glob_in_dir().
It only bombs if libPW(alloca.o) is used.
If GNU alloca.c is used, it doesn't bomb.
No, libPW(alloca.o) is not broken.

It's pcc that is broken.
Did you know that pcc's optimizer does function inlining?
Well, it does.  But not always correctly.
It decided to inline my_realloc() in glob.c.

The problem is that if the inlined function has parameters,
and if a "real" alloca has been used in the calling function
before the inlined function is invoked, the optimizer is
unaware of the extra space created by alloca on the stack and
fails to reference the inlined function's parameters.  (It
attempts to reference them as offsets from the calling
function's frame pointer.  The inlined function does not
have its own frame pointer.)

Neat, huh?

Maybe some of those allegedly broken alloca's aren't broken
after all...

I guess that alloca needs to be a compiler built-in if the
compiler does function inlining.

By the way, pcc's optimizer takes lots of undocumented
options.  Anyone know what they do?

Does anyone know if System V/386 R4's compiler has the
same problem with alloca and function inlining?
-- 
Carl Mascott
cmascott@world.std.com
uunet!world!cmascott