I've added some fixes to compile mplayer with gcc4, anyway they are even nonsenses like asm memory addressing of a binary operation of two vars. There are some stuff should be fixed like includes in libavcodec, gcc4 seams to not like struct AVOption without a type if used not as pointer (also this seams reasonable to me). The patch is splitted in two part, libavcodec and mplayer. I don't like much the way I've patched common.h and avcodec.h, feel free to find a better way. I'm also in doubt with: extern struct STRTAB chanlist_names[]; that I've changed in: extern struct CHANLISTS chanlist_names[]; I cannot found STRTAB anyway in the source ;( I've no clue to compile libmpcodecs/native/RTjpegN.c with gcc4, it complains for a wrong operand in mmx (?) instructions. Bye -- Gianluigi Tiesi <sherpya@netfarm.it> EDP Project Leader Netfarm S.r.l. - http://www.netfarm.it/ Free Software: http://oss.netfarm.it/
Hi On Thursday 24 February 2005 19:15, Gianluigi Tiesi wrote:
I've added some fixes to compile mplayer with gcc4, anyway they are even nonsenses like asm memory addressing of a binary operation of two vars. There are some stuff should be fixed like includes in libavcodec, gcc4 seams to not like struct AVOption without a type if used not as pointer (also this seams reasonable to me). The patch is splitted in two part, libavcodec and mplayer. I don't like much the way I've patched common.h and avcodec.h, feel free to find a better way.
I'm also in doubt with: extern struct STRTAB chanlist_names[]; that I've changed in: extern struct CHANLISTS chanlist_names[];
I cannot found STRTAB anyway in the source ;( I've no clue to compile libmpcodecs/native/RTjpegN.c with gcc4, it complains for a wrong operand in mmx (?) instructions.
[...]
#ifdef HAVE_MMX assert(filterSize % 4 == 0 && filterSize>0); + int ptr;
mixing of statements and declarations breaks gcc 2.95 [...] -- Michael "nothing is evil in the beginning. Even Sauron was not so." -- Elrond
On Fri, Feb 25, 2005 at 03:31:49AM +0100, Michael Niedermayer wrote:
Hi
On Thursday 24 February 2005 19:15, Gianluigi Tiesi wrote:
I've added some fixes to compile mplayer with gcc4, anyway they are even nonsenses like asm memory addressing of a binary operation of two vars. There are some stuff should be fixed like includes in libavcodec, gcc4 seams to not like struct AVOption without a type if used not as pointer (also this seams reasonable to me). The patch is splitted in two part, libavcodec and mplayer. I don't like much the way I've patched common.h and avcodec.h, feel free to find a better way.
I'm also in doubt with: extern struct STRTAB chanlist_names[]; that I've changed in: extern struct CHANLISTS chanlist_names[];
I cannot found STRTAB anyway in the source ;( I've no clue to compile libmpcodecs/native/RTjpegN.c with gcc4, it complains for a wrong operand in mmx (?) instructions.
[...]
#ifdef HAVE_MMX assert(filterSize % 4 == 0 && filterSize>0); + int ptr;
mixing of statements and declarations breaks gcc 2.95
You are right but it's enough to put the var at the top of the block, I'm still searching for a better way to patch common.h and avcodec.h -- Gianluigi Tiesi <sherpya@netfarm.it> EDP Project Leader Netfarm S.r.l. - http://www.netfarm.it/ Free Software: http://oss.netfarm.it/
Updated patches to be compatible with gcc-2.95 -- Gianluigi Tiesi <sherpya@netfarm.it> EDP Project Leader Netfarm S.r.l. - http://www.netfarm.it/ Free Software: http://oss.netfarm.it/
Bernhard Rosenkraenzer sent me patches to fix STRTAB and mmx.h I've tried it with gcc-2.95 gcc-3.3.5 and gcc-4.0 snapshot, and compiles fine. Please take a look on mmx code, Bernhard's seams to be ok but I have no clue on mmx asm. Bye -- Gianluigi Tiesi <sherpya@netfarm.it> EDP Project Leader Netfarm S.r.l. - http://www.netfarm.it/ Free Software: http://oss.netfarm.it/
Hi On Friday 25 February 2005 20:43, Gianluigi Tiesi wrote:
Updated patches to be compatible with gcc-2.95
+ int ptr;
very missleading name (an integer with name ptr)
+ ptr = ((int) src) + filterSize;
u do not know if a pointer will fit in an int, if it doesnt this will fail
- :: "r" (src), "m" (dst), "m" (dstWidth), "m" (xInc>>16), "m" (xInc&0xFFFF) + :: "r" (src), "m" (dst), "m" (dstWidth), "m" (x1), "m" (x2)
this is significantly less readable, theres no hope that anyone could guess from the names x1 and x2 what they are furthermore theres the fundamental question why exactly every project which uses asm should rewrite their code for gcc 4, this is not about correct or incorrect code, its practically just a syntax change the changes gcc 4 needs makes the code much harder to read, harder to optimize for the compiler and much longer is there some bugreport on gccs bugtracker about this? its breaking code which was valid in the past -- Michael "nothing is evil in the beginning. Even Sauron was not so." -- Elrond
Michael Niedermayer wrote:
furthermore theres the fundamental question why exactly every project which uses asm should rewrite their code for gcc 4, this is not about correct or incorrect code, its practically just a syntax change the changes gcc 4 needs makes the code much harder to read, harder to optimize for the compiler and much longer
is there some bugreport on gccs bugtracker about this? its breaking code which was valid in the past
AFAIR already gcc 3.4 reported warnings on this being deprecated. Offtopic: I just looked into cmmx.h and wonder why all the mmx replacements work on unsigned long, instead of unsigned long long? -- Jindrich Makovicka
Jindrich Makovicka wrote:
Offtopic: I just looked into cmmx.h and wonder why all the mmx replacements work on unsigned long, instead of unsigned long long?
Because long long is slow on 32-bit machines. cmmx.h is supposed to help to write faster filters on machines without mmx support, but if you use long long it's not going to be fast. Zoli
Hi On Saturday 26 February 2005 23:19, Jindrich Makovicka wrote:
Michael Niedermayer wrote:
furthermore theres the fundamental question why exactly every project which uses asm should rewrite their code for gcc 4, this is not about correct or incorrect code, its practically just a syntax change the changes gcc 4 needs makes the code much harder to read, harder to optimize for the compiler and much longer
is there some bugreport on gccs bugtracker about this? its breaking code which was valid in the past
AFAIR already gcc 3.4 reported warnings on this being deprecated.
i know but, it was valid before 3.4 [...] -- Michael "nothing is evil in the beginning. Even Sauron was not so." -- Elrond
On Sat, Feb 26, 2005 at 10:56:50PM +0100, Michael Niedermayer wrote:
Hi
On Friday 25 February 2005 20:43, Gianluigi Tiesi wrote:
Updated patches to be compatible with gcc-2.95
+ int ptr;
very missleading name (an integer with name ptr)
+ ptr = ((int) src) + filterSize;
u do not know if a pointer will fit in an int, if it doesnt this will fail
- :: "r" (src), "m" (dst), "m" (dstWidth), "m" (xInc>>16), "m" (xInc&0xFFFF) + :: "r" (src), "m" (dst), "m" (dstWidth), "m" (x1), "m" (x2)
this is significantly less readable, theres no hope that anyone could guess from the names x1 and x2 what they are
furthermore theres the fundamental question why exactly every project which uses asm should rewrite their code for gcc 4, this is not about correct or incorrect code, its practically just a syntax change the changes gcc 4 needs makes the code much harder to read, harder to optimize for the compiler and much longer
is there some bugreport on gccs bugtracker about this? its breaking code which was valid in the past
imo "m" is an invalid constraint for things like "(xInc>>16)" which are not an lvalue and obviously don't have an address. apparently old versions of gcc just ignored the "m" and treated this as "r"...or did they have some other hack to work with it? in any case, replacing "m" with "r" seems like the sanest alternative. rich
Hi On Sunday 27 February 2005 00:07, D Richard Felker III wrote:
On Sat, Feb 26, 2005 at 10:56:50PM +0100, Michael Niedermayer wrote:
Hi
On Friday 25 February 2005 20:43, Gianluigi Tiesi wrote:
Updated patches to be compatible with gcc-2.95
+ int ptr;
very missleading name (an integer with name ptr)
+ ptr = ((int) src) + filterSize;
u do not know if a pointer will fit in an int, if it doesnt this will fail
- :: "r" (src), "m" (dst), "m" (dstWidth), "m" (xInc>>16),
"m" (xInc&0xFFFF)
+ :: "r" (src), "m" (dst), "m" (dstWidth), "m" (x1), "m" (x2)
this is significantly less readable, theres no hope that anyone could guess from the names x1 and x2 what they are
furthermore theres the fundamental question why exactly every project which uses asm should rewrite their code for gcc 4, this is not about correct or incorrect code, its practically just a syntax change the changes gcc 4 needs makes the code much harder to read, harder to optimize for the compiler and much longer
is there some bugreport on gccs bugtracker about this? its breaking code which was valid in the past
imo "m" is an invalid constraint for things like "(xInc>>16)" which are not an lvalue and obviously don't have an address. apparently old versions of gcc just ignored the "m" and treated this as "r"...or did
no it was never treated as "r"
they have some other hack to work with it?
yes, they putted the result of the expression on the stack and used that, which is exactly what the patch does but its significantly less readable
in any case, replacing "m" with "r" seems like the sanest alternative.
unless u run out of registers or gccs register allocator runs out of whatever it uses also keep "g" in mind (register or memory) in this case we need to put it redundantly on the stack with the new rules, and hope that gcc can figure out that nothing uses the thing from the stack [...] -- Michael "nothing is evil in the beginning. Even Sauron was not so." -- Elrond
On Sat, Feb 26, 2005 at 10:56:50PM +0100, Michael Niedermayer wrote:
Hi
On Friday 25 February 2005 20:43, Gianluigi Tiesi wrote:
Updated patches to be compatible with gcc-2.95
+ int ptr;
very missleading name (an integer with name ptr)
+ ptr = ((int) src) + filterSize;
you can use different name or use unsigned int since it should be equal to a pointer, here filterSize is an int and it's added to a pointer, also this sum should be wrong. Anyway this can be decared as a pointer but adding filterSize will cause compiler to complain, but I think this can be acceptable.
u do not know if a pointer will fit in an int, if it doesnt this will fail
- :: "r" (src), "m" (dst), "m" (dstWidth), "m" (xInc>>16), "m" (xInc&0xFFFF) + :: "r" (src), "m" (dst), "m" (dstWidth), "m" (x1), "m" (x2)
this is significantly less readable, theres no hope that anyone could guess from the names x1 and x2 what they are
variable names can be changed to make it more readable x1 can be called xInt_sh16 and x2 can be called xInt_and_ffff
furthermore theres the fundamental question why exactly every project which uses asm should rewrite their code for gcc 4, this is not about correct or incorrect code, its practically just a syntax change the changes gcc 4 needs makes the code much harder to read, harder to optimize for the compiler and much longer
is there some bugreport on gccs bugtracker about this? its breaking code which was valid in the past
There is no sense at all to assign a memory operand to a bit & binary operation, since there is no memory for this value unless you don't use a variable, I think older gcc does a similar workaround. Also note that: dc_mask & eq_mask will never fit in a registry on a 32bit machine since they are declared as int64_t. There is no advantage to retain a broken code even if it's more readable. -- Gianluigi Tiesi <sherpya@netfarm.it> EDP Project Leader Netfarm S.r.l. - http://www.netfarm.it/ Free Software: http://oss.netfarm.it/
Hi On Sunday 27 February 2005 11:00, Gianluigi Tiesi wrote:
On Sat, Feb 26, 2005 at 10:56:50PM +0100, Michael Niedermayer wrote: [...]
furthermore theres the fundamental question why exactly every project which uses asm should rewrite their code for gcc 4, this is not about correct or incorrect code, its practically just a syntax change the changes gcc 4 needs makes the code much harder to read, harder to optimize for the compiler and much longer
is there some bugreport on gccs bugtracker about this? its breaking code which was valid in the past
There is no sense at all to assign a memory operand to a bit & binary operation,
diagree
since there is no memory for this value unless you don't use a variable,
yes, but neither is there a register to such a operation, the compiler can build the value in memory so it is never in a register, its the exact same situation, the compiler must put the value in a place which matches the constraint, not the user, later just cant, you could also consider a constraint with a specific register, its the compiler which must ensure that it ends in that register, the user has no control over this [...]
There is no advantage to retain a broken code even if it's more readable.
please elaborate about why it is broken in your oppinion -- Michael "nothing is evil in the beginning. Even Sauron was not so." -- Elrond
On Sun, Feb 27, 2005 at 12:58:10PM +0100, Michael Niedermayer wrote:
Hi
On Sunday 27 February 2005 11:00, Gianluigi Tiesi wrote:
On Sat, Feb 26, 2005 at 10:56:50PM +0100, Michael Niedermayer wrote: [...]
furthermore theres the fundamental question why exactly every project which uses asm should rewrite their code for gcc 4, this is not about correct or incorrect code, its practically just a syntax change the changes gcc 4 needs makes the code much harder to read, harder to optimize for the compiler and much longer
is there some bugreport on gccs bugtracker about this? its breaking code which was valid in the past
There is no sense at all to assign a memory operand to a bit & binary operation,
diagree
since there is no memory for this value unless you don't use a variable,
yes, but neither is there a register to such a operation, the compiler can build the value in memory so it is never in a register, its the exact same situation, the compiler must put the value in a place which matches the constraint, not the user, later just cant, you could also consider a constraint with a specific register, its the compiler which must ensure that it ends in that register, the user has no control over this
[...]
There is no advantage to retain a broken code even if it's more readable.
please elaborate about why it is broken in your oppinion
a binary and over two vars has not a memory location then has not an lvalue to put in asm code, I'm not the only that says this, if you disagree complain to gcc developers... :) -- Gianluigi Tiesi <sherpya@netfarm.it> EDP Project Leader Netfarm S.r.l. - http://www.netfarm.it/ Free Software: http://oss.netfarm.it/
Hi On Monday 28 February 2005 04:10, Gianluigi Tiesi wrote:
On Sun, Feb 27, 2005 at 12:58:10PM +0100, Michael Niedermayer wrote:
Hi
On Sunday 27 February 2005 11:00, Gianluigi Tiesi wrote:
On Sat, Feb 26, 2005 at 10:56:50PM +0100, Michael Niedermayer wrote:
[...]
furthermore theres the fundamental question why exactly every project which uses asm should rewrite their code for gcc 4, this is not about correct or incorrect code, its practically just a syntax change the changes gcc 4 needs makes the code much harder to read, harder to optimize for the compiler and much longer
is there some bugreport on gccs bugtracker about this? its breaking code which was valid in the past
There is no sense at all to assign a memory operand to a bit & binary operation,
diagree
since there is no memory for this value unless you don't use a variable,
yes, but neither is there a register to such a operation, the compiler can build the value in memory so it is never in a register, its the exact same situation, the compiler must put the value in a place which matches the constraint, not the user, later just cant, you could also consider a constraint with a specific register, its the compiler which must ensure that it ends in that register, the user has no control over this
[...]
There is no advantage to retain a broken code even if it's more readable.
please elaborate about why it is broken in your oppinion
a binary and over two vars has not a memory location then has not an lvalue to put in asm code, I'm not the only that says this, if you disagree complain to gcc developers... :)
"m" is NOT an output, its an input only constraint, "=m" would be an output, so IMO theres no need for it to be a lvalue if it where "=m" then your argument is certainly true and it would have to be an lvalue ... -- Michael "nothing is evil in the beginning. Even Sauron was not so." -- Elrond
On Mon, Feb 28, 2005 at 04:42:06AM +0100, Michael Niedermayer wrote:
There is no advantage to retain a broken code even if it's more readable.
please elaborate about why it is broken in your oppinion
a binary and over two vars has not a memory location then has not an lvalue to put in asm code, I'm not the only that says this, if you disagree complain to gcc developers... :)
"m" is NOT an output, its an input only constraint, "=m" would be an output, so IMO theres no need for it to be a lvalue
if it where "=m" then your argument is certainly true and it would have to be an lvalue ...
imo it does make sense to require an lvalue. "m" is the inline-asm equivalent of the & (address of) operator in c, and thus it makes sense to require not only an lvalue, but an lvalue for which taking the address makes sense (e.g. not a variable declared as register). rich
Hi On Monday 28 February 2005 06:24, D Richard Felker III wrote:
On Mon, Feb 28, 2005 at 04:42:06AM +0100, Michael Niedermayer wrote:
There is no advantage to retain a broken code even if it's more readable.
please elaborate about why it is broken in your oppinion
a binary and over two vars has not a memory location then has not an lvalue to put in asm code, I'm not the only that says this, if you disagree complain to gcc developers... :)
"m" is NOT an output, its an input only constraint, "=m" would be an output, so IMO theres no need for it to be a lvalue
if it where "=m" then your argument is certainly true and it would have to be an lvalue ...
imo it does make sense to require an lvalue. "m" is the inline-asm equivalent of the & (address of) operator in c, and thus it makes
IMO "m" is not the equivalent of address of, if it where this would have very serious consequences there are 2 possibilities, either the compiler is able to copy a value onto the stack and access it via esp/ebp or it is not able to do the (address of) equivalently would mean no copy to stack, but this would make it practically impossible for gcc to solve the register assignment, as the copy to stack is needed as a fallback if gcc runs out of registers, yes i know this is exactly what happens, as gcc never copies a variable from memory to a different location furtermore "m" can and is often not a single register but base+index*scale+offset style address, this really isnt equivalent of an (address of) operator, IMO "g"(&foobar) would be, though that would need to be written as void *dummy= &foobar; ... "g"(dummy) now with latest and greatest gcc [...] -- Michael "nothing is evil in the beginning. Even Sauron was not so." -- Elrond
Hi, On Mon, Feb 28, 2005 at 12:24:57AM -0500, D Richard Felker III wrote:
On Mon, Feb 28, 2005 at 04:42:06AM +0100, Michael Niedermayer wrote:
"m" is NOT an output, its an input only constraint, "=m" would be an output, so IMO theres no need for it to be a lvalue
if it where "=m" then your argument is certainly true and it would have to be an lvalue ...
imo it does make sense to require an lvalue. "m" is the inline-asm equivalent of the & (address of) operator in c, and thus it makes sense to require not only an lvalue, but an lvalue for which taking the address makes sense (e.g. not a variable declared as register).
Sorry, but IMHO then printf("hello"); shouldn't be valid either, and instead you would have to do char hello[6]={'h','e','l','l','o',0}; printf(hello); Probably that will be the newest feature in gcc5... Greetings, Reimar Döffinger
On Sun, Feb 27, 2005 at 11:00:20AM +0100, Gianluigi Tiesi wrote:
On Sat, Feb 26, 2005 at 10:56:50PM +0100, Michael Niedermayer wrote:
Hi
On Friday 25 February 2005 20:43, Gianluigi Tiesi wrote:
Updated patches to be compatible with gcc-2.95
+ int ptr;
very missleading name (an integer with name ptr)
+ ptr = ((int) src) + filterSize;
you can use different name or use unsigned int since it should be equal to a pointer, here filterSize is an int and it's added to a pointer, also this sum should be wrong. Anyway this can be decared as a pointer but adding filterSize will cause compiler to complain, but I think this can be acceptable.
Nonsense. pointer = pointer + int; is totally valid C. Learn C if you're going to patch C code... :) Rich
On Sun, Feb 27, 2005 at 01:22:48PM -0500, D Richard Felker III wrote:
On Sun, Feb 27, 2005 at 11:00:20AM +0100, Gianluigi Tiesi wrote:
On Sat, Feb 26, 2005 at 10:56:50PM +0100, Michael Niedermayer wrote:
Hi
On Friday 25 February 2005 20:43, Gianluigi Tiesi wrote:
Updated patches to be compatible with gcc-2.95
+ int ptr;
very missleading name (an integer with name ptr)
+ ptr = ((int) src) + filterSize;
you can use different name or use unsigned int since it should be equal to a pointer, here filterSize is an int and it's added to a pointer, also this sum should be wrong. Anyway this can be decared as a pointer but adding filterSize will cause compiler to complain, but I think this can be acceptable.
Nonsense. pointer = pointer + int; is totally valid C. Learn C if you're going to patch C code... :)
Rich ...
-- Gianluigi Tiesi <sherpya@netfarm.it> EDP Project Leader Netfarm S.r.l. - http://www.netfarm.it/ Free Software: http://oss.netfarm.it/
On Thursday 24 February 2005 19:15, Gianluigi Tiesi wrote:
I'm also in doubt with: extern struct STRTAB chanlist_names[]; that I've changed in: extern struct CHANLISTS chanlist_names[];
You can use extern struct STRTAB *chanlist_names; For all that matters, it's equivalent to extern struct STRTAB chanlist_names[];, and gcc 4.0 accepts that variant.
I've no clue to compile libmpcodecs/native/RTjpegN.c with gcc4, it complains for a wrong operand in mmx (?) instructions.
That looks like broken constraints given in mmx.h -- try the attached patch, works for me. LLaP bero
Hi On Friday 25 February 2005 22:36, Bernhard Rosenkraenzer wrote:
On Thursday 24 February 2005 19:15, Gianluigi Tiesi wrote: [...]
I've no clue to compile libmpcodecs/native/RTjpegN.c with gcc4, it complains for a wrong operand in mmx (?) instructions.
That looks like broken constraints given in mmx.h -- try the attached patch, works for me.
1 of 22 broken constraints fixed ... why dont u fix the others too? or even better fix the code so it doesnt need this broken crap [...] -- Michael "nothing is evil in the beginning. Even Sauron was not so." -- Elrond
On Sat, Feb 26, 2005 at 10:35:20PM +0100, Michael Niedermayer wrote:
Hi
On Friday 25 February 2005 22:36, Bernhard Rosenkraenzer wrote:
On Thursday 24 February 2005 19:15, Gianluigi Tiesi wrote: [...]
I've no clue to compile libmpcodecs/native/RTjpegN.c with gcc4, it complains for a wrong operand in mmx (?) instructions.
That looks like broken constraints given in mmx.h -- try the attached patch, works for me.
1 of 22 broken constraints fixed ... why dont u fix the others too? or even better fix the code so it doesnt need this broken crap
[...] -- As I said I have no clue about mmx, so if someone understands mmx and can fix in a better way ;)
-- Gianluigi Tiesi <sherpya@netfarm.it> EDP Project Leader Netfarm S.r.l. - http://www.netfarm.it/ Free Software: http://oss.netfarm.it/
participants (7)
-
Bernhard Rosenkraenzer -
D Richard Felker III -
Gianluigi Tiesi -
Jindrich Makovicka -
Michael Niedermayer -
Reimar Döffinger -
Zoltan Hidvegi