[Bug target/39758] New: FAIL: gcc.dg/initpri1.c, g++.dg/special/initpri1.C on arm target
The toolchain is built with newlib C.
*** EXIT code 4242
FAIL: gcc.dg/initpri1.c execution test
The constructors are performed in the correct order, from lowest to highest.
However the destructors are performed in a wrong order.
...
void d1() __attribute__((destructor (500)));
void d2() __attribute__((destructor (700)));
void d3() __attribute__((destructor (600)));
void d1() {
if (--i != 0)
abort ();
}
void d2() {
if (--i != 2)
abort ();
}
void d3() {
if (j != 2)
abort ();
if (--i != 1)
abort ();
}
void cd4() __attribute__((constructor (800), destructor (800)));
void cd4() {
if (i != 3)
abort ();
++j;
}
The correct order should be:
cd4() -> d2() -> d3() -> d1()
However, on arm target, the order is d1()->d3()->d2()->cd4().
--
Summary: FAIL: gcc.dg/initpri1.c, g++.dg/special/initpri1.C on
arm target
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jingyu at google dot com
GCC build triplet: i686-linux-gnu, x86_64-pc-linux-gnu
GCC host triplet: i686-linux-gnu, x86_64-pc-linux-gnu
GCC target triplet: arm-unknown-eabi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39758
[Bug testsuite/39733] gcc.misc-tests/help.exp doesn't work with multilib
--- Comment #10 from hjl dot tools at gmail dot com 2009-04-14 04:42 --- Fixed. -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39733
[Bug c++/39480] generated memcpy causes trouble in assignment
--- Comment #30 from jason at gcc dot gnu dot org 2009-04-14 03:31 --- Fixed for 4.3, 4.4 and 4.5. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39480
[Bug c++/39480] generated memcpy causes trouble in assignment
--- Comment #29 from jason at gcc dot gnu dot org 2009-04-14 03:30 --- Subject: Bug 39480 Author: jason Date: Tue Apr 14 03:30:12 2009 New Revision: 146020 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146020 Log: PR c++/39480 * call.c (build_over_call): Don't call memcpy if the target is the same as the source. Added: branches/gcc-4_3-branch/gcc/testsuite/g++.dg/init/copy7.C - copied unchanged from r146011, trunk/gcc/testsuite/g++.dg/init/copy7.C Modified: branches/gcc-4_3-branch/gcc/cp/ChangeLog branches/gcc-4_3-branch/gcc/cp/call.c branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39480
[Bug middle-end/39757] inconsistency in array bounds checking with -O3
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-14 03:00 --- -O3 has extra inlining. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Component|c |middle-end http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39757
[Bug c/39757] New: inconsistency in array bounds checking with -O3
gcc version: Using built-in specs. Target: i486-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.3.2-1.1' --with-bugurl=file:///usr/share/doc/gcc-4.3/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --enable-shared --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --enable-nls --with-gxx-include-dir=/usr/include/c++/4.3 --program-suffix=-4.3 --enable-clocale=gnu --enable-libstdcxx-debug --enable-objc-gc --enable-mpfr --enable-targets=all --enable-cld --enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu --target=i486-linux-gnu Thread model: posix gcc version 4.3.2 (Debian 4.3.2-1.1) system type: Linux debian 2.6.26-1-686 #1 SMP Fri Mar 13 18:08:45 UTC 2009 i686 GNU/Linux command line: gcc -DNO_LCMS -Wall -Werror -O3 -c -o dcraw.o dcraw.c source files: curl -O 'http://www.cybercom.net/~dcoffin/dcraw/dcraw.c' description of the expected behavior: Compiles without errors. description of actual behavior: cc1: warnings being treated as errors dcraw.c: In function adobe_coeff: dcraw.c:6493: error: array subscript is above array bounds dcraw.c:6493: error: array subscript is above array bounds dcraw.c:6493: error: array subscript is above array bounds dcraw.c:6493: error: array subscript is above array bounds dcraw.c:6493: error: array subscript is above array bounds dcraw.c:6493: error: array subscript is above array bounds dcraw.c:6493: error: array subscript is above array bounds dcraw.c:6493: error: array subscript is above array bounds dcraw.c:6493: error: array subscript is above array bounds dcraw.c: In function parse_phase_one: dcraw.c:5751: error: array subscript is above array bounds dcraw.c:5751: error: array subscript is above array bounds dcraw.c:5751: error: array subscript is above array bounds dcraw.c:5751: error: array subscript is above array bounds dcraw.c:5751: error: array subscript is above array bounds dcraw.c:5751: error: array subscript is above array bounds The inconsistency hcc1: warnings being treated as errors dcraw.c: In function adobe_coeff: dcraw.c:6493: error: array subscript is above array bounds dcraw.c:6493: error: array subscript is above array bounds dcraw.c:6493: error: array subscript is above array bounds dcraw.c:6493: error: array subscript is above array bounds dcraw.c:6493: error: array subscript is above array bounds dcraw.c:6493: error: array subscript is above array bounds dcraw.c:6493: error: array subscript is above array bounds dcraw.c:6493: error: array subscript is above array bounds dcraw.c:6493: error: array subscript is above array bounds dcraw.c: In function parse_phase_one: dcraw.c:5751: error: array subscript is above array bounds dcraw.c:5751: error: array subscript is above array bounds dcraw.c:5751: error: array subscript is above array bounds dcraw.c:5751: error: array subscript is above array bounds dcraw.c:5751: error: array subscript is above array bounds dcraw.c:5751: error: array subscript is above array bounds For one, the compiler considers it an issues that array cam_xyz[4][3] is accessed as cam_xyz[0][j], 0 <= j < 12. This issue is found with -O3 but not with -O2. The inconsistency, which I see is a bug, is that romm_camm[3][3] which is accessed as romm_cam[0][i], i <= j < 9, does not raise an error even after the above two cases are fixed. -- Summary: inconsistency in array bounds checking with -O3 Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ptrktn at gmail dot com GCC build triplet: i486-linux-gnu GCC host triplet: i686-linux-gnu GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39757
[Bug bootstrap/19255] cross-chain build failure [MinGW]
--- Comment #4 from monaka at monami-software dot com 2009-04-14 02:49 --- This issue is about 3.4.x. It's reasonable to close as wontfix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19255
[Bug objc/39753] [4.3/4.4/4.5 Regression] Objective-C(++) and C90 strict-aliasing interaction bug
--- Comment #4 from john dot engelhart at gmail dot com 2009-04-14 01:15 --- Another point to consider is whether or not C99's 'restrict' is a legitimate type qualifier for pointers to Objective-C objects. This is really more of an observation that pragmatically, very little can be said about which object a particular objc object pointer points to at any point in time. This is beyond the normal 'points to' ambiguity one deals with in C code due to the very dynamic nature of Objective-C. IMHO, a programmer would have an extremely difficult time keeping the promise that 'restrict' implies, even if one wanted to. I would guess that the 'safest' way of dealing with restrict qualified pointers to objc objects would be to silently drop the restrict qualifier internally, just make it a no-op. The same could also be said of 'const'. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39753
[Bug libgomp/39746] [4.5 Regression] Fail pr34513.c and pr34513.C at -O1 and above
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2009-04-14 00:10 --- Subject: Re: [4.5 Regression] Fail pr34513.c and pr34513.C at -O1 and above > The "if (shrd != thrs)" is optimized away. Attached .s files with -O0 > and -O2. The last pass with the comparison at -O2 is 051t.cunrolli. Dave --- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2009-04-14 00:10 --- Created an attachment (id=17628) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17628&action=view) --- Comment #6 from dave at hiauly1 dot hia dot nrc dot ca 2009-04-14 00:10 --- Created an attachment (id=17629) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17629&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39746
[Bug libgomp/39746] [4.5 Regression] Fail pr34513.c and pr34513.C at -O1 and above
--- Comment #1 from dave at hiauly1 dot hia dot nrc dot ca 2009-04-13 23:10 --- Subject: Re: New: [4.5 Regression] Fail pr34513.c and pr34513.C at -O1 and above The "if (shrd != thrs)" is optimized away. Attached .s files with -O0 and -O2. Dave --- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2009-04-13 23:10 --- Created an attachment (id=17626) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17626&action=view) --- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2009-04-13 23:10 --- Created an attachment (id=17627) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17627&action=view) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39746
[Bug objc/39753] [4.3/4.4/4.5 Regression] Objective-C(++) and C90 strict-aliasing interaction bug
-- jakub at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39753
[Bug objc/39753] [4.3/4.4/4.5 Regression] Objective-C(++) and C90 strict-aliasing interaction bug
--- Comment #3 from pinskia at gcc dot gnu dot org 2009-04-13 22:00 --- (In reply to comment #2) > Is this really "broken" when the Apple compiler has the same behavior > (assuming > we all accept that the Apple Objective-C semantics are the de facto standard)? Apple's compiler does not have the same behavior because they disable strict aliasing by default for all languages. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39753
[Bug objc/39753] [4.3/4.4/4.5 Regression] Objective-C(++) and C90 strict-aliasing interaction bug
--- Comment #2 from steven at gcc dot gnu dot org 2009-04-13 21:59 --- Is this really "broken" when the Apple compiler has the same behavior (assuming we all accept that the Apple Objective-C semantics are the de facto standard)? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39753
[Bug c++/39754] [4.5 Regression] ICE: tree check: accessed elt 2 of tree_vec with 1 elts in tsubst, at cp/pt.c:9248
--- Comment #1 from hjl dot tools at gmail dot com 2009-04-13 21:26 --- It is caused by revision 145440: http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg00060.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||dseketel at redhat dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-04-13 21:26:38 date|| Summary|ICE: tree check: accessed |[4.5 Regression] ICE: tree |elt 2 of tree_vec with 1|check: accessed elt 2 of |elts in tsubst, at |tree_vec with 1 elts in |cp/pt.c:9248|tsubst, at cp/pt.c:9248 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39754
[Bug c++/39480] generated memcpy causes trouble in assignment
--- Comment #28 from jason at gcc dot gnu dot org 2009-04-13 20:56 --- Subject: Bug 39480 Author: jason Date: Mon Apr 13 20:56:45 2009 New Revision: 146013 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146013 Log: PR c++/39480 * call.c (build_over_call): Don't call memcpy if the target is the same as the source. Added: branches/gcc-4_4-branch/gcc/testsuite/g++.dg/init/copy7.C - copied unchanged from r146011, trunk/gcc/testsuite/g++.dg/init/copy7.C Modified: branches/gcc-4_4-branch/gcc/cp/ChangeLog branches/gcc-4_4-branch/gcc/cp/call.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39480
[Bug c++/39480] generated memcpy causes trouble in assignment
--- Comment #27 from jason at gcc dot gnu dot org 2009-04-13 20:53 --- Subject: Bug 39480 Author: jason Date: Mon Apr 13 20:53:34 2009 New Revision: 146011 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146011 Log: PR c++/39480 * call.c (build_over_call): Don't call memcpy if the target is the same as the source. Added: trunk/gcc/testsuite/g++.dg/init/copy7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39480
[Bug ada/39756] New: FAIL: c9a011b
splitting /test/gnu/gcc/objdir/gcc/testsuite/ada/acats/tests/c9/c9a011b.ada into : c9a011b.adb BUILD c9a011b.adb gnatmake --GCC="/test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/" -gnat ws -O2 -I/test/gnu/gcc/objdir/gcc/testsuite/ada/acats/support c9a011b.adb -largs --GCC="/test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/" /test/gnu/gcc/objdir/gcc/xgcc -c -B/test/gnu/gcc/objdir/gcc/ -gnatws -O2 -I/test /gnu/gcc/objdir/gcc/testsuite/ada/acats/support c9a011b.adb gnatbind -I/test/gnu/gcc/objdir/gcc/testsuite/ada/acats/support -x c9a011b.ali gnatlink c9a011b.ali --GCC=/test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/ gcc/ RUN c9a011b ,.,. C9A011B ACATS 2.5 09-04-13 06:26:51 C9A011B CHECK THAT "TASKING_ERROR" IS RAISED BY A TIMED ENTRY CALL IF THE CALLED TASK IS ABORTED BEFORE THE DELAY EXPIRES BUT NOT WHEN THE CALL IS FIRST EXECUTED. * C9A011B NO EXCEPTION RAISED. C9A011B FAILED . FAIL: c9a011b Doesn't fail every time. -- Summary: FAIL: c9a011b Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa2.0w-hp-hpux11.11 GCC host triplet: hppa2.0w-hp-hpux11.11 GCC target triplet: hppa2.0w-hp-hpux11.11 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39756
[Bug c++/39480] generated memcpy causes trouble in assignment
--- Comment #26 from jason at gcc dot gnu dot org 2009-04-13 20:08 --- I think this actually only comes up at -O0; without optimization we don't try to expand a call to __builtin_memcpy as a block move because we need TER to tell us what the real alignment of the operands is. With optimization we use emit_block_move_hints, which should be safe. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39480
[Bug c/39755] New: inline memcpy() incorrectly optimized on MIPS target
In one case the C compiler can optimize away an inline memcpy() on a
MIPS target. The problem was duplicated with GCC 3.2.1 and 3.3.3.
The problem does not affect x86 targets or GCC 4.x (tested on 4.2.4).
The MIPS cross-compiler runs under RHEL. Tested MIPS cross-compilers
under Cygwin and Mingw with the same results.
This is the test code and the resulting output. The "if" statement and
16-byte memcpy() are optimized away, leaving only the 4-byte memcpy.
Compile with: mipsisa32-elf-gcc -O2 -c test.c
---
#include
typedef struct {
char C[16];
int E;
} st;
void f( st *S, char* c );
void f( st *S, char* c )
{
if ( S->E == 6 )
memcpy( &S->C, c, 16 );
else
memcpy( &S->C, c, 4 );
}
---
:
0: 88a2lwl v0,0(a1)
4: 98a20003lwr v0,3(a1)
8: a882swl v0,0(a0)
c: 03e8jr ra
10: b8820003swr v0,3(a0)
---
Compiler info:
$ mipsisa32-elf-gcc -v
Reading specs from
/tools/ecos/3.2.1_opt/Linux/opt/ecos/gnutools/mipsisa32-elf/bin/../lib/gcc-lib/mipsisa32-elf/3.2.1/specs
Configured with: /home/msieweke/ecos20/gnutools-src/gcc-3.2.1/configure
--target=mipsisa32-elf --prefix=/home/msieweke/gnutools_321
--enable-languages=c,c++ --enable-gofast --with-gnu-as --with-gnu-ld
--with-newlib
--with-gxx-include-dir=/home/msieweke/gnutools_321/mipsisa32-elf/include -v
Thread model: single
gcc version 3.2.1
--
Summary: inline memcpy() incorrectly optimized on MIPS target
Product: gcc
Version: 3.2.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: msieweke at broadcom dot com
GCC build triplet: i386-gnu-linux
GCC host triplet: i386-gnu-linux
GCC target triplet: mipsisa32-elf
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39755
[Bug testsuite/39733] gcc.misc-tests/help.exp doesn't work with multilib
--- Comment #9 from hjl at gcc dot gnu dot org 2009-04-13 19:42 --- Subject: Bug 39733 Author: hjl Date: Mon Apr 13 19:42:26 2009 New Revision: 146009 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146009 Log: 2009-04-13 H.J. Lu PR testsuite/39733 * gcc.misc-tests/options.exp (check_for_options): Renamed to ... (check_for_all_options): This. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.misc-tests/options.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39733
[Bug c++/39750] ICE in uses_template_parms, at cp/pt.c:6332
--- Comment #3 from jason at gcc dot gnu dot org 2009-04-13 19:27 --- Subject: Bug 39750 Author: jason Date: Mon Apr 13 19:27:20 2009 New Revision: 146008 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146008 Log: PR c++/39750 * pt.c (uses_template_parms): Handle CONSTRUCTOR. Added: branches/gcc-4_4-branch/gcc/testsuite/g++.dg/template/crash90.C - copied unchanged from r146006, trunk/gcc/testsuite/g++.dg/template/crash90.C Modified: branches/gcc-4_4-branch/gcc/cp/ChangeLog branches/gcc-4_4-branch/gcc/cp/pt.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39750
[Bug c++/39754] New: ICE: tree check: accessed elt 2 of tree_vec with 1 elts in tsubst, at cp/pt.c:9248
The following code produces an ICE in 4.5.0 while previous versions reported an
incomplete type error:
== 8< ==
template < typename > struct A ;
template < typename U , typename > struct B
{
typedef U V ;
A < V * > a ;
} ;
template < typename W > struct C
{
A < W * > a ;
} ;
C < int > c ;
== >8 ==
-- 4.5.0 --
$ x86_64-linux-gnu-g++-trunk -v -c ice-accessed-elt-2-of-tree_vec.ii
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure
--prefix=/opt/software/gcc-x86_64/gcc-trunk --program-suffix=-trunk
--enable-languages=c,c++
Thread model: posix
gcc version 4.5.0 20090410 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-c' '-shared-libgcc' '-mtune=generic'
/opt/software/gcc-x86_64/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/cc1plus
-fpreprocessed ice-accessed-elt-2-of-tree_vec.ii -quiet -dumpbase
ice-accessed-elt-2-of-tree_vec.ii -mtune=generic -auxbase
ice-accessed-elt-2-of-tree_vec -version -o /tmp/ccSsFbFa.s
GNU C++ (GCC) version 4.5.0 20090412 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.5.0 20090410 (experimental), GMP version
4.2.2, MPFR version 2.3.1.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: b13346d60276f3352c4b7dd22e3889d7
ice-accessed-elt-2-of-tree_vec.ii: In instantiation of C:
ice-accessed-elt-2-of-tree_vec.ii:11: instantiated from here
ice-accessed-elt-2-of-tree_vec.ii:9: internal compiler error: tree check:
accessed elt 2 of tree_vec with 1 elts in tsubst, at cp/pt.c:9248
-- 4.4.0 --
$ x86_64-linux-gnu-g++-4.4.x -v -c ice-accessed-elt-2-of-tree_vec.ii
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4_4-branch/configure
--prefix=/opt/software/gcc-x86_64/gcc-4.4.x --program-suffix=-4.4.x
--enable-languages=c,c++ --enable-checking
Thread model: posix
gcc version 4.4.0 20090413 (prerelease) (GCC)
COLLECT_GCC_OPTIONS='-v' '-c' '-shared-libgcc' '-mtune=generic'
/opt/software/gcc-x86_64/gcc-4.4.x/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/cc1plus
-fpreprocessed ice-accessed-elt-2-of-tree_vec.ii -quiet -dumpbase
ice-accessed-elt-2-of-tree_vec.ii -mtune=generic -auxbase
ice-accessed-elt-2-of-tree_vec -version -o /tmp/ccEdsa3a.s
GNU C++ (GCC) version 4.4.0 20090413 (prerelease) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.4.0 20090413 (prerelease), GMP version
4.2.2, MPFR version 2.3.1.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 4c95a5cf24794a394976148039ecc611
ice-accessed-elt-2-of-tree_vec.ii: In instantiation of C:
ice-accessed-elt-2-of-tree_vec.ii:11: instantiated from here
ice-accessed-elt-2-of-tree_vec.ii:9: error: C::a has incomplete type
ice-accessed-elt-2-of-tree_vec.ii:1: error: declaration of struct A
--
Summary: ICE: tree check: accessed elt 2 of tree_vec with 1 elts
in tsubst, at cp/pt.c:9248
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at abeckmann dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39754
[Bug target/39738] GCC cannot build itself for win64 platform
--- Comment #11 from ktietz at gcc dot gnu dot org 2009-04-13 19:25 --- (In reply to comment #10) > I try to build gcc with latest CRT from svn (revision 764) - build is OK. It > seems, snapshot from sourceforge download page(November 15, 2008) not > compatible with gcc 4.4. > Well, this is true. We'll release soon the gcc 4.4 version is out of the door. Of course we will update the crt/header-set tarball also. Thanks and cheers, Kai -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39738
[Bug c++/39750] ICE in uses_template_parms, at cp/pt.c:6332
--- Comment #4 from jason at gcc dot gnu dot org 2009-04-13 19:27 --- Fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39750
[Bug c++/39750] ICE in uses_template_parms, at cp/pt.c:6332
--- Comment #2 from jason at gcc dot gnu dot org 2009-04-13 18:54 --- Subject: Bug 39750 Author: jason Date: Mon Apr 13 18:54:40 2009 New Revision: 146006 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146006 Log: PR c++/39750 * pt.c (uses_template_parms): Handle CONSTRUCTOR. Added: trunk/gcc/testsuite/g++.dg/template/crash90.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39750
[Bug target/39738] GCC cannot build itself for win64 platform
--- Comment #10 from css20 at mail dot ru 2009-04-13 18:06 --- I try to build gcc with latest CRT from svn (revision 764) - build is OK. It seems, snapshot from sourceforge download page(November 15, 2008) not compatible with gcc 4.4. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39738
[Bug objc/39753] [4.3/4.4/4.5 Regression] Objective-C(++) and C90 strict-aliasing interaction bug
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-04-13 17:51 --- Confirmed, the aliasing rules were also in ISO C90 (aka ANSI C89). This has been broken since 3.0 when strict aliasing was enabled by default. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||pinskia at gcc dot gnu dot ||org Severity|major |normal Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Keywords||alias, wrong-code Known to fail||3.0 3.1 3.3.3 3.4.0 3.2.3 ||4.1.0 4.4.0 4.3.0 Known to work||2.95.3 Last reconfirmed|-00-00 00:00:00 |2009-04-13 17:51:29 date|| Summary|Objective-C(++) and C99 |[4.3/4.4/4.5 Regression] |strict-aliasing interaction |Objective-C(++) and C90 |bug |strict-aliasing interaction ||bug Target Milestone|--- |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39753
[Bug objc/39753] New: Objective-C(++) and C99 strict-aliasing interaction bug
Please keep in mind that I'm not a GCC internals expert, and this really
requires some analysis from an ObjC maintainer (and expert) along with someone
who is familiar with the details of how -fstrict-aliasing works.
See also: http://gcc.gnu.org/ml/gcc/2009-04/msg00290.html
The short version is this: Currently, it would appear the compiler (and I'm
assuming all versions of the compiler that perform -fstrict-aliasing) applies
C99 strict-aliasing rules to pointers to Objective-C objects. Although there
is no formal language specification for Objective-C, it would seem that the
most appropriate way to treat pointers to Objective-C objects is the same as
'char *' in terms of C99 aliasing rules. That is to say, a pointer to an
Objective-C object can aliasing anything.
As an experiment, I added the following line to c-common.c /
c_common_get_alias_set() to determine how often the compiler is applying
incorrect aliasing rules while informing the alias analyzer that the pointer
can aliasing anything.
if(((c_language == clk_objc) || (c_language == clk_objcxx)) &&
((TYPE_LANG_SPECIFIC (t) && (TYPE_LANG_SPECIFIC(t)->objc_info)) ||
objc_is_object_ptr(t))) {
warning(OPT_Wstrict_aliasing, "Caught and returning 'can alias anything' for
objc type");
return(0);
}
right before the following line:
if (c_language != clk_c || flag_isoc99)
This returned a number (actually, a lot) of warnings when compiling Objective-C
code at -O2 and -Wstrict-aliasing.
In the mailing-list post referenced above, someone mentions that they think
that GNUstep uses '-fno-strict-aliasing' when compiling code. This seems like
a good test to see how effective a patch like this is.
Recommendation:
Apply the above 'patch' (or functional equivalent) to the compiler, minus the
warning() line, to all versions of the compiler that apply C99 strict-aliasing
rules.
--
Summary: Objective-C(++) and C99 strict-aliasing interaction bug
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: objc
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: john dot engelhart at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39753
[Bug testsuite/39752] test-demangle.c failed to compile
--- Comment #1 from peter dot kovar at gmail dot com 2009-04-13 17:40 --- Created an attachment (id=17625) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17625&action=view) Rename getline () to get_line () in test-demangle.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39752
[Bug testsuite/39752] New: test-demangle.c failed to compile
libiberty/testsuite/test-demangle.c After configuration with the following ../../configure --program-suffix=-4.5.0 --enable-languages=c,c++,objc,obj-c++ I've started make check which failed on Fedora 10+ x86 as well as x86-64 ../../../../libiberty/testsuite/test-demangle.c:49: error: conflicting types for getline /usr/include/stdio.h:653: note: previous declaration of getline was here make[3]: *** [test-demangle] Error 1 because of name clash with #ifdef __USE_XOPEN2K8 /* Like `getdelim', but reads up to a newline. This function is not part of POSIX and therefore no official cancellation point. But due to similarity with an POSIX interface or due to the implementation it is a cancellation point and therefore not marked with __THROW. */ extern _IO_ssize_t getline (char **__restrict __lineptr, size_t *__restrict __n, FILE *__restrict __stream) __wur; #endif -- Summary: test-demangle.c failed to compile Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: peter dot kovar at gmail dot com GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39752
[Bug testsuite/39733] gcc.misc-tests/help.exp doesn't work with multilib
--- Comment #8 from dominiq at lps dot ens dot fr 2009-04-13 17:21 --- The patch in http://gcc.gnu.org/ml/gcc-patches/2009-04/msg00852.html fixes PR39749. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39733
[Bug testsuite/39749] FAIL: compiler driver -v --help option(s) (assembler options)
--- Comment #7 from dominiq at lps dot ens dot fr 2009-04-13 17:19 --- I finally used make -k check-gcc RUNTESTFLAGS="help.exp=* --target_board=unix/-m64" and got with the patch in http://gcc.gnu.org/ml/gcc-patches/2009-04/msg00852.html === gcc Summary === # of expected passes37 # of expected failures 2 So it seems to be indeed a duplicate of PR39733. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39749
[Bug libfortran/39665] [4.5 Regression] Fortran IO using unaligned accesses to read/write doubles.
--- Comment #12 from jb at gcc dot gnu dot org 2009-04-13 16:55 --- Fixed as of r145875 -- jb at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39665
[Bug testsuite/39749] FAIL: compiler driver -v --help option(s) (assembler options)
--- Comment #6 from dominiq at lps dot ens dot fr 2009-04-13 16:02 --- > I will bet they are the same bug. One easy way to verify it is to > apply my patch for PR 39733 to see if those failures disappear. What magic incantation should I use to test it. I tried make -k check-gcc RUNTESTFLAGS="help.exp=* --target_board=unix'-m64'" without success. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39749
[Bug target/39738] GCC cannot build itself for win64 platform
--- Comment #9 from css20 at mail dot ru 2009-04-13 15:48 --- > Do you use for native toolchain an fresh initialized directory? > Which version of toolchain you are using (especially header-set)? > Do you use --prefix and --with-sysroot options? I use directory with mingw-64 runtime installed as --prefix= and --with-sysroot= argument. Toolchain versions: binutils 2.19.1 gmp 4.2.4 mpfr 2.4.1 CRT and pthreads - last versions from http://sourceforge.net/project/showfiles.php?group_id=202880 > You can try the following. Remove in your directory the folder > lib/gcc/x86_64-pc-mingw32/4.4.0/ and remove in your gcc's build directory the > x86_64-pc-mingw32 folder. Then do a 'make' No any changes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39738
[Bug c++/39750] ICE in uses_template_parms, at cp/pt.c:6332
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2009-04-13 15:06:38 |2009-04-13 15:31:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39750
[Bug testsuite/39733] gcc.misc-tests/help.exp doesn't work with multilib
--- Comment #7 from hjl dot tools at gmail dot com 2009-04-13 15:12 --- *** Bug 39749 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39733
[Bug testsuite/39749] FAIL: compiler driver -v --help option(s) (assembler options)
--- Comment #5 from hjl dot tools at gmail dot com 2009-04-13 15:12 --- Since this happens "on i686-apple-darwin9 with -m64", it seems like multilib configuration. It is very likely a dup for PR 39733. Please reopen it if my fix for PR 39733 doesn't fix it. *** This bug has been marked as a duplicate of 39733 *** -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39749
[Bug c++/39751] ICE in cp_lexer_new_from_tokens, at cp/parser.c:342
--- Comment #5 from paolo dot carlini at oracle dot com 2009-04-13 15:12 --- HJ, you are wrong, make sure to pass --enable-checking explicitly in 4_4-branch. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-04-13 15:12:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39751
[Bug c++/39751] ICE in cp_lexer_new_from_tokens, at cp/parser.c:342
--- Comment #4 from paolo dot carlini at oracle dot com 2009-04-13 15:10 --- Indeed, I just checked and 4.4.0 also ICEs when checking is enabled, thus behaves exactly like 4.5.0. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Known to fail|4.5.0 |4.4.0 4.5.0 Known to work|4.4.0 | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39751
[Bug c++/39750] ICE in uses_template_parms, at cp/pt.c:6332
--- Comment #1 from hjl dot tools at gmail dot com 2009-04-13 15:06 --- This is caused by revision 137361: http://gcc.gnu.org/ml/gcc-cvs/2008-07/msg00065.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||jason at redhat dot com Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-04-13 15:06:38 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39750
[Bug c++/39751] ICE in cp_lexer_new_from_tokens, at cp/parser.c:342
--- Comment #3 from pinskia at gmail dot com 2009-04-13 15:06 ---
Subject: Re: New: ICE in cp_lexer_new_from_tokens, at cp/parser.c:342
Sent from my iPhone
On Apr 13, 2009, at 7:43 AM, "gcc at abeckmann dot de"
wrote:
> This is a 4.5.0 regression on invalid code:
>
> == 8< ==
> template < typename >
> struct A
> {
> A < struct
> {
> f () :
> == >8 ==
>
> -- 4.5.0 --
> $ x86_64-linux-gnu-g++-trunk -v -c ice-cp_parser_c-342.ii
>
> Using built-in specs.
> Target: x86_64-unknown-linux-gnu
> Configured with: ../gcc-trunk/configure
> --prefix=/opt/software/gcc-x86_64/gcc-trunk --program-suffix=-trunk
> --enable-languages=c,c++
> Thread model: posix
> gcc version 4.5.0 20090410 (experimental) (GCC)
> COLLECT_GCC_OPTIONS='-v' '-c' '-shared-libgcc' '-mtune=generic'
>
> /opt/software/gcc-x86_64/gcc-trunk/libexec/gcc/x86_64-unknown-linux-
> gnu/4.5.0/cc1plus
> -fpreprocessed ice-cp_parser_c-342.ii -quiet -dumpbase ice-
> cp_parser_c-342.ii
> -mtune=generic -auxbase ice-cp_parser_c-342 -version -o /tmp/
> ccqQZWYs.s
> GNU C++ (GCC) version 4.5.0 20090412 (experimental) (x86_64-unknown-
> linux-gnu)
>compiled by GNU C version 4.5.0 20090410 (experimental), GMP
> version
> 4.2.2, MPFR version 2.3.1.
> GGC heuristics: --param ggc-min-expand=30 --param ggc-min-
> heapsize=4096
> Compiler executable checksum: b13346d60276f3352c4b7dd22e3889d7
> ice-cp_parser_c-342.ii:6: error: ISO C++ forbids declaration of
> âfâ with no
> type
> ice-cp_parser_c-342.ii:6: error: expected â}â at end of input
> ice-cp_parser_c-342.ii:6: error: expected template-argument at end
> of input
> ice-cp_parser_c-342.ii:6: error: expected â>â at end of input
> ice-cp_parser_c-342.ii:6: error: expected â::â at end of input
> ice-cp_parser_c-342.ii:6: error: expected unqualified-id at end of
> input
> ice-cp_parser_c-342.ii:6: error: expected â;â at end of input
> ice-cp_parser_c-342.ii:6: error: expected â}â at end of input
> ice-cp_parser_c-342.ii:6: internal compiler error: in
> cp_lexer_new_from_tokens,
> at cp/parser.c:342
>
>
> using 4.4.0 or older the compilation terminates with
>
> ice-cp_parser_c-342.ii:6: confused by earlier errors, bailing out
Then this is not a regression :). That message is the same as an ice
but just for releases;).
>
>
>
> --
> Summary: ICE in cp_lexer_new_from_tokens, at cp/parser.c:342
> Product: gcc
> Version: 4.5.0
>Status: UNCONFIRMED
> Severity: normal
> Priority: P3
> Component: c++
>AssignedTo: unassigned at gcc dot gnu dot org
>ReportedBy: gcc at abeckmann dot de
>
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39751
>
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39751
Re: [Bug c++/39751] New: ICE in cp_lexer_new_from_tokens, at cp/parser.c:342
Sent from my iPhone
On Apr 13, 2009, at 7:43 AM, "gcc at abeckmann dot de" > wrote:
This is a 4.5.0 regression on invalid code:
== 8< ==
template < typename >
struct A
{
A < struct
{
f () :
== >8 ==
-- 4.5.0 --
$ x86_64-linux-gnu-g++-trunk -v -c ice-cp_parser_c-342.ii
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure
--prefix=/opt/software/gcc-x86_64/gcc-trunk --program-suffix=-trunk
--enable-languages=c,c++
Thread model: posix
gcc version 4.5.0 20090410 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-c' '-shared-libgcc' '-mtune=generic'
/opt/software/gcc-x86_64/gcc-trunk/libexec/gcc/x86_64-unknown-linux-
gnu/4.5.0/cc1plus
-fpreprocessed ice-cp_parser_c-342.ii -quiet -dumpbase ice-
cp_parser_c-342.ii
-mtune=generic -auxbase ice-cp_parser_c-342 -version -o /tmp/
ccqQZWYs.s
GNU C++ (GCC) version 4.5.0 20090412 (experimental) (x86_64-unknown-
linux-gnu)
compiled by GNU C version 4.5.0 20090410 (experimental), GMP
version
4.2.2, MPFR version 2.3.1.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-
heapsize=4096
Compiler executable checksum: b13346d60276f3352c4b7dd22e3889d7
ice-cp_parser_c-342.ii:6: error: ISO C++ forbids declaration of
‘f’ with no
type
ice-cp_parser_c-342.ii:6: error: expected ‘}’ at end of input
ice-cp_parser_c-342.ii:6: error: expected template-argument at end
of input
ice-cp_parser_c-342.ii:6: error: expected ‘>’ at end of input
ice-cp_parser_c-342.ii:6: error: expected ‘::’ at end of input
ice-cp_parser_c-342.ii:6: error: expected unqualified-id at end of
input
ice-cp_parser_c-342.ii:6: error: expected ‘;’ at end of input
ice-cp_parser_c-342.ii:6: error: expected ‘}’ at end of input
ice-cp_parser_c-342.ii:6: internal compiler error: in
cp_lexer_new_from_tokens,
at cp/parser.c:342
using 4.4.0 or older the compilation terminates with
ice-cp_parser_c-342.ii:6: confused by earlier errors, bailing out
Then this is not a regression :). That message is the same as an ice
but just for releases;).
--
Summary: ICE in cp_lexer_new_from_tokens, at cp/parser.c:342
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at abeckmann dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39751
[Bug c++/39751] ICE in cp_lexer_new_from_tokens, at cp/parser.c:342
--- Comment #2 from hjl dot tools at gmail dot com 2009-04-13 15:04 --- (In reply to comment #1) > Are you *sure* this is a regression? Did you compare to 4.5.0 a 4.4.0 built > with checking *enabled*? > FWIW, gcc 4.4.0 doesn't ICE when checking isn't disabled. But this testcase has been failing since gcc 4.3.0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39751
[Bug c++/39751] ICE in cp_lexer_new_from_tokens, at cp/parser.c:342
--- Comment #1 from paolo dot carlini at oracle dot com 2009-04-13 14:47 --- Are you *sure* this is a regression? Did you compare to 4.5.0 a 4.4.0 built with checking *enabled*? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39751
[Bug c++/39751] New: ICE in cp_lexer_new_from_tokens, at cp/parser.c:342
This is a 4.5.0 regression on invalid code:
== 8< ==
template < typename >
struct A
{
A < struct
{
f () :
== >8 ==
-- 4.5.0 --
$ x86_64-linux-gnu-g++-trunk -v -c ice-cp_parser_c-342.ii
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure
--prefix=/opt/software/gcc-x86_64/gcc-trunk --program-suffix=-trunk
--enable-languages=c,c++
Thread model: posix
gcc version 4.5.0 20090410 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-c' '-shared-libgcc' '-mtune=generic'
/opt/software/gcc-x86_64/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/cc1plus
-fpreprocessed ice-cp_parser_c-342.ii -quiet -dumpbase ice-cp_parser_c-342.ii
-mtune=generic -auxbase ice-cp_parser_c-342 -version -o /tmp/ccqQZWYs.s
GNU C++ (GCC) version 4.5.0 20090412 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.5.0 20090410 (experimental), GMP version
4.2.2, MPFR version 2.3.1.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: b13346d60276f3352c4b7dd22e3889d7
ice-cp_parser_c-342.ii:6: error: ISO C++ forbids declaration of f with no
type
ice-cp_parser_c-342.ii:6: error: expected } at end of input
ice-cp_parser_c-342.ii:6: error: expected template-argument at end of input
ice-cp_parser_c-342.ii:6: error: expected > at end of input
ice-cp_parser_c-342.ii:6: error: expected :: at end of input
ice-cp_parser_c-342.ii:6: error: expected unqualified-id at end of input
ice-cp_parser_c-342.ii:6: error: expected ; at end of input
ice-cp_parser_c-342.ii:6: error: expected } at end of input
ice-cp_parser_c-342.ii:6: internal compiler error: in cp_lexer_new_from_tokens,
at cp/parser.c:342
using 4.4.0 or older the compilation terminates with
ice-cp_parser_c-342.ii:6: confused by earlier errors, bailing out
--
Summary: ICE in cp_lexer_new_from_tokens, at cp/parser.c:342
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at abeckmann dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39751
[Bug testsuite/39749] FAIL: compiler driver -v --help option(s) (assembler options)
--- Comment #4 from hjl dot tools at gmail dot com 2009-04-13 14:22 --- (In reply to comment #3) > Reopening this bug, it is not a duplicate of 39733: > > bug #39733 is about an extra -v added to the argument list of subprocesses, > and is due to gcc.misc-tests/options.exp and lib/options.exp defining the same > functions, and I think is fixed by the patch that HJ posted. I do not know > whether that patch is desirable though: it renames the old function (so there > could be active branches which now use the old function, but after merging > could be using check_for_options from lib/options.exp). > > bug #39749 is, AIUI, a report about passing --help to an assembler on Darwin, > and this as does not understand --help. This is a genuine bug in gcc and/or > as, and is only uncovered, but not caused, by the help.exp tests. > I will bet they are the same bug. One easy way to verify it is to apply my patch for PR 39733 to see if those failures disappear. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39749
[Bug middle-end/39651] New cleanup test failures
--- Comment #2 from danglin at gcc dot gnu dot org 2009-04-13 14:07 --- Fixed. -- danglin at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39651
[Bug testsuite/39749] FAIL: compiler driver -v --help option(s) (assembler options)
--- Comment #3 from rwild at gcc dot gnu dot org 2009-04-13 13:54 --- Reopening this bug, it is not a duplicate of 39733: bug #39733 is about an extra -v added to the argument list of subprocesses, and is due to gcc.misc-tests/options.exp and lib/options.exp defining the same functions, and I think is fixed by the patch that HJ posted. I do not know whether that patch is desirable though: it renames the old function (so there could be active branches which now use the old function, but after merging could be using check_for_options from lib/options.exp). bug #39749 is, AIUI, a report about passing --help to an assembler on Darwin, and this as does not understand --help. This is a genuine bug in gcc and/or as, and is only uncovered, but not caused, by the help.exp tests. -- rwild at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39749
[Bug testsuite/39733] gcc.misc-tests/help.exp doesn't work with multilib
--- Comment #6 from hjl dot tools at gmail dot com 2009-04-13 13:30 ---
(In reply to comment #5)
> HJ, can you please show verbose log output from the failed tests that proves
> that this bug and the other one are indeed duplicates? I don't see why on
> GNU/Linux, as should fail when passed --help
>
-v is added by check_for_options in gcc.misc-tests/options.exp. You can use
# make check-gcc RUNTESTFLAGS="options.exp help.exp --target_board
'unix{-m32,-m32}'"
to see it for yourselves on x86 platforms.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39733
[Bug middle-end/39701] [4.5 Regression] Revision 145846 caused many test failures
--- Comment #15 from hjl dot tools at gmail dot com 2009-04-13 13:18 --- Fixed -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39701
[Bug testsuite/39733] gcc.misc-tests/help.exp doesn't work with multilib
--- Comment #5 from rwild at gcc dot gnu dot org 2009-04-13 13:17 --- HJ, can you please show verbose log output from the failed tests that proves that this bug and the other one are indeed duplicates? I don't see why on GNU/Linux, as should fail when passed --help -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39733
[Bug testsuite/39749] FAIL: compiler driver -v --help option(s) (assembler options)
--- Comment #2 from hjl dot tools at gmail dot com 2009-04-13 13:11 --- *** This bug has been marked as a duplicate of 39733 *** -- hjl dot tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39749
[Bug testsuite/39733] gcc.misc-tests/help.exp doesn't work with multilib
--- Comment #4 from hjl dot tools at gmail dot com 2009-04-13 13:11 --- *** Bug 39749 has been marked as a duplicate of this bug. *** -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||dominiq at lps dot ens dot ||fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39733
[Bug target/39063] libgcc2.c:mprotect() for mingw, incompatible pointer type warning
--- Comment #6 from sezeroz at gmail dot com 2009-04-13 11:55 --- (In reply to comment #4) > The fix may have broken cross compiling: > > http://gcc.gnu.org/ml/gcc/2009-03/msg00525.html > PR39503 has already been closed for some fime, so this one should be closed, too. -- sezeroz at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39063
[Bug target/39397] libiberty/pex-*, inconsistent/incorrect pid_t usage
--- Comment #5 from ktietz at gcc dot gnu dot org 2009-04-13 10:51 --- Applied to gcc's 4.5 (trunk at revision 146001) and binutils/gdb's head. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39397
[Bug target/39397] libiberty/pex-*, inconsistent/incorrect pid_t usage
--- Comment #4 from ktietz at gcc dot gnu dot org 2009-04-13 10:46 --- Subject: Bug 39397 Author: ktietz Date: Mon Apr 13 10:45:58 2009 New Revision: 146001 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146001 Log: 2009-04-13 Ozkan Sezer PR target/39397 * pex-common.h (struct pex_obj): Store pid values as pid_t, not as long (members *children and (*wait)) * pex-common.c (pex_run_in_environment): Likewise. * pex-win32.c (pex_win32_wait): Return pid_t and properly check returned pid value. * pex-djgpp.c (pex_djgpp_wait): Return pid_t. * pex-msdos.c (pex_msdos_wait): Likewise. Modified: trunk/libiberty/ChangeLog trunk/libiberty/pex-common.c trunk/libiberty/pex-common.h trunk/libiberty/pex-djgpp.c trunk/libiberty/pex-msdos.c trunk/libiberty/pex-win32.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39397
[Bug other/39062] libssp/ssp.c needs malloc.h for mingw
--- Comment #4 from ktietz at gcc dot gnu dot org 2009-04-13 10:38 --- Applied to 4.5 at revision 146000. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39062
[Bug other/39062] libssp/ssp.c needs malloc.h for mingw
--- Comment #3 from ktietz at gcc dot gnu dot org 2009-04-13 10:37 --- Subject: Bug 39062 Author: ktietz Date: Mon Apr 13 10:37:17 2009 New Revision: 146000 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146000 Log: 2009-04-13 Ozkan Sezer PR target/39062 * ssp.c: Also include malloc.h for alloca(). MinGW needs it. * configure.ac: Also check for malloc.h. * configure: Regenerated. * config.h.in: Regenerated. Modified: trunk/libssp/ChangeLog trunk/libssp/config.h.in trunk/libssp/configure trunk/libssp/configure.ac trunk/libssp/ssp.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39062
[Bug target/39066] DO_GLOBAL_CTORS_BODY needs uintptr_t
--- Comment #3 from ktietz at gcc dot gnu dot org 2009-04-13 10:12 --- Committed to 4.5 as revision 145999. -- ktietz at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39066
[Bug c++/39750] New: ICE in uses_template_parms, at cp/pt.c:6332
This looks like a ice-on-invalid-code regression in g++ 4.4/4.5:
==
template < unsigned >
struct A ;
template < typename >
struct B ;
template < typename T , A < B < T >
{ }
==
-- 4.4.0 --
$ x86_64-linux-gnu-gcc-4.4.x -v -std=c++0x -c
ice-uses_template_parms-cp_pt.c-6333.ii
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4_4-branch/configure
--prefix=/opt/software/gcc-x86_64/gcc-4.4.x --program-suffix=-4.4.x
--enable-languages=c,c++
Thread model: posix
gcc version 4.4.0 20090410 (prerelease) (GCC)
COLLECT_GCC_OPTIONS='-v' '-std=c++0x' '-c' '-mtune=generic'
/opt/software/gcc-x86_64/gcc-4.4.x/libexec/gcc/x86_64-unknown-linux-gnu/4.4.0/cc1plus
-fpreprocessed ice-uses_template_parms-cp_pt.c-6333.ii -quiet -dumpbase
ice-uses_template_parms-cp_pt.c-6333.ii -mtune=generic -auxbase
ice-uses_template_parms-cp_pt.c-6333 -std=c++0x -version -o /tmp/cc39e69f.s
GNU C++ (GCC) version 4.4.0 20090410 (prerelease) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.4.0 20090410 (prerelease), GMP version
4.2.2, MPFR version 2.3.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 657fe6b0026e91b1c11fd1c9e3d93a45
ice-uses_template_parms-cp_pt.c-6333.ii:7: internal compiler error: in
uses_template_parms, at cp/pt.c:6332
-- 4.5.0 --
$ x86_64-linux-gnu-gcc-trunk -v -std=c++0x -c
ice-uses_template_parms-cp_pt.c-6333.ii
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure
--prefix=/opt/software/gcc-x86_64/gcc-trunk --program-suffix=-trunk
--enable-languages=c,c++
Thread model: posix
gcc version 4.5.0 20090412 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-std=c++0x' '-c' '-mtune=generic'
/opt/software/gcc-x86_64/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/cc1plus
-fpreprocessed ice-uses_template_parms-cp_pt.c-6333.ii -quiet -dumpbase
ice-uses_template_parms-cp_pt.c-6333.ii -mtune=generic -auxbase
ice-uses_template_parms-cp_pt.c-6333 -std=c++0x -version -o /tmp/ccNif1hj.s
GNU C++ (GCC) version 4.5.0 20090412 (experimental) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.5.0 20090410 (experimental), GMP version
4.2.2, MPFR version 2.3.1.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: b13346d60276f3352c4b7dd22e3889d7
ice-uses_template_parms-cp_pt.c-6333.ii:7: internal compiler error: in
uses_template_parms, at cp/pt.c:6333
-- 4.3.x --
$ x86_64-linux-gnu-gcc-4.3.x -v -std=c++0x -c
ice-uses_template_parms-cp_pt.c-6333.ii
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4_3-branch/configure
--prefix=/opt/software/gcc-x86_64/gcc-4.3.x --program-suffix=-4.3.x
--enable-languages=c,c++
Thread model: posix
gcc version 4.3.4 20090410 (prerelease) (GCC)
COLLECT_GCC_OPTIONS='-v' '-std=c++0x' '-c' '-mtune=generic'
/opt/software/gcc-x86_64/gcc-4.3.x/libexec/gcc/x86_64-unknown-linux-gnu/4.3.4/cc1plus
-fpreprocessed ice-uses_template_parms-cp_pt.c-6333.ii -quiet -dumpbase
ice-uses_template_parms-cp_pt.c-6333.ii -mtune=generic -auxbase
ice-uses_template_parms-cp_pt.c-6333 -std=c++0x -version -o /tmp/ccPe9b92.s
GNU C++ (GCC) version 4.3.4 20090410 (prerelease) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.3.4 20090410 (prerelease), GMP version
4.2.2, MPFR version 2.3.1.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: d7de70b1d6112d4a739b8abc5fbe181e
ice-uses_template_parms-cp_pt.c-6333.ii:5: error: template argument 1 is
invalid
ice-uses_template_parms-cp_pt.c-6333.ii:6: error: expected '>' before '{' token
ice-uses_template_parms-cp_pt.c-6333.ii:6: error: expected unqualified-id
before '{' token
--
Summary: ICE in uses_template_parms, at cp/pt.c:6332
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: gcc at abeckmann dot de
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39750
[Bug testsuite/39749] FAIL: compiler driver -v --help option(s) (assembler options)
--- Comment #1 from rwild at gcc dot gnu dot org 2009-04-13 09:44 --- This looks like a genuine bug in the GCC driver or as to me: gcc shouldn't pass on flags to subprocesses if they don't understand them. The testsuite addition just exposed them. How can this as be made to output help? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39749
[Bug testsuite/39749] New: FAIL: compiler driver -v --help option(s) (assembler options)
On i686-apple-darwin9 with -m64 I have the following failures: FAIL: compiler driver --help option(s) (linker options) FAIL: compiler driver -v --help option(s) (assembler options) FAIL: compiler driver -v --help option(s) (linker options) FAIL: compiler driver -v --help option(s) (assembler options) FAIL: compiler driver --help=optimizers option(s) (assembler options) FAIL: compiler driver --help=params option(s) (assembler options) FAIL: compiler driver --help=C option(s) (assembler options) FAIL: compiler driver --help=C++ option(s) (assembler options) FAIL: compiler driver --help=common option(s) (assembler options) FAIL: compiler driver --help=undocumented option(s) (linker options) FAIL: compiler driver --help=^undocumented option(s) (compiler options) FAIL: compiler driver --help=target,undocumented option(s) (linker options) FAIL: compiler driver --help=target,optimizers option(s) (linker options) FAIL: compiler driver --help=warnings,^joined,^undocumented option(s) (linker options) FAIL: compiler driver -Q -O2 --help=optimizers option(s) (compiler options) FAIL: compiler driver -Q -O3 --help=optimizers option(s) (compiler options) FAIL: compiler driver --help=params --help=optimizers option(s) (compiler options) FAIL: compiler driver --help=joined option(s) (assembler options) FAIL: compiler driver --help=separate option(s) (assembler options) FAIL: compiler driver --help=warnings,joined option(s) (assembler options) FAIL: compiler driver --help=warnings,^joined option(s) (assembler options) FAIL: compiler driver --help=joined,separate option(s) (linker options) FAIL: compiler driver --help=^joined,separate option(s) (linker options) FAIL: compiler driver --help=joined,^separate option(s) (linker options) FAIL: compiler driver --help=joined,undocumented option(s) (linker options) FAIL: compiler driver --help=^joined,^separate option(s) (linker options) Looking at the log I see: /Volumes/MacBook/opt/gcc/i686-darwin/gcc/as -arch x86_64 -force_cpusubtype_ALL --help -o /var/folders/iU/iUj3xngxGYe3MPCc0TZUcE+++TI/-Tmp-//ccuHQL7j.o /var/folders/iU/iUj3xngxGYe3MPCc0TZUcE+++TI/-Tmp-//ccrq4DTI.s^M FATAL:/usr/bin/../libexec/gcc/darwin/x86_64/as: I don't understand '-' flag!^M This looks related to the change at revision 145851. See also http://gcc.gnu.org/ml/gcc-testresults/2009-04/msg01229.html -- Summary: FAIL: compiler driver -v --help option(s) (assembler options) Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dominiq at lps dot ens dot fr GCC build triplet: i686-apple-darwin9 GCC host triplet: i686-apple-darwin9 GCC target triplet: i686-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39749
[Bug c/39748] possible bogus offset warning
--- Comment #1 from dcb314 at hotmail dot com 2009-04-13 09:23 --- Created an attachment (id=17624) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17624&action=view) C source code -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39748
[Bug c/39748] New: possible bogus offset warning
I just tried to compile the popular bzip2 package
with the GNU gcc version 4.5 snapshot 20090409.
The compiler said
bzlib.c: In function 'bzopen_or_bzdopen':
bzlib.c:1443: warning: offset '2' outside bounds of constant string
bzlib.c:1443: warning: offset '3' outside bounds of constant string
The source code is
if (path==NULL || strcmp(path,"")==0) {
This looks like a bogus warning to me.
Preprocessed source code attached. No special flags required.
--
Summary: possible bogus offset warning
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dcb314 at hotmail dot com
GCC host triplet: x86_64-suse-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39748
[Bug fortran/35385] gfortran does not support the COCO preprocessor
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2009-04-13 09:22 --- Closing as WONTFIX, see the thread starting at http://gcc.gnu.org/ml/fortran/2009-03/msg00205.html -- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35385
[Bug target/39738] GCC cannot build itself for win64 platform
--- Comment #8 from ktietz at gcc dot gnu dot org 2009-04-13 08:34 --- (In reply to comment #7) > > Please make sure, that you have in your gcc source root directory the > > symbolic > > link "winsup" pointing to your prefix directory. Secondly, make sure you > > have > > the symbolic link "mingw" in your prefix directory, which has to point to > > x86_64-pc-mingw32 directory. > > I use Gentoo Linux x64 as build OS with system compiler gcc 4.3.3, > configuration script arguments you can see in my first post. Both symbolic > links were created.. existing stddef.h file in winsup/mingw/include causes > error: 'NULL' was not declared in this scope during libstdc++ building (see my > earlier post). > > > Yes, there is already one. But this bug is work-a-round by a temporary hack > > in > > our crt. So it shouldn't appear anymore. > Alltimes use -O0 is not the solution.. temporary CRT hacks too. Where I can > get > more information about this bug ? > Why using all time -O0? This bug you reference to is not related to your bootstrap issue. So, the only issue I see here are the following possible reasons (beside the possibility of wrong symbolic links, which you have shown to setup properly). Do you use for native toolchain an fresh initialized directory? Which version of toolchain you are using (especially header-set)? Do you use --prefix and --with-sysroot options? You can try the following. Remove in your directory the folder lib/gcc/x86_64-pc-mingw32/4.4.0/ and remove in your gcc's build directory the x86_64-pc-mingw32 folder. Then do a 'make'. This error can happen also, when the sysroot headers are copied too late (after the 'make all-gcc', because fixinclude get executed already here). Cheers, Kai -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39738
[Bug c/35634] [4.3/4.4/4.5 Regression] operand of pre-/postin-/decrement not promoted
--- Comment #25 from rguenth at gcc dot gnu dot org 2009-04-13 08:19 --- *** Bug 39736 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||edwintorok at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35634
[Bug tree-optimization/39736] signed overflow in loop induction variable: missing warning and wrong code
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-04-13 08:19 --- *** This bug has been marked as a duplicate of 35634 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39736
[Bug libgcj/39747] [4.5/4.5 Regression] libjavamath is linking against libgmp
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-04-13 08:17 --- It is? Anyway, you should build static gmp with -fPIC. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39747
[Bug target/39738] GCC cannot build itself for win64 platform
--- Comment #7 from css20 at mail dot ru 2009-04-13 08:11 --- > Please make sure, that you have in your gcc source root directory the symbolic > link "winsup" pointing to your prefix directory. Secondly, make sure you have > the symbolic link "mingw" in your prefix directory, which has to point to > x86_64-pc-mingw32 directory. I use Gentoo Linux x64 as build OS with system compiler gcc 4.3.3, configuration script arguments you can see in my first post. Both symbolic links were created.. existing stddef.h file in winsup/mingw/include causes error: 'NULL' was not declared in this scope during libstdc++ building (see my earlier post). > Yes, there is already one. But this bug is work-a-round by a temporary hack in > our crt. So it shouldn't appear anymore. Alltimes use -O0 is not the solution.. temporary CRT hacks too. Where I can get more information about this bug ? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39738
[Bug tree-optimization/39736] signed overflow in loop induction variable: missing warning and wrong code
--- Comment #6 from schwab at linux-m68k dot org 2009-04-13 07:53 --- (In reply to comment #4) > But your test program does cause signed overflow No, it doesn't. There is a conversion (from int to short) where the value is not representable by the target type, but that is _not_ undefined, but rather implementation-defined, and GCC has chosen to define the conversion as modulo operation. There is no room for GCC to behave differently. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39736
