[MPlayer-dev-eng] [PATCH] fix asm deps [RESENT]

[Dirk Mueller]

On Thursday 18 March 2004 00:40, Michael Niedermayer wrote:

> ok, it seems u missunderstood, the reason why the code is using MANGLE()
> instead of "m" to access some variables is because it didnt work the other
> way with some version of gcc

eh, which version of gcc? I've been reading cvs annotate and cvs log quite 
extensively, and the only reason for MANGLE() is that the symbol names are 
different on Cygwin/Windows as far as I can see. 

> so it doesnt help if it compiles with ur gcc 
> 2.95.?, one or more of these asm statements will fail to compile or lead to
> incorrect code with some other gcc version

which other gcc version? there is no indication whatsoever that there was ever 
such a problem in CVS, at least in the file I touched. It might have been in 
some other place however. Reading all changelogs of all files in CVS is quite 
painful..

I don't see why this would cause a bigger problem, since gcc documentation 
describes this as the way to go. 

> the problem should be fixed in this strange way anyway, the correct fix is
> to add attribute_used to the variables and define it to attribute((used))
> if gcc supports it

Well, I'd love to do a patch that way, but it doesn't work. gcc "see's" the 
trick and ignores the __attribute__ ((used)). With other words - the static 
const variables are not in the resulting object file and you get undefined 
symbols during linking. 

So is there a way to figure out which gcc version miscompiled the assembler 
(!) code when the dependencies were explicitely given?

Funny thing is, there are plenty of other places using "m" as input without 
apparent miscompilation, so I'm really wondering what is different here...

Are you perhaps referring to the volatile'ing of several variables to avoid 
that gcc optimizes away dead stores?


Dirk