[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203 Jackie Rosen jackie.rosen at hushmail dot com changed: What|Removed |Added CC||jackie.rosen at hushmail dot com --- Comment #41 from Jackie Rosen jackie.rosen at hushmail dot com --- *** Bug 260998 has been marked as a duplicate of this bug. *** Seen from the domain http://volichat.com Marked for reference. Resolved as fixed @bugzilla.
[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3
--- Comment #40 from astrange at ithinksw dot com 2009-10-18 19:56 --- Linked from http://x264dev.multimedia.cx/?p=185, I'd forgotten all about the ridiculous flamewar in this one. Just as a note, the actual definitions of the four variables (from liba52): x2k = x + 2 * k; x3k = x2k + 2 * k; x4k = x3k + 2 * k; wB = wTB + 2 * k; Also, the asm inputs are silly - output 0 is the same as input 6 for no reason, and the same with output 2 and input 7. So change those to +m and change %6/%7 to %0/%2. That doesn't actually change anything, even though it should free two registers. It works with gcc 4.5 -O0 -fno-pic -fomit-frame-pointer, but not without one of those flags. Looks like that's because it's allocating 2 more registers for the unused fake inputs for the +m - change it to =m and it works with one flag removed, but still not both. So there's a specific bug. And of course it all works at -O1 because it doesn't have to use registers there. So maybe it should just do that. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3
--- Comment #38 from xyzzy at speakeasy dot org 2007-02-27 19:36 --- (In reply to comment #37) now if there is a unwritten rule that m operands and variations of them cannot be copied anywhere, then it would be very desireable to have a asm constraint like m without this restriction this would resolve this and several other bugs also it would be very nice if such a dont copy restriction on m if it does exist could be documented Copying m operands onto the stack might not be such a great thing to wish for. Imagine if you used asm(movaps %xmm0, %0: =m(x[i])); If x[i] is only 32-bits, and gcc copied it onto the stack, then writing 16 bytes with movaps wouldn't also write to x[i+1] to x[i+3] as intended. I know there is a plenty of asm code in ffmpeg that overwrites or overreads memory operands and will fail if gcc tried to move them onto the stack. There is also alignment. movaps requires an aligned address, and maybe you have chosen x and i in such a way that it will be aligned. But when gcc copies the value onto the stack, how is it supposed to know what alignment it needs? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3
--- Comment #39 from michaelni at gmx dot at 2007-02-27 22:50 --- (In reply to comment #38) (In reply to comment #37) now if there is a unwritten rule that m operands and variations of them cannot be copied anywhere, then it would be very desireable to have a asm constraint like m without this restriction this would resolve this and several other bugs also it would be very nice if such a dont copy restriction on m if it does exist could be documented Copying m operands onto the stack might not be such a great thing to wish for. Imagine if you used asm(movaps %xmm0, %0: =m(x[i])); If x[i] is only 32-bits, and gcc copied it onto the stack, then writing 16 bytes with movaps wouldn't also write to x[i+1] to x[i+3] as intended. I know there is a plenty of asm code in ffmpeg that overwrites or overreads memory operands and will fail if gcc tried to move them onto the stack. There is also alignment. movaps requires an aligned address, and maybe you have chosen x and i in such a way that it will be aligned. But when gcc copies the value onto the stack, how is it supposed to know what alignment it needs? well the data type used in m() must of course be correct, that is here a 128bit type, alignment can be handled like with all other types, double also gets aligned if the architecture needs it, so a uint128_t or sse128 or whatever can as well, the example you show is a fairly obscure special case in respect to moving m to the stack, in the end theres a need for a m like constraint which must not be moveable and a m like constraint which should be moveable (to the stack for example) the exact letters used are irrelevant -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3
--- Comment #36 from xyzzy at speakeasy dot org 2006-11-08 20:03 --- (In reply to comment #21) asm volatile( : =m (*(unsigned int*)(src + 0*stride)), =m (*(unsigned int*)(src + 1*stride)), =m (*(unsigned int*)(src + 2*stride)), =m (*(unsigned int*)(src + 3*stride)), =m (*(unsigned int*)(src + 4*stride)), =m (*(unsigned int*)(src + 5*stride)), =m (*(unsigned int*)(src + 6*stride)), =m (*(unsigned int*)(src + 7*stride)) ); (In reply to comment #26) it might also happen that in some intentionally overconstrained cases it ends up searching the whole 5040 possible assignments of 7 registers onto 7 non memory operands but still it wont fail The example Martin gave has *8* operands. You can try every possible direct mapping of those 8 addresses to just 7 registers, but they will obviously all fail. Except with ia32 addressing modes it _can_ be done, and with only 4 registers. reg1 = src, reg2 = stride, reg3 = src+stride*3, reg4 = src+stride*6 Then the 8 memory operands are: (reg1), (reg1,reg2,1), (reg1,reg2,2), (reg3), (reg1,reg2,4), (reg3,reg2,2), (reg4), (reg3,reg2,4) When one considers all the addressing modes, there are not just 7 possible registers, but (I think) 261 possible addresses. There are not just 5040 possibilities as Michael said, but over 76 x 10^15 possible ways of assigning these addresses to 7 operands! Then each register can be loaded not just with an address but with some sub-expression too, like how I loaded reg2 with stride. Even for ia32, which makes up for its limited number of registers with complex addressing modes, finding a register allocation that satisfies an asm statement is not something that can always be done in reasonable time. If the number of operands = number of available registers it should be able to (but gcc doesn't) always find an allocation (_an_ allocation, not the best allocation). -- xyzzy at speakeasy dot org changed: What|Removed |Added CC||xyzzy at speakeasy dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3
--- Comment #37 from michaelni at gmx dot at 2006-11-08 20:45 --- (In reply to comment #36) (In reply to comment #21) asm volatile( : =m (*(unsigned int*)(src + 0*stride)), =m (*(unsigned int*)(src + 1*stride)), =m (*(unsigned int*)(src + 2*stride)), =m (*(unsigned int*)(src + 3*stride)), =m (*(unsigned int*)(src + 4*stride)), =m (*(unsigned int*)(src + 5*stride)), =m (*(unsigned int*)(src + 6*stride)), =m (*(unsigned int*)(src + 7*stride)) ); (In reply to comment #26) it might also happen that in some intentionally overconstrained cases it ends up searching the whole 5040 possible assignments of 7 registers onto 7 non memory operands but still it wont fail The example Martin gave has *8* operands. You can try every possible direct mapping of those 8 addresses to just 7 registers, but they will obviously all fail. Except with ia32 addressing modes it _can_ be done, and with only 4 registers. reg1 = src, reg2 = stride, reg3 = src+stride*3, reg4 = src+stride*6 Then the 8 memory operands are: (reg1), (reg1,reg2,1), (reg1,reg2,2), (reg3), (reg1,reg2,4), (reg3,reg2,2), (reg4), (reg3,reg2,4) When one considers all the addressing modes, there are not just 7 possible registers, but (I think) 261 possible addresses. There are not just 5040 possibilities as Michael said, but over 76 x 10^15 possible ways of assigning these addresses to 7 operands! Then each register can be loaded not just with an address but with some sub-expression too, like how I loaded reg2 with stride. m operands and variations can be copied onto the stack and accessed from there, so no matter how many memory operands there are they can always be accessed over esp on ia32, so whatever you did calculate it is meaningless now if there is a unwritten rule that m operands and variations of them cannot be copied anywhere, then it would be very desireable to have a asm constraint like m without this restriction this would resolve this and several other bugs also it would be very nice if such a dont copy restriction on m if it does exist could be documented -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3
--- Comment #34 from langer_mann at web dot de 2006-04-21 15:56 --- The reason is dead simple: register allocation is NP-complete, so it is even *theoretically* not possible to write register allocators that always find a coloring. Not at all. If a problem is NP-hard, you can in fact solve it! It is just quite likely that your algortihm takes exponentiallly many steps in the size of the problem. Which, given the few registers of x86 might turn out not to be a problem. That means any register allocator will always fail on some very constrained asm input. And you cannot allow it to run indefinitely until a coloring is found, because then you've turned the graph coloring problem into the halting problem because you can't prove that a coloring exists and that the register allocator algorithm will terminate. Not necessary. The coloring problem is decidable (just enumerate all the colorings aka. register mappings), whereas the halting problem is not decidable (or semi-decidable if you're intrested in that) So really it doesn't matter at all whether or not your specific inline asm compiles or not. When yours does, someone else's will fail. Nope. -- langer_mann at web dot de changed: What|Removed |Added CC||langer_mann at web dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3
--- Comment #35 from langer_mann at web dot de 2006-04-21 15:59 --- (In reply to comment #34) The reason is dead simple: register allocation is NP-complete, so it is even *theoretically* not possible to write register allocators that always find a coloring. Not at all. If a problem is NP-hard, you can in fact solve it! It is just quite likely that your algortihm takes exponentiallly many steps in the size of the problem. Which, given the few registers of x86 might turn out not to be a problem. That means any register allocator will always fail on some very constrained asm input. And you cannot allow it to run indefinitely until a coloring is found, because then you've turned the graph coloring problem into the halting problem because you can't prove that a coloring exists and that the register allocator algorithm will terminate. Not necessary. The coloring problem is decidable (just enumerate all the colorings aka. register mappings), whereas the halting problem is not decidable (or semi-decidable if you're intrested in that) So really it doesn't matter at all whether or not your specific inline asm compiles or not. When yours does, someone else's will fail. Nope. Sorry for the spam. Didn't read up to the end. Have been quite angry with the whole situation -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3
--- Comment #33 from pinskia at gcc dot gnu dot org 2006-01-19 12:38 --- *** Bug 25853 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||backes at rhrk dot uni-kl ||dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3
--- Comment #31 from pinskia at gcc dot gnu dot org 2005-12-02 17:44 --- *** Bug 25226 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pluto at agmk dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3
--- Comment #32 from pinskia at gcc dot gnu dot org 2005-12-02 17:46 --- *** Bug 25221 has been marked as a duplicate of this bug. *** -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||jakub at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-09-05 22:20 --- *** Bug 23743 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||halcy0n at gentoo dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-26 00:29 --- *** Bug 20645 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||mikulas at artax dot karlin ||dot mff dot cuni dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3
--- Additional Comments From spigel at olvs dot miee dot ru 2005-01-24 06:45 --- Subject: Re: source doesn't compile with -O0 but they compile with -O3 Yeah, fine battle! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-22 12:14 --- Martin, you should realize that this problem *cannot* be solved. Yes, there will perhaps be a time when this particular test case compiles, though I think that is unlikely. But anyway, then there will be other cases that fail. The reason is dead simple: register allocation is NP-complete, so it is even *theoretically* not possible to write register allocators that always find a coloring. That means any register allocator will always fail on some very constrained asm input. And you cannot allow it to run indefinitely until a coloring is found, because then you've turned the graph coloring problem into the halting problem because you can't prove that a coloring exists and that the register allocator algorithm will terminate. So really it doesn't matter at all whether or not your specific inline asm compiles or not. When yours does, someone else's will fail. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3
--- Additional Comments From stian at nixia dot no 2005-01-22 15:58 --- if you resolve all memory-referenses to temporary variables void *a=(src + 0*stride) and use those instead. Doesn't that lessen the stress the register-allocator is given? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3
--- Additional Comments From michaelni at gmx dot at 2005-01-22 17:10 --- (In reply to comment #14) In any case, just because code is syntactically valid GNU C doesn't mean gcc can always compile it. With this kind of inline asm, you're bound to confuse the register allocator. The fact that it works at O3 is pure luck and not a bug. well, you are the gcc developers so theres not much arguing about what you consider valid, but last time i checked the docs did not mention that asm statemts may fail to compile at random, and IMO as long as this is not clearly stated in the docs this bugreport really shouldnt be marked as invalid, say you dont want to fix it, say it would be too complicated to fix or whatever but its not invalid Note that you're hitting an *error*, not an ICE. no, at least one of the bugreports marked as duplicate of this ends in an ICE (In reply to comment #24) Martin, you should realize that this problem *cannot* be solved. Yes, there will perhaps be a time when this particular test case compiles, though I think that is unlikely. But anyway, then there will be other cases that fail. hmm, so the probelm cannot be solved but then maybe it will be solved but this doesnt count because there will be other unrelated bugs? i cant follow this reasoning or do u mean that u can never solve all bugs and so theres no need to fix any single one? The reason is dead simple: register allocation is NP-complete, so it is even *theoretically* not possible to write register allocators that always find a coloring. register allocation in general is NP-complete, yes, but it seems u forget that this is about finding the optimal solution while gcc fails finding any solution which in practice is a matter of assigning the registers beginning from the most constrained operands to the least, and copying a few things on the stack if gcc cant figure out howto access them, sure this method might fail in 0.001% of the practical cases and need a 2nd or 3rd pass where it tries different registers it might also happen that in some intentionally overconstrained cases it ends up searching the whole 5040 possible assignments of 7 registers onto 7 non memory operands but still it wont fail That means any register allocator will always fail on some very constrained asm input. now that statement is just false, not to mention irrelevant as none of these asm statemets are unreasonably constrained And you cannot allow it to run indefinitely until a coloring is found, because then you've turned the graph coloring problem into the halting problem because you can't prove that a coloring exists and that the register allocator algorithm will terminate. this is ridiculous, the number of possible colorings is finite, u can always try them all in finite time -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
Re: [Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3
The reason is dead simple: register allocation is NP-complete, so it is even *theoretically* not possible to write register allocators that always find a coloring. register allocation in general is NP-complete, yes, but it seems u forget that this is about finding the optimal solution while gcc fails finding any solution which in practice is a matter of assigning the registers beginning from the most constrained operands to the least, and copying a few things on the stack if gcc cant figure out howto access them, sure this method might fail in 0.001% of the practical cases and need a 2nd or 3rd pass where it tries different registers it might also happen that in some intentionally overconstrained cases it ends up searching the whole 5040 possible assignments of 7 registers onto 7 non memory operands but still it wont fail Just to also point out, it doesn't appear to be NP complete for register interference graphs, because they all seem to be 1-perfect. Various papers have observed this, and i've actually compiled all of gcc, libstdc++, etc, and every package ever on my computer, and not once has a single non-1-perfect interference graph occurred [my compiler would abort if it was true]. On 1-perfect graphs you can solve this problem in O(time it takes to determine the max clique), and there already exists a polynomial time algorithm for max-clique on perfect graphs. That means any register allocator will always fail on some very constrained asm input. now that statement is just false, not to mention irrelevant as none of these asm statemets are unreasonably constrained You are correct, NP completeness does not imply impossiblity. There are only a finite number of possibilities. And you cannot allow it to run indefinitely until a coloring is found, because then you've turned the graph coloring problem into the halting problem because you can't prove that a coloring exists and that the register allocator algorithm will terminate. this is ridiculous, the number of possible colorings is finite, u can always try them all in finite time You are right, he is wrong.
[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3
--- Additional Comments From dberlin at gcc dot gnu dot org 2005-01-22 17:21 --- Subject: Re: source doesn't compile with -O0 but they compile with -O3 The reason is dead simple: register allocation is NP-complete, so it is even *theoretically* not possible to write register allocators that always find a coloring. register allocation in general is NP-complete, yes, but it seems u forget that this is about finding the optimal solution while gcc fails finding any solution which in practice is a matter of assigning the registers beginning from the most constrained operands to the least, and copying a few things on the stack if gcc cant figure out howto access them, sure this method might fail in 0.001% of the practical cases and need a 2nd or 3rd pass where it tries different registers it might also happen that in some intentionally overconstrained cases it ends up searching the whole 5040 possible assignments of 7 registers onto 7 non memory operands but still it wont fail Just to also point out, it doesn't appear to be NP complete for register interference graphs, because they all seem to be 1-perfect. Various papers have observed this, and i've actually compiled all of gcc, libstdc++, etc, and every package ever on my computer, and not once has a single non-1-perfect interference graph occurred [my compiler would abort if it was true]. On 1-perfect graphs you can solve this problem in O(time it takes to determine the max clique), and there already exists a polynomial time algorithm for max-clique on perfect graphs. That means any register allocator will always fail on some very constrained asm input. now that statement is just false, not to mention irrelevant as none of these asm statemets are unreasonably constrained You are correct, NP completeness does not imply impossiblity. There are only a finite number of possibilities. And you cannot allow it to run indefinitely until a coloring is found, because then you've turned the graph coloring problem into the halting problem because you can't prove that a coloring exists and that the register allocator algorithm will terminate. this is ridiculous, the number of possible colorings is finite, u can always try them all in finite time You are right, he is wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3
--- Additional Comments From drab at kepler dot fjfi dot cvut dot cz 2005-01-21 12:39 --- (In reply to comment #15) I will note for the record that disabling local-alloc will resolve this problem. A patch for that is in the audit trail of another bug, for unrelated reasons: http://gcc.gnu.org/PR13776. It also happens to fix the particular problem in this bug report. I didn't test the source proposed in this bugreport, but the patch mentioned above (disabling of local-alloc) DOES NOT resolve the problem with the testcode proposed in bugreport http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19549, and, though, it also doesn't fix the problem of compiling ffmpegs libavcodec/i386/dsputil_mmx.c, because that is the original, from which the testcode was extracted/simplified. So, either it is not the same bug (as marked by Andrew) or the problem was not resolved. And IMHO this shoul be perfectly valid, since the operands to the asm construction are all marked as m (!!!), so no registers should be needed for that! They are just memory operands!! And so I think this bug (or at least http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19549) should NOT be marked as resolved. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3
--- Additional Comments From falk at debian dot org 2005-01-21 13:55 --- (In reply to comment #17) And IMHO this shoul be perfectly valid, since the operands to the asm construction are all marked as m (!!!), so no registers should be needed for that! Huh? The memory operands are not at a compile time constant address, so of course you need a register to hold them. Of course, you need only one register for all of them, but you explicitely disallowed gcc to discover that by specifying -O0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3
--- Additional Comments From drab at kepler dot fjfi dot cvut dot cz 2005-01-21 14:10 --- (In reply to comment #18) Huh? The memory operands are not at a compile time constant address, so of course you need a register to hold them. Of course, you need only one register for all of them, but you explicitely disallowed gcc to discover that by specifying -O0. Sure, one, sorry. But problem is the Bug 19549 testcode doesn't compile AT ALL. I.e., not only with -O0, but also with -O1, -O2, or -O3. It simply doesn't compile under any circumstances. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-21 15:15 --- *** Bug 19549 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3
--- Additional Comments From drab at kepler dot fjfi dot cvut dot cz 2005-01-21 15:49 --- OK, sorry, the Bug 19549 testcode passes with -O1 and above, but the original, that it was stripped from (maybe too much stripped) doesn't: -- test2.c - extern const unsigned char ff_h263_loop_filter_strength[32]; static const unsigned long long ff_pb_FC __attribute__((used)) __attribute__ ((aligned(8))) = 0xFCFCFCFCFCFCFCFCULL; void h263_h_loop_filter_mmx(unsigned char *src, int stride, int qscale){ const int strength= ff_h263_loop_filter_strength[qscale]; unsigned long long temp[4] __attribute__ ((aligned(8))); unsigned char *btemp= (unsigned char *)temp; src -= 2; asm volatile( : +m (temp[0]), +m (temp[1]), +m (temp[2]), +m (temp[3]) : g (2*strength), m(ff_pb_FC) ); asm volatile( : =m (*(unsigned int*)(src + 0*stride)), =m (*(unsigned int*)(src + 1*stride)), =m (*(unsigned int*)(src + 2*stride)), =m (*(unsigned int*)(src + 3*stride)), =m (*(unsigned int*)(src + 4*stride)), =m (*(unsigned int*)(src + 5*stride)), =m (*(unsigned int*)(src + 6*stride)), =m (*(unsigned int*)(src + 7*stride)) ); } Or do you consider this also invalid? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3
--- Additional Comments From falk at debian dot org 2005-01-21 16:33 --- (In reply to comment #21) Or do you consider this also invalid? It doesn't seem invalid to me. But it is basically impossible to write the register allocator such that it finds a register allocation for every situation where it's theoretically possible. So this is unlikely to get fixed in a reliable way. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3
--- Additional Comments From drab at kepler dot fjfi dot cvut dot cz 2005-01-21 16:48 --- (In reply to comment #22) It doesn't seem invalid to me. But it is basically impossible to write the register allocator such that it finds a register allocation for every situation where it's theoretically possible. So this is unlikely to get fixed in a reliable way. OK, I guess I fixed the code in the ffmpeg to help gcc in the compilation a bit (I hope it will be accepted). So consider the above code rather as another code for testing, if occasionally, sometimes the problem gets resolved. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-20 21:04 --- *** Bug 19549 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||drab at kepler dot fjfi dot ||cvut dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3
--- Additional Comments From stian at nixia dot no 2005-01-01 17:15 --- Reference to other bug-reports: http://bugs.gentoo.org/show_bug.cgi?id=71360 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-01-01 17:22 --- Why do people write inline-asm like this? It is crazy to do so. Split up the inline-asm correctly. Anyone who writes like inline-asm should get what they get. For mmx inline-asm, you should be using the intrinsics instead as suggested before or just write real asm file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3
--- Additional Comments From michaelni at gmx dot at 2005-01-01 18:57 --- (In reply to comment #12) Why do people write inline-asm like this? why not? its valid code and a compiler should compile valid code ... It is crazy to do so. Split up the inline-asm correctly. fix gcc first so it doesnt loadstore more then needed between the splited up parts Anyone who writes like inline-asm should get what they get. For mmx inline-asm, you should be using the intrinsics instead as suggested before lets see why its not using intrinsics * it was written before intrinsics support was common * intrinsics fail / get misscompiled commonly, its so bad that some of the altivec intrinsic code has been disabled in ffmpeg if standard gcc is detected, there also have been very serious and similar problems in mplayer with altivec-intrinsics, sadly i cant provide more details as i dont have a ppc * many if not most of the mplayer developers still use gcc 2.95 because gcc 3.* is slower and needs more memory, and AFAIK 2.95 doesnt support intrinsics * it is alot of work to rewrite and debug it just to make it compileable with gcc -O0 or just write real asm file. thats not a good idea either as: * its slower due to the additional call/ret/parameter passing * there are some symbol name mangling issues on some obscure systems (see mplayer-dev or cvslog mailinglist, it was disscussed there a long time ago) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-01 22:50 --- You've just constrained the compiler too much to do anything. You're right that gcc should produce fewer loads and stores sometimes, but in this case I suggest you show that this actually hurts you still with GCC 4.0, I would hope it does better. In any case, just because code is syntactically valid GNU C doesn't mean gcc can always compile it. With this kind of inline asm, you're bound to confuse the register allocator. The fact that it works at O3 is pure luck and not a bug. Note that you're hitting an *error*, not an ICE. It is a deliberate choice to inform you that GCC cannot compile your inline assembly. Bad luck for you. -- What|Removed |Added Status|NEW |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203
[Bug inline-asm/11203] source doesn't compile with -O0 but they compile with -O3
--- Additional Comments From steven at gcc dot gnu dot org 2005-01-01 23:05 --- I will note for the record that disabling local-alloc will resolve this problem. A patch for that is in the audit trail of another bug, for unrelated reasons: http://gcc.gnu.org/PR13776. It also happens to fix the particular problem in this bug report. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11203