[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