site_archiver@lists.apple.com Delivered-To: darwin-dev@lists.apple.com lwz r2,56(r30) addi r2,r2,-8 lwz r9,0(r2) lwz r2,56(r30) addi r0,r2,-4 stw r0,56(r30) lwz r2,56(r30) lwz r0,0(r2) add r0,r9,r0 lwz r2,56(r30) addi r2,r2,-8 stw r0,0(r2) -Aaron On Jun 30, 2008, at 9:28 AM, Jim Jagielski wrote: On Jun 30, 2008, at 9:21 AM, J. Aaron Pendergrass wrote: Here's some sample code that demonstrates the behavior: { long stack[4] = {1,2,3,4}; long *sp = test + 4; /* top of stack is at (sp - 1) */ /* add the top of stack to the next element and pop */ *(sp - 2) += *(--sp); } One might expect this to result in a stack like: {1, 2, 7, 4} Actually, one might expect anything since: *(sp - 2) += *(--sp); is really undefined within C... just check out K&R 2.12 for example. _______________________________________________ Do not post admin requests to the list. They will be ignored. Darwin-dev mailing list (Darwin-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/darwin-dev/site_archiver%40lists.appl... I'm aware that this is undefined. I did explicitly say that the C spec leaves this unspecified. But {1,2,7,4} seems like such an odd choice. Especially when looking at the disassembly: which really seems to be going out of its way to implement a fairly unintuitive semantics for this piece of undefined behavior and I was curious what the motivation behind this behavior might be. Hello list, I just ran into what seems to be fairly peculiar behavior of Apple's GCC (v4.0.1 PPC) that seemed worth pointing out. It is hard to say if it is really a bug since the C spec is fairly non-deterministic, but it is peculiar. This email sent to site_archiver@lists.apple.com