This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: PATCH: Fix 20000724-1.c


In article <20010430112038W.mitchell@codesourcery.com>,
Mark Mitchell  <mark@codesourcery.com> wrote:
>
>But, by your argument that my original analysis was bogus, it seems
>like the user *did* write enough.  So, we should be able to key off of
>something about the instruction, not just its asm-ness.

The fact that it has a pointer to the frame should be enough to key off.

The user passed in a pointer to the frame to the asm. Which according to
any sane interpretation should mean that the compiler cannot de-allocate
the frame (at least not that _part_ of the frame) before the asm is done
with it.

So the "volatile" and the memory clobbers are irrelevant. The only thing
that matters is that we've given the asm a pointer, and we de-allocated
that pointer before-hand.

Think of it this way. What if the user had done a

	mem = malloc(..);
	asm("xxxx": :"r" (mem));
	free(mem);

instead? You would consider it to be an obvious bug if the compiler
moved the "free" to be above the asm, no?

Now, change the above to

	mem = alloca(...);
	asm("xxxx": :"r" (mem));
	return;

where the "return" does the implicit freeing of the alloca'ed memory. 
You'd still consider it a bug if the stack frame (that contains the
calloc'ed memory) was free'd before the asm, wouldn't you?

Now, the test-case in question is _really_ close to the above alloca()
case. It's just that the stack space was allocated by taking the address
of a local variable. And it's still a bug to free the memory before the
last reference to it is gone.


		Linus


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]