On Oct 14, 2002, "H. J. Lu" <hjl@lucon.org> wrote: > Have you ever tried g++.dg/opt/longbranch1.C in gcc 3.2 for ELF/mips? Yes, I have, and it has failed in the past. I don't know about the current status and, frankly, I don't understand what point you're trying to make waving your hands in the general direction of longbranch1.C while discussing whether gas would have any chance of filling a delay slot that gcc has failed to fill. > If you want, I can tell you where you can find a complete cross > toolchain for Linux/mips hosted on Linux/x86. Thanks, I've built such toolchains more than once a day lately :-) I know the problem that branch relaxation is intended to solve: it's a work around for a long-standing bug in the compiler. In that it apparently assumes that the expansion of certain macros is shorter than they actually are, so it ends up not doing branch shortening in some necessary situations. This gets even worse with mips16, in which we don't do branch shortening, and the assembler doesn't do branch relaxation. But while you're trying to paper over the problem, others are rewriting the mips back end so as to not make use of macros, such that instruction lengths will be more accurate and then branch shortening will (hopefully) work correctly. The compiler is the right place in which to fix out-of-range jumps, because the compiler has better information on how to reduce the performance impact of such transformation. It can be fixed in the assembler, but it can't be done as efficiently. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer aoliva@{redhat.com, gcc.gnu.org} CS PhD student at IC-Unicamp oliva@{lsd.ic.unicamp.br, gnu.org} Free Software Evangelist Professional serial bug killer
