------- 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