[Bug tree-optimization/29212] ICE with -fipa-pta
--- Comment #12 from jv244 at cam dot ac dot uk 2009-05-28 07:05 --- (In reply to comment #5) > Subject: Re: ICE with -fipa-pta > As the person working on ipa-pta, I'm happy for you to file bug > reports against ipa-pta, but I should warn you that a lot of these > bugs are just going to magically disappear one day when some bug fixes > to other parts of gcc are merged from the ipa-branch :) > A lot are not really ipa-pta bugs, they are just things i have not > worked around because I am waiting for the real fixes to go in. what's the status of the ipa-branch, has it been merged? -- jv244 at cam dot ac dot uk changed: What|Removed |Added CC||dberlin at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29212
[Bug middle-end/33699] [4.3/4.4/4.5 regression], missing optimization on const addr area store
--- Comment #6 from nemet at gcc dot gnu dot org 2009-05-28 07:43 --- Subject: Bug 33699 Author: nemet Date: Thu May 28 07:42:52 2009 New Revision: 147944 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147944 Log: PR middle-end/33699 * target.h (struct gcc_target): Fix indentation. Add const_anchor. * target-def.h (TARGET_CONST_ANCHOR): New macro. (TARGET_INITIALIZER): Use it. * cse.c (CHEAPER): Move it up to the other macros. (insert): Rename this ... (insert_with_costs): ... to this. Add cost parameters. Update function comment. (insert): New function. Call insert_with_costs. (compute_const_anchors, insert_const_anchor, insert_const_anchors, find_reg_offset_for_const, try_const_anchors): New functions. (cse_insn): Call try_const_anchors. Adjust cost of src_related when using a const-anchor. Call insert_const_anchors. * config/mips/mips.c (mips_set_mips16_mode): Set targetm.const_anchor. * doc/tm.texi (Misc): Document TARGET_CONST_ANCHOR. testsuite/ * gcc.target/mips/const-anchor-1.c: New test. * gcc.target/mips/const-anchor-2.c: New test. Added: trunk/gcc/testsuite/gcc.target/mips/const-anchor-1.c trunk/gcc/testsuite/gcc.target/mips/const-anchor-2.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/mips/mips.c trunk/gcc/cse.c trunk/gcc/doc/tm.texi trunk/gcc/target-def.h trunk/gcc/target.h trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33699
[Bug middle-end/33699] [4.3/4.4/4.5 regression], missing optimization on const addr area store
--- Comment #7 from nemet at gcc dot gnu dot org 2009-05-28 07:49 --- Note that the above patch does not yet fix the testcase. Besides this patch we need some more cost adjustments and also some changes in fwprop to propagate into the address expression. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33699
[Bug libstdc++/40278] -std=c++0x is error, but -std=gnu++0x is OK!
--- Comment #6 from dannysmith at users dot sourceforge dot net 2009-05-28 08:26 --- (In reply to comment #4) > Because __STRICT_ANSI__ means strict to the standard so -std=c++0x enables > __STRICT_ANSI__. But the mingw headers don't know about C++0x standard so it > does not know those functions should be enabled. > mingw does not yet provide ANSI (c99) compliant swprintf or vswprintf implementations. The functions it does provide, _swprintf and _vswprintf, are pre-c99 MSVCRT implementations. Danny -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40278
[Bug target/35079] [arm] ICE (segfault) with gfortran -O3 -funroll-loops
--- Comment #4 from mikpe at it dot uu dot se 2009-05-28 08:40 --- (In reply to comment #3) > I just tried this with gfortran 4.3.3 that I have on my ubuntu box. I don't > get > a failure with arm-linux-gnueabi. Can you verify that this still exists with > arm-linux configurations ? This problem looks like a dupe of PR35964 and PR39076. If so then it's probably fixed in current 4.3 branch, and Debian used to backport the fix to their 4.3 compilers which may be why it appears fixed on Ubuntu. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35079
[Bug tree-optimization/40254] [4.5 Regression] SPEC2006 403.gcc miscompares
--- Comment #6 from irar at gcc dot gnu dot org 2009-05-28 09:03 --- Subject: Bug 40254 Author: irar Date: Thu May 28 09:02:53 2009 New Revision: 147945 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147945 Log: PR tree-optimization/40254 * tree-data-ref.c (dr_analyze_innermost): Take POFFSET into account in analysis of basic blocks. Added: trunk/gcc/testsuite/gcc.dg/vect/pr40254.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-data-ref.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40254
[Bug middle-end/40279] [4.3/4.4 Regression] incorrect code generated when testing 31st bit of 64bit integer with optimiaztion on
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-05-28 09:09 --- Confirmed (HWI32 issue). We do a very funny expansion: ;; if (((int) (in >> 31) & 1) != 0) (insn 8 5 6 t.c:10 (clobber (reg:DI 61)) -1 (insn_list:REG_LIBCALL 9 (nil))) (insn 6 8 7 t.c:10 (parallel [ (set (subreg:SI (reg:DI 61) 0) (and:SI (subreg:SI (reg/v:DI 60 [ in ]) 0) (const_int -2147483648 [0x8000]))) (clobber (reg:CC 17 flags)) ]) -1 (expr_list:REG_NO_CONFLICT (reg/v:DI 60 [ in ]) (nil))) (insn 7 6 9 t.c:10 (parallel [ (set (subreg:SI (reg:DI 61) 4) (and:SI (subreg:SI (reg/v:DI 60 [ in ]) 4) (const_int -1 [0x]))) (clobber (reg:CC 17 flags)) ]) -1 (expr_list:REG_NO_CONFLICT (reg/v:DI 60 [ in ]) (nil))) (insn 9 7 10 t.c:10 (set (reg:DI 61) (reg:DI 61)) -1 (insn_list:REG_RETVAL 8 (expr_list:REG_EQUAL (and:DI (reg/v:DI 60 [ in ]) (const_int -2147483648 [0x8000])) (nil (insn 10 9 11 t.c:10 (parallel [ (set (reg:SI 62) (ior:SI (subreg:SI (reg:DI 61) 4) (subreg:SI (reg:DI 61) 0))) (clobber (reg:CC 17 flags)) ]) -1 (nil)) (insn 11 10 12 t.c:10 (set (reg:CCZ 17 flags) (compare:CCZ (reg:SI 62) (const_int 0 [0x0]))) -1 (nil)) must be some "optimization" of narrowed bit-tests. Without TER it is ok (-fno-tree-ter). Trunk seems to be unaffected (likely due to less TER due to expand-from-SSA): (insn 8 7 9 /tmp/t.c:10 (parallel [ (set (reg:DI 64) (lshiftrt:DI (reg/v:DI 63 [ in ]) (const_int 31 [0x1f]))) (clobber (reg:CC 17 flags)) ]) -1 (nil)) (insn 9 8 10 /tmp/t.c:10 (parallel [ (set (reg:SI 65) (and:SI (subreg:SI (reg:DI 64) 0) (const_int 1 [0x1]))) (clobber (reg:CC 17 flags)) ]) -1 (nil)) -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||matz at gcc dot gnu dot org Status|UNCONFIRMED |NEW Component|c |middle-end Ever Confirmed|0 |1 Known to fail||4.1.0 4.3.3 Known to work||3.4.6 4.0.3 Last reconfirmed|-00-00 00:00:00 |2009-05-28 09:09:11 date|| Summary|incorrect code generated|[4.3/4.4 Regression] |when testing 31st bit of|incorrect code generated |64bit integer with |when testing 31st bit of |optimiaztion on |64bit integer with ||optimiaztion on http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40279
[Bug middle-end/40279] [4.3/4.4 Regression] incorrect code generated when testing 31st bit of 64bit integer with optimiaztion on
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40279
[Bug libstdc++/40278] -std=c++0x is error, but -std=gnu++0x is OK!
--- Comment #7 from paolo dot carlini at oracle dot com 2009-05-28 09:10 --- We had a similar issue elsewhere (see [GLIBCXX_CHECK_C99_TR1]). Essentially, the issue has nothing to do with C++0x, instead with GNU mode vs strict ansi mode, and as such is actually *very* old: appears also for -std=c++98 vs -std=gnu++98, but often it's not noticed because people don't use -std=c++98 very often, as far as I know. The point is simply that the configure check for those functions, in [GLIBCXX_ENABLE_WCHAR_T] is carried out with the default C++ compiler, thus including the GNU extensions, that is the -std=gnu++98 behavior. In linux, both modes enable the same wchar_t functions, but that doesn't happen for mingw, apparently. Is this expected? If you want me to change the configure test to use -std=c++98 just let me know. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40278
[Bug middle-end/40282] ICE with -fipa-type-escape
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-28 09:11 --- IPA-type-escape is likely completely broken (and unused - well, used by IPA-struct-reorg which is broken as well ...). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||zadeck at naturalbridge dot ||com Summary|ICE with -fipa-type-escape |ICE with -fipa-type-escape http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40282
[Bug tree-optimization/40254] [4.5 Regression] SPEC2006 403.gcc miscompares
--- Comment #7 from rguenth at gcc dot gnu dot org 2009-05-28 09:12 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40254
[Bug libstdc++/40278] -std=c++0x is error, but -std=gnu++0x is OK!
--- Comment #8 from paolo dot carlini at oracle dot com 2009-05-28 09:14 --- Just wanted to add, that eventually, the new C++ standard will be known to the libc implementations, thus the fact that in it the C99 functions are part of the strict ansi mode of operation. This isn't really something we can or should discuss here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40278
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #60 from davek at gcc dot gnu dot org 2009-05-28 10:48 --- Subject: Bug 37216 Author: davek Date: Thu May 28 10:48:35 2009 New Revision: 147950 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147950 Log: gcc/ChangeLog: 2009-05-28 Dave Korn PR target/37216 * configure.ac (HAVE_GAS_ALIGNED_COMM): Add autoconf test and macro definition for support of three-operand format aligned .comm directive in assembler on cygwin/pe/mingw target OS. * configure: Regenerate. * config.in: Regenerate. * config/i386/winnt.c (i386_pe_asm_output_aligned_decl_common): Use aligned form of .comm directive if -mpe-aligned-commons is in effect. * config/i386/cygming.opt (-mpe-aligned-commons): Add new option. * doc/invoke.texi (-mpe-aligned-commons): Document new target option. * doc/tm.texi (ASM_OUTPUT_COMMON): Document zero size commons. gcc/testsuite/ChangeLog: 2009-05-28 Dave Korn Uros Bizjak Danny Smith PR target/37216 * lib/target-supports.exp (check_effective_target_pe_aligned_commons): New function. * gcc.target/i386/pr37216.c: New test source file. * gcc.dg/compat/struct-layout-1_generate.c (dg_options[]): No longer use -fno-common for testing Cygwin and MinGW targets. Added: trunk/gcc/testsuite/gcc.target/i386/pr37216.c Modified: trunk/gcc/ChangeLog trunk/gcc/config.in trunk/gcc/config/i386/cygming.opt trunk/gcc/config/i386/winnt.c trunk/gcc/configure trunk/gcc/configure.ac trunk/gcc/doc/invoke.texi trunk/gcc/doc/tm.texi trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/compat/struct-layout-1_generate.c trunk/gcc/testsuite/lib/target-supports.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug middle-end/40279] [4.3/4.4 Regression] incorrect code generated when testing 31st bit of 64bit integer with optimiaztion on
--- Comment #2 from jakub at gcc dot gnu dot org 2009-05-28 11:12 --- *** This bug has been marked as a duplicate of 40057 *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40279
[Bug middle-end/40057] Incorrect right shift by 31 with long long
--- Comment #12 from jakub at gcc dot gnu dot org 2009-05-28 11:12 --- *** Bug 40279 has been marked as a duplicate of this bug. *** -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||jisooy at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40057
[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 #9 from dodji at gcc dot gnu dot org 2009-05-28 11:24 --- Subject: Bug 39754 Author: dodji Date: Thu May 28 11:24:18 2009 New Revision: 147951 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147951 Log: Fix for PR c++/PR39754 gcc/cp/ChangeLog: PR c++/39754 * cp-tree.h (canonical_type_variant): Remove this function declaration. (strip_typedefs): New function declaration. * tree.c (strip_typedefs): New function definition. (canonical_type_variant): Remove function definition. * cvt.c (convert_from_reference): No need to use canonical_type_variant. * typeck.c (cp_build_indirect_ref): Likewise. * error.c (dump_template_bindings): Use strip_typedefs instead of canonical_type_variant. * pt.c (convert_template_argument, unify): Likewise. * mangle.c (canonicalize_for_substitution): Don't use canonical_type_variant. gcc/testsuite/ChangeLog: PR c++/39754 * g++.dg/template/canon-type-1.C: New test. * g++.dg/template/canon-type-2.C: Likewise. * g++.dg/template/canon-type-3.C: Likewise. * g++.dg/template/canon-type-4.C: Likewise. * g++.dg/template/canon-type-5.C: Likewise. * g++.dg/template/canon-type-6.C: Likewise. * g++.dg/template/canon-type-7.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/template/canon-type-1.C trunk/gcc/testsuite/g++.dg/template/canon-type-2.C trunk/gcc/testsuite/g++.dg/template/canon-type-3.C trunk/gcc/testsuite/g++.dg/template/canon-type-4.C trunk/gcc/testsuite/g++.dg/template/canon-type-5.C trunk/gcc/testsuite/g++.dg/template/canon-type-6.C trunk/gcc/testsuite/g++.dg/template/canon-type-7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/cvt.c trunk/gcc/cp/error.c trunk/gcc/cp/mangle.c trunk/gcc/cp/pt.c trunk/gcc/cp/tree.c trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39754
[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 #10 from dodji at gcc dot gnu dot org 2009-05-28 12:42 --- Fixed in gcc 4.5. -- dodji at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39754
Re: [Bug c++/40092] -std=gnu++0x expansion pattern fails with error about derived template instead of actual template
On 05/14/09 20:19, cppljevans at suddenlink dot net wrote: --- Comment #4 from cppljevans at suddenlink dot net 2009-05-15 01:19 --- Created an attachment (id=17869) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17869&action=view) Much simpler code showing problem Code has #defines which can be enabled or disabled to show or hide bug. The same error occurs with snapshot: ftp://gcc.gnu.org/pub/gcc/snapshots/4.4-20090519/gcc-4.4-20090519.tar.bz2 The error message is from gcc/cp/pt.c:2692. I suspect there's some problem in find_parameter_packs_r used as arg a few lines up as: cp_walk_tree (&arg, &find_parameter_packs_r, &ppd, ppd.visited); I've tried using gdb stepping to see where the problem is; however, it's so hard to understand the tree structure and which type of tree is supposed to be valid with a given TREE_CODE(t), that I haven't had much success yet. Help on how to debug this would be appreciated.
[Bug c++/40283] New: [C++0x] Context-specific explicit conversion doesn't work
std::unique_ptr has an explicit conversion to
bool operator. However, according to Wikipedia:
http://en.wikipedia.org/wiki/C%2B%2B0x#Explicit_conversion_operators
In C++0x, the explicit keyword can now be applied to conversion operators. As
with constructors, it prevents the use of those conversion functions in
implicit conversions. However, language contexts that specifically require a
boolean value (the conditions of if-statements and loops, as well as operands
to the logical operators) count as explicit conversions and can thus use a bool
conversion operator.
But the following code doen't compile:
#include
#include
int main(int argc, char *argv[]) {
std::unique_ptr p(0);
if (p) {}
return 0;
}
Results in:
$ gcc -std=gnu++0x testcase.cpp
testcase.cpp: In function 'int main(int, char**)':
testcase.cpp:10: error: could not convert 'p' to 'bool'
--
Summary: [C++0x] Context-specific explicit conversion doesn't
work
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: piotr dot wyderski at gmail dot com
GCC host triplet: Cygwin/GCC-trunk rev. 147886
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40283
[Bug c/37985] [4.3/4.4/4.5 Regression] unsigned char shift lacks "statement with no effect" warning
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37985
[Bug debug/40012] [4.5 Regression] Bad debug info for local variables
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-28 14:52 ---
Confirmed.
(gdb) start
Temporary breakpoint 2, main () at dlmod.i:24
24list a3 = { 0 };
(gdb) p &a3
$4 = (list *) 0xd05c
(gdb) n
25f0(0, 0, 0, &a3);
(gdb) s
f0 (a=0x0, b=0x0, c=0x0, d=0xd05c) at dlmod.i:15
15 for(problem = d; problem; problem = problem->next) {
(gdb) n
16int variable = 0;
(gdb) p problem
$5 = (list *) 0x0
(gdb) n
17f1(c, problem);
(gdb) s
f1 (a=0x0, b=0xd05c) at dlmod.i:29
29 void f1(void*a, list*b) { }
(gdb) p b
$6 = (list *) 0xd05c
(gdb) up
#1 0x0804840b in f0 (a=0x0, b=0x0, c=0x0, d=0xd05c) at dlmod.i:17
17f1(c, problem);
(gdb) p problem
$7 = (list *) 0x0
works with 4.4.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Known to fail||4.5.0
Known to work||4.4.0
Priority|P3 |P1
Last reconfirmed|-00-00 00:00:00 |2009-05-28 14:52:09
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40012
[Bug middle-end/40244] [4.5 Regression] Revision147829 caused extra failures
--- Comment #2 from rguenth at gcc dot gnu dot org 2009-05-28 14:53 --- Waiting for HJ. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40244
[Bug middle-end/40253] [4.5 Regression] label emitted for debug has no reference?
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Component|c |middle-end Priority|P3 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40253
[Bug middle-end/40244] [4.5 Regression] Revision147829 caused extra failures
--- Comment #3 from hjl dot tools at gmail dot com 2009-05-28 15:43 --- (In reply to comment #1) > (In reply to comment #0) > > On Linux/ia64, revision 147829: > > http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00806.html > > caused: > > FAIL: Matrix4f -O3 compilation from source > > Could you please provide some information, it doesn't fail on x86_64... > > > FAIL: gcc.dg/vect/bb-slp-10.c scan-tree-dump-times slp "unsupported > > alignment > > in basic block." 1 > > FAIL: gcc.dg/vect/bb-slp-4.c scan-tree-dump-times slp "basic block > > vectorized > > using SLP" 0 > > I think they can be fixed as following. Could you please check? > Please provide a patch as an attachment. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40244
[Bug fortran/40264] Recursive constraint for specific calling same-named generic procedure
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-28 16:02:35 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40264
[Bug libfortran/40267] Eventually get rid of libgfortranbegin.a
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Component|fortran |libfortran Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-28 16:03:12 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40267
[Bug fortran/40264] Recursive constraint for specific calling same-named generic procedure
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |SUSPENDED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40264
[Bug driver/40275] -combine should work for Fortran
--- Comment #3 from steven at gcc dot gnu dot org 2009-05-28 18:15 --- This will never be implemented. -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40275
[Bug ada/38394] [4.3/4.4/4.5 regression] clashing assembler symbols
--- Comment #3 from michael dot voelske at medien dot uni-weimar dot de 2009-05-28 18:24 --- FYI, this issue seems to be fixed in GNAT GPL 2009, released today. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38394
[Bug libstdc++/40094] FAIL: ext/throw_allocator/deallocate_global.cc execution test
--- Comment #14 from bkoz at gcc dot gnu dot org 2009-05-28 18:53 --- Back, and on darwin as well. http://gcc.gnu.org/ml/gcc-testresults/2009-05/msg02455.html http://gcc.gnu.org/ml/gcc-testresults/2009-05/msg02457.html Please hang on while I work through this. -- bkoz at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40094
[Bug libstdc++/40094] FAIL: ext/throw_allocator/deallocate_global.cc execution test
--- Comment #15 from bkoz at gcc dot gnu dot org 2009-05-28 18:53 --- Mine -- bkoz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-05-28 18:53:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40094
[Bug c++/40284] New: regression? ICE (segfault) on invalid virtual dtor in template
on Debian squeeze, Linux 2.6.26-2-amd64 #1 SMP:
The following incorrect code cause g++ to segfault on "g++ (Debian 4.3.3-3)
4.3.3" but not on "g++ (GCC) 4.1.1 20070105 (Red Hat 4.1.1-51)":
// g++ -Wall -save-temps -c bugreport0.cpp
template
struct Registry {
pointer_type pointer;
// copy-paste error should not cause ICE
virtual ~ModuleRegistry() { delete pointer; }
};
struct ModuleRegistry: public Registry {};
compilation log:
g++ -Wall -save-temps -c bugreport0.cpp
bugreport0.cpp:8: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
Compilation exited abnormally with code 1 at Thu May 28 12:03:42
--
Summary: regression? ICE (segfault) on invalid virtual dtor in
template
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: poftwaresatent at gmail dot com
GCC build triplet: x86_64-linux-gnu
GCC host triplet: x86_64-linux-gnu
GCC target triplet: x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40284
[Bug c++/40284] regression? ICE (segfault) on invalid virtual dtor in template
--- Comment #1 from poftwaresatent at gmail dot com 2009-05-28 19:03 --- Created an attachment (id=17925) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17925&action=view) output from -save-temps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40284
[Bug ada/38394] [4.3/4.4 regression] clashing assembler symbols
--- Comment #4 from laurent at guerby dot net 2009-05-28 19:30 --- The issue is present on 4.4.0 gue...@gcc16:~/tmp$ /opt/cfarm/release/4.4.0/bin/gcc -c pkg.adb /tmp/cc6tnj9K.s: Assembler messages: /tmp/cc6tnj9K.s:86: Error: symbol `pkg__foo__T3scc___U' is already defined But fixed on trunk as of revision 147903 -- laurent at guerby dot net changed: What|Removed |Added Known to fail|4.3.2 |4.3.2 4.4.0 Summary|[4.3/4.4/4.5 regression]|[4.3/4.4 regression] |clashing assembler symbols |clashing assembler symbols http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38394
[Bug libstdc++/40094] FAIL: ext/throw_allocator/deallocate_global.cc execution test
--- Comment #16 from paolo dot carlini at oracle dot com 2009-05-28 19:59 --- At least, now we are sure the issue was not caused by my tentative fixes to throw_allocator. -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|bkoz at gcc dot gnu dot org |unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40094
[Bug libstdc++/40094] FAIL: ext/throw_allocator/deallocate_global.cc execution test
--- Comment #17 from paolo dot carlini at oracle dot com 2009-05-28 20:09 --- Sorry. -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |bkoz at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40094
[Bug libstdc++/40094] FAIL: ext/throw_allocator/deallocate_global.cc execution test
--- Comment #18 from dave at hiauly1 dot hia dot nrc dot ca 2009-05-28 20:15 --- Subject: Re: FAIL: ext/throw_allocator/deallocate_global.cc execution test > At least, now we are sure the issue was not caused by my tentative fixes to > throw_allocator. My conclusion was that this is a target bug involving the ordering of atexit and static destructors. The C++ standard apparently requires that these be interleaved based on the order of registration. I don't think it would be possible to achieve full compliance because of the limited capability of atexit, but it might be possible to change the ordering. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40094
[Bug java/35923] gcj: error trying to exec 'ecj1': execvp: No such file or directory
--- Comment #9 from jlquinn at optonline dot net 2009-05-28 20:59 --- Same problem with a clean build of gcc 4.4.0 on fc7 x86_64 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35923
[Bug c++/40284] regression? ICE (segfault) on invalid virtual dtor in template
--- Comment #2 from jakub at gcc dot gnu dot org 2009-05-28 21:01 --- Works with 4.4/trunk (fixed in between r143845 and r144437 on the trunk). Likely PR39225. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40284
[Bug target/38085] gcc -m64 -pg generates invalid assembler code on Solaris 10/x86
--- Comment #1 from mcintosh_shane at emc dot com 2009-05-28 21:01 ---
I can confirm this bug exists when generating position independent code:
-bash-3.00$ uname -a
SunOS bu-navel 5.10 Generic_118855-33 i86pc i386
-bash-3.00$ /usr/sfw/bin/gcc --version
gcc (GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
Copyright (C) 2004 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
-bash-3.00$ cat test.c
int
main(void)
{
}
-bash-3.00$ gcc -fPIC -m64 -pg -o test test.c
/var/tmp//ccAhFbgE.s: Assembler messages:
/var/tmp//ccAhFbgE.s:16: Error: junk `@' after expression
-bash-3.00$ /usr/sfw/bin/gcc -S -fPIC -m64 -pg -o test.s test.c
-bash-3.00$ cat test.s
.file "test.c"
.text
.globl main
.type main, @function
main:
.LFB2:
pushq %rbp
.LCFI0:
movq%rsp, %rbp
.LCFI1:
.data
.align 8
.LP2:
.quad 0
.text
leaq.LP2@(%rip),%r11
call*_mco...@gotpcrel(%rip)
leave
ret
.LFE2:
.size main, .-main
.section.eh_frame,"a",@unwind
.Lframe1:
.long .LECIE1-.LSCIE1
.LSCIE1:
.long 0x0
.byte 0x1
.string "zR"
.uleb128 0x1
.sleb128 -8
.byte 0x10
.uleb128 0x1
.byte 0x1b
.byte 0xc
.uleb128 0x7
.uleb128 0x8
.byte 0x90
.uleb128 0x1
.align 8
.LECIE1:
.LSFDE1:
.long .LEFDE1-.LASFDE1
.LASFDE1:
.long .LASFDE1-.Lframe1
.long .LFB2-.
.long .LFE2-.LFB2
.uleb128 0x0
.byte 0x4
.long .LCFI0-.LFB2
.byte 0xe
.uleb128 0x10
.byte 0x86
.uleb128 0x2
.byte 0x4
.long .LCFI1-.LCFI0
.byte 0xd
.uleb128 0x6
.align 8
.LEFDE1:
.ident "GCC: (GNU) 3.4.3 (csl-sol210-3_4-branch+sol_rpath)"
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38085
[Bug target/37216] [cygming] Invalid alignment for SSE store to .comm data generated with -O3
--- Comment #61 from ubizjak at gmail dot com 2009-05-28 21:45 --- Fixed for 4.5.0. -- ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37216
[Bug libfortran/40267] Eventually get rid of libgfortranbegin.a
--- Comment #1 from burnus at gcc dot gnu dot org 2009-05-28 21:50 --- Before removal, one may deprecate it as explained at: http://gcc.gnu.org/ml/fortran/2009-05/msg00400.html http://gcc.gnu.org/ml/fortran/2009-05/msg00401.html (I needed to remove the , "rd" to get it assemble. And testing did not show an error for linking "file.o libgfortranbegin.a".) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40267
[Bug target/40265] sh2a compiler ICEs in simplify_subreg, at simplify-rtx.c:4960
--- Comment #1 from kkojima at gcc dot gnu dot org 2009-05-28 22:02 --- Fixed. -- kkojima at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40265
[Bug libstdc++/40094] FAIL: ext/throw_allocator/deallocate_global.cc execution test
--- Comment #19 from paolo dot carlini at oracle dot com 2009-05-28 22:25 --- Let's see what Benjamin eventually figures out: he has a lot of experience with such nasty ordering issues... ;) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40094
[Bug target/39856] [4.4/4.5 Regression] ICE in subst_stack_regs_pat, at reg-stack.c:1386
--- Comment #11 from jakub at gcc dot gnu dot org 2009-05-28 22:39 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39856
[Bug ada/40285] New: Including Ada.Real_Time.Timing_Events breaks signal handling
This issue has also been discussed on the comp.lang.ada newsgroup, see [1] for details. Signal-handling using a protected type as handler is not possible any more if an application includes the Ada.Real_Time.Timing_Events package. It's not necessary to actually use types from the package, including it is enough to break signal handling. I wrote a small reproducer to illustrate the problem, the files are attached. The protected object Signal_Handler defined in the package Handlers is used as a signal handler, which can be attached to a specific interrupt/signal. The Signal_Handler type is used in the small test application implemented as procedure Interrupt_Problem in the interrupt_problem.adb file. As expected, when sending SIGTERM (or other signals) to the running 'Interrupt_Problem' process "Interrupt received ..." is displayed. When the Ada.Real_Time.Timing_Events package is included, this mechanism breaks. The signal handler is not invoked any more when signals are sent to a running 'Interrupt_Problem' process, the Handler.Wait entry is not triggered. The problem seems to have various characteristics on different architectures, see the newsgroup thread [1]. gnatgcc -v output: 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) -- [1] - http://groups.google.com/group/comp.lang.ada/browse_thread/thread/e69505d5161d7d41 -- Summary: Including Ada.Real_Time.Timing_Events breaks signal handling Product: gcc Version: 4.3.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: reet at codelabs dot ch GCC build triplet: i486-linux-gnu GCC host triplet: i486-linux-gnu GCC target triplet: i486-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40285
[Bug ada/40285] Including Ada.Real_Time.Timing_Events breaks signal handling
--- Comment #1 from reet at codelabs dot ch 2009-05-28 23:01 --- Created an attachment (id=17926) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17926&action=view) Simple application which uses a protected type for signal handling. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40285
[Bug ada/40285] Including Ada.Real_Time.Timing_Events breaks signal handling
--- Comment #2 from reet at codelabs dot ch 2009-05-28 23:02 --- Created an attachment (id=17927) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17927&action=view) Handlers package spec. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40285
[Bug ada/40285] Including Ada.Real_Time.Timing_Events breaks signal handling
--- Comment #3 from reet at codelabs dot ch 2009-05-28 23:03 --- Created an attachment (id=17928) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17928&action=view) Handlers package body. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40285
[Bug middle-end/40244] [4.5 Regression] Revision147829 caused extra failures
--- Comment #4 from hjl dot tools at gmail dot com 2009-05-28 23:59 --- (In reply to comment #1) > (In reply to comment #0) > > On Linux/ia64, revision 147829: > > http://gcc.gnu.org/ml/gcc-cvs/2009-05/msg00806.html > > caused: > > FAIL: Matrix4f -O3 compilation from source > > Could you please provide some information, it doesn't fail on x86_64... > > > FAIL: gcc.dg/vect/bb-slp-10.c scan-tree-dump-times slp "unsupported > > alignment > > in basic block." 1 > > FAIL: gcc.dg/vect/bb-slp-4.c scan-tree-dump-times slp "basic block > > vectorized > > using SLP" 0 > > I think they can be fixed as following. Could you please check? > Yes, it fixed the problem. Thanks. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40244
[Bug middle-end/40079] [4.5 Regression] Revision 147294 caused extra failures
--- Comment #3 from hjl dot tools at gmail dot com 2009-05-29 00:02 --- Fixed as of revision 147806. -- 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=40079
[Bug libstdc++/40094] FAIL: ext/throw_allocator/deallocate_global.cc execution test
--- Comment #20 from bkoz at gcc dot gnu dot org 2009-05-29 01:13 --- Created an attachment (id=17929) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17929&action=view) reworked version of throw_allocator -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40094
[Bug libstdc++/40094] FAIL: ext/throw_allocator/deallocate_global.cc execution test
--- Comment #21 from bkoz at gcc dot gnu dot org 2009-05-29 01:20 ---
Yeah Paolo, didn't these this was due to your rework. I think the test cases
are ok now, seems like a better starting place although we may need to add
// { dg-require-cxa-atexit "" }
on more of these.
Actually had another idea about reworking throw_allocator, as attached for
trunk at some point. Although hackish, the current version's weird linkage gets
the job done without exports so don't see any need to mess with 4.4 branch.
My plan is to work through the testsuite failures first and then when that dust
settles down then merge in the reworked throw_allocator.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40094
[Bug bootstrap/40250] make bootstrap fails on IRIX64: ar: libbackend.a: Error reading tree-phinodes.o
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-05-29 02:46 --- >The stage2 and stage3 versions of tree-phinodes.o is a lot smaller than the stage1 version: It should be. What happens if you replace tree-phinodes.o from stage2 into stage3 does that help? -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40250
[Bug driver/40251] Using the -V option makes the compiler to exit with 0 exit code on error
--- Comment #1 from pinskia at gcc dot gnu dot org 2009-05-29 02:49 --- I have been noticing weird issues with -V option too like the -o option not being passed correctly and such. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Severity|major |normal Component|c |driver http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40251
[Bug libffi/40242] unsupported asm instructions in libffi/src/arm/sysv.S
--- Comment #2 from pinskia at gcc dot gnu dot org 2009-05-29 02:53 --- http://www.nabble.com/Re:-libFFI-arm-compilation-fails-with-assembly-td20346235.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40242
[Bug fortran/40005] segfault in gt_ggc_mx_lang_tree_node
--- Comment #17 from pinskia at gcc dot gnu dot org 2009-05-29 03:00 --- Yes I am going to be still looking into this. I just had other things to do first. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40005
[Bug debug/40012] [4.5 Regression] Revision 146817 generated bad debug info for local variables
--- Comment #3 from hjl dot tools at gmail dot com 2009-05-29 03:22 --- Revision 146817: http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg01459.html is the cause. -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com, matz at suse dot de Summary|[4.5 Regression] Bad debug |[4.5 Regression] Revision |info for local variables|146817 generated bad debug ||info for local variables http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40012
[Bug bootstrap/40286] New: mkinstalldirs in install-plugin target missing DESTDIR
currently the install-plugin target creates directories in $(plugin_includedir). this is broken wrt DESTDIR and causes a sandbox violation for us (we install into a sandboxed DESTDIR before merging with the live filesystem). the attached patch was sent to gcc-patches but got no response, so i'm filing a PR. I don't have a copyright assignment, but I'm thinking this counts as obvious. https://bugs.gentoo.org/270558 -- Summary: mkinstalldirs in install-plugin target missing DESTDIR Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: dirtyepic at gentoo dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40286
[Bug bootstrap/40286] mkinstalldirs in install-plugin target missing DESTDIR
--- Comment #1 from dirtyepic at gentoo dot org 2009-05-29 04:57 --- Created an attachment (id=17930) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17930&action=view) gcc45-plugin-destdir.patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40286
