Bug#168086: optimization/9090: [3.2/3.3/3.4 regression?] arm ICE with >= -O2; regression from 2.95
Synopsis: [3.2/3.3/3.4 regression?] arm ICE with >= -O2; regression from 2.95 State-Changed-From-To: analyzed->closed State-Changed-By: rearnsha State-Changed-When: Tue Jan 28 09:45:00 2003 State-Changed-Why: This has been fixed on the trunk and both maintained release branches. http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9090
Bug#178790: gcc: internal error - cpp0 got fatal signal 11 - cc -O3 poll.c from perl5.8.0
Package: gcc Version: 2:2.95.4-14 Severity: important I was trying to locally build perl5.8.0 from the source. The compilation bailed out as follows: cp lib/IO/Seekable.pm ../../lib/IO/Seekable.pm /home/vassilii/src/perl-5.8.0/miniperl "-I../../lib" "-I../../lib" ../../lib/ExtUtils/xsubpp -typemap ../../lib/ExtUtils/typemap IO.xs > IO.xsc && mv IO.xsc IO.c cc -c -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DDEBIAN -O3 -DVERSION=\"1.20\" -DXS_VERSION=\"1.20\" -fpic "-I../.." IO.c cc -c -fno-strict-aliasing -I/usr/local/include -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -DDEBIAN -O3 -DVERSION=\"1.20\" -DXS_VERSION=\"1.20\" -fpic "-I../.." poll.c cc: Internal compiler error: program cpp0 got fatal signal 11 make[1]: *** [poll.o] Error 1 make[1]: Leaving directory `/home/vassilii/src/perl-5.8.0/ext/IO' make: *** [lib/auto/IO/IO.so] Error 2 For the record, my cc is indeed gcc 2.95.4-14: stalker:~> which cc /usr/bin/cc stalker:~> ls -l /usr/bin/cc lrwxrwxrwx1 root root 20 Nov 8 13:27 /usr/bin/cc -> /etc/alternatives/cc* stalker:~> ls -l /etc/alternatives/cc lrwxrwxrwx1 root root 12 Nov 8 13:27 /etc/alternatives/cc -> /usr/bin/gcc* stalker:~> dpkg -S /usr/bin/gcc gcc: /usr/bin/gcc When the optimization level is reduced from -O3 to -O2, the problem doesn't happen. (Debian-shipped perl5.6 is compiled with -O2, apparently for a reason). -- System Information Debian Release: 3.0 Architecture: i386 Kernel: Linux stalker.iGuide.co.il 2.4.18-bf2.4 #1 Son Apr 14 09:53:28 CEST 2002 i686 Locale: LANG=C, LC_CTYPE=C Versions of packages gcc depends on: ii cpp2:2.95.4-14 The GNU C preprocessor. ii cpp-2.95 1:2.95.4-11woody1 The GNU C preprocessor. ii gcc-2.95 1:2.95.4-11woody1 The GNU C compiler.
Bug#178596: {s390} operand out of range at assembly time when using -O2
On Monday 27 January 2003 14:51, Josselin Mouette wrote: > Package: gcc-3.2 > Version: 1:3.2.2-0pre3 > Severity: important > > There is a build regression of wmcoincoin on s390 between GCC 2.95 and > GCC 3.0, which is caused by the optimisation flags. See > http://buildd.debian.org/fetch.php?&pkg=wmcoincoin&ver=2.4.3c-1&arch=s390&s >tamp=1043265213&file=log&as=raw > > Using -O0 or -O1 gets the file to build correctly, while -O2 or -O3 > fails. > The preprocessed source can be found at > http://people.debian.org/~joss/wmcoincoin_failure.i > Hi, thanks for the complete info. This is a known bug that is already fixed in gcc 3.3. It could be backported only with a high effort. Since the problem occurs very seldom a backport is unlikely. Could you build your package with -01 for the time being? Regards, Gerhard
Bug#178596: {s390} operand out of range at assembly time when using -O2
Le mar 28/01/2003 à 19:11, Gerhard Tonn a écrit : > This is a known bug that is already fixed in gcc 3.3. It could be backported > only with a high effort. Since the problem occurs very seldom a backport is > unlikely. > > Could you build your package with -01 for the time being? No problem, I'll do that. Thanks for the info. Regards, -- .''`. Josselin Mouette/\./\ : :' : [EMAIL PROTECTED] `. `'[EMAIL PROTECTED] `- Debian GNU/Linux -- The power of freedom signature.asc Description: PGP signature
Processed: Re: Bug#178596: {s390} operand out of range at assembly time when using -O2
Processing commands for [EMAIL PROTECTED]:
> retitle 178596 [fixed in 3.3] {s390} operand out of range at assembly time
> when using -O2
Bug#178596: {s390} operand out of range at assembly time when using -O2
Changed Bug title.
> thanks
Stopping processing here.
Please contact me if you need assistance.
Debian bug tracking system administrator
(administrator, Debian Bugs database)
Bug#178830: {ia64} gcc-3.2 fails w/ optimization
Package: gcc-3.2
Version: 3.2.2-0pre6
Severity: important
On ia64, the attached, simple test program fails to link with
optimization turned on. Here's the output:
# gcc -O2 -o test test.c
/tmp/ccQCPFMM.o(.text+0xa0): In function `main':
: undefined reference to `.L13'
collect2: ld returned 1 exit status
Works w/o optimization or w/ gcc-2.96
--
Alex Williamson Linux Development Lab
[EMAIL PROTECTED] Hewlett Packard
970-898-9173 Fort Collins, CO#include
#include
int
main(int argc, char **argv)
{
int arg, value = 0;
printf("%s %d\n",argv[0], atoi(argv[1]));
arg = atoi(argv[1]);
switch (arg) {
case 0:
value += arg;
break;
case 1:
value += arg;
break;
case 2:
value += arg;
break;
case 3:
value += arg;
break;
case 4:
value += arg;
break;
default:
value = 0;
break;
}
printf("value = %d\n",value);
return 0;
}
Bug#178867: libstdc++5: shlibs depends >=1:3.2.1-1 - compiling against 3.2.2 breaks running against 3.2.1
Package: libstdc++5 Version: 1:3.2.2-0pre6 Severity: important libstdc++5.shlib declares a dependency of >=3.2.1-1. However, an application built against 3.2.2 doesn't appear to run if 3.2.1 is installed, giving /usr/lib/libstdc++.so.5: version `GLIBCPP_3.2.2' not found -- System Information Debian Release: testing/unstable Kernel Version: Linux vavatch 2.4.20-xfs #1 Sat Jan 25 03:01:49 GMT 2003 i686 unknown unknown GNU/Linux Versions of the packages libstdc++5 depends on: ii gcc-3.2-base 3.2.2-0pre6The GNU Compiler Collection (base package) ii libc6 2.3.1-10 GNU C Library: Shared libraries and Timezone ii libgcc13.2.2-0pre6GCC support library
[hppa-linux, gcc-3.2 regression] structure copy clobbers stores to substructure
>Submitter-Id: net
>Originator:Randolph Chung
>Organization: Debian
>Confidential: no
>Synopsis: Structure copy clobbers subsquent stores to structure
>Severity: serious
>Priority: medium
>Category: optimization
>Class: wrong-code
>Release: 3.2.2 20030124 (Debian prerelease)
>Environment:
System: Linux legolas 2.4.20-pa18 #110 Mon Jan 27 23:44:18 PST 2003 parisc
unknown unknown GNU/Linux
Architecture: parisc
host: hppa-unknown-linux-gnu
build: hppa-unknown-linux-gnu
target: hppa-unknown-linux-gnu
configured with: ../src/configure -v
--enable-languages=c,c++,f77,proto,pascal,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-__cxa_atexit
--enable-clocale=gnu --enable-objc-gc hppa-linux
>Description:
When -O2 is applied, the attach program generates incorrect output.
This test case is extracted from a miscompilation in the linux kernel.
The code does a structure copy then an assignment to a member of the
structure. At -O2 (-O1 -fschedule-insns) the assignment is moved before
the structure copy, and subsequently gets clobbered.
>How-To-Repeat:
Compile the following piece of code with gcc-3.2 -O2
/*
** Test to reproduce storing into a substructure getting
** clobbered by a structure copy.
**
** Compile with: gcc -O2 -o pty_test pty_test.c
*/
#include
#include
#include
#include
typedef unsigned char cc_t;
typedef unsigned int tcflag_t;
typedef unsigned int __kernel_size_t;
typedef int __kernel_ssize_t;
typedef unsigned short kdev_t;
struct termios {
tcflag_t c_iflag;
tcflag_t c_oflag;
tcflag_t c_cflag;
tcflag_t c_lflag;
cc_t c_line;
cc_t c_cc[19];
};
struct tty_driver {
int magic;
const char *driver_name;
const char *name;
int name_base;
short major;
short minor_start;
short num;
short type;
short subtype;
struct termios init_termios;
int flags;
int *refcount;
};
struct termios tty_std_termios = {1, 2, 3, 4, 5};
static int pty_refcount;
static struct tty_driver pty_driver;
int main(void)
{
memset(&pty_driver, 0, sizeof(struct tty_driver));
pty_driver.magic = 0x5402;
pty_driver.driver_name = "pty_master";
pty_driver.name = "pty";
pty_driver.major = 2;
pty_driver.minor_start = 0;
pty_driver.num = 256;
pty_driver.type = 0x0004;
pty_driver.subtype = 0x0001;
pty_driver.init_termios = tty_std_termios;
pty_driver.init_termios.c_iflag = 0;
pty_driver.init_termios.c_oflag = 0;
pty_driver.init_termios.c_cflag = 017 | 060 | 200;
pty_driver.init_termios.c_lflag = 0;
pty_driver.refcount = &pty_refcount;
pty_driver.flags = 0x0002 | 0x0004;
/* clobber the arg registers so the c_lflag value gets reloaded */
close(10);
printf("pty_driver.init_termios.c_lflag = %d (should be 0)\n",
pty_driver.init_termios.c_lflag);
return 0;
}
>Fix:
putting a reorder barrier (e.g. asm("")) before the store to
c_lflag will workaround the bug
