Re: gcc 3.3.1 fixes
"Valeriy E. Ushakov" <[email protected]>
| Newsgroups | gmane.os.netbsd.ports.sh3,gmane.os.netbsd.devel.toolchain |
|---|---|
| Message-ID | <[email protected]> |
On Wed, Jul 30, 2003 at 14:38:49 +0400, Valeriy E. Ushakov wrote: > I'm trying to build hpcsh with the new gcc 3.3.1. Can someone please > review the changes I had to do. [...] > 1. NO_PROFILE_COUNTERS [...] Committed. > 2. const in ASM_OUTPUT_LABELREF - w/out it the build dies with > "discard qualifiers" warning/error. Committed. > 3. the rest is the RETURN_ADDR_RTX changes (done after alpha and mmix). Committed. I have redone this fix by pulling the same change from gcc-current. > I've almost successfully completed the hpcsh build (MKPROFILE=no) with > the last two changes in my tree. The only problem was: > > /nb/src/gnu/dist/gcc/gcc/function.c: In function `assign_parms': > /nb/src/gnu/dist/gcc/gcc/function.c:4740: warning: `and' of mutually exclusive equal-tests is always 0 > > Which I fail to understand, as the only && in that condition seems to > be TARGET_SHMEDIA that expands to: > > (target_flags & SH5_BIT) && !(target_flags & SH1_BIT) This one still exists. Other than that one glitch the word compiles cleanly. However some of the resulting binaries behave strangely. E.g. mv(1) will always fail with "out of memory", ksh will dump core, sshd will complain that there's no userfor privilege separation, etc. I have tracked it down to this: If gcc needs to do an integer division it will emit a call to __udivsi3, but it will *NOT* mark scratch registers as clobbered by that call. So it will happily use scratch registers to keep values across the call to __udivsi3 (r2 in the mv(1) case I used to debug this). The problem is that __udivsi3 is in libc, so it gets linked dynamically. If __udivsi3 is linked statically all is ok, as it doesn't touch any of the scratch registers. But a call into libc.so __udivsi3 will clobber them on it's way through dynamic linker, I guess. To verify that theory I put udivsi3.o from libc.a into libgcc.a and relinked few failing binaries - and they worked ok. I wonder what is a proper solution for this? SY, Uwe -- [email protected] | Zu Grunde kommen http://www.ptc.spbu.ru/~uwe/ | Ist zu Grunde gehen