Re: -ftree-check for review

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Nic" == Nic Volanschi <nic.volanschi@free.fr> writes:

Nic> Hum, I agree that the "B" is not very nice. We could get rid of
Nic> it if we dumped gimple code without the "B". Let me explain. In
Nic> fact, the Condate parser doesn't parse the patterns at all. It
Nic> actually parses everything in the file except the patterns
Nic> themselves. Why? Because writing a pattern parser is difficult
Nic> (you'd have to extend C's grammar accordingly, and that's
Nic> tough). Instead, I chose a simple shorthand, by rather unparsing
Nic> the AST and comparing it with the pattern.

Ok... I hadn't read the details of the patch, so I did not realize
this.  This doesn't strike me as a very robust way to go.

Is it that hard to parse the kinds of statements that the checking
pass could see?  It seems like there aren't that many kinds of
statement in GIMPLE, and anyway we do already have a C parser lying
around if need be.

Nic> This prices has important rewards for the users: they have to
Nic> write only one gimple pattern to catch many surface-level
Nic> forms. If we explain this well, I think the users will accept it,
Nic> because you really gain a lot of time not writing all possible
Nic> ways to do something in C.

Yes, this is attractive.  I do like the pattern-based C-like
"scripting" approach, versus writing plugins.

Nic> The following paper describes the language more formally and
Nic> compares it with the Metal checker on a concrete real-world
Nic> example:

Nic> http://mygcc.free.fr/condate-ppdp06.pdf

Thanks.  This was interesting.

Tom