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

[Michael Niedermayer]

Hi

On Tue, Nov 07, 2006 at 07:38:01PM -0800, Trent Piepho wrote:
[...]
> > > You have instead dismissed this as irrelevant, and claimed what is
> > > relevant is how you think future versions of gcc will work.  At that
> > > point it is no longer a discussion of facts, but one of opinions.
> >
> > you repeated many times how different gcc versions had difficulty with
> > specific asm constructs which where working with others, you yourself
> > claimed with that that gccs interpretation and implementation of asm
> > changes confirming what i said now it doesnt fit into your newly twisted
> > argumentation so you claim the opposit
> 
> My argument has always been that my claims about what asm constructs will
> work with past and present gcc versions and which will not work are
> correct.  Where you have disagreed with me about that, you have been wrong.
> When you said that one must use "=&m" to keep a memory operand from
> overlapping an input, you were wrong.

my argument has always been about the specification of asm in the docs
not the limitations of specific implementations
asm code in mplayer and ffmpeg must conform to the asm
specification in the docs if it does not it is rejected
you can twist what i said if you like it wont help you, maybe some
people who didnt follow the thread carefully will be fooled by your
missrepresentations of what others said, if so thats sad, but it cant
be helped i dont have the time to repeatly reply and say the same thing


>  "=&m" won't even compile!  

and past versions of gcc also failed compiling various things in the c
standard, still that didnt affect what is valid c and what is not it was
just that gcc was broken


> When you
> said "=m"(a), "0"(a) is equivalent to "=m"(a), "m"(a) you were wrong.

i did not say this
i said:"
fact seems to be gcc due to limitations of its architecture cannot
copy or move a variable to another memory locations, and with this
additional limitation of the current gcc implementation
"=m"(a), "0"(a) is equivalent to "=m"(a), "m"(a)
this is NOT guranteed by the gcc docs and neither is it gurateed to
work in the futur
"


>  Try
> compiling this with -O0 and see which "equivalent" function fails to
> compile:

i see, but gccs ability to compile code is not related to the validity
of the code, and iam just repeating here what ive been told by one of the
most authorative and always correct divine gcc developers:

see http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203#c14

'just because code is syntactically "valid" GNU C doesn't mean gcc can
always compile it.'

furthermore as your arument is based on the claim that i said something
which i didnt, this isnt too relevant or?

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

In the past you could go to a library and read, borrow or copy any book
Today you'd get arrested for mere telling someone where the library is