[PATCH][RFC] Automatized pattern matching
Zdenek Dvorak
rakdver@atrey.karlin.mff.cuni.cz
Sat Jun 7 10:00:00 GMT 2003
Hello,
> I am thinking not so much of performance, as of potential conflicts
> between users of these static variables. If for instance someone
> writes
>
> if(MATCH_RTX("(plus $0 $1)", exp)
> {
> do_something_complicated_with(_match0);
> do_something_complicated_with(_match1);
> }
>
> and do_something_complicated_with() is in the same file, and itself
> uses MATCH_RTX, _match1 is liable to be clobbered, producing a nasty
> and difficult-to-pin-down bug. It's too easy to make this mistake.
right. I have thought about it for some time, but I did not find a
better solution (especially if we consider a case of recursive
functions) than ...
> >> (A twisted alternate idea: "auto TYPE foo;" at file scope is
> >> currently a hard error, and I think a constraint violation; we could
> >> make it mean 'implicitly declare this variable at function scope in
> >> any function that uses it' as an extension.)
> >
> > hmm... interesting idea; not quite sure whether I like it, seems quite
> > crazy :-) Of course we would have to hide it behind some macro
> > machinery in order to keep gcc compilable, but it would solve the
> > problem.
>
> I suggested it thinking that #define AUTO static in stage1 would
> suffice, but that doesn't solve the problem described above. The
> variables really must be on the stack always.
>
> Maybe just
>
> foo()
> {
> MATCH_RTX_VARS;
> /* other variable declarations */
>
> ...
> if(MATCH_RTX(...))
> {
> /* use _matchN here */
> }
> }
... this (accidentaly I have missed this part of the mail when I read it
the first time, so in my implementation the macro has name
USES_PATTERN_MATCHING).
Zdenek
More information about the Gcc-patches
mailing list