Re: [PATCH] sparse change to understand additional postix expressions.

[Linus Torvalds]

On Mon, 1 Sep 2003, Dave Olien wrote:
> 
> This patch makes a cast expression followed by an initializer list into
> a postfix expression that can be dereferenced as a structure or an array.
> There are approximately 7 instances of these expressions in the Linux kernel,
> that give warnings about "expected lvalue for member dereference".

Ok.

I was actually planning on not supporting this gcc feature and trying to
discontinue its use in the kernel (gcc itself has quite often generated
bad code for it, and we've historically had to remove some of the uses
because of gcc flakiness), but your implementation is pretty clean, so..

> The approach involved introducing a new "stack-based temporary" symbol
> of the same type as the cast expression

This is what gcc does too. However, the liveness analysis ends up being 
nasty, especially with inline functions that return one of these beasts. 
So from a code generation standpoint it can be quite problematic.

(Obviously, the current sparse "code generation" in show-parse.c is so 
broken that we don't much care, and right now there are no real back-ends 
using sparse, but I still hope that some day we'll get a back-end too. If 
only because it will be the only way to _really_ figure out whether sparse 
is doing the right thing or not).

Damn, but it shouldn't be that hard for somebody who likes back-ends to
write a bad (non-optimizing) one. I'd actually like to make the tree
linearization be phase #6 of the sparse phase tree, because we can't even
do trivial dead code removal without it.

(The kernel depends on dead-code removal for several things, and I'd 
actually want several warnings to only happen for reachable code. So 
having dead-code removal actually helps sparse even from a pure checking 
standpoint: I'd love to have something like

	static inline struct page *alloc_pages(unsigned int mask, unsigned int order)
	{
		if (__builtin_constant_p(mask) && (mask & __GFP_ATOMIC))
			return alloc_pages_atomic(mask,order);
		return alloc_pages_cansleep(mask,order);
	}

and then have sparse know about sleeping/nonsleeping contexts, and warn 
about calling "alloc_pages()" within a locked context when it might sleep.

See how the above requires trivial dead code removal to work from a 
warning standpoint?

		Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/