The patches are unexpectedly causing gcc to fail while
building ports/graphics/ImageMagick even when the cpu
flags are not used.
Reported by: Andreas Tobler
Initial support for the AMD barcelona chipsets has been available in the
gcc43 branch under GPLv2 but was not included when the Core 2 support
was brought to the system gcc.
AMD and some linux distributions (OpenSUSE) did a backport of the amdfam10
support and made them available. Unfortunately this is still experimental
and while it can improve performance, enabling the CPUTYPE may break some
C++ ports (like clang).
Special care was taken to make sure that the patches predate the GPLv3
switch upstream.
Tested by: Vladimir Kushnir
Reviewed by: mm
Approved by: jhb (mentor)
MFC after: 2 weeks
The fix is similar to the one applied in GCC-4.3 in
GCCSVN-r117929 under the GPLv2.
Submitted by: Andrey Simonenko
Reviewed by: mm
Approved by: jhb (mentor)
MFC after: 3 days
Backported from the gcc-4_3-branch, revision 118001,
under the GPLv2.
This issue was also fixed in Apple's gcc.
PR: 157025
Reviewed by: mm
Approved by: jhb (mentor)
MFC: 2 weeks
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