From current testsuite results, the optimizer bugs don't appear to exist
anymore. RTH@cygnus.com did a lot of work on the Alpha ELF code generator
for GCC 3.2[.0]. A recent FreeBSD/AXP GCC bootstrap is at
http://gcc.gnu.org/ml/gcc-testresults/2002-09/msg00604.html
In this bootstraps, all gcc libraries are built with -O2 and c-torture
gives -O2 a real workout. None of the remaining failures have anything
to do with -O2 optimizer bugs.
Submitted by: Loren James Rittle <rittle@latour.rsch.comm.mot.com>
code will know not to try to use `long long'.
Unfortunately the GCC spec parser will not allow us to properly detect the
"iso9899:1990" and "iso9899:199409" forms of the acceptable -std= arguments,
because of the ':' in the -std argument. :-( I have left them in the spec
as a place holder in hopes someone knows a way to make the detection of
them work.
Desired by: wollman
1.\{2,15\} FREEBSD_NATIVE
1.\{5,13\} ELF, and objformat support
1.\{16,23,25\} Better cross building control
1.21 'GCC_OPTIONS'
1.27 cross-arch MD_EXEC_PREFIX fixes
cc -print-search-dir fixes
1.28 Read specs from /usr/libdata/gcc/specs,
if available
Approved by: obrien
(put the function stabs in traditional order on a.out, or gdb doesn't see
function local variables), I failed to remove the related knobs here.
Effectively were overrode the ELF-wide definition in elfos.h w/o providing
new infrastructure. This is what caused GDB to fail to debug applications
compiled and linked with -stabs. This is because GCC was unconditionally
inserts .stabs instruction for functions after the function body. GDB was
getting confused because what it thinks is function beginning address is
actually function ending address.
Submitted by: Alexander Kabaev <ak03@gte.com>
for space. -Os could do this, but it was easy to hack an MD version.
This saves a whole 32 bytes in boot2, so I think it is worth using it.
(keep how much worse gcc 3.2 will compile boot2...)
Submitted by: bde (minus gcc 3.2 commentary)
This broke newfs (newfs left some garbage in a bitmap).
The ASM for:
#include <string.h>
int x, foo[100];
main()
{
memset(&foo[0], 0, x);
}
is (at least if you have fixed function alignment):
.file "z.c"
.text
.p2align 2,,3
.globl main
.type main,@function
main:
pushl %ebp
movl %esp, %ebp
pushl %edi
pushl %eax
movl x, %ecx
xorl %eax, %eax
shrl $2, %ecx
movl $foo, %edi
cld
rep
stosl
andl $-16, %esp
<-- the lower bits of `len' should be loaded
near here
testl $2, %edi <-- this seems to be meant to test the 2^1
bit in `len' (not alignment of the pointer
like it actually does). %edi is the wrong
register for holding the bits, since it is
still needed for the pointer.
je .L2
stosw
.L2:
testl $1, %edi <-- similarly for the 2^0 bit.
je .L3
stosb
.L3:
movl -4(%ebp), %edi
leave
ret
.Lfe1:
.size main,.Lfe1-main
.comm foo,400,32
.comm x,4,4
.ident "GCC: (GNU) 3.1 [FreeBSD] 20020509 (prerelease)"
This seems to only result in (len % 3) bytes not being cleared, since gcc
doesn't seem to use the builtin memset unless it knows that the pointer is
aligned. If %edi could be misaligned, then too many bytes would be set.
Submitted by: BDE
