>> Abstractly, the same thing is true of inlining bcopy [...]  [T]he
>> major difference is that a frame is missing from the call stack,

> Hm, no frame on the call stack =?

When you fire up a debugger, instead of seeing a call stack like

	main -> foo -> bar -> bcopy -> *boom*

you see just

	main -> foo -> bar -> *boom*

and when you look at the code at the pc, it turns out it's "inside" the
"call" to bcopy.  A little confusing to someone who hasn't seen it
before, or who doesn't realize the compiler does that kind of inlining.

> This seems wrong, at first glance,

Yeah.  It's another way in which the compiler making transformations
that are semantically equivalent when their semantics are defined by
the spec can lead to trouble when the circumstances are such that the
semantics aren't defined by the spec.

> but nothing that -ffreestanding wouldn't solve, I guess.

Yeah...except that that "solves" a lot more than this.  (The real
problem, of course, is not just this one instance, but more generally
the gcc maintainers assuming that semantics undefined by the standard
have not been defined by any gcc target - like what our printf does, or
at least used to do, with nil pointers, printing them as (null).)

/~\ The ASCII				der Mouse
\ / Ribbon Campaign
 X  Against HTML	       mouse@rodents.montreal.qc.ca
/ \ Email!	     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B