Re: GCC 3.2 bootstrap: compare fails
* 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?
> 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?
> --- 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?
I saw this went into the 2.3.x tree
> +++ 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?
> --- gcc-3.2-cvs/gcc/config.gcc.rz Tue Aug 6 11:20:55 2002
> +++ gcc-3.2-cvs/gcc/config.gcc Wed Aug 21 22:49:01 2002
> @@ -2078,7 +2078,7 @@
> # GNU/Linux C library 5
> tm_file=m68k/linux.h
> tmake_file="t-slibgcc-elf-ver t-linux t-linux-gnulibc1 m68k/t-linux"
> - extra_parts="crtbegin.o crtbeginS.o crtend.o crtendS.o"
> + extra_parts="crtbegin.o crtbeginS.o crtend.o crtendS.o crtbeginT.o"
> float_format=m68k
> gnu_ld=yes
> ;;
> @@ -2087,7 +2087,7 @@
> # aka the GNU/Linux C library 6.
> tm_file=m68k/linux.h
> tmake_file="t-slibgcc-elf-ver t-linux m68k/t-linux"
> - extra_parts="crtbegin.o crtbeginS.o crtend.o crtendS.o"
> + extra_parts="crtbegin.o crtbeginS.o crtend.o crtendS.o crtbeginT.o"
> float_format=m68k
> gnu_ld=yes
> ;;
Ah.. noticed this one, too. Are there any evil side effects when
symbolic linking crtbeginS.o to crtbeginT.o (did that while compiling
init). Want to keep the number of recompiles low as it took me 8 days
to compile gcc, even more for glibc last time..
Stefan
--
The x86 isn't all that complex - it just doesn't make a lot of
sense. -- Mike Johnson, Leader of 80x86 Design at AMD
Microprocessor Report (1994)
Reply to: