On Wed, Apr 8, 2020 at 11:23 PM Luc Van Oostenryck
<luc.vanoostenryck@xxxxxxxxx> wrote:
>
> 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.
Yes.
And I don't think that's really a problem per se. I think the gcc
model of saying "you jumped to an invalid place, go away" is fine -
particularly since this can only happen if you use a gcc extension to
begin with.
So I don't think sparse is wrong, except for the total lack of any
error messages.
> I tried to simply discard the early optimization in expand but
> then when testing the kernel I got a whole bunch of warnings
I don't think we want to get rid of the early tree-level
simplifications. They are sensible and help avoid unnecessary work
later.
So I'd much rather just figure out some way to say "hmm, this goto is
to something that was removed earlier, let's just say so".
> 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.
Yes. I think the gcc warning is nice, but I also think that it would
be entirely sufficient to not notice at an early stage, but only when
linearizing and hitting the "I'm branching to something that I can't
generate code for", and report it at that point, instead of being
clever and analyzing scopes up front.
Linus
