I think the subversion build failure with gcc4 is due to an optimiser bug. The code in question is subversion/tests/libsvn_wc/translate-test.c, around line 637: if (dst_eol) /* verify the promised consistent eol style */ { if (strncmp (contents->data + idx, dst_eol, strlen (dst_eol)) != 0) and it's segfaulting in the coredump on the strncmp line, with dst_eol == NULL which Just Isn't Cricket. jorton@jedi:libsvn_wc$ gdb ./translate-test GNU gdb Red Hat Linux (6.1post-1.20040607.61rh) Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-redhat-linux-gnu"...Using host libthread_db library "/lib/tls/libthread_db.so.1". (gdb) run Starting program: /local/dist/subversion/devel/subversion-1.1.3/subversion/tests/libsvn_wc/translate-test [Thread debugging using libthread_db enabled] [New Thread -1208121664 (LWP 3139)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread -1208121664 (LWP 3139)] 0x0804956d in substitute_and_verify (test_name=Variable "test_name" is not available. ) at subversion/tests/libsvn_wc/translate-test.c:637 637 if (strncmp (contents->data + idx, dst_eol, strlen (dst_eol)) != 0) (gdb) print dst_eol $1 = 0x0 (gdb) l 632 633 idx += strlen (expect[i]); 634 635 if (dst_eol != NULL) /* verify the promised consistent eol style */ 636 { 637 if (strncmp (contents->data + idx, dst_eol, strlen (dst_eol)) != 0) 638 639 return svn_error_createf 640 (SVN_ERR_IO_CORRUPT_EOL, NULL, 641 "'%s' has wrong eol style at line %" APR_SIZE_T_FMT, dst_fname, (gdb) Changing the code to be: if (dst_eol) { printf("%s\n", dst_eol); if (strncmp (contents->data + idx, dst_eol, strlen (dst_eol)) != 0) and it works fine. Likewise building translate-test.c at -O0 and it works fine.
(that was with gcc4-4.0.0-0.24.i386 and whatever you did your test mass rebuild with)
Sounds like this is already a known bug.
Should be fixed in gcc4-4.0.0-0.27 already.
Confirmed, thanks Jakub.