[Bug ada/22220] Unable to build gnattools native i586
--- Comment #5 from aoliva at gcc dot gnu dot org 2010-06-23 07:00 --- I've just run into this very problem building i-c.adb on ia64-linux-gnu, using gcc-3.4.6 as the bootstrap compiler to build today's trunk daily bump, r161240. I think I hadn't had Ada enabled on this platform before, so it's the first I saw of it. I had no trouble bootstrapping 4.0.4 with Ada enabled on the same machine, with the same initial compiler, and then I could use the newly-built 4.0.4 to build the trunk as intended. However, gcc/doc/install.texi still says Ada is supposed to build with gcc 3.4, so at the very last we have a documentation problem. The compiler output for i-c.adb looks about the same as the one in the initial description, except that the warnings about the unrecognized Ada_05 pragmas weren't there. -- aoliva at gcc dot gnu dot org changed: What|Removed |Added CC||aoliva at gcc dot gnu dot ||org Status|RESOLVED|REOPENED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=0
[Bug ada/22220] Unable to build gnattools native i586
--- Comment #6 from charlet at gcc dot gnu dot org 2010-06-23 07:09 --- Subject: Bug 0 Author: charlet Date: Wed Jun 23 07:08:46 2010 New Revision: 161255 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161255 Log: PR 0 * doc/install.texi: Update requirements to build GNAT. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/install.texi -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=0
[Bug ada/22220] Unable to build gnattools native i586
--- Comment #7 from charlet at gcc dot gnu dot org 2010-06-23 07:11 --- Doc updated. -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=0
[Bug ada/22220] Unable to build gnattools native i586
--- Comment #8 from charlet at gcc dot gnu dot org 2010-06-23 07:48 --- Subject: Bug 0 Author: charlet Date: Wed Jun 23 07:47:57 2010 New Revision: 161256 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161256 Log: Replace PR 0 by PR ada/0. Modified: trunk/gcc/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=0
[Bug other/44644] New: type/data name clash makes --enable-build-with-cxx cc1 hard to debug
When cc1 is build using --enable-build-with-cxx, it is nigh impossible to debug because the variables insn_data and df share their name with the struct tags of the element / pointed-to data. I believe the struct tags should be renamed, e.g. insn_data_d and df_d. -- Summary: type/data name clash makes --enable-build-with-cxx cc1 hard to debug Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44644
[Bug bootstrap/44433] [meta-bug] --enable-build-with-cxx issues
--- Comment #2 from amylaar at gcc dot gnu dot org 2010-06-23 08:58 --- Should I add PR44644 to the list of PRs blocking this one? Although you can bootstrap gcc without fixing that PR, it causes considerable problems when debugging gcc, and it could be easily fixed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44433
[Bug ada/44633] Incorrect behaviour of gnat make -s flag with -gnatW8
--- Comment #2 from charlet at gcc dot gnu dot org 2010-06-23 09:15 --- Subject: Bug 44633 Author: charlet Date: Wed Jun 23 09:14:55 2010 New Revision: 161264 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161264 Log: 2010-06-23 Thomas Quinot qui...@adacore.com * sem_util.adb: Minor code cleanup: test for proper entity instead of testing just Chars attribute when checking whether a given scope is System. * exp_ch4.adb, einfo.adb: Minor reformatting. 2010-06-23 Vincent Celier cel...@adacore.com PR ada/44633 * switch-m.adb (Normalize_Compiler_Switches): Take into account switches -gnatB, -gnatD=nn, -gnatG (incuding -gnatG=nn), -gnatI, -gnatl=file, -gnatS, -gnatjnn, -gnateI=nn and -gnatWx. 2010-06-23 Ed Schonberg schonb...@adacore.com * sem_res.adb (Resolve_Membership_Op): If left operand is a mixed mode operation with a universal real operand, and the right operand is a range with universal bounds, find unique fixed point that may be candidate, and warn appropriately. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/einfo.adb trunk/gcc/ada/exp_ch4.adb trunk/gcc/ada/sem_res.adb trunk/gcc/ada/sem_util.adb trunk/gcc/ada/switch-m.adb -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44633
[Bug ada/44633] Incorrect behaviour of gnat make -s flag with -gnatW8
--- Comment #3 from charlet at gcc dot gnu dot org 2010-06-23 09:15 --- Fixed on trunk. -- charlet at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44633
[Bug ada/44633] Incorrect behaviour of gnat make -s flag with -gnatW8
--- Comment #4 from pini_os at yahoo dot fr 2010-06-23 09:53 --- (In reply to comment #3) Fixed on trunk. Thanks for the fix and the reactivity. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44633
[Bug other/44644] type/data name clash makes --enable-build-with-cxx cc1 hard to debug
--- Comment #1 from amylaar at gcc dot gnu dot org 2010-06-23 10:08 --- Created an attachment (id=20985) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20985action=view) patch from multi-target-20100613-branch This is the patch that I have just unbundled from multi-target-20100613-branch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44644
[Bug c++/44645] New: [4.5 Regression] wrong debug info for nested typedef
this breaks debugging of std::map and other tree-based containers in the
library, see http://gcc.gnu.org/ml/libstdc++/2010-06/msg00159.html for more
info
$ cat debug2.cc
struct S
{
typedef S* ptr;
ptr p;
};
int main()
{
S s = { };
return !s.p;
}
$ $GCC45/bin/g++ -g -Wl,-R$GCC45/lib64 debug2.cc -o out2-45
$ gdb --quiet ./out2-45
Reading symbols from /tmp/out2-45...done.
(gdb) ptype S
type = struct S {
S::ptr p;
}
(gdb) ptype S::p
type = void *
That type is wrong, it should be S* not void*
GCC 4.4 gets it right, by not tracking the typedef at all:
(gdb) ptype S
type = struct S {
S *p;
}
(gdb) ptype S::p
type = struct S {
S *p;
} *
GCC 4.6 tracks the typedef and gets its type right:
(gdb) ptype S
type = struct S {
S::ptr p;
}
(gdb) ptype S::p
type = struct S {
S::ptr p;
} *
--
Summary: [4.5 Regression] wrong debug info for nested typedef
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: wrong-debug
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: redi at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44645
[Bug target/44643] ice in c-typeck.c
--- Comment #3 from jsm28 at gcc dot gnu dot org 2010-06-23 11:07 --- This is a bug in the AVR back end; if it marks a decl readonly it must also adjust the type of the decl. The problem code is probably in avr_insert_attributes. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Component|c |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44643
[Bug target/18788] -pthreads option with -shared does not cause libpthread.so to be linked in.
-- ro at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |ro at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2005-11-26 01:31:49 |2010-06-23 12:01:58 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18788
[Bug target/18788] -pthreads option with -shared does not cause libpthread.so to be linked in.
--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-06-23 12:07 --- Subject: Re: -pthreads option with -shared does not cause libpthread.so to be linked in. I've found that the Sun Studio compiler behaves the same with its -mt option and asked the maintainers about it: http://mail.opensolaris.org/pipermail/tools-compilers/2010-June/001156.html The relevance of that behavior has gone with the unified process model in Solaris 10, and it's causing me trouble when implementing TLS support for Solaris 8 and 9, so I'm going to fix this for 4.6.0, together with that TLS patch. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18788
[Bug target/44631] [sparc] long long to double conversion error
--- Comment #4 from mikpe at it dot uu dot se 2010-06-23 12:12 --- Created an attachment (id=20986) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20986action=view) test long long to double runtime conversions Making the constant signed rather than unsigned makes no difference. I converted the test case to do the conversions at runtime and to print the hex representations of the long long and double values. Here's some results: gcc -O2 -m32 -mcpu=v8 pr44631.c ; ./a.out 97979797979797980 (0x015c181b6dc019dc) - 9.79798e+16 (0x4375c181b6dc019e) 72057594037927936 (0x0100) - 7.20576e+16 (0x4370) 72057594037927935 (0x00ff) - 7.20576e+16 (0x4370) This looks fine, but the topmost two values have been rounded. gcc -O2 -m32 -mcpu=v9 pr44631.c ; ./a.out 97979797979797980 (0x015c181b6dc019dc) - 2.47804e+17 (0x438b83036db8033c) 72057594037927936 (0x0100) - 1.44115e+17 (0x4380) 72057594037927935 (0x00ff) - 7.20576e+16 (0x4370) Note the discontinuity. Looks to me like fxtod fails to round and instead produces a large jump in the exponent. Does gcc assume some specific setting in FSR? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44631
[Bug fortran/43945] [OOP] Derived type with GENERIC: resolved to the wrong specific TBP
--- Comment #21 from sfilippone at uniroma2 dot it 2010-06-23 12:20 ---
(In reply to comment #20)
(In reply to comment #14)
The attached variation of generic_23 still does not work.
... and the dump shows why:
The specific PPCs of 'foo2' point to the right procedures, but their generic
counterparts don't.
Same thing happens for the code of #19:
struct class$base_sparse_mat class.6;
if (vtab$d_coo_sparse_mat.allocate == 0B)
{
vtab$vtype$d_coo_sparse_mat$allocate.allocate_mnnz =
base_allocate_mnnz;
vtab$d_coo_sparse_mat.allocate = vtab$vtype$d_coo_sparse_mat$allocate;
vtab$d_coo_sparse_mat.allocate_mnnz = (void (*T5b) (void))
d_coo_allocate_mnnz;
vtab$d_coo_sparse_mat.set_null = (void (*T5b) (void)) base_set_null;
vtab$d_coo_sparse_mat.get_fmt = (void (*T5b) (void)) d_coo_get_fmt;
}
class.6.$vptr = (struct vtype$base_sparse_mat *) vtab$d_coo_sparse_mat;
class.6.$data = (struct base_sparse_mat *) acoo;
base_allocate_mnnz (n, n, class.6, nnz);
^
Note the last statement should ultimately be resolved to
vtab$d_coo_sparse_mat.allocate_mnnz
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43945
[Bug target/44640] spu port fails to build with --enable-build-with-cxx
--- Comment #3 from amylaar at gcc dot gnu dot org 2010-06-23 13:19 --- spu patches have been committed to trunk, the remaining issue is PR44512. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44640
[Bug other/44644] type/data name clash makes --enable-build-with-cxx cc1 hard to debug
--- Comment #2 from amylaar at gcc dot gnu dot org 2010-06-23 13:41 --- A patch is here: http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02330.html -- amylaar at gcc dot gnu dot org changed: What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44644
[Bug target/18788] -pthreads option with -shared does not cause libpthread.so to be linked in.
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2010-06-23 13:48 --- The relevance of that behavior has gone with the unified process model in Solaris 10, and it's causing me trouble when implementing TLS support for Solaris 8 and 9, so I'm going to fix this for 4.6.0, together with that TLS patch. I wouldn't break backward compatibility and deviate from Sun Studio just because of the dubious goal of enabling TLS on antiquated Solaris versions. Nobody cares about GCC implementing TLS on those versions in 2010! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18788
[Bug fortran/44646] New: [F2008] Implement DO CONCURRENT
DO [,] CONCURRENT forall-header is a special loop variant with some extra constraints; in particular, it allows the compiler to run through the loop in any index order. That's somewhat similar to FORALL (or at least to how FORALL is perceived) but avoids (a) temporaries (which FORALL often requires), (b) is no assignment feature (like FORALL) but a real loop, which allows for more things in the loop. First step is to implement the syntax and map DO CONCURRENT on a normal loop; I have a embryonic patch for this. Next step is to optimize for DO CONCURRENT (possibly thinking of automatic parallelization during -fopenmp/-ftree-parallelize-loops, etc.) Interpretation requests (main reason for opening this PR): http://j3-fortran.org/doc/meeting/192/10-172.txt http://j3-fortran.org/doc/meeting/192/10-173.txt http://j3-fortran.org/doc/meeting/192/10-175.txt http://j3-fortran.org/doc/meeting/192/10-176.txt -- Summary: [F2008] Implement DO CONCURRENT Product: gcc Version: 4.6.0 Status: UNCONFIRMED 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=44646
[Bug fortran/37336] Fortran 2003: Finish derived-type finalization
--- Comment #3 from burnus at gcc dot gnu dot org 2010-06-23 14:13 --- [Cf. also Corrigenda 1 to 5 (informal collection of these 5 documents) ftp://ftp.nag.co.uk/sc22wg5/N1801-N1850/N1823.pdf (F2008 should incorporate those changes)] Current (on-going) interpretation requests: http://j3-fortran.org/doc/meeting/192/10-158.txt http://j3-fortran.org/doc/meeting/192/10-159.txt http://j3-fortran.org/doc/meeting/192/10-160.txt http://j3-fortran.org/doc/meeting/192/10-161.txt * * * Last patch was http://gcc.gnu.org/ml/fortran/2008-11/msg00229.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336
[Bug fortran/37336] Fortran 2003: Finish derived-type finalization
--- Comment #4 from burnus at gcc dot gnu dot org 2010-06-23 14:21 --- Add another J3 meeting #192 link, which is only a discussion item, but give some idea: http://j3-fortran.org/doc/meeting/192/10-164.txt -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336
[Bug other/44644] type/data name clash makes --enable-build-with-cxx cc1 hard to debug
--- Comment #3 from amylaar at gcc dot gnu dot org 2010-06-23 14:25 --- Subject: Bug 44644 Author: amylaar Date: Wed Jun 23 14:25:33 2010 New Revision: 161281 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161281 Log: PR other/44644 * df-core.c (struct df): Rename to df_d. * df.h (struct df): Likewise. * dse.h (struct df): Remove forward declaration. * recog.h (struct insn_data): Rename to: (struct_insn_data_d). Adjusted all users. Modified: trunk/gcc/ChangeLog trunk/gcc/builtins.c trunk/gcc/config/i386/i386.c trunk/gcc/config/mep/mep.c trunk/gcc/df-core.c trunk/gcc/df.h trunk/gcc/dse.h trunk/gcc/expmed.c trunk/gcc/genoutput.c trunk/gcc/recog.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44644
[Bug libstdc++/44647] New: std::nothrow and std::bad_alloc are coupled
The definitions of std::nothrow, __new_handler and std::bad_alloc are in the same file. This is bad since the std::bad_alloc definition pulls in the exception support. The std::bad_alloc definitions should be placed into a separate file. -- Summary: std::nothrow and std::bad_alloc are coupled Product: gcc Version: 4.4.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sebastian dot huber at embedded-brains dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44647
[Bug libstdc++/44647] std::nothrow and std::bad_alloc are coupled
--- Comment #1 from redi at gcc dot gnu dot org 2010-06-23 14:57 --- (In reply to comment #0) The std::bad_alloc definitions should be placed into a separate file. IIUC that wouldn't work, new is required to declare bad_alloc, so if bad_alloc was moved to a separate file, the parts of the library which need nothrow_t, new_handler and operator new etc. would still have to include new, which would still have to include bad_alloc. The way to achieve what you want is to put everything except bad_alloc in a separate file, and include that file instead of new when bad_alloc is not needed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44647
[Bug libstdc++/44647] std::nothrow and std::bad_alloc are coupled
--- Comment #2 from sebastian dot huber at embedded-brains dot de 2010-06-23 15:02 --- (In reply to comment #1) (In reply to comment #0) The std::bad_alloc definitions should be placed into a separate file. IIUC that wouldn't work, new is required to declare bad_alloc, so if bad_alloc was moved to a separate file, the parts of the library which need nothrow_t, new_handler and operator new etc. would still have to include new, which would still have to include bad_alloc. The way to achieve what you want is to put everything except bad_alloc in a separate file, and include that file instead of new when bad_alloc is not needed. There is nothing wrong with new. The problem is new_handler.cc. Suppose you use #include new int *p = new (std::nothrow) int; this will use the operator new implementation in new_opnt.cc. This one uses __new_handler which is now coupled with std::bad_alloc. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44647
[Bug libstdc++/44647] std::nothrow and std::bad_alloc are coupled
--- Comment #3 from redi at gcc dot gnu dot org 2010-06-23 15:14 --- OK, now I understand what you're suggesting. Confirmed as a valid enhancement request. -- redi at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-23 15:14:45 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44647
[Bug libstdc++/44647] std::nothrow and std::bad_alloc are coupled
--- Comment #4 from sebastian dot huber at embedded-brains dot de 2010-06-23 15:20 --- Created an attachment (id=20987) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20987action=view) Moves std::bad_alloc implementation into new file bad_alloc.cc I don't know how to regenerate the Makefile.in. A simple automake invocation changes a lot in the Makefile.in. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44647
[Bug libstdc++/44647] std::nothrow and std::bad_alloc are coupled
--- Comment #5 from redi at gcc dot gnu dot org 2010-06-23 15:24 --- leave it to me (apart from not including the re-generated autoconf file, your patch doesn't update the Copyright dates) -- redi at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |redi at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-06-23 15:14:45 |2010-06-23 15:24:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44647
[Bug c++/44648] New: missing -Wunused warning on a const variable in if statement
gcc warns about the unused variable on line 3 below but not for the one on line
8. I would expect to see a warning in both cases.
$ cat -n z.cpp g++ -O2 -Wunused z.cpp
1 int main()
2 {
3 if (bool b = 1)
4 return 0;
5 else
6 return 1;
7
8 if (const bool b = 1)
9 return 0;
10 else
11 return 1;
12 }
z.cpp: In function int main():
z.cpp:3: warning: unused variable b
--
Summary: missing -Wunused warning on a const variable in if
statement
Product: gcc
Version: 4.4.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: msebor at gmail dot com
GCC build triplet: all
GCC host triplet: all
GCC target triplet: all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44648
[Bug fortran/44649] New: [OOP] F2008: storage_size intrinsic (also working for polymorphic types)
Cf. F2008: 13.7.160 STORAGE SIZE (A [, KIND]) Description. Storage size in bits. Class. Inquiry function. Arguments. A shall be a scalar or array of any type. If it is polymorphic it shall not be an undefined pointer. If it has any deferred type parameters it shall not be an unallocated allocatable variable or a disassociated or undefined pointer. KIND (optional) shall be a scalar integer constant expression. Similarly to C_SIZEOF, but returns always the size for a scalar and supports dynamic types. Additionally, (C_)SIZEOF return the size in bytes, storage_size in bits. -- Summary: [OOP] F2008: storage_size intrinsic (also working for polymorphic types) Product: gcc Version: 4.6.0 Status: UNCONFIRMED 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=44649
[Bug target/44643] ice in c-typeck.c
--- Comment #4 from weasel at cs dot stanford dot edu 2010-06-23 15:59 --- thanks for the hint about avr_insert_attribute. there's a comment there mumbling: /* ??? This seems sketchy. Why can't the user declare the thing const in the first place? */ when it sets the node's readonly-ness. if i declare the array to have const elements there's no ICE. i guess the 'fix' is to sprinkle const-goodness around the source although it might be nice to have a slightly nicer error message. -- weasel at cs dot stanford dot edu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44643
[Bug c++/44650] New: internal compiler error: in ei_container, at basic-block.h:687
Opensuse 10.2 - gcc -v: ma...@pc-31c:~ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/home/marco/local/gcc-4.5.0/libexec/gcc/x86_64-unknown-linux-gnu/4.5.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../configure --enable-threads=posix --prefix=/home/marco/local/gcc-4.5.0 --enable-shared --enable-__cxa_atexit --enable-libstdcxx-allocator=new --with-cpu=opteron --enable-languages=c,c++,fortran --with-mpfr=/home/marco/local/mpfr-2.4.2 --with-mpc=/home/marco/local/mpc-0.8.1 --enable-gold --enable-lto Thread model: posix gcc version 4.5.0 (GCC) - command line: g++ -c -O2 -funroll-loops -pthread -fstack-check -fPIC -DPIC beam.ii - error message: beam.cc: In member function virtual void ViscoElasticBeam::AssStiffnessMat(FullSubMatrixHandler, FullSubMatrixHandler, doublereal, const VectorHandler, const VectorHandler): beam.cc:2019:1: internal compiler error: in ei_container, at basic-block.h:687 Note that omitting -O2 , i.e. g++ -c -funroll-loops -pthread -fstack-check -fPIC -DPIC beam.ii leads to beam.cc: In member function virtual void Beam::AssStiffnessMat(FullSubMatrixHandler, FullSubMatrixHandler, doublereal, const VectorHandler, const VectorHandler): beam.cc:694:1: warning: frame size too large for reliable stack checking beam.cc:694:1: warning: try reducing the number of local variables beam.cc: In member function virtual void ViscoElasticBeam::AssStiffnessMat(FullSubMatrixHandler, FullSubMatrixHandler, doublereal, const VectorHandler, const VectorHandler): beam.cc:2019:1: warning: frame size too large for reliable stack checking -- Summary: internal compiler error: in ei_container, at basic- block.h:687 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: morandini at aero dot polimi dot it http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44650
[Bug c++/44650] internal compiler error: in ei_container, at basic-block.h:687
--- Comment #1 from morandini at aero dot polimi dot it 2010-06-23 16:02 --- Created an attachment (id=20988) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20988action=view) preprocessed file triggering the bug -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44650
[Bug target/44643] ice in c-typeck.c
--- Comment #5 from jsm28 at gcc dot gnu dot org 2010-06-23 16:35 --- An assertion failure is always a bug. Yes, an error if the object isn't already const would be one valid fix. -- jsm28 at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44643
[Bug fortran/40568] F2008: C_SIZEOF is in the wrong scope, rejected as initialization expression
--- Comment #4 from burnus at gcc dot gnu dot org 2010-06-23 16:45 --- Cf. PR 40569 for two other module procedures of ISO_C_BINDING -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40568
[Bug fortran/40569] F2008: Support COMPILER_OPTIONS() / COMPILER_VERSION()
--- Comment #2 from burnus at gcc dot gnu dot org 2010-06-23 16:46 --- Cf. PR 40568 for C_SIZEOF, a F2008 module procedure of ISO_C_BINDING -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40569
[Bug fortran/44596] [OOP] Dynamic dispatch uses broken types
--- Comment #4 from paul dot richard dot thomas at gmail dot com 2010-06-23 17:36 --- Subject: Re: [OOP] Dynamic dispatch uses broken types Tobias, On Tue, Jun 22, 2010 at 5:00 PM, burnus at gcc dot gnu dot org gcc-bugzi...@gcc.gnu.org wrote: --- Comment #2 from burnus at gcc dot gnu dot org 2010-06-22 15:00 --- CC Paul as he might have an idea how to handle it (cf. comment 1). It's obvious, the vtables for a given class can all be of the same type, thus eliminating the problem. :-) BTW: The mem-ref2 branch (cf. http://gcc.gnu.org/wiki/MemRef ) will be merged soon. Cheers Paul -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44596
[Bug bootstrap/44096] Error because cfns.h is empty
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-06-23 19:39 --- This works for me and many other people. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44096
[Bug c++/44650] internal compiler error: in ei_container, at basic-block.h:687
--- Comment #2 from paolo dot carlini at oracle dot com 2010-06-23 20:20 --- Can you try reducing the reproducer to something more manageable? Here you can find some tips: http://gcc.gnu.org/wiki/A_guide_to_testcase_reduction -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44650
[Bug fortran/44646] [F2008] Implement DO CONCURRENT
-- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||tkoenig at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-23 20:42:48 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44646
[Bug target/44640] spu port fails to build with --enable-build-with-cxx
--- Comment #4 from amylaar at gcc dot gnu dot org 2010-06-23 23:32 --- Subject: Bug 44640 Author: amylaar Date: Wed Jun 23 23:32:38 2010 New Revision: 161299 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161299 Log: PR target/44640 * config/spu/spu-protos.h (spu_expand_epilogue) Use bool. * config/spu/spu.c (spu_scalar_mode_supported_p): Declare with bool. (spu_vector_mode_supported_p, spu_handle_fndecl_attribute): Likewise. (spu_handle_vector_attribute, spu_pass_by_reference): Likewise. (spu_rtx_costs, spu_function_ok_for_sibcall): Likewise. PR target/44640 * config/spu/spu.c (ea_load_store_inline): Use add_reg_note. Modified: branches/multi-target-20100622-branch/gcc/ChangeLog branches/multi-target-20100622-branch/gcc/config/spu/spu-protos.h branches/multi-target-20100622-branch/gcc/config/spu/spu.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44640
[Bug other/44644] type/data name clash makes --enable-build-with-cxx cc1 hard to debug
--- Comment #4 from amylaar at gcc dot gnu dot org 2010-06-23 23:35 --- Subject: Bug 44644 Author: amylaar Date: Wed Jun 23 23:35:04 2010 New Revision: 161300 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161300 Log: PR other/44644 * df-core.c (struct df): Rename to df_d. * df.h (struct df): Likewise. * dse.h (struct df): Remove forward declaration. * recog.h (struct insn_data): Rename to: (struct_insn_data_d). Adjusted all users. Modified: branches/multi-target-20100622-branch/gcc/ChangeLog branches/multi-target-20100622-branch/gcc/builtins.c branches/multi-target-20100622-branch/gcc/config/i386/i386.c branches/multi-target-20100622-branch/gcc/config/mep/mep.c branches/multi-target-20100622-branch/gcc/df-core.c branches/multi-target-20100622-branch/gcc/df.h branches/multi-target-20100622-branch/gcc/dse.h branches/multi-target-20100622-branch/gcc/expmed.c branches/multi-target-20100622-branch/gcc/genoutput.c branches/multi-target-20100622-branch/gcc/recog.h -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44644
[Bug bootstrap/44637] rs6000 port fails to build with --enable-build-with-cxx
--- Comment #1 from amylaar at gcc dot gnu dot org 2010-06-23 23:51 --- Subject: Bug 44637 Author: amylaar Date: Wed Jun 23 23:51:11 2010 New Revision: 161301 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=161301 Log: PR bootstrap/44637 * config/rs6000/rs6000.c (rs6000_xcoff_strip_dollar): Use const char * variable for const char * strchr result. Modified: branches/multi-target-20100622-branch/gcc/ChangeLog branches/multi-target-20100622-branch/gcc/config/rs6000/rs6000.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44637
[Bug testsuite/44651] New: gcc.target/x86_64/abi/callabi/leaf-[1,2].c fail on darwin
The new testcases... r161063 | ktietz | 2010-06-21 03:27:19 -0400 (Mon, 21 Jun 2010) | 6 lines 2010-06-21 Kai Tietz kai.ti...@onevision.com * gcc.target/x86_64/abi/callabi/leaf-1.c: New. * gcc.target/x86_64/abi/callabi/leaf-2.c: New. fail on x86_64-apple-darwin10 as follows... FAIL: gcc.target/x86_64/abi/callabi/leaf-1.c scan-assembler-not %rsp FAIL: gcc.target/x86_64/abi/callabi/leaf-2.c scan-assembler-not %rsp -- Summary: gcc.target/x86_64/abi/callabi/leaf-[1,2].c fail on darwin Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: howarth at nitro dot med dot uc dot edu GCC build triplet: x86_64-apple-darwin10 GCC host triplet: x86_64-apple-darwin10 GCC target triplet: x86_64-apple-darwin10 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44651
[Bug testsuite/44651] gcc.target/x86_64/abi/callabi/leaf-[1,2].c fail on darwin
--- Comment #1 from howarth at nitro dot med dot uc dot edu 2010-06-24 00:59 --- Created an attachment (id=20989) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20989action=view) leaf-1.s from x86_64-apple-darwin10 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44651
[Bug testsuite/44651] gcc.target/x86_64/abi/callabi/leaf-[1,2].c fail on darwin
--- Comment #2 from howarth at nitro dot med dot uc dot edu 2010-06-24 00:59 --- Created an attachment (id=20990) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20990action=view) leaf-2.s from x86_64-apple-darwin10 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44651
[Bug testsuite/44651] gcc.target/x86_64/abi/callabi/leaf-[1,2].c fail on darwin
--- Comment #3 from howarth at nitro dot med dot uc dot edu 2010-06-24 01:00 --- Attached the assembly files generated with... /sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/ /sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100623/gcc/testsuite/gcc.target/x86_64/abi/callabi/leaf-1.c -O2 -mabi=sysv -S -o leaf-1.s /sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc46-4.6.0-1000/darwin_objdir/gcc/ /sw/src/fink.build/gcc46-4.6.0-1000/gcc-4.6-20100623/gcc/testsuite/gcc.target/x86_64/abi/callabi/leaf-2.c -O2 -mabi=sysv -S -o leaf-2.s -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44651
[Bug debug/42648] [4.5/4.6 Regression] gcc.dg/guality/pr41353-1.c FAILs at -On, n 0
--- Comment #10 from aoliva at gcc dot gnu dot org 2010-06-24 03:34 --- I can only duplicate this problem, even on 4.5 branch, using an old version of GDB, on ia64-linux-gnu. With GDB 7.1, it gets the variables as expected. -- aoliva at gcc dot gnu dot org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42648
[Bug middle-end/12392] very long optimized compile
--- Comment #30 from aoliva at gcc dot gnu dot org 2010-06-24 04:01 --- Patch installed on 2009-10-01, assuming fixed. -- aoliva at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12392
