Re: Interesting (?) failure case

[Luc Van Oostenryck <luc.vanoostenryck@gmail.com>]

On Wed, Apr 08, 2020 at 09:02:59PM -0700, Linus Torvalds wrote:
> Try linearizing this with 'sparse', and see it fail miserably:
> 
>    int t(void)
>    {
>         goto inside;
>         return 0 ?
>                  ({ inside: return 3; 1; })
>                 :
>                  2;
>    }
> 
> I came up with that disgusting example after talking to Nick
> Desaulniers about how sparse does some front-end optimizations early,
> and it made me go "Hmm... What about.."

Funny, I worked on something very similar last week:
	void f(int x, int y)
	{
		1 ? x : ({
	a:
			 y;
		});
		goto a;
	}

> There are two reasonable approaches for the above:
> 
>  - return 3 (due to the "goto inside")
> 
>  - tell the user to pound sand for doing crazy things and jumping into
> a statement expression from outside.
> 
> clang does #1. gcc does #2.
> 
> sparse does something bad, and just generates garbage silently.

Yes, the problem is caused at expand_conditional() where one of
the sides is throwed away if the condition is known. So the label
doesn't exist anymore and at linearization Sparse ends with a
jump to an unexisting BB.

I tried to simply discard the early optimization in expand but
then when testing the kernel I got a whole bunch of warnings
(bad type or dereference of noderef type, I don't remember).
So it seems that in general (when nobody jump into the expression
statement) the conditional needs to be simplified before evaluation.

I tried also to warn on gotos jumping into an expression statement.
The idea was to give a new 'label_scope' for each such statement.
Things are a bit complicated because the labels are implicitly
declared by the gotos.

I'll need to look a bit more at this.

-- Luc