[Bug c/40909] New: GCC mis-optimizes GDB
GDB compiled with
x86_64-w64-mingw32-gcc (GCC) 4.5.0 20090726 (experimental)
doesn't work (refuses to load symbols for any executable).
This is happening because is_regular_file in gdb/source.c appears to be
mis-optimized (disabling optimization for that one file produces a working
GDB).
The source reads:
/* Return True if the file NAME exists and is a regular file */
static int
is_regular_file (const char *name)
{
struct stat st;
const int status = stat (name, &st);
/* Stat should never fail except when the file does not exist.
If stat fails, analyze the source of error and return True
unless the file does not exist, to avoid returning false results
on obscure systems where stat does not work as expected.
*/
if (status != 0)
return (errno != ENOENT);
return S_ISREG (st.st_mode);
}
Oprimized code is:
05d0 <_is_regular_file>:
5d0: 48 81 ec 98 00 00 00sub$0x98,%rsp
5d7: 48 8d 54 24 20 lea0x20(%rsp),%rdx
5dc: ff 15 00 00 00 00 callq *0x0(%rip)# 5e2
<_is_regular_file+0x12>
5de: R_X86_64_PC32 __imp___stat64
5e2: 85 c0 test %eax,%eax
5e4: 75 1d jne603 <_is_regular_file+0x33>
5e6: 0f b7 44 24 66 movzwl 0x66(%rsp),%eax
5eb: 25 00 f0 00 00 and$0xf000,%eax
5f0: 3d 00 80 00 00 cmp$0x8000,%eax
5f5: 0f 94 c0sete %al
5f8: 48 81 c4 98 00 00 00add$0x98,%rsp
5ff: 0f b6 c0movzbl %al,%eax
602: c3 retq
603: ff 15 00 00 00 00 callq *0x0(%rip)# 609
<_is_regular_file+0x39>
605: R_X86_64_PC32 __imp___errno
609: 83 38 02cmpl $0x2,(%rax)
60c: 0f 95 c0setne %al
60f: 48 81 c4 98 00 00 00add$0x98,%rsp
616: 0f b6 c0movzbl %al,%eax
619: c3 retq
Without optimization:
0e89 <_is_regular_file>:
e89: 55 push %rbp
e8a: 48 89 e5mov%rsp,%rbp
e8d: 48 83 ec 60 sub$0x60,%rsp
e91: 48 89 4d 10 mov%rcx,0x10(%rbp)
e95: 48 8d 45 c0 lea-0x40(%rbp),%rax
e99: 48 89 c2mov%rax,%rdx
e9c: 48 8b 4d 10 mov0x10(%rbp),%rcx
ea0: e8 00 00 00 00 callq ea5 <_is_regular_file+0x1c>
ea1: R_X86_64_PC32 _stat
ea5: 89 45 fcmov%eax,-0x4(%rbp)
ea8: 83 7d fc 00 cmpl $0x0,-0x4(%rbp)
eac: 74 16 je ec4 <_is_regular_file+0x3b>
eae: 48 8b 05 00 00 00 00mov0x0(%rip),%rax# eb5
<_is_regular_file+0x2c>
eb1: R_X86_64_PC32 __imp___errno
eb5: ff d0 callq *%rax
eb7: 8b 00 mov(%rax),%eax
eb9: 83 f8 02cmp$0x2,%eax
ebc: 0f 95 c0setne %al
ebf: 0f b6 c0movzbl %al,%eax
ec2: eb 17 jmpedb <_is_regular_file+0x52>
ec4: 0f b7 45 c6 movzwl -0x3a(%rbp),%eax
ec8: 0f b7 c0movzwl %ax,%eax
ecb: 25 00 f0 00 00 and$0xf000,%eax
ed0: 3d 00 80 00 00 cmp$0x8000,%eax
ed5: 0f 94 c0sete %al
ed8: 0f b6 c0movzbl %al,%eax
edb: c9 leaveq
edc: c3 retq
It appears that unoptimized code calls _stat, which jumps to _stat64i32, which
has this:
extern __inline__ int __attribute__((__cdecl__)) _stat64i32(const char
*_Name,struct _stat64i32 *_Stat)
{
struct _stat64 st;
int ret=_stat64(_Name,&st); // calls _imp___stat64
_Stat->st_dev=st.st_dev;
_Stat->st_ino=st.st_ino;
_Stat->st_mode=st.st_mode;
_Stat->st_nlink=st.st_nlink;
_Stat->st_uid=st.st_uid;
_Stat->st_gid=st.st_gid;
_Stat->st_rdev=st.st_rdev;
_Stat->st_size=(_off_t) st.st_size;
_Stat->st_atime=st.st_atime;
_Stat->st_mtime=st.st_mtime;
_Stat->st_ctime=st.st_ctime;
return ret;
}
whereas the optimized code calls into _imp__stat64 directly and doesn't perform
the _stat64 -> _stat64i32 transformation.
In the optimized case, immediately after _imp___stat64 returns:
(gdb) p/x st
$1 = {st_dev = 0x22a520, st_ino = 0x0, st_mode = 0x0, st_nlink = 0x4,
st_uid = 0x0, st_gid = 0x0, st_rdev = 0x68a4e5, st_size = 0x0,
st_atime = 0x7ff7fc35af9, st_mtime = 0x0, st_ctime = 0x1}
In the non-optimized case, immediately after _stat returns:
(gd
[Bug middle-end/40867] [4.5 Regression] FAIL: StackTrace2 output - source compiled test
--- Comment #3 from aph at gcc dot gnu dot org 2009-07-30 07:37 --- This regression in debuginfo seems to have been downgraded to P4, with no explanation or discussion of which I'm aware. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40867
[Bug target/40577] ICE on valid code: in extract_insn
--- Comment #6 from uros at gcc dot gnu dot org 2009-07-30 07:45 --- Subject: Bug 40577 Author: uros Date: Thu Jul 30 07:45:26 2009 New Revision: 150249 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150249 Log: PR target/40577 * config/alpha/alpha.c (alpha_expand_unaligned_store): Convert src to DImode when generating insq_le insn. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/config/alpha/alpha.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40577
[Bug target/40905] GCC creates invalid executable with auto-imported DLL and __attribute__((cold))
--- Comment #4 from dannysmith at users dot sourceforge dot net 2009-07-30 08:00 --- (In reply to comment #2) > > Is it possible that it triggers the exception trying to write in text.unlikely > which is READONLY? > Exactly. This is a linker, not a compiler issue. If you are using a relatively recent binutils and mingw run time, the addition of the switch -Wl,--enable-runtime-pseudo-reloc-v2 should get around the READONLY problem. Otherwise, you could always just add __declspec (dllimport) to extern int foo[2]; and so retain portability with the rest of the PE-COFF world. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40905
[Bug fortran/40881] warn for obsolescent features
--- Comment #3 from janus at gcc dot gnu dot org 2009-07-30 08:20 --- In principle warnings for obsolescent features are already there (cf. GFC_STD_F95_OBS). They are issued with -std=f95 or above, which does work e.g. for arithmetic if. However, there is no warning for alternate return (maybe others are missing as well). The warnings about deleted features can be turned off via -std=legacy, and are turned into errors by -std=f95 and above. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40881
[Bug c/40909] GCC mis-optimizes GDB
--- Comment #1 from ktietz at gcc dot gnu dot org 2009-07-30 08:38 --- Hmm, possibly this is a bug in our inline functions of mingw-w64. Does the switch -fno-strict-aliasing solves this issue, too? We have here struct casts, which maybe are reasoning here strict aliasing issues. Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40909
[Bug c/40910] New: -04 -fsee libgcc2.c
Computer Environment OS:FreeBSD 8.0 Beta 2 CPU:Intel Pentium 4 3.06GHz(HT Enabled) Mem:1.5GB(Memtest86+ Passed) Situation Installed from ports GCC 4.4.1 Recomplie from GCC 4.4.1 Compile flag /* CFLAGS= -fmudflapir -fsel-sched-pipelining-outer-loops -fsel-sched-pipelining -funsafe-loop-optimizations -fgcse-las -ftracer -O4 -pipe -mtune=pentium4 -fno-strict-aliasing -mmmx -msse -msse2 -mfpmath=both -ffast-math -fforce-addr -funroll-loops -frerun-loop-opt -frounding-math -fbranch-target-load-optimize2 -freciprocal-math -fassociative-math -fmodulo-sched -fira-coalesce -fsee */ Result libgcc2.c In Function '__divdi3': libgcc2.c:1098:Internal compile error: Segment fault: 11 -- Summary: -04 -fsee libgcc2.c Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: freebse at live dot jp GCC build triplet: 20090721 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40910
[Bug bootstrap/40894] [4.4 Regression] bootstrap4-lean failed crtfastmath.o comparision
--- Comment #2 from htl10 at users dot sourceforge dot net 2009-07-30 09:52 --- (In reply to comment #1) > There is no indication in this bug report of whether the issue also > appears for 4.5. If it does, please update the regression marker to > "4.4/4.5 Regression". I downloaded and tried the gcc-4.5-20090723 snapshot tar ball with make bootstrap-lean - it finished the building and comparison of the C compiler but failed later in libstdc++-v3 . I hope this get fixed by 4.4.2 if there is one. Meanwhile I'll check and possibly file the libstdc++-v3 issue. -- htl10 at users dot sourceforge dot net changed: What|Removed |Added Known to fail||4.4.0 4.4.1 Known to work||4.3.1 4.3.3 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40894
[Bug c/40909] GCC mis-optimizes GDB
--- Comment #2 from sezeroz at gmail dot com 2009-07-30 09:58 --- Hmm, with gcc-4.4.2 (branch rev. 150249), I always get "mode = 81ff" reported on the console with both -O0 and -O2 compiled exes from t.c test. This is with mingw-w64 headers and crt revision 1101, the exes cross-compiled from an i686-linux host. It ~may~ be a gcc-4.5 thing, but we don't know which revision of mingw-w64-crt and mingw-w64-headers the reporter used, either. -- sezeroz at gmail dot com changed: What|Removed |Added CC||sezeroz at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40909
[Bug c/40911] New: Strange type incompatibility is field initialization (type pointer to array)
Compiling file test.c using command: gcc -c test.c -o test.o
test.c
/* 01 */ int foo[] = { 0 };
/* 02 */
/* 03 */ int (*bar)[] = &foo;
/* 04 */
/* 05 */ struct {
/* 06 */int (*bar)[];
/* 07 */ } myStruct = {
/* 08 */.bar = &foo
/* 09 */ };
/* 10 */
>>> test.c
raises the following warning:
test.c:9: warning: initialization from incompatible pointer type
I don't understand why types are not compatible and what is strange is that
line #03 does not raise the same warning though variable 'bar' and field
'myStruct.bar' have excatly the same types and initialized with the same value.
===
gcc version info
===
$ avr-gcc --version
avr-gcc (GCC) 4.3.2
Copyright (C) 2008 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ avr-gcc -v
Using built-in specs.
Target: avr
Configured with: ../configure --prefix=/usr/local/CrossPack-AVR-20090415
--disable-dependency-tracking --disable-nls --disable-werror --target=avr
--enable-languages=c,c++ --disable-nls --disable-libssp --with-dwarf2
Thread model: single
gcc version 4.3.2 (GCC)
I have the same problem with other gcc versions, like :
==
os x gcc (4.2.1)
==
$ gcc-4.2 --version
i686-apple-darwin9-gcc-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5566)
Copyright (C) 2007 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ gcc-4.2 -v
Using built-in specs.
Target: i686-apple-darwin9
Configured with: /var/tmp/gcc_42/gcc_42-5566~1/src/configure --disable-checking
--enable-werror --prefix=/usr --mandir=/usr/share/man
--enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib
--build=i686-apple-darwin9 --with-gxx-include-dir=/usr/include/c++/4.0.0
--host=i686-apple-darwin9 --target=i686-apple-darwin9
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5566)
arm-elf-gcc (4.1.0)
$ arm-elf-gcc --version
arm-elf-gcc (GCC) 4.1.0
Copyright © 2006 Free Software Foundation, Inc.
Ce logiciel est libre; voir les sources pour les conditions de copie. Il n'y a
PAS
GARANTIE; ni implicite pour le MARCHANDAGE ou pour un BUT PARTICULIER.
$ arm-elf-gcc -v
Utilisation des specs internes.
Target: arm-elf
Configuré avec: ./configure --target=arm-elf --prefix=/usr/local/arm
--enable-interwork --enable-multilib --enable-languages=c,c++ --with-newlib
--with-headers=../../src/newlib-1.14.0/newlib/libc/include
Modèle de thread: single
version gcc 4.1.0
==
avr-gcc (4.2.0)
==
$ avr-gcc --version
avr-gcc (GCC) 4.2.0 20060701 (experimental)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
$ avr-gcc -v
Using built-in specs.
Target: avr
Configured with: ../configure --prefix=/Users/lobry/avr/avr-toolchain
--target=avr --enable-languages=c --disable-nls --disable-libssp
Thread model: single
gcc version 4.2.0 20060701 (experimental)
Best regards,
Olivier
--
Summary: Strange type incompatibility is field initialization
(type pointer to array)
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: olivier dot lobry at free dot fr
GCC build triplet: i386-apple-darwin8.10.1
GCC host triplet: i386-apple-darwin8.10.1
GCC target triplet: avr-unknown-none
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40911
[Bug libstdc++/40912] New: 4.5 weekly snapshot: failed to pre-compile bits/stdc++.h.gch/O2ggnu++0x.gch
I don't know if it is appropriate to file bugs against a snapshot... it is okay to close this if the issue was transient and a latter commit fixes the issue reported here. In the course of checking bug 40894 against current gcc code base I got the gcc-4.5-20090723 weekly snapshot tar ball. make bootstrap4-lean fails while precompiling the libstdc++ headers: -- make[3]: Entering directory `/home/htl10/tmp-build/obj45-dir/alphaev68-dec-osf5.1a/libstdc++-v3' Making all in include make[4]: Entering directory `/home/htl10/tmp-build/obj45-dir/alphaev68-dec-osf5.1a/libstdc++-v3/include' mkdir -p ./alphaev68-dec-osf5.1a/bits/stdc++.h.gch /home/htl10/tmp-build/obj45-dir/./gcc/xgcc -shared-libgcc -B/home/htl10/tmp-build/obj45-dir/./gcc -nostdinc++ -L/home/htl10/tmp-build/obj45-dir/alphaev68-dec-osf5.1a/libstdc++-v3/src -L/home/htl10/tmp-build/obj45-dir/alphaev68-dec-osf5.1a/libstdc++-v3/src/.libs -B/usr/local/alphaev68-dec-osf5.1a/bin/ -B/usr/local/alphaev68-dec-osf5.1a/lib/ -isystem /usr/local/alphaev68-dec-osf5.1a/include -isystem /usr/local/alphaev68-dec-osf5.1a/sys-include-x c++-header -g -O2 -mieee -I/home/htl10/tmp-build/obj45-dir/alphaev68-dec-osf5.1a/libstdc++-v3/include/alphaev68-dec-osf5.1a -I/home/htl10/tmp-build/obj45-dir/alphaev68-dec-osf5.1a/libstdc++-v3/include -I/home/htl10/tmp-build/gcc-4.5-20090723/libstdc++-v3/libsupc++ -O2 -g -std=gnu++0x /home/htl10/tmp-build/gcc-4.5-20090723/libstdc++-v3/include/precompiled/stdc++.h \ -o alphaev68-dec-osf5.1a/bits/stdc++.h.gch/O2ggnu++0x.gch In file included from /home/htl10/tmp-build/obj45-dir/alphaev68-dec-osf5.1a/libstdc++-v3/include/random:50:0, from /home/htl10/tmp-build/gcc-4.5-20090723/libstdc++-v3/include/precompiled/stdc++.h:102: /home/htl10/tmp-build/obj45-dir/alphaev68-dec-osf5.1a/libstdc++-v3/include/bits/random.h:1310:38: error: 'uint_fast32_t' was not declared in this scope /home/htl10/tmp-build/obj45-dir/alphaev68-dec-osf5.1a/libstdc++-v3/include/bits/random.h:1310:79: error: template argument 1 is invalid /home/htl10/tmp-build/obj45-dir/alphaev68-dec-osf5.1a/libstdc++-v3/include/bits/random.h:1310:79: error: '' is not a valid type for a template constant parameter /home/htl10/tmp-build/obj45-dir/alphaev68-dec-osf5.1a/libstdc++-v3/include/bits/random.h:1310:79: error: '' is not a valid type for a template constant parameter /home/htl10/tmp-build/obj45-dir/alphaev68-dec-osf5.1a/libstdc++-v3/include/bits/random.h:1310:79: error: '' is not a valid type for a template constant parameter /home/htl10/tmp-build/obj45-dir/alphaev68-dec-osf5.1a/libstdc++-v3/include/bits/random.h:1311:15: error: invalid type in declaration before ';' token /home/htl10/tmp-build/obj45-dir/alphaev68-dec-osf5.1a/libstdc++-v3/include/bits/random.h:1316:38: error: 'uint_fast32_t' was not declared in this scope /home/htl10/tmp-build/obj45-dir/alphaev68-dec-osf5.1a/libstdc++-v3/include/bits/random.h:1316:79: error: template argument 1 is invalid /home/htl10/tmp-build/obj45-dir/alphaev68-dec-osf5.1a/libstdc++-v3/include/bits/random.h:1316:79: error: '' is not a valid type for a template constant parameter /home/htl10/tmp-build/obj45-dir/alphaev68-dec-osf5.1a/libstdc++-v3/include/bits/random.h:1316:79: error: '' is not a valid type for a template constant parameter /home/htl10/tmp-build/obj45-dir/alphaev68-dec-osf5.1a/libstdc++-v3/include/bits/random.h:1316:79: error: '' is not a valid type for a template constant parameter /home/htl10/tmp-build/obj45-dir/alphaev68-dec-osf5.1a/libstdc++-v3/include/bits/random.h:1317:14: error: invalid type in declaration before ';' token /home/htl10/tmp-build/obj45-dir/alphaev68-dec-osf5.1a/libstdc++-v3/include/bits/random.h:1328:5: error: 'uint_fast32_t' was not declared in this scope /home/htl10/tmp-build/obj45-dir/alphaev68-dec-osf5.1a/libstdc++-v3/include/bits/random.h:1333:35: error: template argument 1 is invalid /home/htl10/tmp-build/obj45-dir/alphaev68-dec-osf5.1a/libstdc++-v3/include/bits/random.h:1333:35: error: '' is not a valid type for a template constant parameter /home/htl10/tmp-build/obj45-dir/alphaev68-dec-osf5.1a/libstdc++-v3/include/bits/random.h:1333:35: error: '' is not a valid type for a template constant parameter /home/htl10/tmp-build/obj45-dir/alphaev68-dec-osf5.1a/libstdc++-v3/include/bits/random.h:1333:35: error: '' is not a valid type for a template constant parameter /home/htl10/tmp-build/obj45-dir/alphaev68-dec-osf5.1a/libstdc++-v3/include/bits/random.h:1333:35: error: '' is not a valid type for a template constant parameter /home/htl10/tmp-build/obj45-dir/alphaev68-dec-osf5.1a/libstdc++-v3/include/bits/random.h:1333:35: error: '' is not a valid type for a template constant parameter /home/htl10/tmp-build/obj45-dir/alphaev68-dec-osf5.1a/libstdc++-v3/include/bits/random.h:1333:44: error: invalid type in declaration before ';' token /home/htl10/tmp-build/obj45-dir/alphaev68-dec-osf5.1a/libstdc++-v3/include/bits/random.h:1339:5: error: 'uint_fast64_t' was not declared in this scope
[Bug c/40910] -04 -fsee libgcc2.c
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-07-30 10:22 --- Don't use -fsee. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40910
[Bug c/40909] GCC mis-optimizes GDB
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-07-30 10:24 --- It indeed smells like a alias violation. Preprocessed source would help here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40909
[Bug bootstrap/38903] Bootstrap failure on Cygwin vs. libiberty.
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38903
[Bug middle-end/40867] [4.5 Regression] FAIL: StackTrace2 output - source compiled test
--- Comment #4 from joseph at codesourcery dot com 2009-07-30 11:24 --- Subject: Re: [4.5 Regression] FAIL: StackTrace2 output - source compiled test On Thu, 30 Jul 2009, aph at gcc dot gnu dot org wrote: > This regression in debuginfo seems to have been downgraded to P4, with no > explanation or discussion of which I'm aware. Java issues are not release-critical. Restore to P3 if you have a C or C++ test showing the problem. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40867
[Bug c/40911] Strange type incompatibility is field initialization (type pointer to array)
--- Comment #1 from jsm28 at gcc dot gnu dot org 2009-07-30 11:27 --- *** This bug has been marked as a duplicate of 36432 *** -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40911
[Bug c/36432] [4.2 Regression] �incompatible pointer type� with pointer to array as a struct member
--- Comment #8 from jsm28 at gcc dot gnu dot org 2009-07-30 11:27 --- *** Bug 40911 has been marked as a duplicate of this bug. *** -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added CC||olivier dot lobry at free ||dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36432
[Bug libstdc++/40912] 4.5 weekly snapshot: failed to pre-compile bits/stdc++.h.gch/O2ggnu++0x.gch
--- Comment #1 from paolo dot carlini at oracle dot com 2009-07-30 11:30 --- Why don't you just use SVN? Also, is this failure new, or not? As far as I know could even be months old... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40912
[Bug c/40910] -04 -fsee libgcc2.c
--- Comment #2 from manu at gcc dot gnu dot org 2009-07-30 11:34 --- Perhaps it would be better just to remove it in the next GCC 4.4 release (I guess it has been fixed/removed in GCC 4.5). Telling people not to use it after they discover it is broken is a bit useless. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40910
[Bug middle-end/40867] [4.5 Regression] FAIL: StackTrace2 output - source compiled test
--- Comment #5 from aph at gcc dot gnu dot org 2009-07-30 11:36 --- Hmm, this seems to me as a rather perverse interpretation of the rule that "Java issues are not release-critical": this bug may be manifested in Java programs, but there is no evidence of which I'm aware that this specifically is a Java issue. It seems to be coincident with the gimplify unit-at-a-time patch. I'll try to figure out what is going wrong. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40867
[Bug libstdc++/40912] 4.5 weekly snapshot: failed to pre-compile bits/stdc++.h.gch/O2ggnu++0x.gch
--- Comment #2 from htl10 at users dot sourceforge dot net 2009-07-30 11:49 --- (In reply to comment #1) > Why don't you just use SVN? Also, is this failure new, or not? As far as I > know > could even be months old... I am digging a hole for myself here - am currently building svn (and before that, openssl) just so that I can checkout the lastest gcc code instead of last week's snapshot :-(. I try to keep the system vanilla... The bug is reasonably new - 4.3.3 did work, and 4.4.1 worked as make (caveate bug 40894). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40912
[Bug regression/35671] GCC 4.4.x vs. 4.2.x performance regression
--- Comment #16 from manu at gcc dot gnu dot org 2009-07-30 12:02 --- (In reply to comment #8) > If anyone cares to repeat my test results, here's a simple test case: This is not a simple testcase. A simple testcase is a sufficiently small self-contained compilable code that shows the problem in a way that can be reliably and consistently reproduced. The ideal testcase would be the smallest possible still showing the problem but anything below 100 lines of preprocessed code is probably small enough. There are currently 3615 bugs opened. Many of them have simple testcases and some of them even provide what is the difference in the generated code that leads to worse performance. This problem report provides neither. Guess which one is more likely to be worked on. Each of the following steps increases the chances of getting a problem fixed: 1. Provide a self-contained testcase. 2. Provide a very small self-contained testcase. 3. Describe the differences in the generated code that leads to worse performance. 4. Find the exact flags that trigger the loss in performance. 5. Find the exact revision that introduced the loss in performance. 6. Find the exact code in GCC that contains the bug. (In reply to comment #9) > I hope GCC 4.5.0 will become sane again. You mean that you hope that your current problems get fixed by chance. If you cannot wait for the surprise, just grab a recent snapshot or current SVN trunk and check it out. Good luck! -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35671
[Bug libstdc++/40912] 4.5 weekly snapshot: failed to pre-compile bits/stdc++.h.gch/O2ggnu++0x.gch
--- Comment #3 from paolo dot carlini at oracle dot com 2009-07-30 12:41 --- Well, the file itself didn't *exist* in 4.3.x and 4.4.x... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40912
[Bug bootstrap/40788] [4.5 regression] ICE on sparc: tree check: expected class 'expression', have 'declaration' (var_decl) in gimplify_va_arg_expr, at builtins.c:5107
--- Comment #3 from laurent at guerby dot net 2009-07-30 12:42 --- Seen on sparc-linux as well on farm machine gcc54, so confirming on this platform. sparc64 (gccdoes work though. Last known successful bootstrap at revision 149705 First FAIL at revision 149748 ===X UPDATE === Fri Jul 17 17:27:37 CEST 2009 Updating SVN tree Ulibgomp/configure Ulibgomp/ChangeLog Ugcc/doc/extend.texi Ugcc/doc/gcc.texi Agcc/doc/implement-cxx.texi Ugcc/doc/service.texi Ugcc/tree-complex.c Ugcc/tree-loop-distribution.c Ugcc/DATESTAMP Ugcc/tree.c Ugcc/tree.h Ugcc/builtins.c Ugcc/fold-const.c Ugcc/omp-low.c Ugcc/objc/objc-act.c Ugcc/objc/ChangeLog Ugcc/real.h Ugcc/cgraphunit.c Ugcc/ChangeLog Agcc/testsuite/gcc.c-torture/compile/pr40321.c Ugcc/testsuite/gcc.dg/pr36902.c Ugcc/testsuite/gcc.dg/torture/builtin-math-6.c Ugcc/testsuite/gcc.dg/torture/builtin-math-5.c Ugcc/testsuite/ChangeLog Ugcc/testsuite/g++.old-deja/g++.brendan/overload8.C Ugcc/testsuite/g++.old-deja/g++.brendan/crash63.C Ugcc/testsuite/g++.old-deja/g++.brendan/crash64.C Ugcc/testsuite/g++.old-deja/g++.other/vaarg3.C Ugcc/testsuite/g++.old-deja/g++.pt/vaarg3.C Ugcc/testsuite/g++.dg/other/offsetof3.C Ugcc/testsuite/g++.dg/ext/has_nothrow_assign.C Ugcc/testsuite/g++.dg/ext/is_pod.C Ugcc/testsuite/g++.dg/ext/has_trivial_copy.C Ugcc/testsuite/g++.dg/ext/has_trivial_assign.C Ugcc/testsuite/g++.dg/ext/has_nothrow_copy-1.C Agcc/testsuite/g++.dg/opt/eh4.C Ugcc/testsuite/g++.dg/warn/var-args1.C Agcc/testsuite/g++.dg/cpp0x/trivial1.C Agcc/testsuite/g++.dg/cpp0x/std-layout1.C Ugcc/testsuite/g++.dg/gcov/gcov-2.C Agcc/testsuite/g++.dg/torture/pr40321.C Ugcc/testsuite/g++.dg/overload/ellipsis1.C Agcc/testsuite/g++.dg/template/ptrmem19.C Ugcc/testsuite/lib/target-supports.exp Ugcc/cp/typeck.c Ugcc/cp/init.c Ugcc/cp/class.c Ugcc/cp/decl.c Ugcc/cp/call.c Ugcc/cp/method.c Ugcc/cp/rtti.c Ugcc/cp/except.c Ugcc/cp/error.c Ugcc/cp/cvt.c Ugcc/cp/tree.c Ugcc/cp/mangle.c Ugcc/cp/cp-tree.h Ugcc/cp/ChangeLog Ugcc/cp/cp-gimplify.c Ugcc/cp/cxx-pretty-print.c Ugcc/cp/pt.c Ugcc/cp/semantics.c Ugcc/cp/parser.c Ugcc/tree-ssa-ccp.c Ugcc/modulo-sched.c Ugcc/tree-ssa-dom.c Ugcc/gimple-low.c Ugcc/expr.c Ugcc/tree-ssa-ifcombine.c Ugcc/c-decl.c Ugcc/fortran/trans-expr.c Ugcc/fortran/trans-array.c Ugcc/fortran/trans-openmp.c Ugcc/fortran/ChangeLog Ugcc/fortran/trans-stmt.c Ugcc/fortran/trans.c Ugcc/fortran/trans-io.c Ugcc/fortran/trans-decl.c Ugcc/fortran/trans-intrinsic.c Ugcc/stor-layout.c Ugcc/tree-if-conv.c Ugcc/c-typeck.c Ugcc/gimplify.c Ugcc/calls.c Ugcc/tree-ssa-pre.c Ugcc/tree-sra.c Ugcc/tree-mudflap.c Ugcc/tree-ssa-copy.c Ugcc/tree-ssa-forwprop.c Ugcc/c-convert.c Ugcc/c-omp.c Ugcc/varasm.c Ugcc/tree-inline.c Ugcc/c-common.c Ugcc/c-common.h Ugcc/Makefile.in Ugcc/gimple.c Ugcc/tree-switch-conversion.c Ugcc/gimple.h Ugcc/tree-cfg.c Ugcc/c-parser.c Ugcc/config/m32c/m32c.c Ugcc/convert.c Ulibstdc++-v3/python/libstdcxx/v6/printers.py Ulibstdc++-v3/configure Ulibstdc++-v3/include/std/type_traits Ulibstdc++-v3/ChangeLog Ulibstdc++-v3/testsuite/29_atomics/atomic_integral/cons/assign_neg.cc Ulibstdc++-v3/testsuite/29_atomics/atomic_integral/cons/copy_neg.cc Ulibstdc++-v3/testsuite/29_atomics/atomic/cons/assign_neg.cc Ulibstdc++-v3/testsuite/29_atomics/atomic/cons/copy_neg.cc Ulibstdc++-v3/testsuite/util/testsuite_common_types.h Ulibstdc++-v3/testsuite/20_util/make_signed/requirements/typedefs_neg.cc Ulibstdc++-v3/testsuite/20_util/make_unsigned/requirements/typedefs_neg.cc Ulibmudflap/configure Ulibmudflap/ChangeLog Uboehm-gc/configure.ac Uboehm-gc/ChangeLog Uboehm-gc/configure Uconfig/ChangeLog Uconfig/tls.m4 Ulibjava/ChangeLog Ulibjava/configure Updated to revision 149748. -- laurent at guerby dot net changed: What|Removed |Added CC||laurent at guerby dot net Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|sparc-sun-solaris2.11 |sparc-linux GCC host triplet|sparc-sun-solaris2.11 |sparc-linux GCC target triplet|sparc-sun-solaris2.11 |sparc-linux Keywords||ice-on-valid-code Last reconfirmed|-00-00 00:00:00 |2009-07-30 12:42:11 date|| Summary|[4.5 regression] ICE : tree |[4.5 regression] ICE on |check: expected class |sparc: t
[Bug ada/40637] Ada bootstrap ICE on stage3 s-bitops.o
--- Comment #3 from laurent at guerby dot net 2009-07-30 12:51 --- So confirmed. I'm now trying to identify the commit. -- laurent at guerby dot net changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-07-30 12:51:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40637
[Bug libstdc++/40912] 4.5 weekly snapshot: failed to pre-compile bits/stdc++.h.gch/O2ggnu++0x.gch
--- Comment #4 from htl10 at users dot sourceforge dot net 2009-07-30 12:57 --- (In reply to comment #3) > Well, the file itself didn't *exist* in 4.3.x and 4.4.x... Oh, indeed... have been trying to build subversion for the last few hours just so that I can try last night's instead of last week's gcc, and it is not funny... (the box itself is in the different country and time zone, and behind NAT in both directions... it is getting tempting to *wait* svn co here then *wait* scp two hoops over...). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40912
[Bug bootstrap/40894] [4.4 Regression] bootstrap4-lean failed crtfastmath.o comparision
--- Comment #3 from htl10 at users dot sourceforge dot net 2009-07-30 13:01 --- FYI, the libstdc++v3 issue with gcc 4.5 is filed as bug 40912 . So gcc 4.4/4.5 support are both a bit broken, just differently. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40894
[Bug target/38085] gcc -m64 -pg generates invalid assembler code on Solaris 10/x86
--- Comment #3 from bennett dot schneider at yahoo dot com 2009-07-30 13:06 --- internal_mcount's from and self arguments were reversed from glibc's version. Here's the full diff of gmon-sol2.c that produces correct output: --- gcc/config/i386/gmon-sol2.c.origWed Jul 29 08:57:15 2009 +++ gcc/config/i386/gmon-sol2.c Thu Jul 30 07:53:16 2009 @@ -66,7 +66,7 @@ extern void _mcleanup (void); extern void internal_mcount ( #ifdef __x86_64__ -char *, unsigned short * +unsigned short *, char * #else void #endif @@ -266,8 +266,8 @@ "\tmovq\t%r9,0x30(%rsp)\n" /* Get SELFPC (pushed by the call to this function) and FROMPCINDEX (via the frame pointer. */ -"\tmovq\t0x38(%rsp),%rdi\n" -"\tmovq\t0x8(%rbp),%rsi\n" +"\tmovq\t0x38(%rsp),%rsi\n" +"\tmovq\t0x8(%rbp),%rdi\n" "\tcallq\tinternal_mcount\n" /* Restore the saved registers. */ "\tmovq\t0x30(%rsp),%r9\n" @@ -275,7 +275,7 @@ "\tmovq\t0x20(%rsp),%rdi\n" "\tmovq\t0x18(%rsp),%rsi\n" "\tmovq\t0x10(%rsp),%rdx\n" -"\tmovq\t0x08(%rsp),%rdx\n" +"\tmovq\t0x08(%rsp),%rcx\n" "\tmovq\t(%rsp),%rax\n" "\taddq\t$0x38,%rsp\n" "\tretq\n" @@ -290,8 +290,8 @@ void internal_mcount ( #ifdef __x86_64__ -char *selfpc, -unsigned short *frompcindex +unsigned short *frompcindex, +char *selfpc #else void #endif -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38085
[Bug c/40913] New: hppa-hpux: libgcc_s.sl does not have the 'internal name' (=soname) set
On hppa-hpux (32bit SOM, and likely 64bit ELF), installed libgcc_s.sl is symlinked to libgcc_s.4, but does not have an 'internal name' (=soname) set. So binaries linked against libgcc_s.sl have "libgcc_s.sl" encoded as dependent library, while it should be "libgcc_s.4" instead. As a result, the runtime loader searches for "libgcc_s.0" first (which is a compatibility thingy by hpux) and "libgcc_s.sl" second, instead of "libgcc_s.4". AFAICS, gcc/config/pa/t-hpux-shlib should get something like this patch: SHLIB_LINK = $(GCC_FOR_TARGET) $(LIBGCC2_CFLAGS) -shared -nodefaultlibs \ +-Wl,+h -Wl,$(SHLIB_SONAME) \ -o $(SHLIB_DIR)/$(SHLIB_NAME).tmp @multilib_flags@ $(SHLIB_OBJS) && \ Or is there a reason to not set the 'internal name' I just didn't find? Thank you! -- Summary: hppa-hpux: libgcc_s.sl does not have the 'internal name' (=soname) set Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: michael dot haubenwallner at salomon dot at GCC build triplet: hppa2.0w-hp-hpux11.31 GCC host triplet: hppa2.0w-hp-hpux11.31 GCC target triplet: hppa2.0w-hp-hpux11.31 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40913
[Bug ada/40637] Ada bootstrap on powerpc64 ICE on stage3 s-bitops.o
--- Comment #4 from laurent at guerby dot net 2009-07-30 13:25 --- boot ok 148068 boot fail 149083 binary search running on gcc40 -- laurent at guerby dot net changed: What|Removed |Added Summary|Ada bootstrap ICE on stage3 |Ada bootstrap on powerpc64 |s-bitops.o |ICE on stage3 s-bitops.o http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40637
[Bug tree-optimization/40914] New: ipa_analyze_call_uses fails to handle ptrmemfunc_vbit_in_delta
The code in ipa_analyze_call_uses tries to wade through the gimple to identify uses of pointers to member functions that are invariant after inlining (due to parameter passing). However, the code only looks for the vbit test on the pointer part of the pmf not on the delta. On targets such as ARM all bits in the pointer are meaningful and the vbit is stored in the delta and the code scrubbing fails to match. Testcase is g++.dg/ipa/iinline-1.C On arm the relevant gimple looks like: f$__pfn_4 = f.__pfn; f$__delta_24 = f.__delta; __comp_ctor (&S, &"muhehehe"[0]); D.1787_3 = f$__delta_24 & 1; if (D.1787_3 != 0) goto ; else goto ; : D.1789_6 = f$__delta_24 >> 1; D.1790_7 = (unsigned int) D.1789_6; D.1791_8 = &S + D.1790_7; D.1792_9 = (int (*__vtbl_ptr_type) (void) * *) D.1791_8; D.1793_10 = *D.1792_9; D.1795_12 = (unsigned int) f$__pfn_4; D.1796_13 = D.1793_10 + D.1795_12; D.1797_14 = *D.1796_13; iftmp.0_15 = (String:: *) D.1797_14; : # iftmp.0_1 = PHI D.1789_18 = f$__delta_24 >> 1; D.1790_19 = (unsigned int) D.1789_18; D.1798_20 = &S + D.1790_19; D.1784_21 = iftmp.0_1 (D.1798_20, 4); -- Summary: ipa_analyze_call_uses fails to handle ptrmemfunc_vbit_in_delta Product: gcc Version: 4.4.2 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: rearnsha at gcc dot gnu dot org GCC target triplet: arm-eabi http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40914
[Bug c/40909] GCC mis-optimizes GDB
--- Comment #4 from ppluzhnikov at google dot com 2009-07-30 14:03 --- Created an attachment (id=18272) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18272&action=view) pre-processed t.c Some answers: The -fno-strict-aliasing does help: /usr/local/mingw-w64/bin/x86_64-w64-mingw32-gcc -g t.c -O2 -fno-strict-aliasing && ./a.exe mode = 81ff > which revision of mingw-w64-crt and mingw-w64-headers the reporter used For the record, I am just following up on GDB bug report from here: http://sourceware.org/ml/gdb-patches/2009-07/msg00634.html I did not build mingw-w64 myself, but used a snapshot build from here: http://sourceforge.net/projects/mingw-w64/files/Toolchains%20targetting%20Win64/Automated%20Builds/mingw-w64-bin_i686-cygwin-1.5.25-15_20090726.tar.bz2/download -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40909
[Bug tree-optimization/40744] SRA scalarizes dead objects, single-use objects
--- Comment #3 from jamborm at gcc dot gnu dot org 2009-07-30 14:18 --- Richi, not scalarizing things like the second foo() in the original bug description will inevitably lead to warning failures in g++.dg/warn/unit-1.C and gcc.dg/uninit-I.c. Is that OK? Should I remove or XFAIl them? (Structure copy-prop is being checked on gcc.dg/tree-ssa/sra-6, so that is safe.) Hopefully I will attach a patch here soon. Martin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40744
[Bug tree-optimization/40744] SRA scalarizes dead objects, single-use objects
--- Comment #4 from rguenther at suse dot de 2009-07-30 14:29 --- Subject: Re: SRA scalarizes dead objects, single-use objects On Thu, 30 Jul 2009, jamborm at gcc dot gnu dot org wrote: > --- Comment #3 from jamborm at gcc dot gnu dot org 2009-07-30 14:18 > --- > Richi, not scalarizing things like the second foo() in the original > bug description will inevitably lead to warning failures in > g++.dg/warn/unit-1.C and gcc.dg/uninit-I.c. Is that OK? Should I > remove or XFAIl them? XFAIL them. > (Structure copy-prop is being checked on gcc.dg/tree-ssa/sra-6, so > that is safe.) Good. > Hopefully I will attach a patch here soon. Thx. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40744
[Bug c/40909] GCC mis-optimizes GDB
--- Comment #5 from rguenth at gcc dot gnu dot org 2009-07-30 14:34 ---
Yep:
extern __inline__ int __attribute__((__cdecl__)) stat(const char
*_Filename,struct stat *_Stat) {
return _stat64i32(_Filename,(struct _stat64i32 *)_Stat);
}
that isn't going to fly.
struct stat {
_dev_t st_dev;
_ino_t st_ino;
unsigned short st_mode;
short st_nlink;
short st_uid;
short st_gid;
_dev_t st_rdev;
_off_t st_size;
time_t st_atime;
time_t st_mtime;
time_t st_ctime;
};
struct _stat64i32 {
_dev_t st_dev;
_ino_t st_ino;
unsigned short st_mode;
short st_nlink;
short st_uid;
short st_gid;
_dev_t st_rdev;
_off_t st_size;
__time64_t st_atime;
__time64_t st_mtime;
__time64_t st_ctime;
};
I suggest you mark _stat32i64 with attribute((may_alias)).
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution||INVALID
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40909
[Bug libstdc++/40915] New: [4.5 Regressions] FAIL: 18_support/headers/exception/synopsis.cc (test for excess errors)
Executing on host: /home/dave/gcc-4.5/objdir/./gcc/g++ -shared-libgcc -B/home/da ve/gcc-4.5/objdir/./gcc -nostdinc++ -L/home/dave/gcc-4.5/objdir/hppa-linux/libst dc++-v3/src -L/home/dave/gcc-4.5/objdir/hppa-linux/libstdc++-v3/src/.libs -B/hom e/dave/opt/gnu/gcc/gcc-4.5.0/hppa-linux/bin/ -B/home/dave/opt/gnu/gcc/gcc-4.5.0/ hppa-linux/lib/ -isystem /home/dave/opt/gnu/gcc/gcc-4.5.0/hppa-linux/include -is ystem /home/dave/opt/gnu/gcc/gcc-4.5.0/hppa-linux/sys-include -g -O2 -D_GLIBCXX_ ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOUR CE -g -O2 -D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++ -I/home/dave/gcc-4.5/obj dir/hppa-linux/libstdc++-v3/include/hppa-linux -I/home/dave/gcc-4.5/objdir/hppa- linux/libstdc++-v3/include -I/home/dave/gcc-4.5/gcc/libstdc++-v3/libsupc++ -I/ho me/dave/gcc-4.5/gcc/libstdc++-v3/include/backward -I/home/dave/gcc-4.5/gcc/libst dc++-v3/testsuite/util /home/dave/gcc-4.5/gcc/libstdc++-v3/testsuite/18_support/ headers/exception/synopsis.cc -S -o synopsis.s(timeout = 600) /home/dave/gcc-4.5/gcc/libstdc++-v3/testsuite/18_support/headers/exception/synop sis.cc:32: error: declaration of 'void std::terminate()' throws different except ions /home/dave/gcc-4.5/gcc/libstdc++-v3/libsupc++/exception:96: error: from previous declaration 'void std::terminate() throw ()' compiler exited with status 1 output is: /home/dave/gcc-4.5/gcc/libstdc++-v3/testsuite/18_support/headers/exception/synop sis.cc:32: error: declaration of 'void std::terminate()' throws different except ions /home/dave/gcc-4.5/gcc/libstdc++-v3/libsupc++/exception:96: error: from previous declaration 'void std::terminate() throw ()' FAIL: 18_support/headers/exception/synopsis.cc (test for excess errors) Excess errors: /home/dave/gcc-4.5/gcc/libstdc++-v3/testsuite/18_support/headers/exception/synop sis.cc:32: error: declaration of 'void std::terminate()' throws different except ions /home/dave/gcc-4.5/gcc/libstdc++-v3/libsupc++/exception:96: error: from previous declaration 'void std::terminate() throw ()' This appeared between revisions 146286 and 146460. It only occurs when I configure with --disable-libstdcxx-pch. d...@gsyprf11:~/gcc-4.5/objdir/gcc$ ./xgcc -B./ -v Reading specs from ./specs Target: hppa-linux Configured with: ../gcc/configure --with-gnu-as --with-gnu-ld --enable-shared --enable-nls --prefix=/home/dave/opt/gnu/gcc/gcc-4.5.0 --with-local-prefix=/home/dave/opt/gnu --enable-threads=posix --enable-__cxa_atexit --build=hppa-linux --enable-clocale=gnu --enable-java-gc=boehm --enable-java-awt=xlib --enable-languages=c,c++ --disable-bootstrap --disable-libstdcxx-pch Thread model: posix gcc version 4.5.0 20090420 (experimental) [trunk revision 146460] (GCC) -- Summary: [4.5 Regressions] FAIL: 18_support/headers/exception/synopsis.cc (test for excess errors) Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa-unknown-linux-gnu GCC host triplet: hppa-unknown-linux-gnu GCC target triplet: hppa-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40915
[Bug libstdc++/40915] [4.5 Regressions] FAIL: 18_support/headers/exception/synopsis.cc (test for excess errors)
--- Comment #1 from danglin at gcc dot gnu dot org 2009-07-30 14:55 --- 2009-04-18 Jan Hubicka * libsupc++/eh_type.cc (__cxa_current_exception_type) Mark throw(). * libsupc++/unwind-cxx.h (__cxa_get_globals, __cxa_get_globals_fast): Mark const. (__cxa_get_exception_ptr): Mark pure. (__cxa_bad_cast, __cxa_bad_typeid): Mark noreturn (__terminate): Makr throw (). * libsupc++/exception (terminate): Mark throw(). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40915
[Bug libstdc++/40915] [4.5 Regressions] FAIL: 18_support/headers/exception/synopsis.cc (test for excess errors)
--- Comment #2 from paolo dot carlini at oracle dot com 2009-07-30 15:05 --- Decorating the declaration in the testcase too would of course fix the problem in the trivial way. Now however, I'm rather worried by the fact itself that those decorations we are adding for optimization purposes can be *easily* detected, for example, in conformance suites too... Honza did you review the Standard already in order to make sure we are still strictly conforming in such cases?!? -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||paolo at gcc dot gnu dot ||org, jh at suse dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40915
[Bug libstdc++/40915] [4.5 Regressions] FAIL: 18_support/headers/exception/synopsis.cc (test for excess errors)
--- Comment #3 from paolo dot carlini at oracle dot com 2009-07-30 15:12 --- Ok, it's 17.4.4.8/1, we can proceed with the trivial patch. -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-07-30 15:12:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40915
[Bug libstdc++/40915] [4.5 Regressions] FAIL: 18_support/headers/exception/synopsis.cc (test for excess errors)
--- Comment #4 from paolo at gcc dot gnu dot org 2009-07-30 15:26 --- Subject: Bug 40915 Author: paolo Date: Thu Jul 30 15:26:44 2009 New Revision: 150260 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150260 Log: 2009-07-30 Paolo Carlini PR libstdc++/40915 * testsuite/18_support/headers/exception/synopsis.cc: Fix std::terminate declaration. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/18_support/headers/exception/synopsis.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40915
[Bug libstdc++/40915] [4.5 Regressions] FAIL: 18_support/headers/exception/synopsis.cc (test for excess errors)
--- Comment #5 from paolo dot carlini at oracle dot com 2009-07-30 15:28 --- Fixed. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40915
[Bug libstdc++/40912] 4.5 weekly snapshot: failed to pre-compile bits/stdc++.h.gch/O2ggnu++0x.gch
--- Comment #5 from paolo dot carlini at oracle dot com 2009-07-30 15:41 --- As a side note, I want to mention that we are very close to finally fixing c/448 for 4.5.0. Then, any problem related to will disappear. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40912
[Bug libstdc++/40912] 4.5 weekly snapshot: failed to pre-compile bits/stdc++.h.gch/O2ggnu++0x.gch
--- Comment #6 from htl10 at users dot sourceforge dot net 2009-07-30 15:58 --- (In reply to comment #5) > As a side note, I want to mention that we are very close to finally fixing > c/448 for 4.5.0. Then, any problem related to will disappear. What is 'c/448'? I have spent almost a day now trying to build svn or run one of the other java-based svn client without success. (just svn itself written making far many GNU assumptions, and no working jvm - including gij - on the platform), so I have downloaded the first 4.5, gcc-4.5-20090402, and try building it now. (I thought I would get when the code first entered the system, but it looks like the tar ball was same day but earlier.. oh well). at this rate the next tar ball is due out soon anyway... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40912
[Bug c/40910] -04 -fsee libgcc2.c
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-07-30 16:07 --- -fsee was removed on the trunk so closing as won't fix. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40910
[Bug lto/40903] LTO doesn't merge common sections properly
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-07-30 16:24 --- Subject: Bug 40903 Author: rguenth Date: Thu Jul 30 16:24:05 2009 New Revision: 150262 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150262 Log: 2009-07-30 Richard Guenther PR lto/40903 * lto-symtab.c (lto_symtab_compatible): Only warn for mismatched types. (lto_symtab_merge_decl): For decls we cannot merge chain them appropriately in the symtab entry. (lto_symtab_prevailing_decl): Return a matching entry from the symtab chain. * lto.c (read_cgraph_and_symbols): After fixing up decls choose the largest decl for output and free TREE_CHAIN for further use. * gcc.dg/lto/20090729_0.c: New testcase. * gcc.dg/lto/20090729_1.c: Likewise. Added: branches/lto/gcc/testsuite/gcc.dg/lto/20090729_0.c branches/lto/gcc/testsuite/gcc.dg/lto/20090729_1.c Modified: branches/lto/gcc/ChangeLog.lto branches/lto/gcc/lto-symtab.c branches/lto/gcc/lto/ChangeLog branches/lto/gcc/lto/lto.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40903
[Bug lto/40903] LTO doesn't merge common sections properly
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-07-30 16:24 --- Fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40903
[Bug lto/40903] LTO doesn't merge common sections properly
--- Comment #9 from rguenth at gcc dot gnu dot org 2009-07-30 16:25 --- , -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40903
[Bug libstdc++/40912] 4.5 weekly snapshot: failed to pre-compile bits/stdc++.h.gch/O2ggnu++0x.gch
--- Comment #7 from paolo dot carlini at oracle dot com 2009-07-30 16:26 --- Do you want something to click? PR448 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40912
[Bug tree-optimization/40570] [4.5 Regression] ICE with recursion at -O3
--- Comment #12 from jamborm at gcc dot gnu dot org 2009-07-30 16:26 --- Subject: Bug 40570 Author: jamborm Date: Thu Jul 30 16:26:09 2009 New Revision: 150263 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150263 Log: 2009-07-30 Martin Jambor PR tree-optimization/40570 * ipa-inline.c (cgraph_decide_inlining): Watch out for dead single use inlining loops. * testsuite/gcc.c-torture/compile/pr40570.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr40570.c Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-inline.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40570
[Bug libstdc++/40912] 4.5 weekly snapshot: failed to pre-compile bits/stdc++.h.gch/O2ggnu++0x.gch
--- Comment #8 from joseph at codesourcery dot com 2009-07-30 16:30 --- Subject: Re: 4.5 weekly snapshot: failed to pre-compile bits/stdc++.h.gch/O2ggnu++0x.gch On Thu, 30 Jul 2009, paolo dot carlini at oracle dot com wrote: > As a side note, I want to mention that we are very close to finally fixing > c/448 for 4.5.0. Then, any problem related to will disappear. We're still quite some way from that; I just sent a list of 14 target OSes that either need stdint.h information entered in GCC, or need to be deprecated. (This is down from 20 at the start of April: information has been added since then for Darwin, FreeBSD, HP-UX, Cygwin, MinGW and AIX.) http://gcc.gnu.org/ml/gcc/2009-07/msg00625.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40912
[Bug c/40910] -04 -fsee libgcc2.c
--- Comment #4 from steven at gcc dot gnu dot org 2009-07-30 16:36 --- And -O4 doesn't exist, FWIW. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40910
[Bug tree-optimization/40570] [4.5 Regression] ICE with recursion at -O3
--- Comment #13 from jamborm at gcc dot gnu dot org 2009-07-30 16:43 --- Fixed. -- jamborm at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40570
[Bug libstdc++/40912] 4.5 weekly snapshot: failed to pre-compile bits/stdc++.h.gch/O2ggnu++0x.gch
--- Comment #9 from htl10 at users dot sourceforge dot net 2009-07-30 16:54 --- (In reply to comment #7) > Do you want something to click? PR448 Oh, I didn't expect bug id that old to be relevant - I thought c/448 might be short for bug XX448 so I tried bug 40448 :-). (In reply to comment #8) > Subject: Re: 4.5 weekly snapshot: failed to pre-compile > bits/stdc++.h.gch/O2ggnu++0x.gch > > On Thu, 30 Jul 2009, paolo dot carlini at oracle dot com wrote: > > > As a side note, I want to mention that we are very close to finally fixing > > c/448 for 4.5.0. Then, any problem related to will disappear. > > We're still quite some way from that; I just sent a list of 14 target OSes > that either need stdint.h information entered in GCC, or need to be > deprecated. (This is down from 20 at the start of April: information has > been added since then for Darwin, FreeBSD, HP-UX, Cygwin, MinGW and AIX.) > > http://gcc.gnu.org/ml/gcc/2009-07/msg00625.html > I can't say about the others alpha*-dec-osf[45]*, but I can certainly give you alphaev68-dec-osf5.1a . How do you like this info? If you have a list to hunt for, or even a small test program which includes the various headers and print the numbers, I can do that... See as I seem to be the only one submitting testsuite results for alpha*-dec-osf[45]* beyond 4.1-ish, what is the qualification/requirement for OS porter/maintainer to take it off the deprecated list? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40912
[Bug c/40910] -04 -fsee libgcc2.c
--- Comment #5 from pinskia at gcc dot gnu dot org 2009-07-30 16:55 --- (In reply to comment #4) > And -O4 doesn't exist, FWIW. well it does but it is the same as -O3. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40910
[Bug c/39902] x * 1.0DF gets wrong value
--- Comment #3 from janis at gcc dot gnu dot org 2009-07-30 17:05 --- Subject: Bug 39902 Author: janis Date: Thu Jul 30 17:04:56 2009 New Revision: 150265 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150265 Log: PR c/39902 * gcc.dg/dfp/pr39902.c: Fix typos in constant suffixes. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/dfp/pr39902.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39902
[Bug tree-optimization/40744] SRA scalarizes dead objects, single-use objects
--- Comment #5 from jamborm at gcc dot gnu dot org 2009-07-30 17:07 --- Created an attachment (id=18273) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18273&action=view) Proposed patch The attached patch does turn SRA down a bit. Specifically, in order to create a replacement, the corresponding access (group) must either: - be read individually multiple times or - be read individually and also written to (either individually or through its parent) or - somehow accessed individually and be on the RHS of structure copy-prop link or - be read individually and be on the LHS of structure copy-prop link. (The bottom line is to avoid scalarizing accesses with only stores or just one read - and no stores. Another thing to be noted is that with this patch we also insist the access must be at least once read individually, not as a part of its parent to be scalarized.) I'm bootstrapping and testing this at the moment but only to find out that the testcase changes are OK, the last bootstrap with exactly these changes to tree-sra.c finished fine. I want to have benchmarks run on this, however, to make sure I do not do any harm. I expect to be benchmarking ipa-cp cloning the next couple of days and do this right afterwards, I guess early next week. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40744
[Bug c/39902] x * 1.0DF gets wrong value
--- Comment #4 from janis at gcc dot gnu dot org 2009-07-30 17:08 --- Subject: Bug 39902 Author: janis Date: Thu Jul 30 17:08:09 2009 New Revision: 150266 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150266 Log: PR c/39902 * gcc.dg/dfp/pr39902.c: Fix typos in constant suffixes. Modified: branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/gcc/testsuite/gcc.dg/dfp/pr39902.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39902
[Bug tree-optimization/40744] SRA scalarizes dead objects, single-use objects
--- Comment #6 from jamborm at gcc dot gnu dot org 2009-07-30 17:10 --- Created an attachment (id=18274) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18274&action=view) Proposed patch Well, apparently I forgot to run quilt refresh, this is the current patch with the testcase changes. -- jamborm at gcc dot gnu dot org changed: What|Removed |Added Attachment #18273|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40744
[Bug middle-end/40867] [4.5 Regression] FAIL: StackTrace2 output - source compiled test
--- Comment #6 from aph at gcc dot gnu dot org 2009-07-30 17:24 ---
This seems to be happening very early, because the very first tree dump shows:
StackTrace2$Inner.doCrash(java.lang.Object) (struct StackTrace2$Inner * this,
struct java.lang.Object * o)
[StackTrace2.java : 0:0] {
struct java.lang.Object * #ref#2#2.146;
struct
{
struct java.lang.Class * class;
void * methods[2];
} * D.1837;
void * * D.1838;
void * D.1839;
struct java.lang.String * java.lang.Object:: (struct java.lang.Object *)
* D.1840;
[StackTrace2.java : 34:0] {
void * #ref#1#0;
struct java.lang.Object * D.252;
void * #ref#2#2;
[StackTrace2.java : 33:0] D.252 = o;
[StackTrace2.java : 34:0] #ref#2#2 = D.252;
[StackTrace2.java : 34:0] #ref#2#2.146 = (struct java.lang.Object *)
#ref#2#2;
[StackTrace2.java : 34:0] D.1837 = #ref#2#2.146->vtable;
[StackTrace2.java : 34:0] D.1838 = &D.1837->methods[4];
...
All this code should be marked as Line 33, not line 34. I don't know
why this has changed recently.
--
aph at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |aph at gcc dot gnu dot org
|dot org |
Status|NEW |ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40867
[Bug libstdc++/40916] New: [4.5 Regression] FAIL: 23_containers/list/modifiers/swap/1.cc execution test
Executing on host: /home/dave/gcc-4.5/objdir/./gcc/g++ -shared-libgcc -B/home/da ve/gcc-4.5/objdir/./gcc -nostdinc++ -L/home/dave/gcc-4.5/objdir/hppa-linux/libst dc++-v3/src -L/home/dave/gcc-4.5/objdir/hppa-linux/libstdc++-v3/src/.libs -B/hom e/dave/opt/gnu/gcc/gcc-4.5.0/hppa-linux/bin/ -B/home/dave/opt/gnu/gcc/gcc-4.5.0/ hppa-linux/lib/ -isystem /home/dave/opt/gnu/gcc/gcc-4.5.0/hppa-linux/include -is ystem /home/dave/opt/gnu/gcc/gcc-4.5.0/hppa-linux/sys-include -g -O2 -D_GLIBCXX_ ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOUR CE -g -O2 -D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++ -I/home/dave/gcc-4.5/objdir/ hppa-linux/libstdc++-v3/include/hppa-linux -I/home/dave/gcc-4.5/objdir/hppa-linu x/libstdc++-v3/include -I/home/dave/gcc-4.5/gcc/libstdc++-v3/libsupc++ -I/home/d ave/gcc-4.5/gcc/libstdc++-v3/include/backward -I/home/dave/gcc-4.5/gcc/libstdc++ -v3/testsuite/util /home/dave/gcc-4.5/gcc/libstdc++-v3/testsuite/23_containers/l ist/modifiers/swap/1.cc ./libtestc++.a -Wl,--gc-sections -lm -o ./1.exe (timeout = 600) PASS: 23_containers/list/modifiers/swap/1.cc (test for excess errors) Setting LD_LIBRARY_PATH to :/home/dave/gcc-4.5/objdir/gcc:/home/dave/gcc-4.5/obj dir/hppa-linux/./libstdc++-v3/../libgomp/.libs:/home/dave/gcc-4.5/objdir/hppa-li nux/./libstdc++-v3/src/.libs::/home/dave/gcc-4.5/objdir/gcc:/home/dave/gcc-4.5/o bjdir/hppa-linux/./libstdc++-v3/../libgomp/.libs:/home/dave/gcc-4.5/objdir/hppa- linux/./libstdc++-v3/src/.libs 1.exe: /home/dave/gcc-4.5/gcc/libstdc++-v3/testsuite/23_containers/list/modifier s/swap/1.h:37: void swap11() [with _Tp = std::list]: Assertion `1 == swap_cal ls' failed. FAIL: 23_containers/list/modifiers/swap/1.cc execution test Doing a quick check with gdb, I find that the function to increment swap_calls, _ZNSt4listI1TSaIS0_EE4swapERS2_, is not being called. I don't have an exact revision as to when this fail started, but I know the test was not failing prior to the unit-at-a-time change. This fail only occurs with pch disabled: d...@gsyprf11:~/gcc-4.5/objdir/gcc$ ./xgcc -B./ -v Reading specs from ./specs Target: hppa-linux Configured with: ../gcc/configure --with-gnu-as --with-gnu-ld --enable-shared --enable-nls --prefix=/home/dave/opt/gnu/gcc/gcc-4.5.0 --with-local-prefix=/home/dave/opt/gnu --enable-threads=posix --enable-__cxa_atexit --build=hppa-linux --enable-clocale=gnu --enable-java-gc=boehm --enable-java-awt=xlib --enable-languages=c,c++ --disable-bootstrap --disable-libstdcxx-pch Thread model: posix gcc version 4.5.0 20090730 (experimental) [trunk revision 150259] (GCC) -- Summary: [4.5 Regression] FAIL: 23_containers/list/modifiers/swap/1.cc execution test Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa-unknown-linux-gnu GCC host triplet: hppa-unknown-linux-gnu GCC target triplet: hppa-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40916
[Bug debug/26475] tree-ssa loses line numbers for initializations (constants for PHIs)
--- Comment #5 from amacleod at redhat dot com 2009-07-30 18:40 --- I just checked in the code to track locations through PHI arguments. Comments and patch is located: http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01729.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26475
[Bug target/40916] [4.5 Regression] FAIL: 23_containers/list/modifiers/swap/1.cc execution test
--- Comment #1 from paolo dot carlini at oracle dot com 2009-07-30 18:43 --- A run-time failure which depends on PCHs being enabled or not, isn't a library issue. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Component|libstdc++ |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40916
[Bug fortran/38319] Memory leaks in allocatable component expressions
--- Comment #1 from burnus at gcc dot gnu dot org 2009-07-30 19:07 --- See also http://gcc.gnu.org/ml/fortran/2009-07/msg00260.html and PR 40899. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38319
[Bug fortran/40899] Leakage with derived types with ALLOCATABLE components
--- Comment #1 from burnus at gcc dot gnu dot org 2009-07-30 19:07 --- See PR 38319 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40899
[Bug libstdc++/40912] 4.5 weekly snapshot: failed to pre-compile bits/stdc++.h.gch/O2ggnu++0x.gch
--- Comment #10 from joseph at codesourcery dot com 2009-07-30 19:28 --- Subject: Re: 4.5 weekly snapshot: failed to pre-compile bits/stdc++.h.gch/O2ggnu++0x.gch On Thu, 30 Jul 2009, htl10 at users dot sourceforge dot net wrote: > I can't say about the others alpha*-dec-osf[45]*, but I can certainly give you > alphaev68-dec-osf5.1a . How do you like this info? If you have a list to hunt In the form of a patch submission following the documentation at http://gcc.gnu.org/contribute.html and in particular passing the c99-stdint-* testcases. > See as I seem to be the only one submitting testsuite results for > alpha*-dec-osf[45]* beyond 4.1-ish, what is the qualification/requirement for > OS porter/maintainer to take it off the deprecated list? It's not currently on a deprecation list, but maintainers of parts of the compiler will need to have a copyright assignment on file with the FSF and have submitted sufficient good patches to that part of the compiler to have been made maintainer by the SC. The requirement to avoid deprecation may be less than having a maintainer: monitor test results, send patches to fix issues that arise and other issues (such as this one) that need work for each OS and revise and ping patches as needed to get them in. Personally I think we should eliminate the mips-tdump and mips-tfile programs (which may mean making these targets work properly with the GNU assembler) but I haven't actually made a proposal to deprecate these targets in the absence of elimination of those programs. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40912
[Bug c/40909] GCC mis-optimizes GDB
--- Comment #6 from sezeroz at gmail dot com 2009-07-30 19:30 ---
(In reply to comment #5)
> Yep:
>
> extern __inline__ int __attribute__((__cdecl__)) stat(const char
> *_Filename,struct stat *_Stat) {
> return _stat64i32(_Filename,(struct _stat64i32 *)_Stat);
> }
>
> that isn't going to fly.
[...]
> I suggest you mark _stat32i64 with attribute((may_alias)).
Why does 4.4 not have any problem with this?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40909
[Bug libstdc++/40916] [4.5 Regression] FAIL: 23_containers/list/modifiers/swap/1.cc execution test
--- Comment #2 from paolo dot carlini at oracle dot com 2009-07-30 19:42 --- It's again a problem in the testcase. -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|UNCONFIRMED |ASSIGNED Component|target |libstdc++ Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-07-30 19:42:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40916
[Bug libstdc++/40917] New: FAIL: ext/array_allocator/check_delete.cc (test for excess errors)
Executing on host: /home/dave/gcc-4.5/objdir/./gcc/g++ -shared-libgcc -B/home/da ve/gcc-4.5/objdir/./gcc -nostdinc++ -L/home/dave/gcc-4.5/objdir/hppa-linux/libst dc++-v3/src -L/home/dave/gcc-4.5/objdir/hppa-linux/libstdc++-v3/src/.libs -B/hom e/dave/opt/gnu/gcc/gcc-4.5.0/hppa-linux/bin/ -B/home/dave/opt/gnu/gcc/gcc-4.5.0/ hppa-linux/lib/ -isystem /home/dave/opt/gnu/gcc/gcc-4.5.0/hppa-linux/include -is ystem /home/dave/opt/gnu/gcc/gcc-4.5.0/hppa-linux/sys-include -g -O2 -D_GLIBCXX_ ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2 -D_GNU_SOUR CE -g -O2 -D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++ -I/home/dave/gcc-4.5/objdir/ hppa-linux/libstdc++-v3/include/hppa-linux -I/home/dave/gcc-4.5/objdir/hppa-linu x/libstdc++-v3/include -I/home/dave/gcc-4.5/gcc/libstdc++-v3/libsupc++ -I/home/d ave/gcc-4.5/gcc/libstdc++-v3/include/backward -I/home/dave/gcc-4.5/gcc/libstdc++ -v3/testsuite/util /home/dave/gcc-4.5/gcc/libstdc++-v3/testsuite/ext/array_alloc ator/check_delete.cc ./libtestc++.a -Wl,--gc-sections -lm -o ./check_dele te.exe(timeout = 600) In file included from /home/dave/gcc-4.5/gcc/libstdc++-v3/testsuite/ext/array_al locator/check_delete.cc:24:0: /home/dave/gcc-4.5/gcc/libstdc++-v3/testsuite/util/replacement_memory_operators. h: In function 'bool __gnu_test::check_new(Alloc)': /home/dave/gcc-4.5/gcc/libstdc++-v3/testsuite/util/replacement_memory_operators. h:66:8: error: 'logic_error' is not a member of 'std' /home/dave/gcc-4.5/gcc/libstdc++-v3/testsuite/util/replacement_memory_operators. h: In function 'bool __gnu_test::check_delete(Alloc)': /home/dave/gcc-4.5/gcc/libstdc++-v3/testsuite/util/replacement_memory_operators. h:81:8: error: 'logic_error' is not a member of 'std' /home/dave/gcc-4.5/gcc/libstdc++-v3/testsuite/util/replacement_memory_operators. h: In function 'void* operator new(size_t)': /home/dave/gcc-4.5/gcc/libstdc++-v3/testsuite/util/replacement_memory_operators. h:88:37: error: 'printf' was not declared in this scope /home/dave/gcc-4.5/gcc/libstdc++-v3/testsuite/util/replacement_memory_operators. h: In function 'void operator delete(void*)': /home/dave/gcc-4.5/gcc/libstdc++-v3/testsuite/util/replacement_memory_operators. h:98:40: error: 'printf' was not declared in this scope compiler exited with status 1 output is: In file included from /home/dave/gcc-4.5/gcc/libstdc++-v3/testsuite/ext/array_al locator/check_delete.cc:24:0: /home/dave/gcc-4.5/gcc/libstdc++-v3/testsuite/util/replacement_memory_operators. h: In function 'bool __gnu_test::check_new(Alloc)': /home/dave/gcc-4.5/gcc/libstdc++-v3/testsuite/util/replacement_memory_operators. h:66:8: error: 'logic_error' is not a member of 'std' /home/dave/gcc-4.5/gcc/libstdc++-v3/testsuite/util/replacement_memory_operators. h: In function 'bool __gnu_test::check_delete(Alloc)': /home/dave/gcc-4.5/gcc/libstdc++-v3/testsuite/util/replacement_memory_operators. h:81:8: error: 'logic_error' is not a member of 'std' /home/dave/gcc-4.5/gcc/libstdc++-v3/testsuite/util/replacement_memory_operators. h: In function 'void* operator new(size_t)': /home/dave/gcc-4.5/gcc/libstdc++-v3/testsuite/util/replacement_memory_operators. h:88:37: error: 'printf' was not declared in this scope /home/dave/gcc-4.5/gcc/libstdc++-v3/testsuite/util/replacement_memory_operators. h: In function 'void operator delete(void*)': /home/dave/gcc-4.5/gcc/libstdc++-v3/testsuite/util/replacement_memory_operators. h:98:40: error: 'printf' was not declared in this scope FAIL: ext/array_allocator/check_delete.cc (test for excess errors) Similar fails: FAIL: ext/array_allocator/check_new.cc (test for excess errors) FAIL: ext/bitmap_allocator/check_delete.cc (test for excess errors) FAIL: ext/bitmap_allocator/check_new.cc (test for excess errors) FAIL: ext/debug_allocator/check_delete.cc (test for excess errors) AIL: ext/debug_allocator/check_new.cc (test for excess errors) FAIL: ext/malloc_allocator/check_delete.cc (test for excess errors) FAIL: ext/malloc_allocator/check_new.cc (test for excess errors) FAIL: ext/malloc_allocator/deallocate_global.cc (test for excess errors) FAIL: ext/malloc_allocator/deallocate_local.cc (test for excess errors) FAIL: ext/mt_allocator/check_delete.cc (test for excess errors) FAIL: ext/mt_allocator/check_new.cc (test for excess errors) FAIL: ext/new_allocator/deallocate_global.cc (test for excess errors) FAIL: ext/new_allocator/deallocate_local.cc (test for excess errors) FAIL: ext/pool_allocator/check_delete.cc (test for excess errors) FAIL: ext/pool_allocator/check_new.cc (test for excess errors) These occur building with pch disabled. -- Summary: FAIL: ext/array_allocator/check_delete.cc (test for excess errors) Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org http://gcc.gnu.org/
[Bug libstdc++/40917] FAIL: ext/array_allocator/check_delete.cc (test for excess errors)
-- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-07-30 20:07:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40917
[Bug c++/40918] New: uncaught_exception() returns wrong (inverted) value if some exception have crossed a DLL boundary before
I was not able to reproduce the bug on Linux, so I assume this is a
Windows-specific.
If an exception is generated inside shared library (DLL), then crosses the
DLL-boundary and gets caught in some other module, the std::uncaught_exception
will always return wrong (inverted) value from now on. Here's a small test
case.
The DLL (throw.dll) contains just a single function that throws an exception:
throw.cpp
~
void do_throw(void)
{
throw("");
}
The test program (test.exe) is linked against throw.dll:
test.cpp
#include
#include
bool b;
void do_throw(void);
struct UE
{
~UE()
{
b = std::uncaught_exception();
}
};
int main(void)
{
try
{
do_throw();
}
catch (...)
{
}
try
{
UE ue;
throw "";
}
catch (...)
{
}
std::cout << "Expecting 'true', got " << (b ? "'true'" : "'false'") <<
std::endl;
{
UE ue;
}
std::cout << "Expecting 'false', got " << (b ? "'true'" : "'false'") <<
std::endl;
return 0;
}
test.exe produces the following output:
C:\TEMP\bug>test.exe
Expecting 'true', got 'false'
Expecting 'false', got 'true'
If we comment out the call to do_throw(), std::uncaught_exception will work as
expected. If we put do_throw() in a statically linked module,
std::uncaught_exception will work as expected as well.
--
Summary: uncaught_exception() returns wrong (inverted) value if
some exception have crossed a DLL boundary before
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: andriys at gmail dot com
GCC host triplet: mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40918
[Bug c++/40918] uncaught_exception() returns wrong (inverted) value if some exception have crossed a DLL boundary before
--- Comment #1 from andriys at gmail dot com 2009-07-30 20:22 --- Created an attachment (id=18275) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18275&action=view) Test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40918
[Bug libstdc++/40094] FAIL: ext/throw_allocator/deallocate_global.cc execution test
--- Comment #22 from danglin at gcc dot gnu dot org 2009-07-30 20:23 --- The following two tests also fail on hppa2.0w-hp-hpux11.11: FAIL: ext/new_allocator/deallocate_global.cc execution test FAIL: ext/throw_allocator/deallocate_global.cc execution test -- danglin at gcc dot gnu dot org changed: What|Removed |Added GCC build triplet|hppa64-hp-hpux11.11 |hppa*-hp-hpux* GCC host triplet|hppa64-hp-hpux11.11 |hppa*-hp-hpux* GCC target triplet|hppa64-hp-hpux11.11 |hppa*-hp-hpux* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40094
[Bug libstdc++/40919] New: FAIL: 26_numerics/headers/cmath/c99_classification_macros_c.cc
Here is another testsuite issue: Executing on host: /Users/dave/gnu/gcc/objdir/./gcc/g++ -shared-libgcc -B/Users/ dave/gnu/gcc/objdir/./gcc -nostdinc++ -L/Users/dave/gnu/gcc/objdir/i686-apple-da rwin9/libstdc++-v3/src -L/Users/dave/gnu/gcc/objdir/i686-apple-darwin9/libstdc++ -v3/src/.libs -B/opt/gnu/gcc/gcc-4.5.0/i686-apple-darwin9/bin/ -B/opt/gnu/gcc/gc c-4.5.0/i686-apple-darwin9/lib/ -isystem /opt/gnu/gcc/gcc-4.5.0/i686-apple-darwi n9/include -isystem /opt/gnu/gcc/gcc-4.5.0/i686-apple-darwin9/sys-include -g -O2 -D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -g -O2 -g -O2 -DLOCALEDIR="." -nostdinc++ -I/Users/dave/gnu/gcc/objdir/i686-apple-darw in9/libstdc++-v3/include/i686-apple-darwin9 -I/Users/dave/gnu/gcc/objdir/i686-ap ple-darwin9/libstdc++-v3/include -I/Users/dave/gnu/gcc/gcc/libstdc++-v3/libsupc+ + -I/Users/dave/gnu/gcc/gcc/libstdc++-v3/include/backward -I/Users/dave/gnu/gcc/ gcc/libstdc++-v3/testsuite/util /Users/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/2 6_numerics/headers/cmath/c99_classification_macros_c.cc -S -o c99_classific ation_macros_c.s(timeout = 600) /Users/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_cla ssification_macros_c.cc:39:16: error: macro "isgreater" requires 2 arguments, bu t only 1 given /Users/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_cla ssification_macros_c.cc:41:21: error: macro "isgreaterequal" requires 2 argument s, but only 1 given /Users/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_cla ssification_macros_c.cc:43:13: error: macro "isless" requires 2 arguments, but o nly 1 given /Users/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_cla ssification_macros_c.cc:45:18: error: macro "islessequal" requires 2 arguments, but only 1 given /Users/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_cla ssification_macros_c.cc:47:20: error: macro "islessgreater" requires 2 arguments , but only 1 given /Users/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_cla ssification_macros_c.cc:49:18: error: macro "isunordered" requires 2 arguments, but only 1 given /Users/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_cla ssification_macros_c.cc:27:6: error: expected unqualified-id before 'sizeof' /Users/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_cla ssification_macros_c.cc:27:6: error: expected ')' before 'sizeof' /Users/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_cla ssification_macros_c.cc:29:6: error: expected unqualified-id before 'sizeof' /Users/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_cla ssification_macros_c.cc:29:6: error: expected ')' before 'sizeof' /Users/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_cla ssification_macros_c.cc:31:6: error: expected unqualified-id before 'sizeof' /Users/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_cla ssification_macros_c.cc:31:6: error: expected ')' before 'sizeof' /Users/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_cla ssification_macros_c.cc:33:6: error: expected unqualified-id before 'sizeof' /Users/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_cla ssification_macros_c.cc:33:6: error: expected ')' before 'sizeof' /Users/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_cla ssification_macros_c.cc:35:6: error: expected unqualified-id before 'sizeof' /Users/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_cla ssification_macros_c.cc:35:6: error: expected ')' before 'sizeof' /Users/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_cla ssification_macros_c.cc:37:6: error: expected unqualified-id before 'sizeof' /Users/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_cla ssification_macros_c.cc:37:6: error: expected ')' before 'sizeof' /Users/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_cla ssification_macros_c.cc:39:6: error: variable or field 'isgreater' declared void /Users/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_cla ssification_macros_c.cc:39:6: warning: extended initializer lists only available with -std=c++0x or -std=gnu++0x /Users/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_cla ssification_macros_c.cc:43:6: error: variable or field 'isless' declared void /Users/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_cla ssification_macros_c.cc:43:6: warning: extended initializer lists only available with -std=c++0x or -std=gnu++0x /Users/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_cla ssification_macros_c.cc:47:6: error: variable or field 'islessgreater' declared void /Users/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_cla ssification_mac
[Bug libstdc++/40919] FAIL: 26_numerics/headers/cmath/c99_classification_macros_c.cc
--- Comment #1 from paolo dot carlini at oracle dot com 2009-07-30 20:38 --- In general, this one must be just xfailed, can pass by chance with PCHs. Can you please tweak the dg lines at the beginning of the testcase and make sure it's actually xfailed for this target too? Patch preapproved, thanks. -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |danglin at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-07-30 20:38:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40919
[Bug libstdc++/40919] FAIL: 26_numerics/headers/cmath/c99_classification_macros_c.cc
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2009-07-30 20:47 --- Subject: Re: FAIL: 26_numerics/headers/cmath/c99_classification_macros_c.cc > In general, this one must be just xfailed, can pass by chance with PCHs. Can > you please tweak the dg lines at the beginning of the testcase and make sure > it's actually xfailed for this target too? Patch preapproved, thanks. Ok. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40919
[Bug libstdc++/40917] FAIL: ext/array_allocator/check_delete.cc (test for excess errors)
--- Comment #1 from paolo at gcc dot gnu dot org 2009-07-30 21:03 --- Subject: Bug 40917 Author: paolo Date: Thu Jul 30 21:02:44 2009 New Revision: 150272 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150272 Log: 2009-07-30 Paolo Carlini PR libstdc++/40917 * testsuite/util/replacement_memory_operators.h: Add missing includes, tweak qualifications. 2009-07-30 Paolo Carlini PR libstdc++/40916 * testsuite/23_containers/list/modifiers/swap/1.cc: Fix include order. * testsuite/23_containers/list/modifiers/swap/2.cc: Likewise. * testsuite/23_containers/list/modifiers/swap/2.cc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/23_containers/list/modifiers/swap/1.cc trunk/libstdc++-v3/testsuite/23_containers/list/modifiers/swap/2.cc trunk/libstdc++-v3/testsuite/23_containers/list/modifiers/swap/3.cc trunk/libstdc++-v3/testsuite/util/replacement_memory_operators.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40917
[Bug libstdc++/40916] [4.5 Regression] FAIL: 23_containers/list/modifiers/swap/1.cc execution test
--- Comment #3 from paolo at gcc dot gnu dot org 2009-07-30 21:03 --- Subject: Bug 40916 Author: paolo Date: Thu Jul 30 21:02:44 2009 New Revision: 150272 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150272 Log: 2009-07-30 Paolo Carlini PR libstdc++/40917 * testsuite/util/replacement_memory_operators.h: Add missing includes, tweak qualifications. 2009-07-30 Paolo Carlini PR libstdc++/40916 * testsuite/23_containers/list/modifiers/swap/1.cc: Fix include order. * testsuite/23_containers/list/modifiers/swap/2.cc: Likewise. * testsuite/23_containers/list/modifiers/swap/2.cc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/23_containers/list/modifiers/swap/1.cc trunk/libstdc++-v3/testsuite/23_containers/list/modifiers/swap/2.cc trunk/libstdc++-v3/testsuite/23_containers/list/modifiers/swap/3.cc trunk/libstdc++-v3/testsuite/util/replacement_memory_operators.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40916
[Bug libstdc++/40917] FAIL: ext/array_allocator/check_delete.cc (test for excess errors)
--- Comment #2 from paolo dot carlini at oracle dot com 2009-07-30 21:05 --- Fixed. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40917
[Bug libstdc++/40916] [4.5 Regression] FAIL: 23_containers/list/modifiers/swap/1.cc execution test
--- Comment #4 from paolo dot carlini at oracle dot com 2009-07-30 21:06 --- Fixed. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40916
[Bug libstdc++/40919] FAIL: 26_numerics/headers/cmath/c99_classification_macros_c.cc
--- Comment #3 from paolo dot carlini at oracle dot com 2009-07-30 21:08 --- Thanks again. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40919
[Bug fortran/40920] New: Derived type with BIND(C) - rejected as argument.
Found at http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/220286db9bb4# The following program is rejected with the bogus message that the derived type is not interoperable - it works if one moves the type declaration out of the interface statement. It also works with SEQUENCE instead of BIND(C). RESULTAT, SIGNE) bind(C, name='gsl_sf_lngamma_sgn_e_wrapper') 1 Error: Type 'resultat' at (1) is a parameter to the BIND(C) procedure 'gsl_sf_lngamma_sgn_e_wrapper' but is not C interoperable because derived type 'gsl_sf_result' is not C interoperable. !use iso_c_binding !type, bind(C) :: GSL_SF_RESULT !real(c_double) VALEUR !real(c_double) ERREUR !end type interface integer(c_int) function gsl_sf_lngamma_sgn_e_wrapper(X, & RESULTAT, SIGNE) bind(C, name='gsl_sf_lngamma_sgn_e_wrapper') use iso_c_binding !import :: GSL_SF_RESULT implicit none type, bind(C) :: GSL_SF_RESULT real(c_double) VALEUR real(c_double) ERREUR end type real(c_double), intent(in) :: X type(GSL_SF_RESULT), intent(out) :: RESULTAT real(c_double), intent(out) :: SIGNE end function end interface end -- Summary: Derived type with BIND(C) - rejected as argument. Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40920
[Bug libstdc++/40919] FAIL: 26_numerics/headers/cmath/c99_classification_macros_c.cc
--- Comment #4 from danglin at gcc dot gnu dot org 2009-07-30 22:34 --- Subject: Bug 40919 Author: danglin Date: Thu Jul 30 22:34:31 2009 New Revision: 150278 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=150278 Log: PR libstdc++/40919 * testsuite/26_numerics/headers/cmath/c99_classification_macros_c.cc: xfail on darwin[3-9]*. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/testsuite/26_numerics/headers/cmath/c99_classification_macros_c.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40919
[Bug libstdc++/40919] FAIL: 26_numerics/headers/cmath/c99_classification_macros_c.cc
--- Comment #5 from danglin at gcc dot gnu dot org 2009-07-30 22:36 --- Fixed. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40919
[Bug tree-optimization/40921] New: missed optimization: x + (-y * z * z) => x - y * z * z
Consider the program that follows (you can cut & paste into a shell to get
foo.s). Functions A and B are mathematically identical on the reals.
On Mac OS X 10.5, gcc version 4.4.1, with -O2, we see A and B compiling
differently. In the assembly we see that A squares z, multiplies by y,
subtracts from x -- precisely what the code says. B loads a -1, XORs that with
y to get -y, then multiplies by z, then z again, and adds to x -- so it
computes (-1) * y * z * z + x, which is a bit slower. Worse, reading a
constant in memory means futzing with PIC setup.
By comparison, in function C we have + (-b) converted to just a subtraction, so
it doesn't seem like this has to do with IEEE special cases. I've also tested
with all the -f options that have to do with assuming special cases won't
arise, to no effect.
The behaviour is identical on gcc-4.2.1.
cat > foo.c << EOF
double A (double x, double y, double z) {
return x - y * z*z ;
}
double B (double x, double y, double z) {
return x + (-y * z*z);
}
double C (double a, double b) {
return a + (-b);
}
EOF
gcc -O2 -fomit-frame-pointer -S foo.c
cat foo.s
--
Summary: missed optimization: x + (-y * z * z) => x - y * z * z
Product: gcc
Version: 4.4.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: benoit dot hudson at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40921
[Bug tree-optimization/38401] TreeSSA-PRE load after store missed optimization
--- Comment #25 from amylaar at gcc dot gnu dot org 2009-07-30 23:30 --- (In reply to comment #24) > Unfortunately, there is still no word from the FSF on what they did with our > Copyright Assignment. As already mentioned in PR 38785, I've posted the patch here: http://gcc.gnu.org/ml/gcc-patches/2009-03/msg00250.html It is also integrated in the milepost-branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38401
[Bug tree-optimization/40921] missed optimization: x + (-y * z * z) => x - y * z * z
--- Comment #1 from joseph at codesourcery dot com 2009-07-30 23:45 --- Subject: Re: New: missed optimization: x + (-y * z * z) => x - y * z * z Note that -frounding-math should disable the proposed optimization. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40921
[Bug tree-optimization/40921] missed optimization: x + (-y * z * z) => x - y * z * z
--- Comment #2 from benoit dot hudson at gmail dot com 2009-07-30 23:58
---
> Note that -frounding-math should disable the proposed optimization.
Ah, true; and that means that with the options I said to use, the optimization
is simply wrong. However, I see the same behaviour even with -ffast-math and
-funsafe-math-optimization and various other such options.
Also, squaring z is not necessary. The following program has the same
behaviour:
double A (double x, double y, double z) {
return x - y * z;
}
double B (double x, double y, double z) {
return x + (-y * z);
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40921
[Bug regression/35671] GCC 4.4.x vs. 4.2.x performance regression
--- Comment #17 from jhopper at safe-mail dot net 2009-07-30 23:58 --- you can find a nicer version of results (and potentially future updates) here: http://anonym.to?http://manoa.flnet.org/linux/compilers.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35671
[Bug lto/40902] LTO doesn't merge CV differences properly
--- Comment #1 from bje at gcc dot gnu dot org 2009-07-31 00:00 --- Yes, this seems wrong. -- bje at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-07-31 00:00:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40902
[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned
--- Comment #11 from mikulas at artax dot karlin dot mff dot cuni dot cz
2009-07-31 01:00 ---
So I did this experiment whether the stack is aligned in current Linux
binaries.
I applied this patch for gcc, so that it crashes on function entry if the
function has stack not aligned on 16 bytes.
diff -urp gcc-4.4.1/gcc/varasm.c gcc-4.4.1-test-align/gcc/varasm.c
--- gcc-4.4.1/gcc/varasm.c 2009-03-17 21:18:21.0 +0100
+++ gcc-4.4.1-test-align/gcc/varasm.c 2009-07-25 16:18:11.0 +0200
@@ -1760,6 +1760,8 @@ assemble_start_function (tree decl, cons
/* Standard thing is just output label for the function. */
ASM_OUTPUT_LABEL (asm_out_file, fnname);
#endif /* ASM_DECLARE_FUNCTION_NAME */
+ if (!crtl->stack_realign_needed)
+ fputs("\tsubl\t$12, %esp\n\ttestl\t$15,
%esp\n\tjz\t9f\n\tud2a\n9:\taddl\t$12, %esp\n", asm_out_file);
}
/* Output assembler code associated with defining the size of the
--- and the results are terrifying:
Gcc didn't even bootstrap itself. It failed because it calls glibc function
obstack_init and it calls back to xmalloc - with misaligned stack. So I
compiled gcc without bootstrap and tried to compile glibc-2.7 with it. Glibc
compiles its integer-only code with -mpreferred-stack-boundary=2, so I changed
it to -mpreferred-stack-boundary=4.
Glibc didn't finish its build either (failed when running some self-compiled
scripts), but it at least produced libc.so.
So I tried to preload this libc.so with stack-alignment-checking to various
Linux binaries (with LD_PRELOAD) and see what happens.
Out of 95 binaries in /bin/, only 23 succeeded! The remaining crashed because
of glibc was called with unaligned stack. (the distribution is up-to-date
Debian Lenny).
The non-crashing binaries are:
bzip2recover, cpio, dmesg, fgconsole, fuser, kill, loadkeys, lsmod, lvnet,
mktemp, more (displays help only, crashes when attempting to display any file),
mount, mountpoint, mt, mt-gnu, nbd-server, pidof, ping, ping6, run-parts, sed,
su, tailf, umount
So anyone, who is saying that the stack is aligned to 16 bytes has his mind
disconnected from reality. It isn't.
I find it very unreasonable that GCC developers try to declare their own ABI
with aligned stack --- and that conflicts with what is being used by the
majority of Linux applications. GCC developers are trying to say that 3/4 of
programs in /bin/ are wrong because they don't align the stack.
I think you should really align the stack in the functions that do SSE math and
don't rely on the fact that the stack is already aligned. It is definitelly
easier to use the code for stack reallign than declaring that majority of Linux
binaries are BAD and need to be recompiled.
If some scientists needed extreme performance and can't take the penalty of
realigning the stack, you can add an option -massume-aligned-stack form them
and it is the responsibility of a given scientist that the code compiled with
this option is never called back from libc or anything else else. But don't
assume stack alignment for general code. It just isn't true.
--
mikulas at artax dot karlin dot mff dot cuni dot cz changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|DUPLICATE |
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838
[Bug rtl-optimization/40838] gcc shouldn't assume that the stack is aligned
--- Comment #12 from mikulas at artax dot karlin dot mff dot cuni dot cz 2009-07-31 01:04 --- Created an attachment (id=18276) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18276&action=view) Crash because gcc assumes false stack alignment Here I'm submitting an example code that, when compiled with gcc 4.4.1 with -O3 -march=pentium3, crashes on Debian Lenny. Don't close this bug unless this code is working! You can get it working either by modifying gcc to align the stack (IMHO the easier way) or forcing all the distributions to recompile all their binaries because you want to declare new ABI (IMHO harder or impossible). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40838
[Bug target/38496] Gcc misaligns arrays when stack is forced follow the x8632 ABI
--- Comment #26 from mikulas at artax dot karlin dot mff dot cuni dot cz 2009-07-31 01:18 --- Very unfortunatelly, gcc does assume stack alignment. The problem is not technical (the code to realign the stack is already there, it's easy to activate it), the problem is ideological, because some gcc developers think that they can declare their own ABI and the world will be changing according to them. See comments in the bug #40838. I added that alignment test at the beginning of every libc function, the result is that 75% programs in /bin misalign the stack and are non-conforming to GCC-developer's ideas about their new ABI. I also posted a simple example there that does floating point math in the function that is called as a callback from glibc --- and crashes because of SSE and unaligned stack. I really say that they should align the stack in SSE functions instead of closing this bug with WONTFIX and shouting "everyone's code is bad because we declared it so!" -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38496
[Bug libstdc++/40912] 4.5 weekly snapshot: failed to pre-compile bits/stdc++.h.gch/O2ggnu++0x.gch
--- Comment #11 from htl10 at users dot sourceforge dot net 2009-07-31 01:50 --- gcc-4.5-20090409 (svn r145863) breaks at the same place; gcc-4.5-20090402 (svn r145482) breaks later at - make all-am make[4]: Entering directory `/home/htl10/tmp-build/45b/alphaev68-dec-osf5.1a/libjava/libltdl' /bin/ksh ./libtool --tag=CC --mode=compile /home/htl10/tmp-build/45b/./gcc/xgcc -B/home/htl10/tmp-build/45b/./gcc/ -B/usr/local/alphaev68-dec-osf5.1a/bin/ -B/usr/local/alphaev68-dec-osf5.1a/lib/ -isystem /usr/local/alphaev68-dec-osf5.1a/include -isystem /usr/local/alphaev68-dec-osf5.1a/sys-include -DHAVE_CONFIG_H -I. -I../../../../gcc-4.5-20090402/libjava/libltdl -I. -I/usr/local/include -g -O2 -mieee -c -o ltdl.lo ../../../../gcc-4.5-20090402/libjava/libltdl/ltdl.c libtool: compile: libobj name `ltdl.lo' may not contain shell special characters. make[4]: *** [ltdl.lo] Error 1 make[4]: Leaving directory `/home/htl10/tmp-build/45b/alphaev68-dec-osf5.1a/libjava/libltdl' make[3]: *** [all] Error 2 make[3]: Leaving directory `/home/htl10/tmp-build/45b/alphaev68-dec-osf5.1a/libjava/libltdl' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/home/htl10/tmp-build/45b/alphaev68-dec-osf5.1a/libjava' make[1]: *** [all-target-libjava] Error 2 make[1]: Leaving directory `/home/htl10/tmp-build/45b' make: *** [all] Error 2 -20090402 since the code concerned entered as r145483 just after gcc-4.5-20090402 (svn r145482), I think we can conclude that that bits of code has _always_ been broken since day 1. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40912
[Bug libstdc++/40912] 4.5 weekly snapshot: failed to pre-compile bits/stdc++.h.gch/O2ggnu++0x.gch
--- Comment #12 from htl10 at users dot sourceforge dot net 2009-07-31 02:14 --- (In reply to comment #10) It looks like 4.5 will be dead-on-arrival alpha*-dec-osf[45]*, unless I fix this myself... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40912
[Bug target/40922] New: Mutilib for the gcc 4.4.x branch no longer works
One day, I built gcc 4.4.1 prerelease, with normal multilib. The next day, I realized I forgot to add Ada, and all of a sudden multilib failed with the exact same configuration. At the time, I didn't think too much of it and don't remember if anything else happened between the two builds, but it is likely I updated Binutils between those two exact same builds. I have not been getting it to work at all anymore, and I thought it was unique to Cygwin where I couldn't get 4.4.x Multilib for as far as I can remember. I went back to the build that was building in Multilib, and it died with no rule to make 32/zlib. GCC will accept the -m32 flag, but the 64-bit assembler is used. The 32 dir multi-versions are not created, as if multilib was disabled. This is highly likely related to Binutils. However, whether it is a bug in Binutils, or a change in Binutils that caused a bug in 4.4.x to surface, I do not know. I will give you configuration lines (just one time), but believe me, they are not relevant. --enable-multilib wasn't even necessary for gcc, only Binutils. The working multilib version of 4.4.1 I have proves it (via -v.) This bug applies 100% to Linux x86_64 as it does to Windows x64. It has nothing to do with the Mingw-w64 crt, as it occurs before fresh installation of crt, by gcc in make all-gcc (after doing that, building a new crt reveals the incorrect 64-bit assembler.) Binutils (last tried yesterday's update): ../configure --target=x86_64-w64-mingw32 --enable-multilib --enable-targets=x86_64-w64-mingw32,i686-w64-mingw32 --with-sysroot=/mingw64 --prefix=/mingw64 --with-ppl=/usr --with-cloog=/usr GCC 4.4.1 Release: (small testcase) ../configure --target=x86_64-w64-mingw32 --enable-targets=all --with-sysroot=/mingw64 --prefix=/mingw64 --with-ppl=/usr --with-cloog=/usr --enable-languages=c,c++ Thanks, I will pass this same report to Binutils. -- Summary: Mutilib for the gcc 4.4.x branch no longer works Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: xenofears at gmail dot com GCC build triplet: x86_64-w64-mingw32, x86_64-unknown-linux-gnu, i686-pc- cygwin, li GCC host triplet: x86_64-w64-mingw32, x86_64-unknown-linux-gnu, i686-pc- cygwin, li GCC target triplet: x86_64-w64-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40922
[Bug target/40922] Mutilib for the gcc 4.4.x branch no longer works
--- Comment #1 from xenofears at gmail dot com 2009-07-31 03:47 --- On Binutils I thought I could try an old version, but then realized trying an old version doesn't really answer the question, it could still be in gcc's field, or binutils causing a bug in gcc to surface, and leave the newest versions with a nasty bug. Also, this bug goes back in HEAD/snapshots (Binutils) for at least 2 weeks. GCC 4.4 branch is affected only, including the release and current 4.4.2 pre-release. Thanks for your attention. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40922
[Bug c++/40918] uncaught_exception() returns wrong (inverted) value if some exception have crossed a DLL boundary before
--- Comment #2 from dannysmith at users dot sourceforge dot net 2009-07-31 04:18 --- (In reply to comment #0) > I was not able to reproduce the bug on Linux, so I assume this is a > Windows-specific. > > If an exception is generated inside shared library (DLL), then crosses the > DLL-boundary and gets caught in some other module, the std::uncaught_exception > will always return wrong (inverted) value from now on. Here's a small test > case. > You need to link against a shared libgcc and a shared libstdc++ for this to work. Shared libgcc is part of standard build now for mingw Shared libstdc++ is close. http://gcc.gnu.org/ml/gcc-patches/2009-07/msg01042.html Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40918
[Bug c/40909] GCC mis-optimizes GDB
--- Comment #7 from sezeroz at gmail dot com 2009-07-31 06:30 --- Besides my question in comment #6, I wonder why is this actually considered an aliasing violation? The only difference between struct stat and struct _stat64i32 is the time fields: _stat64i32 has __time64_t and stat has time_t which, in this particular case, is typedef'ed as __time64_t already.. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40909
[Bug c++/40918] uncaught_exception() returns wrong (inverted) value if some exception have crossed a DLL boundary before
--- Comment #3 from andriys at gmail dot com 2009-07-31 06:56 --- I'm linking using g++ driver, so shared libgcc is enabled by default in 4.4.0. I've just tried to enabled shared libstdc++ as described in the Release Notes to the MinGW GCC 4.4.0 release, which made no difference. More over, I modified the test case the following way: I got rid of std::cout in favor of printf(), added -nodefaultlibs option to the linker and specified all the required libraries manually. Now libstdc++ is not linked at all (neither static nor dynamic), the bug is still here. I'll attach the modified test case shortly. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40918
[Bug c++/40918] uncaught_exception() returns wrong (inverted) value if some exception have crossed a DLL boundary before
--- Comment #4 from andriys at gmail dot com 2009-07-31 06:58 --- Created an attachment (id=18277) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18277&action=view) Modified test case (not dependent on libstdc++ at all) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40918
