Gosh, GCC 3.4.6 does so exist...
Dear List, do you all remember this? Look back to http://gcc.gnu.org/ml/gcc/2006-03/msg00759.html if your memory needs to be jogged. two months and a few hours on... has anything changed? Is Gabriel Dos Reis still looking into this, or has he been hit by a bus? Bernard Leak -- Thinking of making this message a monthly cron job
[wwwdocs] RE: Gosh, GCC 3.4.6 does so exist...
On 26 May 2006 11:10, Bernard Leak wrote: > Dear List, > do you all remember this? > > Look back to http://gcc.gnu.org/ml/gcc/2006-03/msg00759.html > if your memory needs to be jogged. > > two months and a few hours on... has anything changed? Is > Gabriel Dos Reis still looking into this, or has he been hit > by a bus? Guess he must have been[*], it really only needed a few minutes to fix. Suppose we could all demand Gaby be removed from RMship of the closed extinct and dead as a dodo 3.4 series but what would be the point? Anyway, how does this look to everyone? 2006-05-26 Dave Korn <[EMAIL PROTECTED]> * htdocs/index.html: Updated for 3.4.6 release and series closure. * htdocs/gcc-3.4/changes.html: Likewise. * htdocs/gcc-3.4/index.html: Likewise. cheers, DaveK [*] - Or just possibly a hippo fell out of the sky and landed on him. Unlikely, but it could happen. -- Can't think of a witty .sigline today release-346-web.diff Description: Binary data
Re: [wwwdocs] RE: Gosh, GCC 3.4.6 does so exist...
Dave, don't forget to send a mail to gcc-announce. No announce has been sent yet: http://gcc.gnu.org/ml/gcc-announce/2006/ http://gcc.gnu.org/ml/gcc-announce/2005/ Cheers, Manuel. On 26/05/06, Dave Korn <[EMAIL PROTECTED]> wrote: On 26 May 2006 11:10, Bernard Leak wrote: > Dear List, > do you all remember this? > > Look back to http://gcc.gnu.org/ml/gcc/2006-03/msg00759.html > if your memory needs to be jogged. > > two months and a few hours on... has anything changed? Is > Gabriel Dos Reis still looking into this, or has he been hit > by a bus? Guess he must have been[*], it really only needed a few minutes to fix. Suppose we could all demand Gaby be removed from RMship of the closed extinct and dead as a dodo 3.4 series but what would be the point? Anyway, how does this look to everyone? 2006-05-26 Dave Korn <[EMAIL PROTECTED]> * htdocs/index.html: Updated for 3.4.6 release and series closure. * htdocs/gcc-3.4/changes.html: Likewise. * htdocs/gcc-3.4/index.html: Likewise. cheers, DaveK [*] - Or just possibly a hippo fell out of the sky and landed on him. Unlikely, but it could happen. -- Can't think of a witty .sigline today
RE: [wwwdocs] RE: Gosh, GCC 3.4.6 does so exist...
On 26 May 2006 12:16, Manuel López-Ibáñez wrote: > Dave, > > don't forget to send a mail to gcc-announce. No announce has been sent yet: > > http://gcc.gnu.org/ml/gcc-announce/2006/ > http://gcc.gnu.org/ml/gcc-announce/2005/ > > Cheers, > Manuel. Don't know if I have the authority to do that. Anyone can offer up a patch, but I am not the RM and don't suppose it would accept mails from me. cheers, DaveK -- Can't think of a witty .sigline today
Re: GCC 4.1.1 Released
Roberto Bagnara wrote: > Mark Mitchell wrote: >> GCC 4.1.1 has been released. >> >> This release is a bug-fix release for problems in GCC 4.0.2. GCC >> [...] > > Do you mean "a bug-fix release for problems in GCC 4.1.0"? Yup. -- Mark Mitchell CodeSourcery [EMAIL PROTECTED] (650) 331-3385 x713
reload bug in 3.4.6
I've got a bug with gcc-3.4.6 (also with 3.3.2, 3.3.6, probably
anything inbetween), target sh-elf. Unfortunately, the test case is
huge, convoluted and proprietary, so I can't send it for now.
When reloading insn 2780:
Breakpoint 3, reload_as_needed (live_known=1)
at ../../gcc-3.4.6/gcc/reload1.c:3802
(gdb) p insn
$3 = (rtx) 0x2b202910
(gdb) call debug_rtx (insn)
(insn:HI 2780 2777 2782 1 (set (reg/f:SI 1726)
(plus:SI (reg/f:SI 1706)
(const_int 4 [0x4]))) 23 {*addsi3_compact} (nil)
(nil))
(gdb) call debug_rtx (reg_equiv_memory_loc [1726])
(mem:SI (plus:SI (reg/f:SI 14 r14)
(const_int 156 [0x9c])) [16 S4 A32])
After calling ``eliminate_regs_in_insn()'':
(gdb) call debug_rtx (insn)
(insn:HI 2780 2777 2782 1 (set (reg/f:SI 1726)
(plus:SI (plus:SI (reg/f:SI 14 r14)
(const_int 124 [0x7c]))
(const_int 4 [0x4]))) 23 {*addsi3_compact} (nil)
(nil))
After calling ``find_reloads()'' and ``choose_reload_regs()'':
(gdb) call debug_reload ()
Reload 0: reload_in (SI) = (plus:SI (reg/f:SI 14 r14)
(const_int 124 [0x7c]))
reload_out (SI) = (mem:SI (plus:SI (plus:SI (reg/f:SI 14 r14)
(const_int 124 [0x7c]))
(const_int 32 [0x20])) [16 S4 A32])
GENERAL_REGS, RELOAD_OTHER (opnum = 0)
reload_in_reg: (plus:SI (reg/f:SI 14 r14)
(const_int 124 [0x7c]))
reload_out_reg: (reg/f:SI 1726)
reload_reg_rtx: (reg:SI 3 r3)
(gdb) call debug_rtx (insn)
(insn:HI 2780 2777 2782 1 (set (mem:SI (plus:SI (plus:SI (reg/f:SI 14 r14)
(const_int 124 [0x7c]))
(const_int 32 [0x20])) [16 S4 A32])
(plus:SI (plus:SI (reg/f:SI 14 r14)
(const_int 124 [0x7c]))
(const_int 4 [0x4]))) 23 {*addsi3_compact} (nil)
(nil))
After calling ``emit_reload_insns()'' the relevant insns are:
(insn 22940 2777 22941 1 (set (reg:SI 3 r3)
(const_int 124 [0x7c])) -1 (nil)
(nil))
(insn 22941 22940 2780 1 (set (reg:SI 3 r3)
(plus:SI (reg:SI 3 r3)
(reg/f:SI 14 r14))) 23 {*addsi3_compact} (nil)
(expr_list:REG_EQUIV (plus:SI (reg/f:SI 14 r14)
(const_int 124 [0x7c]))
(nil)))
(insn:HI 2780 22941 22942 1 (set (mem:SI (plus:SI (plus:SI (reg/f:SI 14 r14)
(const_int 124 [0x7c]))
(const_int 32 [0x20])) [16 S4 A32])
(plus:SI (plus:SI (reg/f:SI 14 r14)
(const_int 124 [0x7c]))
(const_int 4 [0x4]))) 23 {*addsi3_compact} (nil)
(nil))
(insn 22942 2780 2782 1 (set (mem:SI (plus:SI (plus:SI (reg/f:SI 14 r14)
(const_int 124 [0x7c]))
(const_int 32 [0x20])) [16 S4 A32])
(reg:SI 3 r3)) -1 (nil)
(nil))
So far so good. Note that in insn 22942, r3 is saved in [r14 + 156].
However, after calling ``subst_reloads()'', the insns become:
(insn 22940 2777 22941 1 (set (reg:SI 3 r3)
(const_int 124 [0x7c])) -1 (nil)
(nil))
(insn 22941 22940 2780 1 (set (reg:SI 3 r3)
(plus:SI (reg:SI 3 r3)
(reg/f:SI 14 r14))) 23 {*addsi3_compact} (nil)
(expr_list:REG_EQUIV (plus:SI (reg/f:SI 14 r14)
(const_int 124 [0x7c]))
(nil)))
(insn:HI 2780 22941 22942 1 (set (reg:SI 3 r3)
(plus:SI (reg:SI 3 r3)
(const_int 4 [0x4]))) 23 {*addsi3_compact} (nil)
(nil))
(insn 22942 2780 2782 1 (set (mem:SI (plus:SI (reg:SI 3 r3)
(const_int 32 [0x20])) [16 S4 A32])
(reg:SI 3 r3)) -1 (nil)
(nil))
Now r3 is stored at [r14 + 160], which is incorrect. The reason is
that when substituting the reload register into insn 2780, the insn
22942 is modified also, because they share the following rtx: (plus:SI
(reg/f:SI 14 r14) (const_int 124 [0x7c])). Since insn 2780 modifies
r3, r3 is no longer equal to ``r14 + 124'' at insn 22942, which
results in incorrect store.
I'd appreciate any suggestions for fixing this.
~velco
IA-64 speculation patches have bad impact on ARM
Hi Maxim and Vlad,
I just tracked an ICE while building glibc for ARM to this patch,
which introduced --param max-sched-extend-regions-iters with a default
of two:
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg00998.html
The testcase is attached; an arm-linux-gnueabi compiler should be able to
reproduce it with -p -O2. The failure is inability to find two consecutive
registers to hold a DImode value. The cause is roughly like this:
DImode add;
if (({complicated asm with many local register variables}))
return 0;
The register variables get lifted out of the if statement and moved before
the add, thus occupying basically all available hard registers.
If it were just that, I might try to cobble around it in glibc. But there's
actually another layer:
if (DImode compare)
{
DImode add;
if (({complicated asm with many local register variables}))
return 0;
...
}
The register variables and their initializations get hoisted all the way out
of the first if. On ia64, with a million execution units to spare and a
fat pipeline, this may make sense. On targets with a simpler execution
model, though, it's pretty awful. If the condition (which we have no
information on the likelihood of) is false, we've added lots of cycles for
no gain. It's not like the scheduler was filling holes; the initializations
were scheduled as early as possible because they had no dependencies.
With the parameter turned back down to one, the testcase compiles, and the
code looks sensible again. No, I wasn't able to work out why profiling was
necessary to trigger this problem; I suspect it makes some register
unavailable, but I'm not sure which. I didn't look into that further.
What's your opinion? We could easily change the default of the parameter
for ARM, but I assume there are other affected targets. I don't know if we
need the extended region scheduling to be smarter, or if it should simply be
turned off for some targets.
--
Daniel Jacobowitz
CodeSourcery
typedef union
{
struct
{
int __lock;
unsigned int __futex;
__extension__ unsigned long long int __total_seq;
__extension__ unsigned long long int __wakeup_seq;
} __data;
}
pthread_cond_t;
__pthread_cond_signal (cond)
pthread_cond_t *cond;
{
if (cond->__data.__total_seq > cond->__data.__wakeup_seq)
{
++cond->__data.__wakeup_seq;
if (!__builtin_expect (({
do { } while (0);
long int __ret;
__ret = ({
register int _a1 asm ("r0"), _nr asm ("r7");
register int _v2 asm ("v2") = (int)(((4 << 24) | 1));
register int _v1 asm ("v1") = (int)((&cond->__data.__lock));
register int _a4 asm ("a4") = (int)((1));
register int _a3 asm ("a3") = (int)((1));
register int _a2 asm ("a2") = (int)(5);
_a1 = (int) ((&cond->__data.__futex));
_nr = ((0 + 240));
asm volatile ("swi 0x0 @ syscall " "SYS_ify(futex)"
: "=r" (_a1)
: "r" (_nr), "r" (_a1), "r" (_a2),
"r" (_a3), "r" (_a4), "r" (_v1), "r" (_v2)
: "memory");
_a1;});
__ret;}), 0))
return 0;
}
}
RE: reload bug in 3.4.6
On 26 May 2006 16:23, Momchil Velikov wrote: > Now r3 is stored at [r14 + 160], which is incorrect. The reason is > that when substituting the reload register into insn 2780, the insn > 22942 is modified also, because they share the following rtx: (plus:SI > (reg/f:SI 14 r14) (const_int 124 [0x7c])). Since insn 2780 modifies > r3, r3 is no longer equal to ``r14 + 124'' at insn 22942, which > results in incorrect store. > > I'd appreciate any suggestions for fixing this. Unsharing the rtx sounds like the right thing to do to me; the internals docs "Structure sharing assumptions" says things like "* No RTL object appears in more than one place in the RTL structure except as described above. Many passes of the compiler rely on this by assuming that they can modify RTL objects in place without unwanted side-effects on other insns." and by the time we're in reload that should definitely be the case for a complex binary operator. How did they get to be shared in the first place? That's probably the underlying cause of the bug. cheers, DaveK -- Can't think of a witty .sigline today
gcc binary for fc1
I am trying to compile the source for gcc, but do not yet have gcc. I am on a fc1 machine and have been googling for hours at the clients site, trying to find out what I need and where to get it. can anyone help me in figuring out how to get a compiler onto a fc1 machine with _no_compiler? thanks in advance, -JP
RE: gcc binary for fc1
On 26 May 2006 15:48, Dude VanWinkle wrote: > I am trying to compile the source for gcc, but do not yet have gcc. > > I am on a fc1 machine and have been googling for hours at the clients > site, trying to find out what I need and where to get it. > > can anyone help me in figuring out how to get a compiler onto a fc1 > machine with _no_compiler? Well, yes, that's easy; first you need to get a compiler onto it, and then you can build a compiler with it :) So, given that FC1 is a linux distribution, perhaps you can download a binary rpm for it, and then build your own version of the compiler with that? Or, just for kicks, you could take a different machine that already has a compiler, and build a cross-compiled gcc for the fc1 box. cheers, DaveK -- Can't think of a witty .sigline today
Cygwin c++ vs windows or unix socket layer
Hi all, I've stumbled across a small problem. As you may know, cygwin attempts to give the user a free choice of using the winsock API, with SOCKETs being handles not fds, and ioctlsocket and closesocket and so on, or using the posix sockets API, and having sockets being fds just like any other file, using the same ioctl and close functions, etc. etc. This doesn't work well in C++ at the moment, because of a clash between headers; winsock defines gethostname to take an int as the second argument, while cygwin's unistd.h defines it as taking an unsigned int. Normally the solution to this would be to only use one or the other kind of socket library and not attempt to mix the two in one program. Unfortunately, if you include any of the C++ i/o stream related headers, that includes c++io.h, which includes gthr.h and hence gthr-default.h; and gthr-default.h unconditionally #includes . (Note that gthr-posix.h could cause the same problem, if you've explicitly requested posix threads by defining _GLIBCXX__PTHREADS). So the upshot is that if you use C++ i/o streams you get unistd.h included and that defines the posix version of gethostname and then you can't include (or use) the winsock stuff instead; i.e. cygwin's c++ compiler does not currently support allowing the choice of socket library. There's no problem in C, because you're not forced to include the gthreads headers to support standard library functions; it's just that the C++ i/o classes need to know about mutex functionality in order to be threadsafe. A patch like this makes it work for me, and I was wondering if anyone else has had this problem and if I should include it in the next release of cygwin gcc when it comes out. According to the svn logs, the reason gthr-default/posix.h needs to include unistd is solely to get the feature test macros; although posix expects them to be available /through/ unistd.h I think we're still ok by having it as a separate subinclude file and that does give us the advantage of being able to pull them in without all the hundreds and thousands of random unrelated stuff that the full unistd.h has. I've Cc'd the gcc list because, although this is primarily a cygwin issue, and an artifact of the way we try to support two clashing environments, a) someone might know some more important reason why gthr-default really does need the unistd function prototypes, or b) others might also feel that implicitly including unistd.h and thus pulling in a bunch of network/socket related symbols into every C++ io stream-related header file is a bit overly namespace-polluting. c) something else, that I haven't thought of :) --- gthr-default.h 2006-05-26 16:59:57.917146100 +0100 +++ gthr-default.h.new 2006-05-26 17:00:26.307771100 +0100 @@ -41,7 +41,11 @@ Software Foundation, 59 Temple Place - S #endif #include +#ifdef __CYGWIN__ +#include +#else #include +#endif typedef pthread_key_t __gthread_key_t; typedef pthread_once_t __gthread_once_t; [EMAIL PROTECTED] /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/i686-pc-cygwin/bits> cheers, DaveK -- Can't think of a witty .sigline today
"make install-info" no longer works
Has anyone seen http://sources.redhat.com/bugzilla/show_bug.cgi?id=2701 It looks like the result of merging of intl from gcc. It doesn't work for me in gcc either: make[2]: Leaving directory `/export/build/gnu/gcc/build-i686-linux/intl' Doing install-info in intl make[2]: Entering directory `/export/build/gnu/gcc/build-i686-linux/intl' make[2]: *** No rule to make target `install-info'. Stop. make[2]: Leaving directory `/export/build/gnu/gcc/build-i686-linux/intl' make[1]: *** [install-info-intl] Error 1 make[1]: Leaving directory `/export/build/gnu/gcc/build-i686-linux' make: *** [do-install-info] Error 2 [EMAIL PROTECTED] build-i686-linux]$ H.J.
Re: [wwwdocs] RE: Gosh, GCC 3.4.6 does so exist...
> Anyway, how does this look to everyone? FWIW fine with me. Thanks for taking care of this! -- Eric Botcazou
The Linux binutils 2.17.50.0.2 is released
This is the beta release of binutils 2.17.50.0.2 for Linux, which is based on binutils 2006 0526 in CVS on sources.redhat.com plus various changes. It is purely for Linux. The new x86_64 assembler no longer accepts monitor %eax,%ecx,%edx You should use monitor %rax,%ecx,%edx or monitor which works with both old and new x86_64 assemblers. They should generate the same opcode. The new i386/x86_64 assemblers no longer accept instructions for moving between a segment register and a 32bit memory location, i.e., movl (%eax),%ds movl %ds,(%eax) To generate instructions for moving between a segment register and a 16bit memory location without the 16bit operand size prefix, 0x66, mov (%eax),%ds mov %ds,(%eax) should be used. It will work with both new and old assemblers. The assembler starting from 2.16.90.0.1 will also support movw (%eax),%ds movw %ds,(%eax) without the 0x66 prefix. Patches for 2.4 and 2.6 Linux kernels are available at http://www.kernel.org/pub/linux/devel/binutils/linux-2.4-seg-4.patch http://www.kernel.org/pub/linux/devel/binutils/linux-2.6-seg-5.patch The ia64 assembler is now defaulted to tune for Itanium 2 processors. To build a kernel for Itanium 1 processors, you will need to add ifeq ($(CONFIG_ITANIUM),y) CFLAGS += -Wa,-mtune=itanium1 AFLAGS += -Wa,-mtune=itanium1 endif to arch/ia64/Makefile in your kernel source tree. Please report any bugs related to binutils 2.17.50.0.2 to [EMAIL PROTECTED] and http://www.sourceware.org/bugzilla/ If you don't use # rpmbuild -ta binutils-xx.xx.xx.xx.xx.tar.bz2 to compile the Linux binutils, please read patches/README in source tree to apply Linux patches if there are any. Changes from binutils 2.17.50.0.1: 1. Update from binutils 2006 0526. 2. Change the x86-64 maximum page size to 2MB. 3. Support --enable-targets=all for 64bit target and host (PR 1485). 4. Properly update CIE/FDE length and align section for .eh_frame section (PR 2655/2657). 5. Properly handle removed ELF section symbols. 6. Fix an ELF linker regression introduced on 2006-04-21. 7. Fix an segfault in PPC ELF linker (PR 2658). 8. Speed up the ELF linker by caching the result of kept section check. 9. Properly create stabs section for ELF. 10. Preserve ELF program header when copying ELF files. 11. Properly handle ELF SHN_LOPROC/SHN_HIOS when checking section index (PR 2607). 12. Misc mips updates. 13. Misc arm updates. 14. Misc xtensa updates. 15. Fix an alpha assembler warning (PR 2598). 16. Fix assembler buffer overflow. 17. Properly disassemble sgdt/sidt for x86-64. Changes from binutils 2.16.91.0.7: 1. Update from binutils 2006 0427. 2. Fix an objcopy regression (PR 2593). 3. Reduce ar memory usage (PR 2467). 4. Allow application specific ELF sections (PR 2537). 5. Fix an i386 TLS linker bug (PR 2513). 6. Speed up ia64 linker by 1300X in some cases (PR 2442). 7. Check illegal immediate register operand in i386 assembler (PR 2533). 8. Fix a strings bug (PR 2584). 9. Better handle corrupted ELF files (PR 2257). 10. Fix a MIPS linker bug (PR 2267). Changes from binutils 2.16.91.0.6: 1. Update from binutils 2006 0317. 2. Support Intel Merom New Instructions in assembler/disassembler. 3. Support Intel new instructions in Montecito. 4. Fix linker "--as-needed" (PR 2434). 5. Fix linker "-s" regression (PR 2462). 6. Fix REP prefix for string instructions in x86 disassembler (PR 2428). 7. Fix the weak undefined symbols in PIE (PR 2218). 8. Fix 2 DWARF reader bugs (PRs 2443, 2338). 9. Improve ELF linker error message (PR 2322). 10. Avoid abort with dynamic symbols in >64K sections (PR 2411). 11. Handle mismatched symbol types for executables (PR 2404). 12. Avoid a linker linkonce regression (PR 2342). Changes from binutils 2.16.91.0.5: 1. Update from binutils 2006 0212. 2. Correct Linux linker search order for DT_NEEDED entries (PR 2290). 3. Fix the x86-64 disassembler for control/debug register moves. 4. Properly handle ELF strip/objcopy with unmodified program header (PR 2258). 5. Improve ELF linker error handling when there are not enough room for program headers (PR 2322). 6. Properly handle weak undefined symbols in PIE (PR 2218). 7. Support new i386/x86-64 TLS relocations. 8. Fix addr2line for linux kernel (PR 2096). 9. Fix an assembler memory leak with --statistics. 10. Avoid an ia64 assembler regression (PR 2117). Changes from binutils 2.16.91.0.4: 1. Update from binutils 2005 1219. 2. Fix a MIPS linker regression (PR 1932). 3. Fix an objcopy bug for ia64 (PR 1991). 4. Fix a linker crash on bad input (PR 2008). 5. Fix 64bit monitor and mwait (PR 1874). Changes from binutils 2.16.91.0.3: 1. Update from binutils 2005 . 2. Fix ELF orphan section handling (PR 1467) 3. Fix ELF section attribute handleing (PR 1487). 4. Fix IA64 unwind info dump for relocatable files. (PR 1436). 5. Add DWARF info dump to objdump. 6. Fix SHF_LINK_ORDER handling (PR 1321). 7. Don't all
gcc-4.1-20060526 is now available
Snapshot gcc-4.1-20060526 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.1-20060526/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.1 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_1-branch revision 114142 You'll find: gcc-4.1-20060526.tar.bz2 Complete GCC (includes all of below) gcc-core-4.1-20060526.tar.bz2 C front end and core compiler gcc-ada-4.1-20060526.tar.bz2 Ada front end and runtime gcc-fortran-4.1-20060526.tar.bz2 Fortran front end and runtime gcc-g++-4.1-20060526.tar.bz2 C++ front end and runtime gcc-java-4.1-20060526.tar.bz2 Java front end and runtime gcc-objc-4.1-20060526.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.1-20060526.tar.bz2The GCC testsuite Diffs from 4.1-20060519 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.1 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
