From mboxrd@z Thu Jan  1 00:00:00 1970
From: Doug Evans <dje@transmeta.com>
To: Greg McGary <greg@mcgary.org>
Cc: fche@redhat.com (Frank Ch. Eigler), cgen@sourceware.cygnus.com
Subject: Re: PATCH: string-expansion macros
Date: Mon, 16 Apr 2001 13:41:00 -0000
Message-id: <15067.22740.508672.419317@casey.transmeta.com>
References: <200103022358.QAA31874.cygnus.local.cgen@kayak.mcgary.org> <o5k84k3aca.fsf@toenail.toronto.redhat.com> <ms8zl0r4zs.fsf@mcgary.org> <15067.21393.766115.222329@casey.transmeta.com> <msy9t0pozo.fsf@mcgary.org>
X-SW-Source: 2001-q2/msg00016.html

Greg McGary writes:
 > Doug Evans <dje@transmeta.com> writes:
 > 
 > > I think that's the way things should work,
 > > and I wonder if needing to reverse it reveals a problem that
 > > is best solved differently.
 > 
 > Intercepts are one use, whereas what I have implemented is a
 > "fallback" to be used only when a real insn won't match.  Both are
 > valid, IMO.  What needs to be done differently is to allow the
 > programmer to specify whether they want to intercept or if they want
 > to offer fallback.  Sounds like the least disruptive way to go is to
 > retain intercept semantics as the default, and allow an attribute to
 > specify fallback semantics.

I don't have a problem with the attribute (well, I do, but
not a big enough of one to care).
I just wonder whether that's the best way to go.