Re: GCC 3.2 bootstrap: compare fails
On Fri, Nov 22, 2002 at 02:44:47PM +0100, Stefan Reinauer wrote:
> * Richard Zidlicky <rz@linux-m68k.org> [021007 13:51]:
> > > make CFLAGS='-O' LIBCFLAGS='-g -O2' \
> > > LIBCXXFLAGS='-g -O2 -fno-implicit-templates' bootstrap
> >
> > are you sure you want to use this CFLAGS?
>
> Is there anything that really _has_ to go to CFLAGS for m68k?
> I am currently using -O2 -fomit-frame-pointer.
>
> > looks like pretty serious. Binutils 2.13 may be producing wrong code
> > with gcc-3.2, this was fixed only very recently.
>
> I'm currently using binutils-2.13.90.0.10 with some patches and it
> has the bug you described fixed in a more generic way.
>
> > gcc-3.2 works very good for me with another set of patches, no idea
> > what kind of patches are in the debian-gcc-3.2.
>
> Anything 68k specific in that?
all of the patches are m68k specific.
> > There is also a problem that some binutils used to produce code that
> > is sometimes (actually very rarely) incompatible with the dynamic loader
> > in glibc, not sure if this is already fixed in debian.
>
> I get weird return code 139 (which is like 128+11?) from ldd from time
> to time and my gettext/locale stuff seems terribly broken (lots of
> segfaults). Still waiting for gdb to compile until I see more.
> This is glibc-2.2.5 with some patches on it.
>
> > I have attached some patches in case you want to play with it. The gcc
> > patch has also the effect to change cpu target default to 68020-60.
>
> Is this going to produce better code for 68030+ or rather fix the code
> not to use some 020 specifics?
the later, 68060 doesn't have 32x32->64 mul/div insns so this patch
avoids them. Makes some speed difference for bignum apps like crypto
etc.
> > --- glibc-2.2.90/sysdeps/m68k/dl-machine.h.rz Mon Aug 26 11:44:44 2002
> > +++ glibc-2.2.90/sysdeps/m68k/dl-machine.h Mon Aug 26 11:45:31 2002
> > @@ -311,6 +311,8 @@
> > Elf32_Addr *const reloc_addr = (void *) (l_addr + reloc->r_offset);
> > if (ELF32_R_TYPE (reloc->r_info) == R_68K_JMP_SLOT)
> > *reloc_addr += l_addr;
> > + else if (ELF32_R_TYPE (reloc->r_info) == R_68K_NONE)
> > + return;
> > else
> > _dl_reloc_bad_type (map, ELF32_R_TYPE (reloc->r_info), 1);
> > }
>
> This basically keeps elf_machine_rela() from executing
> _dl_reloc_bad_type() in case of R_68K_NONE. Does this actually
> fix any nonworking code or is it there to prevent funny messages?
not just the funny message, dl_reloc_bad_type will kill the
program.
> I saw this went into the 2.3.x tree
good. Oh well, binutils should be fixed not to produce NULL
relocs anyway.
> > +++ gcc-3.2-cvs/gcc/simplify-rtx.c Sat Aug 24 23:06:34 2002
> > @@ -2618,6 +2618,7 @@
> > suppress this simplification. If the hard register is the stack,
> > frame, or argument pointer, leave this as a SUBREG. */
> >
> > +#if 0
> > if (REG_P (op)
> > && (! REG_FUNCTION_VALUE_P (op)
> > || ! rtx_equal_function_value_matters)
> > @@ -2662,6 +2663,7 @@
> > return x;
> > }
> > }
> > +#endif
> >
> > /* If we have a SUBREG of a register that we are replacing and we are
> > replacing it with a MEM, make a new MEM and try replacing the
> > --- gcc-3.2-cvs/gcc/flow.c.rz Thu Apr 18 16:21:09 2002
> > +++ gcc-3.2-cvs/gcc/flow.c Wed Aug 21 22:49:01 2002
> > @@ -1770,8 +1770,11 @@
> > so they are made live. */
> > for (i = 0; i < FIRST_PSEUDO_REGISTER; i++)
> > if (global_regs[i])
> > - mark_used_reg (pbi, gen_rtx_REG (reg_raw_mode[i], i),
> > - cond, insn);
> > + {
> > + SET_REGNO_REG_SET (pbi->reg_live, i);
> > + mark_used_reg (pbi, gen_rtx_REG (reg_raw_mode[i], i),
> > + cond, insn);
> > + }
> > }
> > }
>
> What's the effect of the above 2 changes?
gnats PR's 7872 and 7871.
> Ah.. noticed this one, too. Are there any evil side effects when
> symbolic linking crtbeginS.o to crtbeginT.o (did that while compiling
> init).
I have done much the same and it appeared to work, not heavilly
tested.
Want to keep the number of recompiles low as it took me 8 days
> to compile gcc, even more for glibc last time..
get distcc!!! Getting a crosscompiler to work with that is so
easy that there is no excuse not to do it :)
Richard
Reply to: