[MPlayer-dev-eng] Improved remove-logo filter

[Uoti Urpala]

On Mon, 2006-11-06 at 03:20 -0800, Trent Piepho wrote:
> On Mon, 6 Nov 2006, Uoti Urpala wrote:
> > >   It needs "memory" on the clobber list, or better
> > > yet, "=m"(x) as an output.
> >
> > ... except that if "=m" cannot point to an alias of the variable, your
> > "better" alternative is a bad idea since it requires allocating a
> > register to hold &x unless x is a stack variable or similar that can be
> > accessed without needing an explicit pointer.
> 
> You're wrong about that.  Try it.

About what? Depending on what x is having "=m"(x) in the output list
does require an extra register; I have tested that. Probably best would
be for gcc to support memory variables in the clobber list, but
currently it doesn't.

> > I've already explained this exact thing TWICE. Are you retarted or what?
> > If you need side effects which don't directly affect the current thread
> > to happen then you must specify "volatile". This is true even for plain
> > C, without any asm whatsoever.
> 
> And I already explained to you that you are wrong about what volatile
> means.  It just means that all the loads and stores implied by the code
> must exist.  If you write this:

gcc cannot guarantee that all the loads and stores in asm exist if it
uses a copy of the variable. The asm can do multiple loads or stores and
there's no way they're all guaranteed to exist unless the asm gets the
real address. Of course gcc can specify whatever semantics for asm
constructs it wants; it could require using pointer to volatile as an
asm argument or something similar (with the justification that asm
arguments can be copies like function arguments). Whatever the exact
method used to indicate that accesses must not be optimized it makes no
sense to forbid optimizations *by default* which is what you seem to be
arguing for. Unless specified otherwise C is compiled in a way which is
not guaranteed to work with memory shared by multiple threads; asm
should be handled the same.

> You may wish that the way gcc worked is that if an asm has a volatile
> operand, then a memory reference (but not a register) must not be a copy.
> But that is not how it works.

It isn't? Do you have a counterexample with current gcc? Anyway the
exact method you should use isn't that important; my point is that there
is no reason for gcc to handle asm as if every variable was always
volatile when it doesn't handle C that way.