Bug#164554: gcc-3.2: volatile not respected on alpha
Package: gcc-3.2
Version: 1:3.2.1-0pre2
Severity: normal
The following program produces output where the assignment to j occurs
before the i has been incremented. This breaks any program using such
constructs to ensure consistency:
volatile int i;
int j;
void a() {
i++;
j = 6;
i--;
}
.prologue 1
ldq $3,i($29) !literal
lda $4,6($31)
ldq $1,j($29) !literal
ldl $2,0($3)
stl $4,0($1)
lda $2,1($2)
stl $2,0($3)
-- System Information
Debian Release: testing/unstable
Kernel Version: Linux gondolin 2.4.18-686-smp #1 SMP Sun Apr 14 12:07:19 EST
2002 i686 unknown unknown GNU/Linux
Versions of the packages gcc-3.2 depends on:
ii binutils 2.13.90.0.4-1 The GNU assembler, linker and binary utiliti
ii cpp-3.23.2.1-0pre2The GNU C preprocessor.
ii gcc-3.2-base 3.2.1-0pre2The GNU Compiler Collection (base package).
ii libc6 2.2.5-14.3 GNU C Library: Shared libraries and Timezone
ii libgcc13.2.1-0pre2GCC support library.
Bug#172090: gcc-3.2: [alpha] gcc fails to compile kernel on wildfire
Package: gcc-3.2
Version: 1:3.2.2-0pre0
Severity: normal
Compiling the kernel for the Wildfire fails with:
[EMAIL
PROTECTED]:/mnt/home/herbert/src/debian/work/kernel/build/2.4/kernel-image-alpha-2.4/build-wildfire/drivers/char$
/usr/lib/gcc-lib/alpha-linux/3.2.2/cc1 -lang-c -nostdinc -v
-I/mnt/big/herbert/build/kernel/2.4/kernel-image-alpha-2.4/build-wildfire/include
-D__GNUC__=3 -D__GNUC_MINOR__=2 -D__GNUC_PATCHLEVEL__=0
-D__GXX_ABI_VERSION=102 -D__gnu_linux__ -Dlinux -Dunix -D_LONGLONG -D__alpha__
-D__ELF__ -D__gnu_linux__ -D__linux__ -D__unix__ -D_LONGLONG -D__alpha__
-D__ELF__ -D__linux -D__unix -Asystem=linux -D__OPTIMIZE__ -D__STDC_HOSTED__=1
-D__LANGUAGE_C__ -D__LANGUAGE_C -DLANGUAGE_C -Acpu=alpha -Amachine=alpha
-D__alpha -D__alpha__ -D__alpha_ev6__ -Acpu=ev6 -D__alpha_bwx__ -Acpu=bwx
-D__alpha_max__ -Acpu=max -D__alpha_fix__ -Acpu=fix -D__alpha_cix__ -Acpu=cix
-D__KERNEL__ -DMODULE -DMODVERSIONS -DKBUILD_BASENAME=istallion -include
/mnt/big/herbert/build/kernel/2.4/kernel-image-alpha-2.4/build-wildfire/include/linux/modversions.h
-iwithprefix include istallion.c -quiet -du
mpbase istallion.c -mno-fp-regs -mcpu=ev67 -O2 -Wall -Wstrict-prototypes
-Wno-trigraphs -version -fno-strict-aliasing -fno-common -fomit-frame-pointer
-ffixed-8
GNU CPP version 3.2.2 20021202 (Debian prerelease) (cpplib) (Alpha GNU/Linux
for ELF)
GNU C version 3.2.2 20021202 (Debian prerelease) (alpha-linux)
compiled by GNU C version 3.2.2 20021202 (Debian prerelease).
#include "..." search starts here:
#include <...> search starts here:
/mnt/big/herbert/build/kernel/2.4/kernel-image-alpha-2.4/build-wildfire/include
/usr/lib/gcc-lib/alpha-linux/3.2.2/include
End of search list.
istallion.c: In function `stli_allocbrd':
istallion.c:4738: warning: int format, different type arg (arg 2)
istallion.c: In function `stli_memread':
istallion.c:4895: unable to find a register to spill in class `R27_REG'
istallion.c:4895: this is the insn:
(insn 191 423 192 (parallel[
(set (reg:DI 2 $2 [123])
(umod:DI (reg:DI 24 $24 [122])
(reg:DI 25 $25 [117])))
(clobber (reg:DI 23 $23))
(clobber (reg:DI 28 $28))
] ) 37 {*divmoddi_internal_er} (insn_list 189 (insn_list 184
(insn_list:REG_DEP_ANTI 180 (nil
(expr_list:REG_DEAD (reg:DI 24 $24 [122])
(expr_list:REG_UNUSED (reg:DI 23 $23)
(expr_list:REG_UNUSED (reg:DI 28 $28)
(nil)
istallion.c:4895: confused by earlier errors, bailing out
The compile works if the kernel is configured as generic as opposed to Wildfire.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#178561: gcc-3.2-doc: stream::attach(int fd) porting entry out-of-date
Package: gcc-3.2-doc Version: 1:3.2.2ds5-0pre6 Severity: normal The stream::attach entry in porting-howto.html does not mention the stdio_filebuf as an alternative. -- System Information Debian Release: testing/unstable Kernel Version: Linux gondolin 2.4.20-686-smp #1 SMP Mon Jan 13 23:06:41 EST 2003 i686 Pentium III (Coppermine) GenuineIntel GNU/Linux Versions of the packages gcc-3.2-doc depends on: ii gcc-3.2-base 3.2.1-0pre3The GNU Compiler Collection (base package).
Bug#181096: gcc-3.2: gcc fails to optimise if (l&2) l|=2 away
Package: gcc-3.2
Version: 1:3.2.3-0pre1
Severity: wishlist
The following function doesn't get optimised away as a noop:
int k(int l)
{
if (l & 2)
l |= 2;
return l;
}
$ gcc-3.2 -O2 -S b.c
$ cat b.s
.file "b.c"
.text
.p2align 2,,3
.globl k
.type k,@function
k:
pushl %ebp
movl%esp, %ebp
movl8(%ebp), %eax
testl $2, %eax
je .L2
orl $2, %eax
.L2:
leave
ret
.Lfe1:
.size k,.Lfe1-k
.ident "GCC: (GNU) 3.2.3 20030210 (Debian prerelease)"
-- System Information
Debian Release: testing/unstable
Kernel Version: Linux gondolin 2.4.20-686-smp #1 SMP Mon Jan 13 23:06:41 EST
2003 i686 Pentium III (Coppermine) GenuineIntel GNU/Linux
Versions of the packages gcc-3.2 depends on:
ii binutils 2.13.90.0.10-1 The GNU assembler, linker and binary utiliti
ii cpp-3.23.2.1-0pre3The GNU C preprocessor.
ii gcc-3.2-base 3.2.1-0pre3The GNU Compiler Collection (base package).
ii libc6 2.2.5-14.3 GNU C Library: Shared libraries and Timezone
ii libgcc13.2.1-0pre3GCC support library.
Bug#490644: gcc: -finline-small-functions is overzealous
Package: gcc Version: 4:4.3.1-2 Severity: normal According to info gcc -finline-small-functions should not increase the generated code size: `-finline-small-functions' Integrate functions into their callers when their body is smaller than expected function call code (so overall size of program gets smaller). The compiler heuristically decides which functions are simple enough to be worth integrating in this way. Enabled at level `-O2'. However, it seems that this option increases the code size more often than not. For example, compiling dash with this option increases its size by nearly 10%. Here is a case in point: $ gcc -c -O2 a.c $ size a.o textdata bss dec hex filename 1090 0 81098 44a a.o $ gcc -fno-inline-small-functions -c -O2 a.c $ size a.o textdata bss dec hex filename 1067 0 81075 433 a.o $ I would like to see this option disabled by default so that we don't all end up with an inflated system that doesn't run any faster. -- System Information Debian Release: lenny/sid Kernel Version: Linux gorgoroth 2.6.26-rc8 #2 SMP PREEMPT Wed Jun 25 21:45:17 CST 2008 i686 GNU/Linux Versions of the packages gcc depends on: ii cpp4.3.1-2The GNU C preprocessor (cpp) ii gcc-4.34.3.1-6The GNU C compiler -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#301746: gcc-3.4: Redundant reloading from stack frame
Package: gcc-3.4
Version: 3.4.3-6
Severity: wishlist
This is a regression from gcc-3.2 in that gcc-3.2 does not have this
problem bug gcc-3.3 does.
The attached program generates the following code on i386 with
gcc -S -O2:
...
.L2:
movl-16(%ebp), %eax
xorl%esi, %esi
testl %eax, %eax
je .L8
As you can see %eax now contains the value in -16(%ebp).
subl$12, %esp
movl-16(%ebp), %eax
gcc-3.4 decides to reload for no reason at all.
pushl %eax
callstrlen
movl%eax, %esi
addl$16, %esp
.L5:
pushl %eax
pushl %edi
pushl %ebx
leal2(%edi,%esi), %eax
pushl %eax
callmalloc
movl%eax, (%esp)
movl%eax, %ebx
callmempcpy
movl-16(%ebp), %edi
Again the value of -16(%ebp) is in %edi.
addl$16, %esp
testl %edi, %edi
je .L6
movb$61, (%eax)
pushl %ecx
pushl %esi
movl-16(%ebp), %edx
gcc-3.4 decides to reload it yet again.
pushl %edx
incl%eax
pushl %eax
callmempcpy
addl$16, %esp
...
Cheers,
-- System Information
Debian Release: 3.1
Kernel Version: Linux gondolin 2.4.27-hx-1-686-smp #3 SMP Tue Oct 5 20:01:26
EST 2004 i686 GNU/Linux
Versions of the packages gcc-3.4 depends on:
ii binutils 2.15-5 The GNU assembler, linker and binary utiliti
ii cpp-3.43.4.3-6The GNU C preprocessor
ii gcc-3.4-base 3.4.3-6The GNU Compiler Collection (base package)
ii libc6 2.3.2.ds1-20 GNU C Library: Shared libraries and Timezone
ii libgcc13.4.3-6GCC support library
--
typedef unsigned int size_t;
extern size_t strlen (__const char *__s) __attribute__ ((__pure__));
extern char *strchrnul (__const char *__s, int __c) __attribute__ ((__pure__));
extern void *mempcpy (void *__restrict __dest,
__const void *__restrict __src, size_t __n) ;
extern void *malloc(size_t);
extern void setvareq(char *s, int flags);
extern char *endofname(const char *);
extern void sh_error(const char *, ...) __attribute__ ((__noreturn__));
void
setvar(const char *name, const char *val, int flags)
{
char *p, *q;
size_t namelen;
char *nameeq;
size_t vallen;
q = endofname(name);
p = strchrnul(q, '=');
namelen = p - name;
if (!namelen || p != q)
sh_error("%.*s: bad variable name", namelen, name);
vallen = 0;
if (val == ((void *)0)) {
flags |= 2;
} else {
vallen = strlen(val);
}
p = mempcpy(nameeq = malloc(namelen + vallen + 2), name, namelen);
if (val) {
*p++ = '=';
p = mempcpy(p, val, vallen);
}
*p = '\0';
setvareq(nameeq, flags | 1);
}
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Lindsay Lohan prefers Rolex, Cartier and Breitling
Get the Finest Rolex Watch Replica ! We only sell premium watches. There's no battery in these replicas just like the real ones since they charge themselves as you move. The second hand moves JUST like the real ones, too. These original watches sell in stores for thousands of dollars. We sell them for much less. - Replicated to the Smallest Detail - 98% Perfectly Accurate Markings - Signature Green Sticker w/ Serial Number on Watch Back - Magnified Quickset Date - Includes all Proper Markings http://www.chooseyourwatch4u.net/ you courageous me barlow me [2 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#198269: gcc-3.3: -falign-* has no effect on i386
Package: gcc-3.3
Version: 1:3.3-2
Severity: normal
Compiling the following program (b.c) on i386
int f(int a) {
int i = 0;
if (a > 3)
goto end;
return 3;
end:
return g(0);
}
with "gcc -O2 -falign-jumps=0 -S" produces
.file "b.c"
.text
.p2align 2,,3
.globl f
.type f, @function
f:
pushl %ebp
movl%esp, %ebp
cmpl$3, 8(%ebp)
jle .L4
.L3:
movl$0, 8(%ebp)
leave
jmp g
.p2align 2,,3
.L4:
movl$3, %eax
leave
ret
.size f, .-f
.ident "GCC: (GNU) 3.3 (Debian)"
As you can see, -falign-jumps=0 was ignored. -malign-jumps=0 does
work on the other hand. This applies to all -falign-* options.
-- System Information
Debian Release: testing/unstable
Kernel Version: Linux gondolin 2.4.21-1-686-smp #3 SMP Mon Jun 16 22:16:22 EST
2003 i686 GNU/Linux
Versions of the packages gcc-3.3 depends on:
ii binutils 2.14.90.0.4-0. The GNU assembler, linker and binary utiliti
ii cpp-3.33.3-2 The GNU C preprocessor
ii gcc-3.3-base 3.3-2 The GNU Compiler Collection (base package)
ii libc6 2.3.1-16 GNU C Library: Shared libraries and Timezone
ii libgcc13.3-2 GCC support library
Bug#202016: gcc-3.3: Unnecessary store onto stack
Package: gcc-3.3
Version: 1:3.3.1-0pre0
Severity: minor
The following code induces an unnecessary store of fromp onto the stack.
It is never loaded again.
--
#include
int
main(void)
{
struct sockaddr_storage from;
struct sockaddr *const fromp = (void *)&from;
socklen_t fromlen;
fromlen = sizeof(from);
if (getpeername(0, fromp, &fromlen) < 0) {
return 1;
}
return 0;
}
--
If you compile it with
gcc-3.3 -D_GNU_SOURCE -S -O2
you will get
--
.file "b.c"
.text
.p2align 2,,3
.globl main
.type main,@function
main:
pushl %ebp
movl%esp, %ebp
subl$152, %esp
andl$-16, %esp
pushl %edx
leal-144(%ebp), %edx
leal-136(%ebp), %eax
pushl %edx
pushl %eax
pushl $0
movl$128, -144(%ebp)
movl%eax, -140(%ebp)
callgetpeername
shrl$31, %eax
addl$16, %esp
leave
ret
.Lfe1:
.size main,.Lfe1-main
.ident "GCC: (GNU) 3.2.3 20030415 (Debian prerelease)"
--
The store into -140(%ebp) is useless.
This does not occur if you remove the -D_GNU_SOURCE, so this is related
to the __SOCKADDR_ARG magic in sys/socket.h. I can reproduce this with
gcc 3.2. gcc 2.95 does not have this problem.
I've appended the preprocessed source.
-- System Information
Debian Release: testing/unstable
Kernel Version: Linux gondolin 2.4.21-2-686-smp #1 SMP Sat Jul 5 01:42:22 EST
2003 i686 GNU/Linux
Versions of the packages gcc-3.3 depends on:
ii binutils 2.14.90.0.4-0. The GNU assembler, linker and binary utiliti
ii cpp-3.33.3.1-0pre0The GNU C preprocessor
ii gcc-3.3-base 3.3.1-0pre0The GNU Compiler Collection (base package)
ii libc6 2.3.1-16 GNU C Library: Shared libraries and Timezone
ii libgcc13.3.1-0pre0GCC support library
--
# 1 "b.c"
# 1 ""
# 1 ""
# 1 "b.c"
# 1 "/usr/include/sys/socket.h" 1 3 4
# 23 "/usr/include/sys/socket.h" 3 4
# 1 "/usr/include/features.h" 1 3 4
# 291 "/usr/include/features.h" 3 4
# 1 "/usr/include/sys/cdefs.h" 1 3 4
# 292 "/usr/include/features.h" 2 3 4
# 314 "/usr/include/features.h" 3 4
# 1 "/usr/include/gnu/stubs.h" 1 3 4
# 315 "/usr/include/features.h" 2 3 4
# 24 "/usr/include/sys/socket.h" 2 3 4
# 1 "/usr/include/sys/uio.h" 1 3 4
# 24 "/usr/include/sys/uio.h" 3 4
# 1 "/usr/include/sys/types.h" 1 3 4
# 29 "/usr/include/sys/types.h" 3 4
# 1 "/usr/include/bits/types.h" 1 3 4
# 28 "/usr/include/bits/types.h" 3 4
# 1 "/usr/include/bits/wordsize.h" 1 3 4
# 29 "/usr/include/bits/types.h" 2 3 4
# 1 "/usr/lib/gcc-lib/i386-linux/3.3.1/include/stddef.h" 1 3 4
# 213 "/usr/lib/gcc-lib/i386-linux/3.3.1/include/stddef.h" 3 4
typedef unsigned int size_t;
# 32 "/usr/include/bits/types.h" 2 3 4
typedef unsigned char __u_char;
typedef unsigned short int __u_short;
typedef unsigned int __u_int;
typedef unsigned long int __u_long;
typedef signed char __int8_t;
typedef unsigned char __uint8_t;
typedef signed short int __int16_t;
typedef unsigned short int __uint16_t;
typedef signed int __int32_t;
typedef unsigned int __uint32_t;
__extension__ typedef signed long long int __int64_t;
__extension__ typedef unsigned long long int __uint64_t;
__extension__ typedef long long int __quad_t;
__extension__ typedef unsigned long long int __u_quad_t;
# 128 "/usr/include/bits/types.h" 3 4
# 1 "/usr/include/bits/typesizes.h" 1 3 4
# 129 "/usr/include/bits/types.h" 2 3 4
typedef unsigned long long int __dev_t;
typedef unsigned int __uid_t;
typedef unsigned int __gid_t;
typedef unsigned long int __ino_t;
typedef unsigned long long int __ino64_t;
typedef unsigned int __mode_t;
typedef unsigned int __nlink_t;
typedef long int __off_t;
typedef long long int __off64_t;
typedef int __pid_t;
typedef struct { int __val[2]; } __fsid_t;
typedef long int __clock_t;
typedef unsigned long int __rlim_t;
typedef unsigned long long int __rlim64_t;
typedef unsigned int __id_t;
typedef long int __time_t;
typedef unsigned int __useconds_t;
typedef long int __suseconds_t;
typedef int __daddr_t;
typedef long int __swblk_t;
typedef int __key_t;
typedef int __clockid_t;
typedef int __timer_t;
typedef long int __blksize_t;
typedef long int __blkcnt_t;
typedef long long int __blkcnt64_t;
typedef unsigned long int __fsblkcnt_t;
typedef unsigned long long int __fsblkcnt64_t;
typedef unsigned long int __fsfilcnt_t;
typedef unsigned long long int __fsfilcnt64_t;
typedef int __ssize_t;
typedef __off64_t __loff_t;
typedef __quad_t *__qaddr_t;
typedef char *__caddr_t;
typedef int __intptr_t;
typedef unsigned int __socklen_t;
# 32 "/usr/include/sys/types.h" 2 3 4
typedef __u_char u_char;
typedef __u_short u_short;
typedef __u_int u_int;
typedef __u_long u_long;
typedef __quad_t quad_t;
typedef __u_quad_t u_quad_t;
typedef __fsid_t fsid_t;
typedef __loff_t loff_t;
typedef
Bug#202017: gcc-3.3: Unnecessary branching with INET/INET6 port setting
Package: gcc-3.3
Version: 1:3.3.1-0pre0
Severity: minor
The following program
--
#include
int
main(struct sockaddr *fromp, int port)
{
const int family = fromp->sa_family;
union {
struct sockaddr_in6 in6;
struct sockaddr_in in;
} *const u = (void *)fromp;
if (family == AF_INET6)
u->in6.sin6_port = htons(port);
else
u->in.sin_port = htons(port);
return 0;
}
--
when compiled with
gcc-3.3 -S -O2
produces
--
.file "b.c"
.text
.p2align 2,,3
.globl main
.type main, @function
main:
pushl %ebp
movl%esp, %ebp
subl$8, %esp
movl8(%ebp), %edx
andl$-16, %esp
cmpw$10, (%edx)
movl12(%ebp), %eax
je .L9
#APP
rorw $8, %ax
#NO_APP
.L8:
movw%ax, 2(%edx)
leave
xorl%eax, %eax
ret
.p2align 2,,3
.L9:
#APP
rorw $8, %ax
#NO_APP
jmp .L8
.size main, .-main
.ident "GCC: (GNU) 3.3.1 20030626 (Debian prerelease)"
--
As you can see, the branch due to the family is unnecessary. This bug
exists in gcc272, gcc 2.95 and gcc 3.2
I've attached the preprocessed source.
-- System Information
Debian Release: testing/unstable
Kernel Version: Linux gondolin 2.4.21-2-686-smp #1 SMP Sat Jul 5 01:42:22 EST
2003 i686 GNU/Linux
Versions of the packages gcc-3.3 depends on:
ii binutils 2.14.90.0.4-0. The GNU assembler, linker and binary utiliti
ii cpp-3.33.3.1-0pre0The GNU C preprocessor
ii gcc-3.3-base 3.3.1-0pre0The GNU Compiler Collection (base package)
ii libc6 2.3.1-16 GNU C Library: Shared libraries and Timezone
ii libgcc13.3.1-0pre0GCC support library
--
# 1 "b.c"
# 1 ""
# 1 ""
# 1 "b.c"
# 1 "/usr/include/netinet/in.h" 1 3 4
# 22 "/usr/include/netinet/in.h" 3 4
# 1 "/usr/include/features.h" 1 3 4
# 291 "/usr/include/features.h" 3 4
# 1 "/usr/include/sys/cdefs.h" 1 3 4
# 292 "/usr/include/features.h" 2 3 4
# 314 "/usr/include/features.h" 3 4
# 1 "/usr/include/gnu/stubs.h" 1 3 4
# 315 "/usr/include/features.h" 2 3 4
# 23 "/usr/include/netinet/in.h" 2 3 4
# 1 "/usr/include/stdint.h" 1 3 4
# 27 "/usr/include/stdint.h" 3 4
# 1 "/usr/include/bits/wchar.h" 1 3 4
# 28 "/usr/include/stdint.h" 2 3 4
# 1 "/usr/include/bits/wordsize.h" 1 3 4
# 29 "/usr/include/stdint.h" 2 3 4
# 37 "/usr/include/stdint.h" 3 4
typedef signed char int8_t;
typedef short int int16_t;
typedef int int32_t;
__extension__
typedef long long int int64_t;
typedef unsigned char uint8_t;
typedef unsigned short int uint16_t;
typedef unsigned int uint32_t;
__extension__
typedef unsigned long long int uint64_t;
typedef signed char int_least8_t;
typedef short int int_least16_t;
typedef int int_least32_t;
__extension__
typedef long long int int_least64_t;
typedef unsigned char uint_least8_t;
typedef unsigned short int uint_least16_t;
typedef unsigned int uint_least32_t;
__extension__
typedef unsigned long long int uint_least64_t;
typedef signed char int_fast8_t;
typedef int int_fast16_t;
typedef int int_fast32_t;
__extension__
typedef long long int int_fast64_t;
typedef unsigned char uint_fast8_t;
typedef unsigned int uint_fast16_t;
typedef unsigned int uint_fast32_t;
__extension__
typedef unsigned long long int uint_fast64_t;
# 126 "/usr/include/stdint.h" 3 4
typedef int intptr_t;
typedef unsigned int uintptr_t;
# 138 "/usr/include/stdint.h" 3 4
__extension__
typedef long long int intmax_t;
__extension__
typedef unsigned long long int uintmax_t;
# 24 "/usr/include/netinet/in.h" 2 3 4
# 1 "/usr/include/bits/types.h" 1 3 4
# 28 "/usr/include/bits/types.h" 3 4
# 1 "/usr/include/bits/wordsize.h" 1 3 4
# 29 "/usr/include/bits/types.h" 2 3 4
# 1 "/usr/lib/gcc-lib/i386-linux/3.3.1/include/stddef.h" 1 3 4
# 213 "/usr/lib/gcc-lib/i386-linux/3.3.1/include/stddef.h" 3 4
typedef unsigned int size_t;
# 32 "/usr/include/bits/types.h" 2 3 4
typedef unsigned char __u_char;
typedef unsigned short int __u_short;
typedef unsigned int __u_int;
typedef unsigned long int __u_long;
typedef signed char __int8_t;
typedef unsigned char __uint8_t;
typedef signed short int __int16_t;
typedef unsigned short int __uint16_t;
typedef signed int __int32_t;
typedef unsigned int __uint32_t;
__extension__ typedef signed long long int __int64_t;
__extension__ typedef unsigned long long int __uint64_t;
__extension__ typedef long long int __quad_t;
__extension__ typedef unsigned long long int __u_quad_t;
# 128 "/usr/include/bits/types.h" 3 4
# 1 "/usr/include/bits/typesizes.h" 1 3 4
# 129 "/usr/include/bits/types.h" 2 3 4
typedef unsigned long long int __dev_t;
typedef unsigned int __uid_t;
typedef unsigned int __gid_t;
typedef unsigned long int __ino_t;
typedef unsigned long long int __ino64_t;
typedef unsigned int __mode_t;
typedef unsigned int __nlink_t;
typedef
Bug#204687: gcc-3.3: gcc should use xor trick with -Os
Package: gcc-3.3
Version: 1:3.3.1-0pre0
Severity: wishlist
The program
--
#include
void foo(struct timespec *t, struct timespec *u)
{
struct timespec zero = {0, 0};
*t = zero;
*u = zero;
}
--
produces the following code on i386 with -Os
--
.file "b.c"
.text
.globl foo
.type foo, @function
foo:
pushl %ebp
movl%esp, %ebp
movl8(%ebp), %eax
movl$0, (%eax)
movl$0, 4(%eax)
movl12(%ebp), %eax
movl$0, (%eax)
movl$0, 4(%eax)
leave
ret
.size foo, .-foo
.ident "GCC: (GNU) 3.3.1 20030626 (Debian prerelease)"
--
It would be much better size-wise if it stored a zero in a register
and then stored the register into those locations.
-- System Information
Debian Release: testing/unstable
Kernel Version: Linux gondolin 2.4.21-2-686-smp #1 SMP Sat Jul 5 01:42:22 EST
2003 i686 GNU/Linux
Versions of the packages gcc-3.3 depends on:
ii binutils 2.14.90.0.4-0. The GNU assembler, linker and binary utiliti
ii cpp-3.33.3.1-0pre0The GNU C preprocessor
ii gcc-3.3-base 3.3.1-0pre0The GNU Compiler Collection (base package)
ii libc6 2.3.1-16 GNU C Library: Shared libraries and Timezone
ii libgcc13.3.1-0pre0GCC support library
Bug#219949: gcc: linux-2.6/sound/core/oss/rate.c miscompiled
Package: gcc
Version: 4:3.3.1-2
Severity: normal
gcc -march=i386 -fomit-frame-pointer -O2
miscompiles sound/core/oss/rate.c in Linux 2.6.0-test9.
I've attached the preprocessed source that demonstrates the
problem.
In the assembly output with -S, look for the 5th label in
get_s16_labels.0. That label should do a word load, but
instead it does a double word load:
.L4:
movl(%ebp), %eax
jmp .L111
-- System Information
Debian Release: testing/unstable
Kernel Version: Linux gondolin 2.4.22-1-686-smp #5 SMP Sat Oct 4 14:35:05 EST
2003 i686 GNU/Linux
Versions of the packages gcc depends on:
ii cpp3.3.1-2The GNU C preprocessor.
ii cpp-3.33.3.2-1The GNU C preprocessor
ii gcc-3.33.3.2-1The GNU C compiler
--
begin 600 rate.i.bz2
M0EIH.3%!629360-J_[P`D.=_@'__O[]A2%]WSX:`!0`/
MH```T```'6[79Z>H>"]P#0`"@&E'[EMAIL PROTECTED]'WOK[OO/77CNW?Z/NWN9M:LV^SZ^6!3UN]W?%ON.Y$OKR\/ML;7S?%W9ZY]U5
M[P'U76EON2"[LNN^^WGW%71OK7NGC>3WNN^P'WFY\[OI[WGKP)[WH??`^]=?
M?>;Z>S[90]=`=9K[>]>WWETQPML^%=!;[EMAIL PROTECTED])B?<]>%
M/I\[--L/HH"*(`??6^U4``^SWOIZ]`;:@Z?('1T*]W=W+)M(``L\!>NCHWNQ
MZ\N.>Z>/<]'>KV>]E#V7NSMV^OO?;LSNQU]NO73RZICN]?=\;[EMAIL PROTECTED]
M``Z]KO>]\U`:#QT\5Y9WWVXU6TGU36?:[>)FW;K[VHE.SVZQ+NE[O>J^R^^G
M;W)[T)P?;[EMAIL PROTECTED]@!T$[*:`>@`#0^(/NP`'UK*0V[NJ.
MJUKT-=LM@'MOOOKR?6*O7=I>;O;SFR6S$J\SG)EUEV]MWTYW;=\9N;;T^GH!
M05[UO%]];W,"V`&X:W6%\W6M>\^WN4-[3'?7KOD==O;NWP[[W:T^A4V`=.J!
M]:A%LWOL]G=LZ\]SWE$;45\[3OG39]%N"\>@`HT&K??7/>0^CG8/O>][)MUT
MV;I9GN[ON82M][WN[IW"^[[ON$ONYUOM][;```/=]VNQ;F=VMN][;#3S;'RY
MUZ==9J='=Y?+Y]=WWOJS7L`GA6Y][R]Y#OMWGEPL>^]K[[?+9G!]>]GSOO0L
MT]CNVCSNN`-9!YLZ+"9MZ]KW7M;;:M][YL^M]WH]'WCZ8]]O7KYLK,VT?6=C
MG;&6>>>BY[MT];M;%JK&Q:(]WVJJ0^V250DKZ]GWN[FWN[WNN[FOI>PW,'WL
M[O-Z]C'SMV=LH`]F]/3VRV;%O=R[*2;N>.U%`:``&@``%$\&M[!],J`*D[;U
MHV]:^WT'<)O':^V\9:O67#1[?>]S6GL>0$AKL]R]LGE;[.YLT]`[N^][TK>]
M[[V[?!W%EP``?"[EMAIL PROTECTED]":$R`5/:F$:F&JGY&D>%3TQ3,ID_41I^I-/2`!I
MB&@)3$0B$(02>0:$TU/4V5/:I^J&U#U-'J:;4T``-``&@```"1J2(0)D"8(T
MD_5/*;0:FU/4]#334VIM1H]&49J:>[EMAIL PROTECTED]:&F$R"[EMAIL PROTECTED])@[EMAIL
PROTECTED]"8I
MY--34VD\U&IHT'Z4#U`>H&GZD`/2#U&U,(D1":":$Q,@":v!,IZ*GIZI[*>J>
MT$GE/U)IZGJ9E&AID]1IH&F@::-&@(D1!3!3&@0"D_1H(]3$U-JC4]I1Z>J/
M4&GE`:!M(-``&@#31]SP`"(I(14^Y_J_E_3\T_Z;O&3$^Y#9+C]H<3:#R@"%
ME/PV,@90&[EMAIL PROTECTED]'(!$+#&@3"F1,@.0*$6E%D`+&+G.<[EMAIL PROTECTED]<&V!B
M)>@R'4J&9X]`"XD$]O;;9>R!#S`HB]Q`2`BA(R*T(E`*E*`4!2(%(TJA9P*H
M.A%.*0GJ(1(?\`AG(=(($#]9]26E/V%$M(:1,]KVH3++41IEF2:H*J3FVP%)
[EMAIL PROTECTED]>NC%4]U!241,<@T%)5,FY&#D!I=:`Z:DZ:N;=3
MH.<<[HQ4423513IVMIKD=6CJ2ZM4A.G=CD3N5#J%V-50415%!U+6J0Q6VFDI
MH&6J6)IDI=&[EMAIL PROTECTED]>Z*H,NA-&[UG8ETL2]2\E?$'53%514D[EMAIL PROTECTED],11MC:G&@Y
MP,G(B:M!8BK5+HU6HJ:B(FV;:CF,L0'+3:,XULF-!10W,Y'Q
[EMAIL PROTECTED]&Z!`(I%,NE0+=6C'()"30T"A$44'"2BV:6J:T-"8DJ)*H6)6
[EMAIL PROTECTED]([EMAIL PROTECTED]"A=(%`Z*5T+30$;&[EMAIL
PROTECTED]&E*6FCK/*JL8Q-%55C$1%;6SMG
M!DW:&#KKH.)$)(Q;*:DC0QL!2T4-5BH3$M-5HH"V&,8R[:#2:2C$X*)279=&
MA*&@MDT%9EDL%F.;AS<,::\Y-1$L!+!T>./)BN$Y)T)1D**(@J"U63."8`Q=
M#$8Y3)PVTD1.'&*ZYP.%I-/.;:V,.(-#553;);."$H`T(Z'1H:!HB>XYS1%%!!+%%3%HT44Z'D=7):-4QC)KHYBX9MD*
M>$IHY!245H=*8C0Q!F"(U0U0:-#1B4T:#07+A<*P321`E*43`4":Q*:*I*U0
MYV32.*J3511!5%&C3K6MC=2^C*&(0#L__,?[G_CR?Y(#XA[,4!(E%-55
M551`%+2U0?Y3T]WP/E\V([EMAIL PROTECTED]""[EMAIL PROTECTED],=D&]T9(>-
M,CYC5)%P^?/PN'4(THS?&64UJT*#A*991!36$,N+\)"GQ.#6-G;3BA
M?ACG._EW[_7_/X$&A:[EMAIL PROTECTED]@L+H4-&QI`X[^./B09Q*T%)2T4
M$2M!115(^C7DQPAY(443!R(-'RI+6Q+2M+:I8JE6*JV,K:J;&U0:HS.VM:<:
MB+$FL;9.C->`EI3:^"[EMAIL PROTECTED]"HK+&UH6%5S$Q&EG#69--5!5(T1*%N
M9F+1RRYBIDI;&DK3,):"5K3,IER)[F1H*JNXT%YLH4.C3
M2%!0%`5324T%4!!4I1,145Y?;)SKVXW7>WJ<[EMAIL PROTECTED];[EMAIL PROTECTED]:1*&
MJ&(ID]-#H*-1BB(D:HIIL!;0NAX1B`XSAIBFE"BFB&*)FHUA3FQ%51R,%%PY
MSB)*;8"8*=&@[EMAIL PROTECTED]"@B"L9T;:"JD*-&'.0FK$X,CML&8*(MJ
M<9H-,E42&AM:IDUH-HU:B*=LQ504M-"14,WM*:"EB"[EMAIL PROTECTED])R4
M](%_.(_ZX`(:1?],.6U([EMAIL PROTECTED]@_^\Z+VE2!\TAH58D$*!?IOGE="O"
M5JD3J1.2(Z"DY!2:TE*7`6X`R*/JG^'6A?*!\X'_+$#?%2/]5:@*'U*L0%]Y
M?P[0(:`4_GNH4I3G61$--(\A0*4
M43$(CR02E4Q)[EMAIL PROTECTED]/)5%TC2"E``TB\E5:4[A3D*<@0TB'4`E-(#I`3D+$B%(
M*')%'D`+U([EMAIL PROTECTED]@ZE%Q(([EMAIL PROTECTED]"(TJ)[EMAIL
PROTECTED]>$4.X!?B#/$%)F.H,"1'T/M
M;0_^NOQ[MH/M/=6/\DV_;P:#D`/[EMAIL PROTECTED]&'"K\?Y_T]=T#,]N!F-'A">
M(4I]L'DX`]M2L4A1)`P$30DS4I3<0SG"A.B7%!B-!+"LK24C!`$DL!F!O?+\
M29XZG\&RUCKQF?IWO$S\,N6LS_:G,-[>*NEQ+>7?73YMUS6*7K$/4M6\S^N:HQ+.3B.MZ4I=;8YTCG5Q[=
MI(2YTXK+ZUR;O6TDKR#;YN:L%C6WB-8Z.+K&:2CO>]V]I9-=8U#G4T\>#6),>NGJW6LS+,CZ76SBE&M:F=04$E
MN]KC,Q-7OG(GEZWFM&S7!:G-W6SHU>YDO6]
M\1TDGJX[UJ^GU%?$HNZ5!6$?9I#:U
M75#6A9%8F#\0>(/2]*UW;:]X'O9HRN#2+]LZCL+5;_#&Y555'\W-5?](<_KQ
MN8ZP/')Y]330Q5B4Q_]_^__V1:N^Y(/935__#,##-ZS_"`YNY[/7F0K^+SIW
MQ$]*0HS"H>$:>[EMAIL PROTECTED]@WZ'O
Bug#93278: gcc-2.95: gcc segfaults on kernel 2.4.3
Package: gcc-2.95 Version: 1:2.95.3-10 Severity: serious $ /usr/lib/gcc-lib/i386-linux/2.95.3/cc1 -quiet -dumpbase reg_ld_str.c -mpreferred-stack-boundary=2 -march=i386 -O2 -Wall -Wstrict-prototypes -version -fomit-frame-pointer -fno-strict-aliasing -o reg_ld_str.o reg_ld_str.i GNU C version 2.95.3 20010315 (Debian release) (i386-linux) compiled by GNU C version 2.95.3 20010315 (Debian release). reg_ld_str.c: In function `FPU_store_single': reg_ld_str.c:635: warning: `templ' might be used uninitialized in this function Segmentation fault (core dumped) $ reg_ld_str.i can be obtained from http://gondor.apana.org.au/~herbert/bugs/reg_ld_str.i.bz2 gcc-3.0 compiles it successfully. The segfault goes away if the file is passed through the preprocessor again. -- System Information Debian Release: testing/unstable Kernel Version: Linux gondolin 2.4.2-pentiumiii-smp #1 SMP Tue Mar 13 07:54:37 EST 2001 i686 unknown Versions of the packages gcc-2.95 depends on: ii binutils 2.11.90.0.1-1 The GNU assembler, linker and binary utiliti ii cpp-2.95 2.95.3-6 The GNU C preprocessor. ii gcc2.95.3-5 The GNU C compiler. ii libc6 2.2.2-4GNU C Library: Shared libraries and Timezone
Bug#94701: gcc-3.0: Duplicate loop conditions even with -Os
Package: gcc-3.0
Version: 1:3.0-0pre010403
Severity: wishlist
For the following program,
int k;
extern void b();
int a(int i) {
while (k < i) {
b();
}
}
GCC generates this on i386 (gcc -S -Os),
a:
pushl %ebp
movl%esp, %ebp
pushl %ebx
pushl %ecx
movl8(%ebp), %ebx
cmpl%ebx, k
jge .L7
.p2align 2
.L5:
callb
cmpl%ebx, k
jl .L5
.L7:
popl%edx
popl%ebx
popl%ebp
ret
I don't see the reason why it isn't doing:
.p2align 2
.L5:
cmpl%ebx, k
jge .L7
callb
jmp .L5
.L7:
or
jmp .L7
.p2align 2
.L5:
callb
.L7:
cmpl%ebx, k
jl .L5
-- System Information
Debian Release: testing/unstable
Kernel Version: Linux gondolin 2.4.3-pentiumiii-smp #1 SMP Sun Apr 15 14:20:42
EST 2001 i686 unknown
Versions of the packages gcc-3.0 depends on:
ii binutils 2.11.90.0.1-1 The GNU assembler, linker and binary utiliti
ii cpp-3.03.0-0pre010403 The GNU C preprocessor.
ii gcc-3.0-base 3.0-0pre010403 The GNU compiler collection (base package).
ii libc6 2.2.2-4GNU C Library: Shared libraries and Timezone
ii libgcc300 3.0-0pre010403 Shared libgcc.
Bug#95318: gcc-3.0: unnecessary cwtl
Package: gcc-3.0
Version: 1:3.0-0pre010403
Severity: minor
gcc-3.0 wastes a byte in the following code on i386:
a:
pushl %ebp
movl%esp, %ebp
movl8(%ebp), %eax
andl$1, %eax
cwtl
popl%ebp
ret
The cwtl is unnecessary since %eax has just been anded with 1.
The source is:
int a(short i) {
return i & 1;
}
-- System Information
Debian Release: testing/unstable
Kernel Version: Linux gondolin 2.4.3-686-smp #1 SMP Sun Apr 22 13:43:38 EST
2001 i686 unknown
Versions of the packages gcc-3.0 depends on:
ii binutils 2.11.90.0.1-1 The GNU assembler, linker and binary utiliti
ii cpp-3.03.0-0pre010403 The GNU C preprocessor.
ii gcc-3.0-base 3.0-0pre010403 The GNU compiler collection (base package).
ii libc6 2.2.2-4GNU C Library: Shared libraries and Timezone
ii libgcc300 3.0-0pre010403 Shared libgcc.
Bug#97904: gcc-3.0: Pointless moving
Package: gcc-3.0
Version: 1:3.0-0pre010427
Severity: normal
I was wondering if gcc-3.0 can decrease the size of ash since it combines
those esp additions/subtractions. Unfortunately, it actually ends up being
bigger. Part of the reason for that may be this:
findstring:
pushl %ebp
movl%esp, %ebp
subl$20, %esp
pushl $pstrcmp
pushl $4
pushl 16(%ebp)
leal8(%ebp), %edx
pushl 12(%ebp)
movl%edx, %eax
pushl %eax
callbsearch
leave
ret
Notice the line "movl %edx, %eax" is unnecessary if we push edx instead of
eax, or if we lea into eax instead of edx. The source of this is:
#include
int pstrcmp(const void *, const void *);
const char *const *findstring(
const char *s, const char *const *array, size_t nmemb
) {
return bsearch(&s, array, nmemb, sizeof(const char *), pstrcmp);
}
-- System Information
Debian Release: testing/unstable
Kernel Version: Linux gondolin 2.4.4-686-smp #1 SMP Sun Apr 29 12:50:30 EST
2001 i686 unknown
Versions of the packages gcc-3.0 depends on:
ii binutils 2.11.90.0.7-2 The GNU assembler, linker and binary utiliti
ii cpp-3.03.0-0pre010403 The GNU C preprocessor.
ii gcc-3.0-base 3.0-0pre010403 The GNU compiler collection (base package).
ii libc6 2.2.3-1GNU C Library: Shared libraries and Timezone
ii libgcc03.0-0pre010427 Shared libgcc.
Bug#105309: gcc-3.0: i386 optimisation: joining tests
Package: gcc-3.0
Version: 1:3.0-0pre010427
Severity: wishlist
Here's another segment that needs to have an assembler optimiser run over it:
int foo(char c) {
if (c && !(c & 0x80)) {
a();
} else {
b();
}
}
produces with -O2:
0: 55 push %ebp
1: 89 e5 mov%esp,%ebp
3: 83 ec 08sub$0x8,%esp
6: 8a 45 08mov0x8(%ebp),%al
9: 84 c0 test %al,%al
b: 74 04 je 11
d: 84 c0 test %al,%al
f: 79 07 jns18
9-f can be rewritten as:
test%al, %al
jg 18
11: e8 fc ff ff ff call 12
12: R_386_PC32 b
16: c9 leave
17: c3 ret
18: e8 fc ff ff ff call 19
19: R_386_PC32 a
1d: eb f7 jmp16
And what purpose does this jmp serve? Surely it can be replaced with
leave
ret
1f: 90 nop
-- System Information
Debian Release: testing/unstable
Kernel Version: Linux gondolin 2.4.6-686-smp #1 SMP Thu Jul 5 22:06:27 EST 2001
i686 unknown
Versions of the packages gcc-3.0 depends on:
ii binutils 2.11.90.0.7-2 The GNU assembler, linker and binary utiliti
ii cpp-3.03.0-0pre010403 The GNU C preprocessor.
ii gcc-3.0-base 3.0-0pre010403 The GNU compiler collection (base package).
ii libc6 2.2.3-5GNU C Library: Shared libraries and Timezone
ii libgcc03.0-0pre010427 Shared libgcc.
Bug#106866: gcc-3.0: Optimisation: [i386] pointless jump before a call
Package: gcc-3.0 Version: 1:3.0.1-0pre010723 Severity: normal I was playing with the noreturn flag when I noticed the following pointless jump into a call instruction: 86: a1 00 00 00 00 mov0x0,%eax 87: R_386_32intpending 8b: 85 c0 test %eax,%eax 8d: 74 c9 je 58 8f: eb 3b jmpcc 91: 8d 76 00lea0x0(%esi),%esi ... c8: eb d4 jmp9e ca: 89 f6 mov%esi,%esi cc: e8 fc ff ff ff call cd cd: R_386_PC32 doint d1: 8d 76 00lea0x0(%esi),%esi There are no other jumps to cc. That costed me 8 bytes and a pointless jump. The source that generated this can be fetched from http://gondor.apana.org.au/~herbert/bugs/gcc-bug-1.tar.bz2 To reproduce, do: gcc-3.0 -g -O2 -DUSE_DOINT -c eval.c -- System Information Debian Release: testing/unstable Kernel Version: Linux gondolin 2.4.7-686-smp #1 SMP Sun Jul 22 14:00:21 EST 2001 i686 unknown Versions of the packages gcc-3.0 depends on: ii binutils 2.11.90.0.24-1 The GNU assembler, linker and binary utiliti ii cpp-3.03.0.1-0pre0107 The GNU C preprocessor. ii gcc-3.0-base 3.0.1-0pre0107 The GNU Compiler Collection (base package). ii libc6 2.2.3-7GNU C Library: Shared libraries and Timezone ii libgcc13.0.1-0pre0107 GCC support library.
Bug#108036: gcc: gcc generates ..ng references for static aliases
Package: gcc
Version: 1:2.95.3-7
Severity: normal
Architecture: alpha
This file compiles but doesn't link on alpha:
#include
void foo(int);
static void bar(int) __attribute__ ((noreturn));
void foo(int k) {
if (k) {
exit(k);
}
}
static void bar(int) __attribute__ ((alias("foo")));
int main(int k) {
if (k < 0) {
bar(1);
}
return k;
}
What happens is that gcc generates a reference to bar..ng but the alias
only exists for bar. The problem goes away when bar is not declared as
static.
I've reproduced this problem with gcc-3.0 as well.
-- System Information
Debian Release: testing/unstable
Kernel Version: Linux gondolin 2.4.7-686-smp #1 SMP Sun Jul 22 14:00:21 EST
2001 i686 unknown
Versions of the packages gcc depends on:
ii cpp2.95.3-7 The GNU C preprocessor.
ii cpp-2.95 2.95.4-0.01042 The GNU C preprocessor.
ii gcc-2.95 2.95.4-0.01042 The GNU C compiler.
Bug#127890: gcc-3.0: ICE in gen_subprogram_die 9463
Package: gcc-3.0
Version: 1:3.0.2-4
Severity: normal
The following program bombs out on alpha:
$ gcc-3.0 -g -O2 -c a.c
a.c: In function `make_rate':
a.c:16: Internal compiler error in gen_subprogram_die, at dwarf2out.c:9463
Please submit a full bug report,
with preprocessed source if appropriate.
See http://www.gnu.org/software/gcc/bugs.html> for instructions.
It was abstracted out from drivers/atm/horizon.c in linux 2.4.17.
I've reproduced it with today's CVS gcc 3.0 branch. However, it is fixed in
the 3.1 dev branch.
-- System Information
Debian Release: 3.0
Kernel Version: Linux gondolin 2.4.17-686-smp #2 SMP Sat Dec 22 22:00:42 EST
2001 i686 unknown
Versions of the packages gcc-3.0 depends on:
ii binutils 2.11.92.0.12.3 The GNU assembler, linker and binary utiliti
ii cpp-3.03.0.2-4The GNU C preprocessor.
ii gcc-3.0-base 3.0.2-4The GNU Compiler Collection (base package).
ii libc6 2.2.4-7GNU C Library: Shared libraries and Timezone
ii libgcc13.0.2-4GCC support library.
--
int g(void);
static int make_rate(unsigned c, unsigned actual) {
unsigned br = g() ? 500 : 400;
int set_cr(void) {
actual = br;
return 0;
}
if (!c) {
return 0;
}
return set_cr();
}
Bug#259887: gcc-3.3: Miscompiles automatic dynamic arrays
Package: gcc-3.3
Version: 1:3.3.4-3
Severity: critical
With the option -mpreferred-stack-boundary=2, gcc 3.3.4 is miscompiling
automatic dynamic arrays. Unfortunately both are used in the
crypto/IPsec subsystems of the Linux kernel.
Here is a sample program:
#include
int bar(char *s);
int foo(char *s, int len, int x)
{
char buf[x ? len : 0];
if (x) {
memcpy(buf, s, len);
s = buf;
}
return bar(s);
}
With gcc 3.3.4, this produces:
++
.file "b.c"
.text
.p2align 4,,15
.globl foo
.type foo, @function
foo:
pushl %ebp
xorl%eax, %eax
movl%esp, %ebp
subl$24, %esp
movl16(%ebp), %ecx
movl%edi, -4(%ebp)
movl12(%ebp), %edx
movl%esp, %edi
movl%ebx, -12(%ebp)
movl%esi, -8(%ebp)
decl%edx
movl8(%ebp), %esi
testl %ecx, %ecx
setne %al
decl%eax
orl %eax, %edx
addl$19, %edx
andl$-4, %edx
-
subl%edx, %esp
leal27(%esp), %ebx
andl$-16, %ebx
Note the offset 27. The same program when compiled with gcc 3.2.3
produces similar output but it uses an offset of 15.
Suppose that len = 16, x != 0, and %esp & 15 = 8 before the subl.
That means %edx = (15 + 19) & ~3 = 32. So %esp & 15 is still 8
after the subtraction. That is, %esp = 16x + 8. Hence
%ebx = (%esp + 27) & ~15 = (16x + 35) & ~15 = 16x + 32 = %esp + 24.
Therefore buf will only contain 8 bytes of space instead of 16
bytes.
-
testl %ecx, %ecx
jne .L5
.L4:
movl%esi, (%esp)
callbar
movl%edi, %esp
movl-12(%ebp), %ebx
movl-8(%ebp), %esi
movl-4(%ebp), %edi
movl%ebp, %esp
popl%ebp
ret
.p2align 4,,7
.L5:
movl12(%ebp), %eax
movl%esi, 4(%esp)
movl%ebx, %esi
movl%eax, 8(%esp)
movl%ebx, (%esp)
callmemcpy
jmp .L4
.size foo, .-foo
.section.note.GNU-stack,"",@progbits
.ident "GCC: (GNU) 3.3.4 (Debian 1:3.3.4-3)"
++
Since this bug can lead to remotely triggered crashes and possibly
exploits I'm rating it as critical.
-- System Information
Debian Release: testing/unstable
Kernel Version: Linux gondolin 2.4.26-1-686-smp #1 SMP Sat May 1 19:17:11 EST
2004 i686 GNU/Linux
Versions of the packages gcc-3.3 depends on:
ii binutils 2.14.90.0.7-8 The GNU assembler, linker and binary utiliti
ii cpp-3.33.3.4-1The GNU C preprocessor
ii gcc-3.3-base 3.3.4-1The GNU Compiler Collection (base package)
ii libc6 2.3.2.ds1-13 GNU C Library: Shared libraries and Timezone
ii libgcc13.3.4-1GCC support library
Bug#152601: gcc-3.0: Dead symlink at /usr/lib/gcc-lib/hppa-linux/3.0.4/libgcc_s.so
Moin, [EMAIL PROTECTED]:~$ dpkg -S /usr/lib/gcc-lib/hppa-linux/3.0.4/libgcc_s.so gcc-3.0: /usr/lib/gcc-lib/hppa-linux/3.0.4/libgcc_s.so [EMAIL PROTECTED]:~$ dpkg -L libgcc1 /. /usr /usr/share /usr/share/doc /usr/share/doc/libgcc1 /usr/share/doc/libgcc1/copyright /usr/share/doc/libgcc1/changelog.Debian.gz /lib Regards Herbert. Matthias Klose wrote: > > [EMAIL PROTECTED] writes: > > Package: gcc-3.0 > > Version: 1:3.0.4-7 > > Severity: normal > > > > AIDE reported this dead symlink: > > > > lrwxrwxrwx1 root root 18 Jul 5 20:16 > > /usr/lib/gcc-lib/hppa-linux/3.0.4/libgcc_s.so -> /lib/libgcc_s.so.1 > > > > could you send the output for > > dpkg -S /usr/lib/gcc-lib/hppa-linux/3.0.4/libgcc_s.so > > dpkg -L libgcc1 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#164554: gcc-3.2: volatile not respected on alpha
On Mon, Oct 14, 2002 at 06:01:24PM -0400, Daniel Jacobowitz wrote:
>
> I don't see the problem. Volatile in C doesn't provide any sort of
> barrier; you have to place one yourself if you want one. It only
> guaranatees that the two accesses to "i" will not be reordered or
> eliminated.
My copy of C99 says:
5The least requirements on a conforming implementation are:
- At sequence points, volatile objects are stable in the sense that previou
s accesses are
complete and subsequent accesses have not yet occurred.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#164554: gcc-3.2: volatile not respected on alpha
On Mon, Oct 14, 2002 at 07:01:46PM -0400, Daniel Jacobowitz wrote:
>
> > My copy of C99 says:
> >
> > 5The least requirements on a conforming implementation are:
> > - At sequence points, volatile objects are stable in the sense that
> > previou
> > s accesses are
> > complete and subsequent accesses have not yet occurred.
>
> Only volatile objects are required to be stable. I believe that if "j"
That's right. However, there is a sequence point between i++ and
j=6, so the previous access to i should be completed at that point.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#164554: gcc-3.2: volatile not respected on alpha
On Tue, Oct 15, 2002 at 08:38:37AM +0200, Martin v. Loewis wrote:
>
> In the code, there are two modifications to i, namely
>
> i++;
> j = 6;
> i--;
>
> So at the first sequence point, i should be incremented, and at the
> second sequence point, i should be decremented to its original value
> (regardless of the value of j, which does not need to be coordinated).
> AFAICT, in the sequence
>
> ldq $3,i($29) !literal
> lda $4,6($31)
> ldq $1,j($29) !literal
> ldl $2,0($3)
> stl $4,0($1)
> lda $2,1($2)
> stl $2,0($3)
>
> the value of i is never changed. Instead, it is loaded into $2, and
> then written back from $2 to i. That seems to be in violation of the
> volatile requirements to me.
I left out the assembly which decrements i, otherwise it is correct.
It's basically doing
j = 6;
i++;
i--;
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Bug#169004: fping makes unaligned mem accesses, emulated by ia64 kernel
reassign 169004 gcc
merge 85468 169004
quit
On Wed, Nov 13, 2002 at 04:06:01PM -0700, dann frazier wrote:
> Package: fping
> Version: 2.4b2-to-ipv6-5
> Severity: normal
>
> fping makes unaligned accesses on ia64.
> such accesses are emulated in the kernel, and are therefore costly,
> and causes the ia64 kernel to bitch:
>
> keywest is unreachable
> [EMAIL PROTECTED]:~$ fping lart
> fping(17887): unaligned access to 0x6000b2e4, ip=0x40005ee1
> fping(17887): unaligned access to 0x6000b2ec, ip=0x40005ef1
> lart is alive
This is another manifestation of #85468, which is a bug in gcc.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: compiling 2.4.18 on pws au500
On Thu, Dec 05, 2002 at 09:01:13AM +0300, Alexander Kotelnikov wrote:
>
> The problem still exists wit 2.4.19 and cureenc gcc-2.95 on both sid
> and woody.
>
> For those, who read about this for the first time: make modules for
> 'generic' alpha Herbert's kernel fails with
gcc-2.95 is broken, please use gcc-3.2.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#85468: Bug#169004: fping makes unaligned mem accesses, emulated by ia64 kernel
On Fri, Dec 27, 2002 at 04:02:56PM +0100, Matthias Klose wrote:
> tags 169004 + moreinfo
> tags 169004 + helpneeded
> thanks
>
> - which compiler versions are used?
> - does the bug persist with gcc-3.2.2 and/or the current gcc-snapshot?
It still happens with 1:3.2.2-0pre2 on alpha. This is the assembly:
26bc: 08 00 2a a0 ldl t0,8(s1)
26c0: 10 00 4a a4 ldq t1,16(s1)
26c4: 18 00 6a a4 ldq t2,24(s1)
26c8: 40 00 3e b0 stl t0,64(sp)
26cc: 48 00 5e b4 stq t1,72(sp)
26d0: 50 00 7e b4 stq t2,80(sp)
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#67206: follwup for #67206
On Thu, Jan 02, 2003 at 02:29:51AM +0100, Matthias Klose wrote:
> Herbert, please could you send a followup (using gcc-3.2 and
> gcc-snapshot)?
The assembly code generated by gcc-3.2 is the same as what you got
in <[EMAIL PROTECTED]> which is part of
the bug log.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#169004: target/9082: [alpha,ia64] memcpy makes unaligned access
On Sun, Jan 26, 2003 at 10:22:31AM -, [EMAIL PROTECTED] wrote:
> Synopsis: [alpha,ia64] memcpy makes unaligned access
>
> State-Changed-From-To: open->closed
> State-Changed-By: rth
> State-Changed-When: Sun Jan 26 10:22:31 2003
> State-Changed-Why:
> When submitting bugs to gcc, one must include the test case,
> not reference it in some package elsewhere. This reduces the
> possibility that the bug requires specific system headers to
> be reproduced.
I'm sorry about that, I'll get the preprocessed program sent to you.
> That said, it's obvious this is a duplicate of PR 9080,
> which is closed due to the input program being invalid.
I'm afraid I don't see the connection between the two reports.
In my case, memcpy is correct programmatically but it's triggering
an alignment error as it's performing 8-byte loads when the source
argument is 4-byte aligned (the destination is 8-byte aligned though).
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#181096: gcc-3.2: gcc fails to optimise if (l&2) l|=2 away
On Fri, Feb 21, 2003 at 04:26:04PM +0100, Matthias Klose wrote:
> please always include information about the status of the gcc-snapshot
> package as well.
This is what the snapshot produces
.file "b.c"
.text
.p2align 2,,3
.globl k
.type k, @function
k:
pushl %ebp
movl%esp, %ebp
movl8(%ebp), %eax
testb $2, %al
je .L2
orl $2, %eax
.L2:
leave
ret
.size k, .-k
.ident "GCC: (GNU) 3.3 20030129 (prerelease)"
As you can see, it is still testing and setting.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Bug#184893: kernel-source-2.4.20: C3 compile options wrong for gcc 3.2
On Sun, Mar 16, 2003 at 09:40:22AM +1100, herbert wrote:
>
> That's a bug in gcc-3.2. In fact it seems that it doesn't respect
> -falign-jumps at all:
>
> gcc-3.2 -falign-labels=0 -falign-jumps=0 -S -O2 a.c
To add insult to injury, -malign-jumps=0 actually works with gcc-3.2!
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Bug#184893: kernel-source-2.4.20: C3 compile options wrong for gcc 3.2
On Sat, Mar 15, 2003 at 10:27:27PM +, David Goodenough wrote:
>
> Possibly, but it would appear that it does not honour the old directives,
> at least the code that is generated is different. I generated kernels
> with the warnings and with a fixed Makefile and the generated kernels
> are of different size.
That's a bug in gcc-3.2. In fact it seems that it doesn't respect
-falign-jumps at all:
gcc-3.2 -falign-labels=0 -falign-jumps=0 -S -O2 a.c
*
int m();
int n();
int k(int l) {
if (l == 3) {
m();
n();
m();
m();
n();
} else {
n();
n();
n();
m();
m();
}
return 3;
}
*
.file "b.c"
.text
.align 2
.p2align 2,,3
.globl k
.type k,@function
k:
pushl %ebp
movl%esp, %ebp
subl$8, %esp
cmpl$3, 8(%ebp)
je .L4
calln
calln
calln
callm
callm
.L3:
movl$3, %eax
leave
ret
.p2align 2,,3
.L4:
callm
calln
callm
callm
calln
jmp .L3
.Lfe1:
.size k,.Lfe1-k
.ident "GCC: (GNU) 3.2.1 20020924 (Debian prerelease)"
*
Anyway, I'm closing this bug because the 2.4 kernels must still work
with gcc 2.95 which does not support -falign.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#189658: cpp-3.2: cpp package won't install
Package: cpp-3.2 Version: 1:3.2.3-0pre9 Severity: grave Justification: renders package unusable Installing the downloaded package returns an error (This occurred first during a regular apt-get upgrade routine, but is also happening when trying to manual install the package (see below)) Transcript : # dpkg -i /var/cache/apt/archives/cpp_3.2.3-0_i386.deb (Reading database ... 17908 files and directories currently installed.) Preparing to replace cpp 3:3.2.2-0 (using .../archives/cpp_3.2.3-0_i386.deb) ... Unpacking replacement cpp ... dpkg: error processing /var/cache/apt/archives/cpp_3.2.3-0_i386.deb (--install): unable to stat `./lib/cpp' (which I was about to install): Value too large for defined data type Errors were encountered while processing: /var/cache/apt/archives/cpp_3.2.3-0_i386.deb # -- System Information: Debian Release: testing/unstable Architecture: i386 Kernel: Linux Custom 2.4.20 #3 Sun Feb 23 00:50:13 CET 2003 i686 Locale: LANG=C, LC_CTYPE=C Versions of packages cpp-3.2 depends on: ii gcc-3.2-base 1:3.2.3-0pre9 The GNU Compiler Collection (base ii libc6 2.3.1-16 GNU C Library: Shared libraries an -- no debconf information
Bug#490644: Acknowledgement (gcc: -finline-small-functions is overzealous)
On Sun, Jul 13, 2008 at 10:27:42AM +, Debian Bug Tracking System wrote:
>
> Thank you for filing a new Bug report with Debian.
Here is the test file.
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
#include
enum token {
EOI,
FILRD,
FILWR,
FILEX,
FILEXIST,
FILREG,
FILDIR,
FILCDEV,
FILBDEV,
FILFIFO,
FILSOCK,
FILSYM,
FILGZ,
FILTT,
FILSUID,
FILSGID,
FILSTCK,
FILNT,
FILOT,
FILEQ,
FILUID,
FILGID,
STREZ,
STRNZ,
STREQ,
STRNE,
STRLT,
STRGT,
INTEQ,
INTNE,
INTGE,
INTGT,
INTLE,
INTLT,
UNOT,
BAND,
BOR,
LPAREN,
RPAREN,
OPERAND
};
enum token_types {
UNOP,
BINOP,
BUNOP,
BBINOP,
PAREN
};
static struct t_op {
const char *op_text;
short op_num, op_type;
} const ops [] = {
{"-r", FILRD, UNOP},
{"-w", FILWR, UNOP},
{"-x", FILEX, UNOP},
{"-e", FILEXIST,UNOP},
{"-f", FILREG, UNOP},
{"-d", FILDIR, UNOP},
{"-c", FILCDEV,UNOP},
{"-b", FILBDEV,UNOP},
{"-p", FILFIFO,UNOP},
{"-u", FILSUID,UNOP},
{"-g", FILSGID,UNOP},
{"-k", FILSTCK,UNOP},
{"-s", FILGZ, UNOP},
{"-t", FILTT, UNOP},
{"-z", STREZ, UNOP},
{"-n", STRNZ, UNOP},
{"-h", FILSYM, UNOP}, /* for backwards compat */
{"-O", FILUID, UNOP},
{"-G", FILGID, UNOP},
{"-L", FILSYM, UNOP},
{"-S", FILSOCK,UNOP},
{"=", STREQ, BINOP},
{"!=", STRNE, BINOP},
{"<", STRLT, BINOP},
{">", STRGT, BINOP},
{"-eq", INTEQ, BINOP},
{"-ne", INTNE, BINOP},
{"-ge", INTGE, BINOP},
{"-gt", INTGT, BINOP},
{"-le", INTLE, BINOP},
{"-lt", INTLT, BINOP},
{"-nt", FILNT, BINOP},
{"-ot", FILOT, BINOP},
{"-ef", FILEQ, BINOP},
{"!", UNOT, BUNOP},
{"-a", BAND, BBINOP},
{"-o", BOR, BBINOP},
{"(", LPAREN, PAREN},
{")", RPAREN, PAREN},
{0, 0, 0}
};
static char **t_wp;
static struct t_op const *t_wp_op;
static const struct t_op *getop(const char *s)
{
const struct t_op *op;
for (op = ops; op->op_text; op++) {
if (strcmp(s, op->op_text) == 0)
return op;
}
return NULL;
}
static int
isoperand(void)
{
struct t_op const *op;
char *s, *t;
if ((s = *(t_wp+1)) == 0)
return 1;
if ((t = *(t_wp+2)) == 0)
return 0;
op = getop(s);
return op && op->op_type == BINOP;
}
static enum token
t_lex(char *s)
{
struct t_op const *op;
if (s == 0) {
t_wp_op = (struct t_op *)0;
return EOI;
}
op = getop(s);
if (op && !(op->op_type == UNOP && isoperand()) &&
!(op->op_num == LPAREN && *(t_wp+1) == 0)) {
t_wp_op = op;
return op->op_num;
}
t_wp_op = (struct t_op *)0;
return OPERAND;
}
int
testcmd(int argc, char **argv)
{
const struct t_op *op;
int res;
if (*argv[0] == '[') {
if (*argv[--argc] != ']')
error("missing ]");
argv[argc] = NULL;
}
if (argc < 2)
return 1;
t_wp = &argv[1];
/*
* POSIX prescriptions: he who wrote this deserves the Nobel
* peace prize.
*/
if (argc == 4) {
op = getop(t_wp[1]);
if (op && op->op_type == BINOP) {
res = binop();
goto done;
}
}
if (argc >= 4 || argc <= 5) {
if (!strcmp(*t_wp, "(") && !strcmp(argv[argc - 1], ")")) {
argv[--argc] = NULL;
t_wp++;
}
}
res = oexpr(t_lex(*t_wp));
if (*t_wp != NULL && *++t_wp != NULL)
syntax(*t_wp, "unexpected operator");
done:
return !res;
}
Bug#490644: gcc: -finline-small-functions is overzealous
On Mon, Jan 04, 2010 at 02:47:18PM +0100, Matthias Klose wrote:
> tags 490644 + moreinfo
> tags 490644 + upstream
> thanks
>
> please could you recheck with GCC-4.4 and GCC-4.5 (experimental) or
> gcc-snapshot (unstable)? would it be possible to forwarded and track this
> report upstream yourself?
It appears to be fixed in gcc 4.4.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~}
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#343108: libstdc++6-4.0-dev: catching exception from codecvt_byname() segfaults
Package: libstdc++6-4.0-dev
Version: 4.0.2-5
Severity: normal
The following code segfaults. Looks like a double delete,
_S_destroy_c_locale() being called twice: first in the regular path of
codecvt.h:codecvt_byname ctor, then a second time when ~codecvt() is
automatically called to clean up the inherited class.
#include
#include
typedef std::codecvt_byname cvt_byname_t;
int main()
{
cvt_byname_t *cvt;
char name[] = "invalid-loc";
try {
cvt = new cvt_byname_t(name);
} catch (const std::runtime_error& re) {
std::cerr << "successfully catched misnamed locale" << std::endl;
}
}
-- System Information:
Debian Release: testing/unstable
APT prefers testing
APT policy: (500, 'testing')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.12-1-686
Locale: LANG=fr_FR.UTF-8, LC_CTYPE=fr_FR.UTF-8 (charmap=UTF-8)
Versions of packages libstdc++6-4.0-dev depends on:
ii g++-4.0 4.0.2-5The GNU C++ compiler
ii gcc-4.0-base 4.0.2-5The GNU Compiler Collection (base
ii libc6-dev 2.3.5-8GNU C Library: Development Librari
ii libstdc++64.0.2-5The GNU Standard C++ Library v3
libstdc++6-4.0-dev recommends no packages.
-- no debconf information
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#343108: idem with new cvt_byname_t(name, 1)
By the way using new cvt_byname_t(name,1) instead of new cvt_byname_t(name) does not change anything. Looks sensible since the suggested "double delete" explanation is a "locale" double delete, not a "facet" double delete. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#301746: [Bug target/23451] [3.4/4.0/4.1/4.2 regression] Redundant reloading from stack frame
On Tue, Jan 10, 2006 at 09:32:58PM -, steven at gcc dot gnu dot org wrote:
>
> --- Comment #6 from steven at gcc dot gnu dot org 2006-01-10 21:32
> ---
> Since GCC 3.2 also has this problem, contrary to what the reporter claims, I
> am
> not sure if we should keep this marked as a regression. Obviously it is a
> missed optimization, so the bug report is valid in that sense, and we should
> keep it open at least.
gcc-3.2 keeps the value in %esi and therefore avoids the problem:
.file "a.c"
.section.rodata.str1.1,"aMS",@progbits,1
.LC0:
.string "%.*s: bad variable name"
.text
.p2align 2,,3
.globl setvar
.type setvar,@function
setvar:
pushl %ebp
movl%esp, %ebp
pushl %edi
pushl %esi
pushl %ebx
subl$24, %esp
movl8(%ebp), %ebx
movl16(%ebp), %eax
movl12(%ebp), %esi
Only one load.
movl%eax, -16(%ebp)
pushl %ebx
callendofname
subl$8, %esp
pushl $61
pushl %eax
movl%eax, %edi
callstrchrnul
movl%eax, %edx
addl$32, %esp
subl%ebx, %edx
je .L3
cmpl%edi, %eax
jne .L3
xorl%edi, %edi
testl %esi, %esi
je .L7
movl%esi, %edi
cld
movl$-1, %ecx
xorl%eax, %eax
repnz
scasb
notl%ecx
leal-1(%ecx), %edi
.L5:
pushl %ecx
pushl %edx
pushl %ebx
leal2(%edi,%edx), %eax
pushl %eax
callmalloc
movl%eax, (%esp)
movl%eax, %ebx
callmempcpy
addl$16, %esp
testl %esi, %esi
je .L6
movb$61, (%eax)
pushl %edx
pushl %edi
pushl %esi
incl%eax
pushl %eax
callmempcpy
addl$16, %esp
.L6:
movb$0, (%eax)
orl $1, -16(%ebp)
movl-16(%ebp), %eax
movl%eax, 12(%ebp)
movl%ebx, 8(%ebp)
leal-12(%ebp), %esp
popl%ebx
popl%esi
popl%edi
leave
jmp setvareq
.p2align 2,,3
.L7:
orl $2, -16(%ebp)
jmp .L5
.L3:
pushl %esi
pushl %ebx
pushl %edx
pushl $.LC0
callsh_error
.Lfe1:
.size setvar,.Lfe1-setvar
.ident "GCC: (GNU) 3.2.3 (Debian)"
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#204687: closed by Debian FTP Masters (Bug#789156: Removed package(s) from unstable)
reopen 204687 reassign 204687 gcc quit On Tue, Jun 23, 2015 at 07:36:09AM +, Debian Bug Tracking System wrote: > This is an automatic notification regarding your Bug report > which was filed against the gcc-4.6,gcc-4.7 package: > > #204687: [PR 11877] gcc should use xor trick with -Os > > It has been closed by Debian FTP Masters . > > Their explanation is attached below along with your original report. > If this explanation is unsatisfactory and you have not received a > better one in a separate message then please contact Debian FTP Masters > by > replying to this email. Reopening as bug is still present. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150623074128.ga17...@gondor.apana.org.au
Bug#85535: closed by Debian FTP Masters (Bug#789156: Removed package(s) from unstable)
reopen 85535 reassign 85535 gcc quit On Tue, Jun 23, 2015 at 07:39:43AM +, Debian Bug Tracking System wrote: > This is an automatic notification regarding your Bug report > which was filed against the gcc,gcc-4.7 package: > > #85535: builtin memcmp() could be optimised > > It has been closed by Debian FTP Masters . > > Their explanation is attached below along with your original report. > If this explanation is unsatisfactory and you have not received a > better one in a separate message then please contact Debian FTP Masters > by > replying to this email. Reopening as bug is still present. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To UNSUBSCRIBE, email to debian-gcc-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150623074957.gb17...@gondor.apana.org.au
Bug#75773: closed by Debian FTP Masters (Bug#796274: Removed package(s) from unstable)
reopen 75773 reassign 75773 gcc quit On Fri, Aug 21, 2015 at 01:47:05PM +, Debian Bug Tracking System wrote: > > Dear submitter, > > as the package gcc-4.6 has just been removed from the Debian archive > unstable we hereby close the associated bug reports. We are sorry > that we couldn't deal with your issue properly. The bug still exists in gcc. -- Email: Herbert Xu Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#301746: gcc-3.4: Redundant reloading from stack frame
On Sun, Apr 03, 2005 at 04:28:22PM +0200, Matthias Klose wrote:
> please can you recheck with the gcc-4.0 package from experimental?
Thanks. Unfortunately it's still reloading it:
.L4:
movl-16(%ebp), %eax
First load
testl %eax, %eax
je .L12
subl$12, %esp
movl-16(%ebp), %eax
Reload
Cheers,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#85468: gcc is correct
reassign 85468 fping
notforwarded 85468
quit
It looks like I miscalculated the alignment of the source argument. Sorry
for the noise.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#94701: acknowledged by developer (Bug#94701: fixed in gcc-3.3 1:3.3ds9-1)
reopen 94701
quit
On Sat, May 17, 2003 at 04:51:55PM -0500, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> #94701: [PR optimization/2960] Duplicate loop conditions even with -Os,
> which was filed against the gcc-3.2 package.
>
> It has been closed by one of the developers, namely
> Matthias Klose <[EMAIL PROTECTED]>.
Although the upstream fix certainly seems to have corrected the
problem, gcc-3.3 -Os from unstable still generates basically the same
code with the dupliate test of %ebx against k:
a:
pushl %ebp
movl%esp, %ebp
pushl %ebx
movl8(%ebp), %ebx
cmpl%ebx, k
jge .L7
.L5:
callb
cmpl%ebx, k
jl .L5
.L7:
popl%ebx
leave
ret
.size a, .-a
.comm k,4,4
.ident "GCC: (GNU) 3.3 (Debian)"
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#85535: acknowledged by developer (Bug#85535: fixed in gcc-3.3 1:3.3ds9-1)
reopen 85535
quit
On Sat, May 17, 2003 at 04:51:38PM -0500, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> #85535: [fixed in gcc-3.1, PR optimization/3508]: builtin memcmp() could be
> optimised,
> which was filed against the gcc package.
>
> It has been closed by one of the developers, namely
> Matthias Klose <[EMAIL PROTECTED]>.
Unfortunately this bug has only been special cased rather than fixed
in its full generality. If we change one of the arguments to a
variable, the compiler still fails to produce the dword comparison
that I would expect:
-- a.c --
int foo(const char *s) {
return !memcmp("abcd", s, 4);
}
-- gcc -S -O2 a.c --
.LC0:
.string "abcd"
.text
.p2align 2,,3
.globl foo
.type foo, @function
foo:
pushl %ebp
movl%esp, %ebp
pushl %edi
pushl %esi
movl8(%ebp), %edi
movl$.LC0, %esi
movl$4, %ecx
cld
repz
cmpsb
sete%al
popl%esi
movzbl %al, %eax
popl%edi
leave
ret
.size foo, .-foo
.ident "GCC: (GNU) 3.3 20030509 (Debian prerelease)"
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#105309: acknowledged by developer (Bug#105309: fixed in gcc-3.3 1:3.3ds9-1)
reopen 105309
quit
On Sat, May 17, 2003 at 04:48:09PM -0500, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> #105309: [fixed in 3.3/HEAD: PR optimization/3995] i386 optimisation: joining
> tests,
> which was filed against the gcc-3.2 package.
>
> It has been closed by one of the developers, namely
> Matthias Klose <[EMAIL PROTECTED]>.
Thanks for your great work.
This bug is mostly fixed, but one small detail remains. The final
jump back to the leave+ret sequence is still there.
Since leave+ret is a two-byte sequence, it makes sense to replace the
jump with a leave+ret.
Here is the -S -O2 output with gcc 3.3:
foo:
pushl %ebp
movl%esp, %ebp
subl$8, %esp
cmpb$0, 8(%ebp)
jle .L2
calla
.L3:
leave
ret
.p2align 2,,3
.L2:
callb
jmp .L3
The last jmp should become
leave
ret
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#95318: acknowledged by developer (Bug#95318: fixed in gcc-3.3 1:3.3ds9-1)
reopen 95318
quit
On Sat, May 17, 2003 at 04:51:59PM -0500, Debian Bug Tracking System wrote:
> This is an automatic notification regarding your Bug report
> #95318: [fixed on 3.3/HEAD: PR optimization/2962] unnecessary cwtl,
> which was filed against the gcc-3.2 package.
>
> It has been closed by one of the developers, namely
> Matthias Klose <[EMAIL PROTECTED]>.
I appologise for all the reopening. Be rest assured that your efforts
in gettings these issues addressed is most appreciated.
Unfortunately as in other cases this bug hasn't been addressed in
full by the upstream. Although the cwtl instructions are gone, it has
been replaced by the equivalent mov?wl:
-- a.c --
#include
int a(short i) {
return i & 1;
}
int foo(int c) {
return isdigit(c);
}
--
-- gcc -S -O2 a.c --
a:
pushl %ebp
movl%esp, %ebp
movswl 8(%ebp),%eax
andl$1, %eax
leave
ret
...
foo:
pushl %ebp
movl%esp, %ebp
subl$8, %esp
call__ctype_b_loc
movl(%eax), %edx
movl8(%ebp), %eax
movzwl (%edx,%eax,2), %eax
andl$2048, %eax
leave
ret
.size foo, .-foo
.ident "GCC: (GNU) 3.3 20030509 (Debian prerelease)"
In both instances the extension (mov?wl) is unnecessary as
it is followed immediately by an and which zaps the high bits.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#194242: acknowledged by developer (Re: Bug#194242: drivers/atm/ambassador.c:301:21: pasting "." and "start" does not give a valid preprocessing token)
On Sun, May 25, 2003 at 01:51:03AM +, Brian M. Carlson wrote:
> reopen 194242
> reassign 194242 gcc
> retitle 194242 gcc: defaulting to 3.3 prevents compilation of the kernel
> merge 194242 194196
> thanks, control
>
> Then gcc 3.3 should not be the default gcc yet. Reassigning to
> gcc.
I disagree. These are not faults in gcc. The kernel will eventually
be changed to compile with 3.3. It's just that it hasn't happened yet.
I will be changing the Debian kernel-source to use gcc-3.2/gcc-2.95 on
i386 until it builds with 3.3.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#202017: gcc-3.3: Unnecessary branching with INET/INET6 port setting
On Sat, Jul 19, 2003 at 01:05:52PM +0200, Martin v. L?wis wrote:
> Falk Hueffner <[EMAIL PROTECTED]> writes:
>
> > This is not the problem. gcc assumes the asm will return the same
> > value unless it is explicitely marked "volatile" (or has no oputputs),
> > and will happily merge them.
>
> I see. Then this would be a glibc bug, for using __asm__ __volatile__
> in __bswap16.
Actually, I just checked my glibc (2.3.1) and it doesn't specify
__bswap16 as volatile:
#if defined __GNUC__ && __GNUC__ >= 2
# define __bswap_16(x) \
(__extension__ \
({ register unsigned short int __v, __x = (x); \
if (__builtin_constant_p (__x)) \
__v = __bswap_constant_16 (__x); \
else \
__asm__ ("rorw $8, %w0"\
: "=r" (__v) \
: "0" (__x) \
: "cc"); \
__v; }))
#else
/* This is better than nothing. */
# define __bswap_16(x) \
(__extension__ \
({ register unsigned short int __x = (x); __bswap_constant_16 (__x); }))
#endif
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Bug#218566: Compilation fails: Can you help with submitting a gcc bug?
reassign 218566 gcc
quit
On Sat, Nov 01, 2003 at 11:07:46AM +0200, Shaul Karl wrote:
> Package: kernel-source-2.6.0-test9
> Version: 2.6.0-test9-1
> Severity: important
> Justification: fails to build from source
>
> There is a compiler problem when compiling net/ipv4/tcp_minisocks.o.
> What other information can you suggests before submitting a gcc bug? The
> URL that is mentioned further below also mentions
>
> * the complete command line that triggers the bug; and
> * the preprocessed file (*.i*) that triggers the bug, generated
> * by adding -save-temps to the complete compilation command, or, in the
> case of a bug report for the GNAT front end, a complete set of
> source files (see below).
>
> However I don't know how to obtain it. I used fakeroot -- make-kpkg.
> Here is what I can see:
Try make V=1
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#218566: [BIO] Bounce queue in bio_add_page
On Fri, Nov 07, 2003 at 12:32:35PM +0100, Jens Axboe wrote:
> On Fri, Nov 07 2003, Herbert Xu wrote:
> > On Fri, Nov 07, 2003 at 12:25:55PM +0100, Jens Axboe wrote:
> > >
> > > Could be related, someone is doing an unlock on an already unlocked
> > > page. Is this the same system that saw the bounce problem initially?
> >
> > Yes, see http://bugs.debian.org/218566 for details.
>
> Then there's likely just some other bug wrt bouncing. Hmm, does this
> work?
>
> = mm/highmem.c 1.47 vs edited =
> --- 1.47/mm/highmem.c Thu Oct 9 15:03:32 2003
> +++ edited/mm/highmem.c Fri Nov 7 12:32:03 2003
> @@ -402,6 +402,8 @@
> to->bv_len = from->bv_len;
> to->bv_offset = from->bv_offset;
>
> + lock_page(to->bv_page);
> +
> if (rw == WRITE) {
> char *vto, *vfrom;
Hi Shaul:
Please check if this patch fixes your last crash.
Thanks,
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#219949: gcc: linux-2.6/sound/core/oss/rate.c miscompiled
On Mon, Nov 10, 2003 at 02:49:28PM +0100, Falk Hueffner wrote:
>
> The attachment seems corrupted, can you please resend it or put it
> somewhere?
Sure. I've just put it up at
http://gondor.apana.org.au/~herbert/bugs/rate.i.bz2
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Processed: your mail
reassign 221621 kernel-image-sparc-2.4
quit
On Wed, Nov 19, 2003 at 03:48:12PM -0600, Debian Bug Tracking System wrote:
> Processing commands for [EMAIL PROTECTED]:
>
> > reassign 221621 kernel-source-2.4.22
> Bug#221621: gcc-3.3: fails to compile the linux kernel
> Bug reassigned from package `gcc-3.3' to `kernel-source-2.4.22'.
Please reassign kernel bugs to the correct architecture.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Processed: your mail
On Wed, Nov 19, 2003 at 05:17:16PM -0500, Ben Collins wrote:
>
> But this is a bug in the kernel source, not in the sparc kernel package.
> Why should it be assigned to the kernel-image-sparc package when it has
> to be fixed in the kernel-source package?
The kernel-source package does not support any architectures apart
from alpha/i386. That's why we have architecture-specific patch packages
and maintainers.
The problem cited in this report is sparc-specific and does not affect
other architectures.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Processed: your mail
On Wed, Nov 19, 2003 at 06:14:30PM -0500, Ben Collins wrote:
>
> Just because the binaries are built somewhere else does not defer the
> fact that the bug is in the source. He's having a problem building the
> kernel-source package, and that has to be fixed there, not in
> kernel-image-sparc. Even if I put a patch in kernel-image-sparc, it
> doesn't fix his problem.
>
> Fact, kernel-image-sparc builds from kernel-source _without_ patches.
OK. I'm happy to do this as long as you don't mind any patch
conflicts as a result this should your architecture require
patches later on.
If you agree with that, please reassign the bug back to the 'kernel'
package.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Processed: your mail
reassign 221621 kernel
quit
On Wed, Nov 19, 2003 at 07:23:04PM -0500, Ben Collins wrote:
>
> > OK. I'm happy to do this as long as you don't mind any patch
> > conflicts as a result this should your architecture require
> > patches later on.
> >
> > If you agree with that, please reassign the bug back to the 'kernel'
> > package.
>
> I have no problem with that.
OK.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#95318: Not just cwtl
It seems that it's not just cwtl that gets used unnecessarily. The same
thing happens with out extension instructions, e.g., movzwl:
Disassembly of section .text:
:
#include
int foo(int c) {
0: 55 push %ebp
1: 89 e5 mov%esp,%ebp
return isdigit(c);
3: 8b 45 08mov0x8(%ebp),%eax
6: 8b 15 00 00 00 00 mov0x0,%edx
8: R_386_32 __ctype_b
c: 66 8b 04 42 mov(%edx,%eax,2),%ax
10: 25 00 08 00 00 and$0x800,%eax
15: 0f b7 c0movzwl %ax,%eax
}
18: 5d pop%ebp
19: c3 ret
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#106285: Please fix it in csh
unmerge 106285
reassign 106285 csh
severity 106285 serious
quit
Since the gcc maintainer has downgraded the bug, I'm reassigning it
back to csh since it is a bug preventing building and it can be easily
fixed in csh by not turning warnings into errors.
--
Debian GNU/Linux 2.2 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Re: Processed: Re: Bug#227894: No error when using older kernel
reassign 227894 valgrind
quit
On Sun, Jan 25, 2004 at 08:03:09AM -0800, Debian Bug Tracking System wrote:
> Processing commands for [EMAIL PROTECTED]:
>
> > reassign 227894 kernel-tree-2.6.0
> Bug#227894: g++ exceptions thrown -> valgrind signals invalid read
> Bug reassigned from package `g++' to `kernel-tree-2.6.0'.
valgrind needs to learn about the vsyscall page @ 0xe000.
--
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#259887: gcc-3.3: Miscompiles automatic dynamic arrays
On Sat, Jul 17, 2004 at 09:27:13AM +0200, Matthias Klose wrote:
>
> I assume the complete flags are -O2 -mpreferred-stack-boundary=2 ? Can
Sorry, yes that's what I used. The kernel adds a few more options like
-fomit-frame-pointer but it doesn't make any differences to the problem.
> you provide a workaround for the kernel source?
The simplest work around is to allocate things using kmalloc instead
of the stack. But I need to discuss it with the others first.
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
Bug#163422: g++-3.2 not compiled for Common C++ ABI!
Package: g++-3.2 Version: 1:3.2.1-0pre2 Severity: important see also http://gcc.gnu.org/gcc-3.2/c++-abi.html "g++-3.2 -v" outputs Reading specs from /usr/lib/gcc-lib/alpha-linux/3.2.1/specs Configured with: /build/buildd/gcc-3.2-3.2.1ds1/src/configure -v --enable-languages=c,c++,java,f77,proto,objc,ada --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.2 --enable-shared --with-system-zlib --enable-nls --without-included-gettext --enable-java-gc=boehm --enable-objc-gc alpha-linux Thread model: posix gcc version 3.2.1 20020912 (Debian prerelease) which definitely lacks "--enable-__cxa_atexit" fyi, other linux distributions (such as redhat-8.0) are using the common ABI convention, if debian does not, we'll suffer interoperability problems with shared C++ libs, and we'll render the whole Common C++ ABI efforts void :-( -- System Information Debian Release: testing/unstable Architecture: alpha Kernel: Linux s4addq 2.4.9-31 #1 Tue Feb 26 06:07:30 EST 2002 alpha Locale: LANG=C, LC_CTYPE=C Versions of packages g++-3.2 depends on: ii gcc-3.21:3.2.1-0pre2 The GNU C compiler. ii gcc-3.2-base 1:3.2.1-0pre2 The GNU Compiler Collection (base ii libc6.12.2.5-14.3GNU C Library: Shared libraries an ii libstdc++5-dev 1:3.2.1-0pre2 The GNU stdc++ library version 3 (
Bug#171411: bits/c++config.h incorrect wrt to existence of long double math.h extensions
Package: libstdc++5-dev Version: 1:3.2.1-0pre3 Severity: normal on debian/sparc /usr/include/c++/3.2/sparc-linux/bits/c++config.h states incorrectly the existence of long double c math functions, thus including causes the following kind of errors: [..] /usr/include/c++/3.2/cmath: In function `long double std::acos(long double)': /usr/include/c++/3.2/cmath:109: `::acosl' undeclared (first use here) /usr/include/c++/3.2/cmath: In function `long double std::asin(long double)': /usr/include/c++/3.2/cmath:127: `::asinl' undeclared (first use here) /usr/include/c++/3.2/cmath: In function `long double std::atan(long double)': /usr/include/c++/3.2/cmath:145: `::atanl' undeclared (first use here) /usr/include/c++/3.2/cmath: In function `long double std::atan2(long double, long double)': [..] and so on... regards, -- System Information Debian Release: testing/unstable Architecture: sparc Kernel: Linux fmadd 2.2.20 #1 Fri Nov 16 15:48:02 EST 2001 sparc Locale: LANG=C, LC_CTYPE=C Versions of packages libstdc++5-dev depends on: ii g++-3.21:3.2.1-0pre3 The GNU C++ compiler. ii gcc-3.2-base 1:3.2.1-0pre3 The GNU Compiler Collection (base ii libc6-dev 2.2.5-14.3GNU C Library: Development Librari ii libstdc++5 1:3.2.1-0pre3 The GNU stdc++ library version 3
Bug#171667: bits/c++config.h incorrect wrt to existence of long double math.h extensions
Package: libstdc++5-dev Version: 1:3.2.1-0pre3 Severity: normal (I'm resending this bug, since I'm not sure it went out the first time) on debian/sparc /usr/include/c++/3.2/sparc-linux/bits/c++config.h states incorrectly the existence of long double c math functions, thus including causes the following kind of errors: [..] /usr/include/c++/3.2/cmath: In function `long double std::acos(long double)': /usr/include/c++/3.2/cmath:109: `::acosl' undeclared (first use here) /usr/include/c++/3.2/cmath: In function `long double std::asin(long double)': /usr/include/c++/3.2/cmath:127: `::asinl' undeclared (first use here) /usr/include/c++/3.2/cmath: In function `long double std::atan(long double)': /usr/include/c++/3.2/cmath:145: `::atanl' undeclared (first use here) /usr/include/c++/3.2/cmath: In function `long double std::atan2(long double, long double)': [..] and so on... regards, -- System Information Debian Release: testing/unstable Architecture: sparc Kernel: Linux fmadd 2.2.20 #1 Fri Nov 16 15:48:02 EST 2001 sparc Locale: LANG=C, LC_CTYPE=C Versions of packages libstdc++5-dev depends on: ii g++-3.21:3.2.1-0pre3 The GNU C++ compiler. ii gcc-3.2-base 1:3.2.1-0pre3 The GNU Compiler Collection (base ii libc6-dev 2.2.5-14.3GNU C Library: Development Librari ii libstdc++5 1:3.2.1-0pre3 The GNU stdc++ library version 3 -- Herbert Valerio Riedel <[EMAIL PROTECTED]> SE/Linux LU
Bug#186788: g++-3.2: undefined reference to `__gxx_personality_v0' on parisc
Package: g++-3.2
Version: 1:3.2.3-0pre6
Severity: normal
$ apt-get install libsigc++-1.2-dev
$ echo 'int main() {}' > main.cc
$ g++-3.2 -O2 -Wall -o main main.cc -lsigc-1.2
/usr/lib/gcc-lib/hppa-linux/3.2.3/../../../libsigc-1.2.so: undefined
reference to `__gxx_personality_v0'
/usr/lib/gcc-lib/hppa-linux/3.2.3/../../../libsigc-1.2.so: undefined
reference to `_Unwind_Resume'
collect2: ld returned 1 exit status
$
...when using g++-3.0 instead of g++-3.2 there's no linker error...
same goes for linking libsigc-1.2.a with g++-3.2 statically...
-- System Information:
Debian Release: testing/unstable
Architecture: hppa
Kernel: Linux combt 2.4.20-pa13 #7 Wed Dec 18 20:52:56 CET 2002 parisc
Locale: LANG=C, LC_CTYPE=C
Versions of packages g++-3.2 depends on:
ii gcc-3.21:3.2.3-0pre6 The GNU C compiler
ii gcc-3.2-base 1:3.2.3-0pre6 The GNU Compiler Collection (base
ii libc6 2.3.1-16 GNU C Library: Shared libraries an
ii libstdc++5-dev 1:3.2.3-0pre6 The GNU Standard C++ Library v3 (d
-- no debconf information
Bug#458745: arm-only miscompilation of alloca code
On Wed, 2008-01-02 at 20:02 +0100, Martin Michlmayr wrote: > Herbert, do you think you could take a quick long at this bug report > before I forward it upstream to the GCC folks? well, I couldn't reproduce that on a Debian EABI system with ii gcc 4:4.2.2-1 The GNU C compiler ii libc6 2.7-5 GNU C Library: Shared libraries no segfaults here... :-/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#193830: g++-3.3: specialization of private members structs fails
Package: g++-3.3
Version: 1:3.3-2
Severity: normal
g++-3.3 fails to compile the following code (which would compile with
previous g++ versions):
$ cat in_class_class.cc
class Foo {
template struct InFoo;
};
template<>
struct Foo::InFoo {
// ...
};
$ g++ -c in_class_class.cc
in_class_class.cc:2: error: `template struct Foo::InFoo' is private
in_class_class.cc:6: error: within this context
$
-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux lfdux.ifs.tuwien.ac.at 2.4.20-1-k7 #1 Sat Mar 22 15:17:52 EST
2003 i686
Locale: LANG=C, LC_CTYPE=C
Versions of packages g++-3.3 depends on:
ii gcc-3.3 1:3.3-2The GNU C compiler
ii gcc-3.3-base 1:3.3-2The GNU Compiler Collection (base
ii libc6 2.3.1-17 GNU C Library: Shared libraries an
ii libstdc++5-3.3-dev1:3.3-2The GNU Standard C++ Library v3 (d
-- no debconf information
Bug#195264: libstdc++5-3.3-dev: forward template declarations in let inlining fail
Package: libstdc++5-3.3-dev
Version: 1:3.3-2
Severity: minor
I just noticed, that std::conj() doesn't get inlined, as one'd expect it
to be;
it seems that a forward declaration like
template complex<_Tp> conj(const complex<_Tp>&);
keeps
template
inline complex<_Tp>
conj(const complex<_Tp>& __z)
{ return complex<_Tp>(__z.real(), -__z.imag()); }
from honoring the 'inline' keyword at all;
by either removing the forward declaration completely, or adding the
inline keyword to it like:
template inline complex<_Tp> conj(const complex<_Tp>&);
g++ happily inlines the function again...
I don't know whether this is a bug at all (after all inline'ing is
optional... :-)...
-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux lfdux.ifs.tuwien.ac.at 2.4.20-1-k7 #1 Sat Mar 22 15:17:52 EST
2003 i686
Locale: LANG=C, LC_CTYPE=C
Versions of packages libstdc++5-3.3-dev depends on:
ii g++-3.3 1:3.3-2The GNU C++ compiler
ii gcc-3.3-base 1:3.3-2The GNU Compiler Collection (base
ii libc6-dev 2.3.1-17 GNU C Library: Development Librari
ii libstdc++51:3.3-2The GNU Standard C++ Library v3
-- no debconf information
Bug#195388: libstdc++5-3.3-dev: erase()ing end() not harmless
Package: libstdc++5-3.3-dev
Version: 1:3.3-2
Severity: normal
...according to TC++PL 3rd ed, section 17.4.1.7,
"Erasing end() is harmless."
but the following code either hangs or crashes when the end() iterator
is being passed to erase();
*** set_erase.cc
#include
#include
#include
int
main(int, char *[])
{
std::set s;
s.insert (1); s.insert (2);
s.insert (1); s.insert (2);
assert (s.count (1) == 1);
assert (s.count (2) == 1);
s.erase (1);
assert (s.count (1) == 0); assert (s.find (1) == s.end ());
assert (s.count (2) == 1); assert (s.find (2) != s.end ());
s.erase (s.find (2));
assert (s.count (2) == 0); assert (s.find (2) == s.end ());
s.erase (s.find (2)); // fails
assert (s.count (2) == 0); assert (s.find (2) == s.end ());
std::map m;
m[1] = 1;
m[2] = 2;
assert (m.count (2) != 0); assert (m.find (2) != m.end ());
m.erase (m.find (2));
assert (m.count (2) == 0); assert (m.find (2) == m.end ());
m.erase (m.find (2)); // fails
assert (m.count (2) == 0); assert (m.find (2) == m.end ());
}
-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux lfdux.ifs.tuwien.ac.at 2.4.20-1-k7 #1 Sat Mar 22 15:17:52 EST
2003 i686
Locale: LANG=C, LC_CTYPE=C
Versions of packages libstdc++5-3.3-dev depends on:
ii g++-3.3 1:3.3-2The GNU C++ compiler
ii gcc-3.3-base 1:3.3-2The GNU Compiler Collection (base
ii libc6-dev 2.3.1-17 GNU C Library: Development Librari
ii libstdc++51:3.3-2The GNU Standard C++ Library v3
-- no debconf information
Bug#195388:
...just found out, that this is a non-bug; please close this bug http://www.research.att.com/~bs/3rd_printing11.html > pg 489 replace "Erasing end() is harmless." by "A call m.erase(b,e) > where e is m.end() is harmless (provided b refers to an element of m > or is m.end()). However, a call m.erase(p) where p is m.end() is a > serious error that could corrupt the container." -- Herbert Valerio Riedel /Phone: (EUROPE) +43-1-58801-18840 Email: [EMAIL PROTECTED] /Finger [EMAIL PROTECTED] for GnuPG Public Key GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748 5F65 4981 E064 883F 4142
Bug#195468: g++-3.3: default construction fails when no explicit default constructor defined
Package: g++-3.3
Version: 1:3.3-2
Severity: normal
I'm not sure, whether this should work according to the ISO C++ specs or
not; IMHO it should work... :-)
$ cat static_var.cc
class bar {
public:
int operator()(int i) { return i; }
//bar (void) {} // default constructor
};
const bar b = bar (); // works always...
const bar b2; // fails if there is no explicit default constructor
$ g++ -c -O0 -Wall static_var.cc
static_var.cc:9: uninitialized const `b2'
$
if the commented out default constructor is enabled, compilation
succeeds...
-- System Information:
Debian Release: testing/unstable
Architecture: i386
Kernel: Linux lfdux.ifs.tuwien.ac.at 2.4.20-1-k7 #1 Sat Mar 22 15:17:52 EST
2003 i686
Locale: LANG=C, LC_CTYPE=C
Versions of packages g++-3.3 depends on:
ii gcc-3.3 1:3.3-2The GNU C compiler
ii gcc-3.3-base 1:3.3-2The GNU Compiler Collection (base
ii libc6 2.3.1-17 GNU C Library: Shared libraries an
ii libstdc++5-3.3-dev1:3.3-2The GNU Standard C++ Library v3 (d
-- no debconf information
Bug#195468: g++-3.3: default construction fails when no explicit default constructor defined
On Fri, 2003-05-30 at 22:08, Phil Edwards wrote:
> On Fri, May 30, 2003 at 09:26:32PM +0200, Herbert Valerio Riedel wrote:
> > $ cat static_var.cc
> >
> > class bar {
> > public:
> > int operator()(int i) { return i; }
> > //bar (void) {} // default constructor
> > };
> >
> > const bar b = bar (); // works always...
> > const bar b2; // fails if there is no explicit default constructor
> > $ g++ -c -O0 -Wall static_var.cc
> > static_var.cc:9: uninitialized const `b2'
> > $
> >
> > if the commented out default constructor is enabled, compilation
> > succeeds...
> Or if you declare b2 as non-const. This is not a bug.
I've reconsidered the problem;
now to me it looks, as if g++ behaves as if bar was a POD type (actually
the class defined above seems to qualify as POD type) since for those
cases, "const bar b2;" would really be uninitialized, since:
>A non-const POD object declared with no initializer has an
>"indeterminate initial value" [§8.5, ¶9].
thus compiling "const foo;" is sensible to fail...
but on the other hand, what 'indeterminate initial value' can there be,
if the struct doesn't contain any data member at all?!?
(fyi, 3 other c++ compilers I've tried compiled the code above
successfully...)
but, according to http://home.fnal.gov/~wb/POD.html, the following would
definitely not be a POD type:
class bar {}; // base class
class foo: public bar { // foo has a base class...
int m_int; // "protected non-static data member"
protected:
int m_int2; // "protected non-static data member"
public:
foo operator=(const foo &f) { return *this; } // "user-defined copy
//assignment operator"
~foo () {} // "user-defined destructor"
};
const foo b; // "error: uninitialized const `b'"
...and yet g++-3.[23] fails to compile this...
(btw...if I'd add a virtual function, or a user declared default
constructor, or some non-POD non-static data member, then the code would
compile...)
...so... is _still_ not a buggy behaviour??
regards,
--
Herbert Valerio Riedel /Phone: (EUROPE) +43-1-58801-18840
Email: [EMAIL PROTECTED] /Finger [EMAIL PROTECTED] for GnuPG Public
Key
GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748 5F65 4981 E064 883F 4142
Bug#195468: g++-3.3: default construction fails when no explicit default constructor defined
On Sat, 2003-05-31 at 10:35, Martin v. Löwis wrote:
> Herbert Valerio Riedel <[EMAIL PROTECTED]> writes:
> > ...so... is _still_ not a buggy behaviour??
>
> No. Look at 8.5/9:
>
> # If no initializer is specified for an object, and the object is of
> # (possibly cv-qualified) non-POD class type (or array thereof), the
> # object shall be default-initialized; if the object is of
> # const-qualified type, the underlying class type shall have a
> # user-declared default constructor.
[..]
# Otherwise, if no initializer is specified for anobject, the object
# and its subobjects, if any, have an indeterminate initial value; if
# the object or any of its subobjects are of const-qualified type, the
# program is ill-formed.
> Your objects have const-qualified type, and the underlying class has
> no user-declared default constructor, hence your program is
> ill-formed.
alright, then g++'s fault is to fail to recognize the ill-formed-ness of
at least the following cases, happily succeeds compiling them...:
struct foo {
virtual void f(void);
};
struct bar {
bar (); // user defined default constructor
};
struct doo {
bar m_bar; // non-POD member w/ u.d.d.c
};
struct zoo: public bar { }; // inherited u.d.d.c
const foo a_foo; // ill-formed - foo has no user-declared def-cons
const bar a_bar; // ok
const doo a_doo; // ill-formed - doo has no user-declared def-cons
const zoo a_zoo; // ill-formed? not sure about this one...
reagards,
--
Herbert Valerio Riedel /Phone: (EUROPE) +43-1-58801-18840
Email: [EMAIL PROTECTED] /Finger [EMAIL PROTECTED] for GnuPG Public
Key
GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748 5F65 4981 E064 883F 4142
Bug#193830: g++-3.3: specialization of private members structs fails
fyi,
gcc version 3.3.1 20030626 (Debian prerelease)
(aka '3.3.1-0pre0' in debian)
improves a bit on the situation:
class Foo {
template struct InFoo;
template struct InFoo2;
};
template<>
struct Foo::InFoo {
// ...this works now... (didn't work with 3.3.0)
};
template
struct Foo::InFoo2 {
// ...this still triggers error
};
regards,
--
Herbert Valerio Riedel /Phone: (EUROPE) +43-1-58801-18840
Email: [EMAIL PROTECTED] /Finger [EMAIL PROTECTED] for GnuPG Public
Key
GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748 5F65 4981 E064 883F 4142
Bug#195264: libstdc++5-3.3-dev: forward template declarations in let inlining fail
On Sun, 2003-06-29 at 12:51, Matthias Klose wrote:
> Please could you check, if the always_inline attribute (gcc-snapshot
> package) works for you?
I don't see why that'd help? (btw, it didn't work, tested with gcc
version 3.4 20030706 (experimental))
the problem is the following:
when compiling the following with -O2
template T foo(T);
template inline T foo(T t)
{
return t;
} // __attribute((always_inline))
long bar (long);
inline long bar (long l)
{
return l;
}
void doo (long &l)
{
l = foo (l);
l = bar (l);
}
Disassembly of section .text:
:
0: 55 push %ebp
1: 89 e5 mov%esp,%ebp
3: 53 push %ebx
4: 83 ec 10sub$0x10,%esp
7: 8b 5d 08mov0x8(%ebp),%ebx
a: ff 33 pushl (%ebx)
c: e8 fc ff ff ff call d
d: R_386_PC32 long foo(long)
11: 89 03 mov%eax,(%ebx)
13: 83 c4 10add$0x10,%esp
16: 8b 5d fcmov0xfffc(%ebp),%ebx
19: c9 leave
1a: c3 ret
Disassembly of section .gnu.linkonce.t._Z3fooIlET_S0_:
(long)>:
0: 55 push %ebp
1: 89 e5 mov%esp,%ebp
3: 8b 45 08mov0x8(%ebp),%eax
6: c9 leave
7: c3 ret
i.e. bar get's inlined, but foo does not... why?
btw, gcc-2.95 would optimize it into a NOP:
:
0: 55 push %ebp
1: 89 e5 mov%esp,%ebp
3: c9 leave
4: c3 ret
-- I'd say that's a regression...
>
> Herbert Valerio Riedel writes:
> > Package: libstdc++5-3.3-dev
> > Version: 1:3.3-2
> > Severity: minor
> >
> >
> > I just noticed, that std::conj() doesn't get inlined, as one'd expect it
> > to be;
> >
> > it seems that a forward declaration like
> >
> > template complex<_Tp> conj(const complex<_Tp>&);
> >
> > keeps
> >
> > template
> > inline complex<_Tp>
> > conj(const complex<_Tp>& __z)
> > { return complex<_Tp>(__z.real(), -__z.imag()); }
> >
> > from honoring the 'inline' keyword at all;
> > by either removing the forward declaration completely, or adding the
> > inline keyword to it like:
> >
> > template inline complex<_Tp> conj(const complex<_Tp>&);
> >
> > g++ happily inlines the function again...
> >
> > I don't know whether this is a bug at all (after all inline'ing is
> > optional... :-)...
> >
> > -- System Information:
> > Debian Release: testing/unstable
> > Architecture: i386
> > Kernel: Linux lfdux.ifs.tuwien.ac.at 2.4.20-1-k7 #1 Sat Mar 22 15:17:52 EST
> > 2003 i686
> > Locale: LANG=C, LC_CTYPE=C
> >
> > Versions of packages libstdc++5-3.3-dev depends on:
> > ii g++-3.3 1:3.3-2The GNU C++ compiler
> > ii gcc-3.3-base 1:3.3-2The GNU Compiler Collection
> > (base
> > ii libc6-dev 2.3.1-17 GNU C Library: Development
> > Librari
> > ii libstdc++51:3.3-2The GNU Standard C++ Library v3
> >
> > -- no debconf information
> >
> >
> >
> > --
> > To UNSUBSCRIBE, email to [EMAIL PROTECTED]
> > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
--
Herbert Valerio Riedel /Phone: (EUROPE) +43-1-58801-18840
Email: [EMAIL PROTECTED] /Finger [EMAIL PROTECTED] for GnuPG Public
Key
GnuPG Key Fingerprint: 7BB9 2D6C D485 CE64 4748 5F65 4981 E064 883F 4142
[Bug target/23451] [3.4/4.0/4.1/4.2 regression] Redundant reloading from stack frame
--- Comment #7 from herbert at gondor dot apana dot org dot au 2006-01-10 22:44 --- Subject: Re: [3.4/4.0/4.1/4.2 regression] Redundant reloading from stack frame On Tue, Jan 10, 2006 at 09:32:58PM -, steven at gcc dot gnu dot org wrote: > > --- Comment #6 from steven at gcc dot gnu dot org 2006-01-10 21:32 > --- > Since GCC 3.2 also has this problem, contrary to what the reporter claims, I > am > not sure if we should keep this marked as a regression. Obviously it is a > missed optimization, so the bug report is valid in that sense, and we should > keep it open at least. gcc-3.2 keeps the value in %esi and therefore avoids the problem: .file "a.c" .section.rodata.str1.1,"aMS",@progbits,1 .LC0: .string "%.*s: bad variable name" .text .p2align 2,,3 .globl setvar .type setvar,@function setvar: pushl %ebp movl%esp, %ebp pushl %edi pushl %esi pushl %ebx subl$24, %esp movl8(%ebp), %ebx movl16(%ebp), %eax movl12(%ebp), %esi Only one load. movl%eax, -16(%ebp) pushl %ebx callendofname subl$8, %esp pushl $61 pushl %eax movl%eax, %edi callstrchrnul movl%eax, %edx addl$32, %esp subl%ebx, %edx je .L3 cmpl%edi, %eax jne .L3 xorl%edi, %edi testl %esi, %esi je .L7 movl%esi, %edi cld movl$-1, %ecx xorl%eax, %eax repnz scasb notl%ecx leal-1(%ecx), %edi .L5: pushl %ecx pushl %edx pushl %ebx leal2(%edi,%edx), %eax pushl %eax callmalloc movl%eax, (%esp) movl%eax, %ebx callmempcpy addl$16, %esp testl %esi, %esi je .L6 movb$61, (%eax) pushl %edx pushl %edi pushl %esi incl%eax pushl %eax callmempcpy addl$16, %esp .L6: movb$0, (%eax) orl $1, -16(%ebp) movl-16(%ebp), %eax movl%eax, 12(%ebp) movl%ebx, 8(%ebp) leal-12(%ebp), %esp popl%ebx popl%esi popl%edi leave jmp setvareq .p2align 2,,3 .L7: orl $2, -16(%ebp) jmp .L5 .L3: pushl %esi pushl %ebx pushl %edx pushl $.LC0 callsh_error .Lfe1: .size setvar,.Lfe1-setvar .ident "GCC: (GNU) 3.2.3 (Debian)" Thanks, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23451 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[Bug target/23451] [3.4/4.0/4.1/4.2 regression] Redundant reloading from stack frame
--- Comment #14 from herbert at gondor dot apana dot org dot au 2006-01-10 23:25 --- Subject: Re: [3.4/4.0/4.1/4.2 regression] Redundant reloading from stack frame On Tue, Jan 10, 2006 at 10:58:03PM -, steven at gcc dot gnu dot org wrote: > > > --- Comment #8 from steven at gcc dot gnu dot org 2006-01-10 22:58 > --- > Unfortunately you're not showing your full command line, so I can only guess > what platform your host is and for what target you are compiling. I will > attach diffs between GCC 3.2 and GCC 3.3-hammer for i[456]86. To me the > changes look insignificant, but maybe you can point out what you're unhappy > with. Good point. I was using gcc-3.2 -S -O2 which for my build defaults to --march=i386. Indeed, using --march=i486 produces the same output as gcc-3.3/gcc-3.4. In fact, using --march=i386 on gcc-3.3/gcc-3.4 also removes the duplicate reloading. So it seems that it's really a difference between --march=i386 versus --march=i486. Cheers, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23451 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[Bug target/23451] [3.4/4.0/4.1/4.2 regression] Redundant reloading from stack frame
--- Comment #16 from herbert at gondor dot apana dot org dot au 2006-01-10 23:41 --- Subject: Re: [3.4/4.0/4.1/4.2 regression] Redundant reloading from stack frame On Tue, Jan 10, 2006 at 11:36:51PM -, steven at gcc dot gnu dot org wrote: > > So, closing as INVALID, i.e. not-a-bug. It's an interesting oddity though. > I've learned something again today :-) I still think this is an optimisation issue though since it should know not to reload something that's already in a register. Cheers, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23451 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[Bug target/23451] Redundant reloading from stack frame on i386
--- Comment #18 from herbert at gondor dot apana dot org dot au 2006-01-10 23:45 --- Subject: Re: Redundant reloading from stack frame on i386 On Tue, Jan 10, 2006 at 11:44:21PM -, steven at gcc dot gnu dot org wrote: > > > --- Comment #17 from steven at gcc dot gnu dot org 2006-01-10 23:44 > --- > Fair enough. I think it's highly unlikely that anyone would care enough about > i386 to worry about fixing this, but you never know. Actually the bug occurs when -march is i[456]86. It goes away with -mi386 :) >What|Removed |Added > > Status|RESOLVED|REOPENED > GCC target triplet|i486-*-*|i386-*-* So I think this needs to be reversed. Thanks, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23451 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
[Bug target/16601] [3.3 regression] miscompilation of automatic dynamic arrays in crypto/IPsec subsystems of the Linux kernel
--- Additional Comments From herbert at gondor dot apana dot org dot au 2004-07-17 19:30 --- I'm sorry but I got this wrong. The compiler is allocating 12 bytes of headroom unconditionally so it is actually safe. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16601 --- You are receiving this mail because: --- You reported the bug, or are watching the reporter.
