[Bug libfortran/34670] bounds checking for array intrinsics
--- Comment #17 from tkoenig at gcc dot gnu dot org 2010-06-04 06:50 --- Subject: Bug 34670 Author: tkoenig Date: Fri Jun 4 06:50:11 2010 New Revision: 160253 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160253 Log: 2010-06-04 Thomas Koenig tkoe...@gcc.gnu.org PR libfortran/34670 * intrinsics/date_and_time.c: Replace assert with runtime_error when VALUE is too small. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/date_and_time.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34670
[Bug libfortran/34670] bounds checking for array intrinsics
--- Comment #18 from tkoenig at gcc dot gnu dot org 2010-06-04 06:51 --- Fixed (finally). Closing. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34670
[Bug fortran/44156] dot_product / matmul and signed zeros
--- Comment #8 from tkoenig at gcc dot gnu dot org 2010-06-04 07:06 --- After the discussion, I think we can close this as WONTFIX. -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44156
[Bug fortran/40452] -fbounds-check: False positive due to ignoring storage association
--- Comment #5 from tkoenig at gcc dot gnu dot org 2010-06-04 07:15 --- Can we close this? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40452
[Bug middle-end/42505] [4.4/4.5/4.6 Regression] loop canonicalization causes a lot of unnecessary temporary variables
--- Comment #5 from steven at gcc dot gnu dot org 2010-06-04 07:45 --- AFAIU, you can't randomly change signed to unsigned, due to different overflow semantics, which is why IVOPTS doesn't make this change itself. Imagine you enter the loop with count = 0, and with a second counter hidden in func. You will not get the same number of iterations if you change the type of count from int to unsigned int. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42505
[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry
--- Comment #30 from jakub at gcc dot gnu dot org 2010-06-04 09:02 --- Created an attachment (id=20833) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20833action=view) rh598310.i.bz2 Another testcase from wine, ./cc1 -m32 -fPIC -fno-strict-aliasing -g -O2 rh598310.i -quiet takes here over 7 minutes, again most of the time spent in find_loc_in_1pdv called from intersect_loc_chains. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug middle-end/42505] [4.4/4.5/4.6 Regression] loop canonicalization causes a lot of unnecessary temporary variables
--- Comment #6 from rguenth at gcc dot gnu dot org 2010-06-04 09:08 --- If the result of the conversion is only used in an exit equality test against a constant it can be dropped. This could also happen in a following forwprop run which is our single tree-combiner (though that currently will combine into comparisons only if the result will be a constant, it doesn't treat defs with a single use specially which it could, if the combined constant is in gimple form). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42505
[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry
--- Comment #31 from jakub at gcc dot gnu dot org 2010-06-04 09:24 --- Created an attachment (id=20834) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20834action=view) limit-depth.patch Quick patch that brings the time down to 1 minute 15 sec. From the callgrind dump on this testcase, intersect_loc_chains in 5159260x cases calls insert_into_intersection in the first loop (i.e. where the recent patch from this PR helps), then calls 320611x find_loc_in_1pdv. Out of these calls, 75537x it returns NULL and the rest of time it returns non-NULL. When it returns non-NULL, it is possible to return non-NULL without recursion 244863x, with one level of find_loc_in_1pdv recursion 205x and with two level recursion 6x. No successful call in this testcase needs deeper recursion. When not limiting the recursion depth, instead just monitoring it, for all cases where find_loc_in_1pdv returned non-NULL the depth at which return node; is used is at most 2 (0 is just find_loc_in_1pdv call with no recursion) and maximum depth ever recursed for the successful calls is 3. I believe the problem of this testcase is not the cases where find_loc_in_1pdv returns non-NULL. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry
--- Comment #32 from jakub at gcc dot gnu dot org 2010-06-04 09:30 --- Created an attachment (id=20835) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20835action=view) hack Hack that shows that the maximum depth is 3 even for the found == NULL cases. Alex tells me on IRC he has the right fix for this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry
--- Comment #33 from aoliva at gcc dot gnu dot org 2010-06-04 09:51 --- Mine -- aoliva at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aoliva at gcc dot gnu dot |dot org |org Status|REOPENED|ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug bootstrap/43847] test for plugin is using wrong objdump for host != target
--- Comment #2 from doko at ubuntu dot com 2010-06-04 09:51 --- having an objdump which supports both the host and the target works around this issue. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43847
[Bug testsuite/43759] The tests gcc.dg/plugindir*.c should be restricted to builds configured with --enable-plugin
--- Comment #4 from doko at ubuntu dot com 2010-06-04 09:53 --- this is fixed on the trunk -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43759
[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry
--- Comment #34 from aoliva at gcc dot gnu dot org 2010-06-04 10:03 --- Created an attachment (id=20836) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20836action=view) Patch that fixes the bug and verifies recursion is bounded as expected This patch (except for comments and ChangeLog) completed stage1 libs, more testing needed. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug lto/44408] FAIL: gcc.dg/lto/20100603-2 c_lto_20100603-2_0.o-c_lto_20100603-2_0.o
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-06-04 11:00 --- Fixed. -- rguenth 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=44408
[Bug lto/41584] WHOPR doesn't grok empty units
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-06-04 11:00 --- Subject: Bug 41584 Author: rguenth Date: Fri Jun 4 11:00:09 2010 New Revision: 160258 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160258 Log: 2010-06-04 Richard Guenther rguent...@suse.de PR lto/41584 * cgraph.h (struct varpool_node): Add lto_file_data field. * lto-cgraph.c (input_varpool_node): Initialize it. lto/ * lto.c (lto_1_to_1_map): Use the proper file_data for varpool nodes. Modified: trunk/gcc/ChangeLog trunk/gcc/cgraph.h trunk/gcc/lto-cgraph.c trunk/gcc/lto/ChangeLog trunk/gcc/lto/lto.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41584
[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry
--- Comment #35 from rguenth at gcc dot gnu dot org 2010-06-04 11:03 --- Created an attachment (id=20837) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20837action=view) bnc611650 Another testcase from open-office this time, on i?86-linux only. $ time g++ -c -g -Os -fomit-frame-pointer analysis.ii real103m46.642s user96m21.093s sys 0m1.196s $ time g++ -c -g -Os analysis.ii real0m19.345s user0m19.177s sys 0m0.168s $ time g++ -c -Os -fomit-frame-pointer analysis.ii real0m3.747s user0m3.640s sys 0m0.104s numbers above are from the 4.5 branch rev. 159866. trunk is also very slow, but the compile didn't yet finish. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry
--- Comment #36 from jakub at gcc dot gnu dot org 2010-06-04 11:15 --- With Alex' patch with checking guarded with #ifdef ENABLE_CHECKING (currently bootstrapping/regtesting that) I see on x86_64 on the trunk: time ./cc1plus -m32 -quiet -g -Os -fomit-frame-pointer bug-611650_analysis.ii real2m16.789s user2m16.333s sys 0m0.276s Of course not ideal, but much better than those 103 minutes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug c++/44412] [4.6 Regression] Another bogus set-but-not-used warning
--- Comment #1 from jakub at gcc dot gnu dot org 2010-06-04 12:03 ---
More complete testcase:
// PR c++/44412
// { dg-do compile }
// { dg-options -Wunused }
struct S
{
static const int a = 3;
static int b;
int c;
};
const int S::a;
int S::b = 4;
int
f1 ()
{
S s;
return s.a;
}
int
f2 ()
{
S s;
return s.b;
}
void
f3 ()
{
S s;
s.c = 6;// { dg-warning set but not used }
}
int
f4 ()
{
S s;
s.c = 6;
return s.c;
}
Guess we should mark the object through which a static data member is accessed,
because that access already marks the object as TREE_USED, yet it is not a set
of the object. Not sure where to do that though. Calling methods or static
methods apparently is handled already, in both cases build_new_method_call
- build_this - cp_build_unary_op ADDR_EXPR - mark_lvalue_use -
mark_exp_read takes care of it:
// PR c++/44412
// { dg-do compile }
// { dg-options -Wunused }
struct S
{
int foo ();
static int bar ();
};
int S::foo ()
{
return 5;
}
int S::bar ()
{
return 6;
}
int
f1 ()
{
S s;
return s.foo ();
}
int
f2 ()
{
S s;
return s.bar ();
}
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
CC||dodji at gcc dot gnu dot
||org, jason at gcc dot gnu
||dot org
Summary|Another bogus set-but-not- |[4.6 Regression] Another
|used warning|bogus set-but-not-used
||warning
Target Milestone|--- |4.6.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44412
[Bug libstdc++/44413] New: inefficient code for std::string::compare on x86-64
This code:
#include string
int foo(const std::string a, const std::string b) { return a.compare(b); }
compiles to code like this on x86-64:
[...]
subq%rdx, %r8
movl$2147483647, %eax
cmpq$2147483647, %r8
jg .L2
movl$-2147483648, %eax
cmpq$-2147483648, %r8
cmovge %r8d, %eax
.L2:
[...]
Since compare need only return a value greater, less, or equal to zero, the
code in _S_compare would be more efficient as simple code that just returns -1,
0, or 1 on most targets where difference_type is wider than int.
--
Summary: inefficient code for std::string::compare on x86-64
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: libstdc++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dgohman at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44413
[Bug fortran/40452] -fbounds-check: False positive due to ignoring storage association
--- Comment #6 from burnus at gcc dot gnu dot org 2010-06-04 12:22 --- Yes, we can CLOSE the bug as FIXED. -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40452
[Bug other/44414] New: hashtab.h functions are undocumented
When I recently needed to use htab_* functions from libiberty's hashtab.h, I found that they are completely undocumented: the comments in the header aren't enough to use them, so I had to look at both the implementation and other uses to figure things out. -- Summary: hashtab.h functions are undocumented Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: documentation Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ro at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44414
[Bug other/44414] hashtab.h functions are undocumented
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-06-04 12:32 --- libiberty has documentation in source libiberty/hashtab.c. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44414
[Bug libgcj/44415] New: [4.6 regression] gmp multilib support broke bootstrap with static libgmp
The recent introduction of this patch 2010-05-29 Mike Stump mikest...@comcast.net * configure.ac: Add multilib support for gmp. Proper -I and -L flags for gmp are added. broke bootstrap on i386-pc-solaris2.11 and almost certainly at least all Solaris 2 platforms with a static libgmp: /bin/ksh ../../../libtool --tag=CC --mode=link /vol/gcc/obj/gcc-4.6.0-20100602/11-gcc/./gcc/xgcc -B/vol/gcc/obj/gcc-4.6.0-20100602/11-gcc/./gcc/ -B/vol/gcc/i386-pc-solaris2.11/bin/ -B/vol/gcc/i386-pc-solaris2.11/lib/ -isystem /vol/gcc/i386-pc-solaris2.11/include -isystem /vol/gcc/i386-pc-solaris2.11/sys-include-W -Wall -Wmissing-declarations -Wwrite-strings -Wmissing-prototypes -Wno-long-long -I/vol/gcc/include -g -O2 -module -version-info 0:0:0 -no-undefined -L/vol/gcc/lib -lgmp -avoid-version -o libjavamath.la -rpath /vol/gcc/lib/gcj-4.6.0-11 gnu_java_math_GMP.lo ../../../native/jni/classpath/jcl.lo -lsocket -lnsl libtool: link: /vol/gcc/obj/gcc-4.6.0-20100602/11-gcc/./gcc/xgcc -B/vol/gcc/obj/gcc-4.6.0-20100602/11-gcc/./gcc/ -B/vol/gcc/i386-pc-solaris2.11/bin/ -B/vol/gcc/i386-pc-solaris2.11/lib/ -isystem /vol/gcc/i386-pc-solaris2.11/include -isystem /vol/gcc/i386-pc-solaris2.11/sys-include-shared -Wl,-z -Wl,text -Wl,-h -Wl,libjavamath.so -o .libs/libjavamath.so .libs/gnu_java_math_GMP.o ../../../native/jni/classpath/.libs/jcl.o -L/vol/gcc/lib /vol/gcc/lib/libgmp.a -lsocket -lnsl -lc Text relocation remains referenced against symbol offset in file .rodata.str1.4 (section)0x2e /vol/gcc/lib/libgmp.a(lt19-get_str.o) [...] The static libgmp is usually non-PIC, while we need PIC code to link libjavamath.so. It turned out to be remarkably difficult to work around this: * While gcc on Solaris supports -mimpure-text to allow linking of non-PIC code into a shared library, all this does is disable the implicit -z text enabled by gcc -shared. Since libtool passes -z text by itself, this doesn't help. * Sun ld doesn't allow -z text -z textoff, so I had to resort to edititing -z text out of libtool and adding -mimpure-text after the -shared there. To fix this for real, one needs to build a PIC libgmp.a, which at the very least needs to be documented. Apart from that, the patch has a couple of other problems: * The ChangeLog entry belongs into classpath/ChangeLog, not libjava/ChangeLog. * For multilibbed targets, it used to be enough to have libgmp for the default multilib. Now you need libgmp for every multilib, otherwise the facitilies between e.g. 32-bit and 64-bit libjavamath.so differ. * There seems to be no provision to pass in -L and -R flags for the non-default multilibs, and neither libtool nor the libjava/classpath make machinery seem to support automatically looking in e.g. $libdir/amd64 for 64-bit multilibs. It seems this needs considerably more work to be complete and useful. -- Summary: [4.6 regression] gmp multilib support broke bootstrap with static libgmp Product: gcc Version: 4.6.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: libgcj AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ro at gcc dot gnu dot org GCC build triplet: *-*-solaris2.* GCC host triplet: *-*-solaris2.* GCC target triplet: *-*-solaris2.* http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44415
[Bug rtl-optimization/42502] [4.4/4.5/4.6 Regression] Bad register allocation in a very simple code
--- Comment #7 from bernds at gcc dot gnu dot org 2010-06-04 12:44 --- Subject: Bug 42502 Author: bernds Date: Fri Jun 4 12:44:01 2010 New Revision: 160260 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160260 Log: PR rtl-optimization/39871 PR rtl-optimization/40615 PR rtl-optimization/42500 PR rtl-optimization/42502 * ira.c (init_reg_equiv_memory_loc: New function. (ira): Call it twice. * reload.h (calculate_elim_costs_all_insns): Declare. * ira-costs.c: Include reload.h. (regno_equiv_gains): New static variable. (init_costs): Allocate it. (finish_costs): Free it. (ira_costs): Call calculate_elim_costs_all_insns. (find_costs_and_classes): Take estimated elimination costs into account. (ira_adjust_equiv_reg_cost): New function. * ira.h (ira_adjust_equiv_reg_cost): Declare it. * reload1.c (init_eliminable_invariants, free_reg_equiv, elimination_costs_in_insn, note_reg_elim_costly): New static functions. (elim_bb): New static variable. (reload): Move code out of here into init_eliminable_invariants and free_reg_equiv. Call them. (calculate_elim_costs_all_insns): New function. (eliminate_regs_1): Declare. Add extra arg FOR_COSTS; all callers changed. If FOR_COSTS is true, don't call alter_reg, but call note_reg_elim_costly if we turned a valid memory address into an invalid one. * Makefile.in (ira-costs.o): Depend on reload.h. testsuite/ PR rtl-optimization/39871 PR rtl-optimization/40615 PR rtl-optimization/42500 PR rtl-optimization/42502 * gcc.target/arm/eliminate.c: New test. Added: trunk/gcc/testsuite/gcc.target/arm/eliminate.c Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/ira-costs.c trunk/gcc/ira.c trunk/gcc/ira.h trunk/gcc/reload.h trunk/gcc/reload1.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42502
[Bug rtl-optimization/42500] Unnecessary mov of sp to a register
--- Comment #6 from bernds at gcc dot gnu dot org 2010-06-04 12:44 --- Subject: Bug 42500 Author: bernds Date: Fri Jun 4 12:44:01 2010 New Revision: 160260 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160260 Log: PR rtl-optimization/39871 PR rtl-optimization/40615 PR rtl-optimization/42500 PR rtl-optimization/42502 * ira.c (init_reg_equiv_memory_loc: New function. (ira): Call it twice. * reload.h (calculate_elim_costs_all_insns): Declare. * ira-costs.c: Include reload.h. (regno_equiv_gains): New static variable. (init_costs): Allocate it. (finish_costs): Free it. (ira_costs): Call calculate_elim_costs_all_insns. (find_costs_and_classes): Take estimated elimination costs into account. (ira_adjust_equiv_reg_cost): New function. * ira.h (ira_adjust_equiv_reg_cost): Declare it. * reload1.c (init_eliminable_invariants, free_reg_equiv, elimination_costs_in_insn, note_reg_elim_costly): New static functions. (elim_bb): New static variable. (reload): Move code out of here into init_eliminable_invariants and free_reg_equiv. Call them. (calculate_elim_costs_all_insns): New function. (eliminate_regs_1): Declare. Add extra arg FOR_COSTS; all callers changed. If FOR_COSTS is true, don't call alter_reg, but call note_reg_elim_costly if we turned a valid memory address into an invalid one. * Makefile.in (ira-costs.o): Depend on reload.h. testsuite/ PR rtl-optimization/39871 PR rtl-optimization/40615 PR rtl-optimization/42500 PR rtl-optimization/42502 * gcc.target/arm/eliminate.c: New test. Added: trunk/gcc/testsuite/gcc.target/arm/eliminate.c Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/ira-costs.c trunk/gcc/ira.c trunk/gcc/ira.h trunk/gcc/reload.h trunk/gcc/reload1.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42500
[Bug rtl-optimization/39871] [4.3/4.4/4.5/4.6 regression] Code size increase on ARM due to poor register allocation
--- Comment #24 from bernds at gcc dot gnu dot org 2010-06-04 12:44 --- Subject: Bug 39871 Author: bernds Date: Fri Jun 4 12:44:01 2010 New Revision: 160260 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160260 Log: PR rtl-optimization/39871 PR rtl-optimization/40615 PR rtl-optimization/42500 PR rtl-optimization/42502 * ira.c (init_reg_equiv_memory_loc: New function. (ira): Call it twice. * reload.h (calculate_elim_costs_all_insns): Declare. * ira-costs.c: Include reload.h. (regno_equiv_gains): New static variable. (init_costs): Allocate it. (finish_costs): Free it. (ira_costs): Call calculate_elim_costs_all_insns. (find_costs_and_classes): Take estimated elimination costs into account. (ira_adjust_equiv_reg_cost): New function. * ira.h (ira_adjust_equiv_reg_cost): Declare it. * reload1.c (init_eliminable_invariants, free_reg_equiv, elimination_costs_in_insn, note_reg_elim_costly): New static functions. (elim_bb): New static variable. (reload): Move code out of here into init_eliminable_invariants and free_reg_equiv. Call them. (calculate_elim_costs_all_insns): New function. (eliminate_regs_1): Declare. Add extra arg FOR_COSTS; all callers changed. If FOR_COSTS is true, don't call alter_reg, but call note_reg_elim_costly if we turned a valid memory address into an invalid one. * Makefile.in (ira-costs.o): Depend on reload.h. testsuite/ PR rtl-optimization/39871 PR rtl-optimization/40615 PR rtl-optimization/42500 PR rtl-optimization/42502 * gcc.target/arm/eliminate.c: New test. Added: trunk/gcc/testsuite/gcc.target/arm/eliminate.c Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/ira-costs.c trunk/gcc/ira.c trunk/gcc/ira.h trunk/gcc/reload.h trunk/gcc/reload1.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39871
[Bug rtl-optimization/40615] unnecessary CSE
--- Comment #7 from bernds at gcc dot gnu dot org 2010-06-04 12:44 --- Subject: Bug 40615 Author: bernds Date: Fri Jun 4 12:44:01 2010 New Revision: 160260 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160260 Log: PR rtl-optimization/39871 PR rtl-optimization/40615 PR rtl-optimization/42500 PR rtl-optimization/42502 * ira.c (init_reg_equiv_memory_loc: New function. (ira): Call it twice. * reload.h (calculate_elim_costs_all_insns): Declare. * ira-costs.c: Include reload.h. (regno_equiv_gains): New static variable. (init_costs): Allocate it. (finish_costs): Free it. (ira_costs): Call calculate_elim_costs_all_insns. (find_costs_and_classes): Take estimated elimination costs into account. (ira_adjust_equiv_reg_cost): New function. * ira.h (ira_adjust_equiv_reg_cost): Declare it. * reload1.c (init_eliminable_invariants, free_reg_equiv, elimination_costs_in_insn, note_reg_elim_costly): New static functions. (elim_bb): New static variable. (reload): Move code out of here into init_eliminable_invariants and free_reg_equiv. Call them. (calculate_elim_costs_all_insns): New function. (eliminate_regs_1): Declare. Add extra arg FOR_COSTS; all callers changed. If FOR_COSTS is true, don't call alter_reg, but call note_reg_elim_costly if we turned a valid memory address into an invalid one. * Makefile.in (ira-costs.o): Depend on reload.h. testsuite/ PR rtl-optimization/39871 PR rtl-optimization/40615 PR rtl-optimization/42500 PR rtl-optimization/42502 * gcc.target/arm/eliminate.c: New test. Added: trunk/gcc/testsuite/gcc.target/arm/eliminate.c Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/ira-costs.c trunk/gcc/ira.c trunk/gcc/ira.h trunk/gcc/reload.h trunk/gcc/reload1.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40615
[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry
--- Comment #37 from rguenth at gcc dot gnu dot org 2010-06-04 12:45 --- Subject: Bug 41371 Author: rguenth Date: Fri Jun 4 12:44:41 2010 New Revision: 160261 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160261 Log: 2010-06-04 Richard Guenther rguent...@suse.de Backport from mainline: 2010-05-18 Jakub Jelinek ja...@redhat.com PR debug/41371 * var-tracking.c (find_loc_in_1pdv): Add a few checks from rtx_equal_p inline. 2010-05-25 Jakub Jelinek ja...@redhat.com PR debug/41371 * var-tracking.c (find_loc_in_1pdv): Guard asserts with ENABLE_CHECKING. (intersect_loc_chains): Walk the s2var's loc_chain together with s1node chain as long as the locations are equal, don't call find_loc_in_1pdv in that case. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/var-tracking.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug libgcj/44415] [4.6 regression] gmp multilib support broke bootstrap with static libgmp
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44415
[Bug testsuite/38946] [4.4/4.5/4.6 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously
--- Comment #16 from ro at gcc dot gnu dot org 2010-06-04 12:53 --- Confirmed: fails for 32-bit and Solaris 10+, unsupported on Solaris 8 and 9. -- ro at gcc dot gnu dot org changed: What|Removed |Added CC||ro at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC target triplet|i386-pc-solaris2.11 |i386-pc-solaris2.1[01] Known to fail||4.4.5 4.5.1 4.6.0 Last reconfirmed|-00-00 00:00:00 |2010-06-04 12:53:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38946
[Bug other/44414] hashtab.h functions are undocumented
--- Comment #2 from ro at gcc dot gnu dot org 2010-06-04 12:58 --- This is not proper documentation: most part of libiberty use comments which can be extracted and put into the .texi files, while hashtab.c does not. -- ro at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WORKSFORME | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44414
[Bug middle-end/44382] Slow integer multiply
--- Comment #2 from hjl dot tools at gmail dot com 2010-06-04 13:08 ---
(In reply to comment #1)
Because our tree reassoc doesn't re-associate them.
The tree reassoc pass makes it slower:
[...@gnu-6 44382]$ cat x.i
extern int a, b, c, d, e, f;
void
foo ()
{
a = (b * c) * (d * e);
}
[...@gnu-6 44382]$ gcc -S -O2 x.i
[...@gnu-6 44382]$ cat x.s
.file x.i
.text
.p2align 4,,15
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
movlc(%rip), %eax
imull b(%rip), %eax
imull d(%rip), %eax
imull e(%rip), %eax
movl%eax, a(%rip)
ret
[...@gnu-6 44382]$ gcc -S -O2 x.i -fno-tree-reassoc
[...@gnu-6 44382]$ cat x.s
.file x.i
.text
.p2align 4,,15
.globl foo
.type foo, @function
foo:
.LFB0:
.cfi_startproc
movlb(%rip), %eax
movld(%rip), %edx
imull c(%rip), %eax
imull e(%rip), %edx
imull %edx, %eax
movl%eax, a(%rip)
ret
[...@gnu-6 44382]$
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44382
[Bug c++/26256] ignores using declaration
-- fabien at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |fabien at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2006-02-13 07:21:15 |2010-06-04 13:13:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26256
[Bug middle-end/44382] Slow integer multiply
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-06-04 13:21 --- Yes, reassoc linearizes instead of building a tree (saves one (or was it two?) registers at best). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44382
[Bug middle-end/44416] New: [4.6 regression] Failed to build 447.dealII in SPEC CPU 2006
On Linux/x86-64, revision 160243 failed to build 447.dealII in SPEC CPU 2006 at -O2 and -O3: g++ -c -o block_vector.o -DSPEC_CPU -DNDEBUG -Iinclude -DBOOST_DISABLE_THREADS -Ddeal_II_dimension=3 -O3 -ffast-math -funroll-loops -DSPEC_CPU_LP64 block_vector.cc In file included from include/lac/block_vector.templates.h:19:0, from block_vector.cc:14: include/lac/block_vector.h:227:17: error: 'ptrdiff_t' does not name a type include/lac/block_vector.h:333:38: error: 'difference_type' does not name a type include/lac/block_vector.h:333:38: note: (perhaps 'typename std::iteratorstd::random_access_iterator_tag, typename internal::BlockVectorIterators::Typesnumber, constness::NumberType::difference_type' was intended) include/lac/block_vector.h:333:54: error: ISO C++ forbids declaration of 'd' with no type [-fpermissive] include/lac/block_vector.h:469:9: error: 'difference_type' does not name a type include/lac/block_vector.h:469:9: note: (perhaps 'typename std::iteratorstd::random_access_iterator_tag, typename internal::BlockVectorIterators::Typesnumber, constness::NumberType::difference_type' was intended) include/lac/block_vector.h:475:9: error: 'difference_type' does not name a type include/lac/block_vector.h:475:9: note: (perhaps 'typename std::iteratorstd::random_access_iterator_tag, typename internal::BlockVectorIterators::Typesnumber, constness::NumberType::difference_type' was intended) include/lac/block_vector.h:482:36: error: 'difference_type' does not name a type include/lac/block_vector.h:482:36: note: (perhaps 'typename std::iteratorstd::random_access_iterator_tag, typename internal::BlockVectorIterators::Typesnumber, constness::NumberType::difference_type' was intended) include/lac/block_vector.h:482:53: error: ISO C++ forbids declaration of 'd' with no type [-fpermissive] include/lac/block_vector.h:489:36: error: 'difference_type' does not name a type include/lac/block_vector.h:489:36: note: (perhaps 'typename std::iteratorstd::random_access_iterator_tag, typename internal::BlockVectorIterators::Typesnumber, constness::NumberType::difference_type' was intended) include/lac/block_vector.h:489:53: error: ISO C++ forbids declaration of 'd' with no type [-fpermissive] include/lac/block_vector.h:496:39: error: 'difference_type' does not name a type include/lac/block_vector.h:496:39: note: (perhaps 'typename std::iteratorstd::random_access_iterator_tag, typename internal::BlockVectorIterators::Typesnumber, constness::NumberType::difference_type' was intended) include/lac/block_vector.h:496:56: error: ISO C++ forbids declaration of 'd' with no type [-fpermissive] include/lac/block_vector.h:503:39: error: 'difference_type' does not name a type include/lac/block_vector.h:503:39: note: (perhaps 'typename std::iteratorstd::random_access_iterator_tag, typename internal::BlockVectorIterators::Typesnumber, constness::NumberType::difference_type' was intended) include/lac/block_vector.h:503:56: error: ISO C++ forbids declaration of 'd' with no type [-fpermissive] include/lac/block_vector.h:1494:52: error: 'difference_type' does not name a type include/lac/block_vector.h:1494:52: note: (perhaps 'typename std::iteratorstd::random_access_iterator_tag, typename internal::BlockVectorIterators::Typesnumber, constness::NumberType::difference_type' was intended) include/lac/block_vector.h:1494:68: error: ISO C++ forbids declaration of 'd' with no type [-fpermissive] include/lac/block_vector.h:1727:5: error: prototype for 'typename internal::BlockVectorIterators::Iteratornumber, constness::difference_type internal::BlockVectorIterators::Iteratornumber, constness::operator-(const internal::BlockVectorIterators::Iteratornumber, constness) const' does not match any in class 'internal::BlockVectorIterators::Iteratornumber, constness' include/lac/block_vector.h:489:18: error: candidate is: internal::BlockVectorIterators::Iteratornumber, constness internal::BlockVectorIterators::Iteratornumber, constness::operator-(const int) const include/lac/block_vector.h:1741:5: error: prototype for 'typename internal::BlockVectorIterators::Iteratornumber, constness::difference_type internal::BlockVectorIterators::Iteratornumber, constness::operator-(const InverseConstnessIterator) const' does not match any in class 'internal::BlockVectorIterators::Iteratornumber, constness' include/lac/block_vector.h:489:18: error: candidate is: internal::BlockVectorIterators::Iteratornumber, constness internal::BlockVectorIterators::Iteratornumber, constness::operator-(const int) const include/lac/block_vector.h:1756:23: error: 'difference_type' does not name a type include/lac/block_vector.h:1756:23: note: (perhaps 'typename std::iteratorstd::random_access_iterator_tag, typename internal::BlockVectorIterators::Typesnumber, constness::NumberType::difference_type' was intended) include/lac/block_vector.h:1756:40: error: ISO C++ forbids declaration of 'd' with no type [-fpermissive] include/lac/block_vector.h:1781:23: error:
[Bug middle-end/44416] [4.6 regression] Failed to build 447.dealII in SPEC CPU 2006
-- hjl dot tools at gmail dot com changed: What|Removed |Added Target Milestone|--- |4.6.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44416
[Bug middle-end/44416] [4.6 regression] Failed to build 447.dealII in SPEC CPU 2006
--- Comment #1 from hjl dot tools at gmail dot com 2010-06-04 13:26 --- It may be caused by revision 160231: http://gcc.gnu.org/ml/gcc-cvs/2010-06/msg00144.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||paolo dot carlini at oracle ||dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44416
[Bug middle-end/44416] [4.6 regression] Failed to build 447.dealII in SPEC CPU 2006
--- Comment #2 from paolo dot carlini at oracle dot com 2010-06-04 13:42 --- I do not have access to those benchmarks. Whoever has, should check that ptrdiff_t is used properly, either after including cstddef, then it can be used both qualified with std:: and unqualified together with v3, or qualified with std:: after essentially after including any other c++ header. For sure the c++ standard doesn't warrant more than the above. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44416
[Bug libstdc++/44417] New: make check-target-libstdc++-v3 fails due to undefined ptrdiff_t
make check-target-libstdc++-v3 fails because ptrdiff_t is undefined. std::ptrdiff_t works. Maybe this bug is related to the Linux system run on. I have openSuse 11.1 running. configure --enable-languages=c,c++ --program-suffix=-rep --prefix=$HOME/gcc/install_trunk_1 In file included from /home/singler/gcc/trunk_1/libstdc++-v3/testsuite/util/testsuite_abi.h:27:0, from /home/singler/gcc/trunk_1/libstdc++-v3/testsuite/util/testsuite_abi.cc:23: /home/singler/gcc/trunk_1/libstdc++-v3/libsupc++/cxxabi.h:371:5: error: 'ptrdiff_t' does not name a type /home/singler/gcc/trunk_1/libstdc++-v3/libsupc++/cxxabi.h:447:23: error: 'ptrdiff_t' has not been declared /home/singler/gcc/trunk_1/libstdc++-v3/libsupc++/cxxabi.h:459:18: error: 'ptrdiff_t' has not been declared /home/singler/gcc/trunk_1/libstdc++-v3/libsupc++/cxxabi.h:469:26: error: 'ptrdiff_t' has not been declared /home/singler/gcc/trunk_1/libstdc++-v3/libsupc++/cxxabi.h:495:18: error: 'ptrdiff_t' has not been declared /home/singler/gcc/trunk_1/libstdc++-v3/libsupc++/cxxabi.h:501:26: error: 'ptrdiff_t' has not been declared /home/singler/gcc/trunk_1/libstdc++-v3/libsupc++/cxxabi.h:540:18: error: 'ptrdiff_t' has not been declared /home/singler/gcc/trunk_1/libstdc++-v3/libsupc++/cxxabi.h:546:26: error: 'ptrdiff_t' has not been declared /home/singler/gcc/trunk_1/libstdc++-v3/libsupc++/cxxabi.h:566:4: error: 'ptrdiff_t' has not been declared compiler exited with status 1 Any ideas and/or a workaround? -- Summary: make check-target-libstdc++-v3 fails due to undefined ptrdiff_t Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: singler at kit dot edu GCC build triplet: x86_64-unknown-linux-gnu GCC host triplet: x86_64-unknown-linux-gnu GCC target triplet: x86_64-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44417
[Bug libstdc++/44417] make check-target-libstdc++-v3 fails due to undefined ptrdiff_t
--- Comment #1 from paolo dot carlini at oracle dot com 2010-06-04 13:49 --- I can't reproduce this. I booted and tested many times on various linux systems and HJ already reported many succesfull testresults since. Please remove everything from the build dir, gave everything fresh and retry. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44417
[Bug middle-end/44382] Slow integer multiply
--- Comment #4 from hjl dot tools at gmail dot com 2010-06-04 13:56 --- (In reply to comment #3) Yes, reassoc linearizes instead of building a tree (saves one (or was it two?) registers at best). Should we always build a tree? It may increase register pressure. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44382
[Bug c++/44412] [4.6 Regression] Another bogus set-but-not-used warning
--- Comment #2 from jakub at gcc dot gnu dot org 2010-06-04 14:12 --- Created an attachment (id=20838) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20838action=view) gcc46-pr44412.patch Untested patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44412
[Bug libstdc++/44417] make check-target-libstdc++-v3 fails due to undefined ptrdiff_t
--- Comment #2 from singler at kit dot edu 2010-06-04 14:16 --- I had cleaned the builddir already. Adding #include cstddef solves the problem. The crucial file seems to be lib/gcc/x86_64-unknown-linux-gnu/4.6.0/include/stddef.h Only if it is (indirectly) included, ptrdiff_t is defined in the global scope. Maybe on other systems, ptrdiff_t is also declared somewhere else, so the problem does not appear. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44417
[Bug middle-end/44416] [4.6 regression] Failed to build 447.dealII in SPEC CPU 2006
--- Comment #3 from singler at kit dot edu 2010-06-04 14:19 --- Bug 44417 is very likely to have the same cause, but here, we can reproduce it more easily, using the testsuite. *** This bug has been marked as a duplicate of 44417 *** -- singler at kit dot edu changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44416
[Bug libstdc++/44417] make check-target-libstdc++-v3 fails due to undefined ptrdiff_t
--- Comment #3 from singler at kit dot edu 2010-06-04 14:19 --- *** Bug 44416 has been marked as a duplicate of this bug. *** -- singler at kit dot edu changed: What|Removed |Added CC||hjl dot tools at gmail dot ||com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44417
[Bug libstdc++/44417] make check-target-libstdc++-v3 fails due to undefined ptrdiff_t
--- Comment #4 from paolo dot carlini at oracle dot com 2010-06-04 14:23 --- To be clear: does a normal 'make check' (either from the root of the build dir or from inside the library build dir) work? Because it works here and fo everybody else on the testresult mailing list, also for people using your exact same linux. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44417
[Bug libstdc++/44417] make check-target-libstdc++-v3 fails due to undefined ptrdiff_t
--- Comment #5 from paolo dot carlini at oracle dot com 2010-06-04 14:28 --- Hey, 44416 is *not* a duplicate! Please re-open it immediately. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44417
[Bug middle-end/44416] [4.6 regression] Failed to build 447.dealII in SPEC CPU 2006
--- Comment #4 from paolo dot carlini at oracle dot com 2010-06-04 14:29 --- Not a duplicate, another issue. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|DUPLICATE | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44416
[Bug lto/42776] LTO doesn't work on non-ELF platforms.
--- Comment #49 from ro at gcc dot gnu dot org 2010-06-04 14:33 --- Subject: Bug 42776 Author: ro Date: Fri Jun 4 14:32:19 2010 New Revision: 160269 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160269 Log: Backport from mainline: 2010-04-27 Dave Korn dave.korn.cyg...@gmail.com PR lto/42776 * lib/lto.exp (lto_prune_vis_warns): New function. (lto-link-and-maybe-run): Call it. 2010-05-10 Rainer Orth r...@cebitec.uni-bielefeld.de * lib/lto.exp (lto_prune_vis_warns): Renamed to lto_prune_warns. Log text on entry and exit. Prune Sun ld warnings for common symbols with differing sizes. (lto-link-and-maybe-run): Change caller. Modified: branches/gcc-4_5-branch/gcc/testsuite/ChangeLog branches/gcc-4_5-branch/gcc/testsuite/lib/lto.exp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776
[Bug middle-end/44382] Slow integer multiply
--- Comment #5 from hjl dot tools at gmail dot com 2010-06-04 14:40 --- tree-ssa-reassoc.c has 2. Left linearization of the expression trees, so that (A+B)+(C+D) becomes (((A+B)+C)+D), which is easier for us to rewrite later. During linearization, we place the operands of the binary expressions into a vector of operand_entry_t I think this may always generate slower codes. We may not want to use much more registers. We can limit us to 2 temporaries. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44382
[Bug libstdc++/44417] make check-target-libstdc++-v3 fails due to undefined ptrdiff_t
--- Comment #6 from paolo dot carlini at oracle dot com 2010-06-04 14:52 --- Note that cxxabi.h already includes stddef.h and at that line 371 uses ptrdiff_t unqualified, thus everything is fine. I suspect you simply forgot to update your compiler, because the current library does not work without a recent front end fix applied by Jason. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44417
[Bug libstdc++/44417] make check-target-libstdc++-v3 fails due to undefined ptrdiff_t
--- Comment #7 from paolo dot carlini at oracle dot com 2010-06-04 14:55 --- Closing. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44417
[Bug middle-end/44416] [4.6 regression] Failed to build 447.dealII in SPEC CPU 2006
--- Comment #5 from jwakely dot gcc at gmail dot com 2010-06-04 14:56 --- I don't have the SPEC benchmarks either, but probably deal.II uses ptrdiff_t unqualified, without explicitly including either cstddef or stddef.h http://www.dealii.org/developer/doxygen/deal.II/block__vector_8h.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44416
[Bug middle-end/44416] [4.6 regression] Failed to build 447.dealII in SPEC CPU 2006
--- Comment #6 from jwakely dot gcc at gmail dot com 2010-06-04 15:00 --- certainly true for an older version http://ganymed.iwr.uni-heidelberg.de/~deal/5.2.0/doxygen/deal.II/block__vector_8h.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44416
[Bug c/25880] improve message of warning for discarding qualifiers
--- Comment #3 from manu at gcc dot gnu dot org 2010-06-04 15:16 --- Subject: Bug 25880 Author: manu Date: Fri Jun 4 15:15:38 2010 New Revision: 160274 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160274 Log: 2010-06-04 Manuel López-Ibáñez m...@gcc.gnu.org PR c/25880 * c-objc-common.c (c_tree_printer): Handle %V, %v and %#v. * c-format.c (gcc_diag_flag_specs): Add hash. (gcc_cxxdiag_flag_specs): Use gcc_diag_flag_specs directly. (gcc_tdiag_char_table,gcc_cdiag_char_table): Handle %V and %v. * c-pretty-print.c (pp_c_cv_qualifier): Rename as pp_c_cv_qualifiers. Handle qualifiers spelling here. (pp_c_type_qualifier_list): Call the function above. * c-pretty-print.h (pp_c_cv_qualifiers): Declare. * c-typeck.c (handle_warn_cast_qual): Print qualifiers. (WARN_FOR_QUALIFIERS): New macro. (convert_for_assignment): Use it. testsuite/ * gcc.dg/assign-warn-2.c: Update. * gcc.dg/cpp/line3.c: Update. * gcc.dg/c99-array-lval-8.c: Update. * gcc.dg/cast-qual-2.c: Update. * gcc.dg/c99-arraydecl-3.c: Update. * gcc.dg/assign-warn-1.c: Update. * gcc.dg/format/gcc_diag-1.c: Update. Modified: trunk/gcc/ChangeLog trunk/gcc/c-format.c trunk/gcc/c-objc-common.c trunk/gcc/c-pretty-print.c trunk/gcc/c-pretty-print.h trunk/gcc/c-typeck.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.dg/assign-warn-1.c trunk/gcc/testsuite/gcc.dg/assign-warn-2.c trunk/gcc/testsuite/gcc.dg/c99-array-lval-8.c trunk/gcc/testsuite/gcc.dg/c99-arraydecl-3.c trunk/gcc/testsuite/gcc.dg/cast-qual-2.c trunk/gcc/testsuite/gcc.dg/cpp/line3.c trunk/gcc/testsuite/gcc.dg/format/gcc_diag-1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25880
[Bug lto/40702] lto-elf.c fails to compile on Solaris
--- Comment #12 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-06-04 15:21 --- Subject: Re: lto-elf.c fails to compile on Solaris --- Comment #11 from rguenth at gcc dot gnu dot org 2010-06-03 13:47 --- The problem seems to have vanished, so eventually the fix can be backported (together with the typo fix in the configure script obviously). Done: I've run toplevel configure and make configure-gcc on both i386-pc-solaris2.11 (which has the new elf_getshdrstrndx) and i386-pc-solaris2.10 (which only has the non-conformant version of elf_getshstrndx) and got the expected results (and no error in gcc/config.log), so I've check this in. Should we ever receive more information for bootstrap/44079, we can either fix the configure tests or document the required version of elfutils libelf. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40702
[Bug c/25880] improve message of warning for discarding qualifiers
--- Comment #4 from manu at gcc dot gnu dot org 2010-06-04 15:21 --- The infrastructure to enable this has been added in GCC 4.6 and some diagnostics are already making use of it, in particular the one reported here. So I consider this FIXED. If anyone finds particular diagnostics that should explicitly print qualifiers, they just need to use %qV, %qv or %q#v to do so. In that case, reopen this PR or open a new one. Patches are also welcome. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25880
[Bug c++/44244] Provide -f flags to turn on individual C++0x features
--- Comment #2 from manu at gcc dot gnu dot org 2010-06-04 15:50 --- I am going to close this as WONTFIX for the following reasons: * We do not want this because: a) We have too many options. b) These options would be of very limited and temporary use but we will have to support them forever. c) c++0x features are spread all over the compiler - this is hard to implement properly as an after-thought. d) The additional checking will slow down the compiler for no significant gain. We are too slow already. * We have too many open PRs, so it is not worth it to keep this open just in case. Sorry about this but I hope you can understand. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44244
[Bug middle-end/44307] warning: may be used uninitialized in this function often building gcc
--- Comment #4 from manu at gcc dot gnu dot org 2010-06-04 15:56 --- Hi Jay, -Wuninitialized is quite unreliable in old compilers and also we do not know what patches Apple applies to its copy of GCC. This is why -Werror is not used in the first stage of building GCC. We do not see these warnings with recent GCC, so I guess they are bogus. If you find a real (potential) uninitialized use, please reopen this PR and point us to the code. Otherwise, fixing this is not worth the effort of anyone. There is a lot more interesting (and urgently needed) work to do in GCC. I am sure Richard Guenther could have fixed a couple of real bugs in the time it took him to read this PR ;). Thanks for the report anyway. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44307
[Bug web/44269] Search for PR number in mailing lists fails
--- Comment #1 from manu at gcc dot gnu dot org 2010-06-04 15:59 --- Who is in charge of GCC infrastructure (wiki, mailing lists, bugzilla)? I am afraid there is no one, so this is not going to be fixed soon. Meanwhile use Google. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-04 15:59:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44269
[Bug c++/44285] Need an option that will create symbols for all public c++ methods, not only for those which bodies are outside the class declaration
--- Comment #8 from manu at gcc dot gnu dot org 2010-06-04 16:03 --- As mentioned in the comments above, there is an easy way to achieve this already without needing to make the compiler more complex and slower. So I will close this as WONTFIX. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44285
[Bug c++/44172] Compiling never ends
--- Comment #5 from manu at gcc dot gnu dot org 2010-06-04 16:11 --- Please fellow GCC maintainers, after checking that a bug is indeed a bug, please set the status to NEW. What more than 1000 unconfirmed reports! -- manu at gcc dot gnu dot org changed: What|Removed |Added CC||manu at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-04 16:11:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44172
[Bug middle-end/44307] warning: may be used uninitialized in this function often building gcc
--- Comment #5 from jay dot krell at cornell dot edu 2010-06-04 16:20 --- Then don't use when I -disable-bootstrap.. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44307
[Bug middle-end/44307] warning: may be used uninitialized in this function often building gcc
--- Comment #6 from manu at gcc dot gnu dot org 2010-06-04 16:22 --- (In reply to comment #5) Then don't use when I -disable-bootstrap.. Do you mean that -Werror is used when you disable-bootstrap? If so, I think that is a bug. Or you mean to not use warnings? I think that would be a nice enhancement, yes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44307
[Bug middle-end/44307] warning: may be used uninitialized in this function often building gcc
--- Comment #7 from jay dot krell at cornell dot edu 2010-06-04 16:30 --- I mean -Wuninitialized. -Werror is already omitted. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44307
[Bug middle-end/44416] [4.6 regression] Failed to build 447.dealII in SPEC CPU 2006
--- Comment #7 from bangerth at gmail dot com 2010-06-04 16:36 --- As the author of the benchmark I can confirm that we apparently forgot to include the proper header file. So you can call it a defect in 447.dealII. The question is how to deal with this, of course. W. -- bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44416
[Bug bootstrap/44307] do not enable warnings when building with the host compiler
--- Comment #8 from manu at gcc dot gnu dot org 2010-06-04 16:36 --- -Wuninitialized is enabled by -Wall (or perhaps -Wextra), not explicitly. I think we should not enable any warnings when building with the host compiler, unless the user requests them. It is probably faster and would produce less clutter in the output. But I don't have enough time to provide a patch to fix this, and I doubt any main developer considers this a priority. -- manu at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Component|middle-end |bootstrap Resolution|WONTFIX | Summary|warning: may be used|do not enable warnings when |uninitialized in this |building with the host |function often building gcc |compiler http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44307
[Bug tree-optimization/44258] [4.5/4.6 Regression] possible SRA wrong-code generation.
--- Comment #7 from maksim at kde dot org 2010-06-04 16:38 --- Created an attachment (id=20839) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20839action=view) Preprocessed source Actually, never mind that --- got it on x86-64 from an another KDEer (credit to Alex Fiestas). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44258
[Bug middle-end/44416] [4.6 regression] Failed to build 447.dealII in SPEC CPU 2006
--- Comment #8 from hjl dot tools at gmail dot com 2010-06-04 16:40 --- (In reply to comment #7) As the author of the benchmark I can confirm that we apparently forgot to include the proper header file. So you can call it a defect in 447.dealII. The question is how to deal with this, of course. I will prepare an alt src. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44416
[Bug tree-optimization/44406] wrong code generation with -ftree-sra
--- Comment #3 from jamborm at gcc dot gnu dot org 2010-06-04 16:42 --- Thanks for a nice testcase. I've been looking at this briefly today and so far I am inclined to say that this is not SRA's fault. First, I have identified the function that is miscompiled (boost::detail::function::basic_vtable4R, T0, T1, T2, T3::assign_to) and the transformation there is very simple and looks OK. Furthermore, the testcase does not miscompile on the current trunk and the output of SRA on the trunk and on the branch is exactly the same. I'll continue looking at this next week. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44406
[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry
--- Comment #38 from jakub at gcc dot gnu dot org 2010-06-04 16:42 --- Subject: Bug 41371 Author: jakub Date: Fri Jun 4 16:42:27 2010 New Revision: 160280 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160280 Log: PR debug/41371 * var-tracking.c (find_loc_in_1pdv): Mark initial value before recursing. Check that recursion is bounded. Rename inner var to avoid hiding incoming argument. Modified: trunk/gcc/ChangeLog trunk/gcc/var-tracking.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug rtl-optimization/44013] VTA produces wrong code
--- Comment #10 from jakub at gcc dot gnu dot org 2010-06-04 16:44 --- Subject: Bug 44013 Author: jakub Date: Fri Jun 4 16:43:42 2010 New Revision: 160281 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160281 Log: PR rtl-optimization/44013 * sched-deps.c (add_dependence_list_and_free): Don't free lists when processing debug insns. Modified: trunk/gcc/ChangeLog trunk/gcc/sched-deps.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44013
[Bug debug/41371] [4.5/4.6 Regression] var-tracking is slow and memory hungry
--- Comment #39 from jakub at gcc dot gnu dot org 2010-06-04 16:48 --- Subject: Bug 41371 Author: jakub Date: Fri Jun 4 16:47:41 2010 New Revision: 160282 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160282 Log: PR debug/41371 * var-tracking.c (find_loc_in_1pdv): Mark initial value before recursing. Check that recursion is bounded. Rename inner var to avoid hiding incoming argument. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/var-tracking.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug libstdc++/44413] inefficient code for std::string::compare on x86-64
--- Comment #1 from redi at gcc dot gnu dot org 2010-06-04 16:52 --- Seems like a reasonable suggestion for improvement. I don't know if anyone relies on the current behaviour, so it might not get changed. -- redi at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-06-04 16:52:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44413
[Bug target/40419] __attribute__((mips16)) is broken on trunk.
--- Comment #2 from zadeck at naturalbridge dot com 2010-06-04 17:18 --- I would just like to say that i think that target_reinit should be removed. It is nothing but trouble. We tried to use it on our private port and it was very slow and most of the time ended up crashing. Furthermore, when we got down to the end, we discovered that in fact it does not end up calling everything that was needed to reinitialize ira. Our platform has a register architecture like a sparc but it has a variable number of ins and outs. The exact number of ins depends on the function signature and the number of outs depends on the signatures of the callees. So we tried using target_reinit to reset the register allocator after we had seen the caller to the function and all of the callees. in the end we added a special pass that does an reinit_regs () before ira. This sped up our compiler by about 4x. (i.e target_reinit is not just buggy, it is slow.) Note that target_reinit does not do a reinit_regs and so it actually does not really reinitialize the target, at least as far as ira is concerned. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40419
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #17 from Kyle dot D dot Moffett at boeing dot com 2010-06-04 17:24 --- Created an attachment (id=20840) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20840action=view) Minimal test with -O1 I've managed to shrink this down to a 44-line testcase that fails with the options listed below. The code is the same but the failure mode is different; Specifically, I get this output: |RESET: 252.00 | 4294967296.00 |RESET: 504.00 | 4294967296.00 |RESET: 756.00 | 4294967296.00 |RESET: 1008.00 | 4294967296.00 |RESET: 1260.00 | 4294967296.00 |RESET: 1512.00 | 4294967296.00 |RESET: 1764.00 | 4294967296.00 |RESET: 2016.00 | 4294967296.00 |RESET: 2268.00 | 4294967296.00 = 2268.00 |RESET: 2520.00 | 4294967296.00 |RESET: 2772.00 | 4294967296.00 From the code, the second floating point value on each line should be equal to the first float from the previous line. If I change the first (unsigned long long) cast to a (long long) cast, the bug goes away and I see the following (correct) output: |RESET: 252.00 | 0.00 |RESET: 504.00 | 252.00 |RESET: 756.00 | 504.00 |RESET: 1008.00 | 756.00 |RESET: 1260.00 | 1008.00 |RESET: 1512.00 | 1260.00 |RESET: 1764.00 | 1512.00 |RESET: 2016.00 | 1764.00 |RESET: 2268.00 | 2016.00 = 2268.00 |RESET: 2520.00 | 2268.00 |RESET: 2772.00 | 2520.00 The full list of compile options: -pipe \ -g \ -Wall \ -fmove-loop-invariants \ -fcaller-saves \ --param max-aliased-vops=100 \ --param avg-aliased-vops=1 \ --param max-fields-for-field-sensitive=0 \ --param loop-invariant-max-bbs-in-loop=1000 \ -O \ -fno-web \ -fno-rename-registers \ -fno-unroll-loops \ -fno-peel-loops \ -fno-split-ivs-in-unroller \ -fno-peephole \ -fno-dce \ -fno-dse \ -fno-unit-at-a-time \ -fno-omit-frame-pointer \ -fno-auto-inc-dec \ -fno-cprop-registers \ -fno-dce \ -fno-defer-pop \ -fno-delayed-branch \ -fno-dse \ -fno-guess-branch-probability \ -fno-if-conversion2 \ -fno-if-conversion \ -fno-inline-small-functions \ -fno-inline-functions-called-once \ -fno-early-inlining \ -fno-ipa-pure-const \ -fno-ipa-reference \ -fno-merge-constants \ -fno-split-wide-types \ -fno-tree-builtin-call-dce \ -fno-tree-ccp \ -fno-tree-ch \ -fno-tree-copyrename \ -fno-tree-dce \ -fno-tree-dominator-opts \ -fno-tree-dse \ -fno-tree-fre \ -fno-tree-sra \ -fno-tree-ter \ -fno-merge-constants \ -fno-branch-count-reg \ -fno-function-cse \ -fno-thread-jumps \ -fno-gcse \ -fno-rerun-cse-after-loop \ -fno-cse-skip-blocks \ -fno-cse-follow-jumps -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug target/44364] Wrong code with e500 double floating point
--- Comment #18 from Kyle dot D dot Moffett at boeing dot com 2010-06-04 17:24 --- Created an attachment (id=20841) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20841action=view) Minimal test objdump with -O1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44364
[Bug testsuite/44418] New: FAIL: gcc.target/powerpc/recip-[123].c on powerpc-apple-darwin9
Since revision 160215 (see http://gcc.gnu.org/ml/gcc-testresults/2010-06/msg00263.html ) one gets the following failures on powerpc-apple-darwin9: FAIL: gcc.target/powerpc/recip-1.c scan-assembler-times frsqrte 2 FAIL: gcc.target/powerpc/recip-1.c scan-assembler-times fmsub 2 FAIL: gcc.target/powerpc/recip-1.c scan-assembler-times fmul 8 FAIL: gcc.target/powerpc/recip-2.c scan-assembler-times frsqrtes 1 FAIL: gcc.target/powerpc/recip-2.c scan-assembler-times fmsubs 1 FAIL: gcc.target/powerpc/recip-2.c scan-assembler-times fmuls 6 FAIL: gcc.target/powerpc/recip-2.c scan-assembler-times fnmsubs 3 FAIL: gcc.target/powerpc/recip-2.c scan-assembler-times fsqrt 1 FAIL: gcc.target/powerpc/recip-3.c scan-assembler-times frsqrtes 1 FAIL: gcc.target/powerpc/recip-3.c scan-assembler-times fmsubs 1 FAIL: gcc.target/powerpc/recip-3.c scan-assembler-times fmuls 4 I'll attach the assemby files for these tests. -- Summary: FAIL: gcc.target/powerpc/recip-[123].c on powerpc-apple- darwin9 Product: gcc Version: 4.6.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: powerpc-apple-darwin9 GCC host triplet: powerpc-apple-darwin9 GCC target triplet: powerpc-apple-darwin9 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44418
[Bug libgcj/44415] [4.6 regression] gmp multilib support broke bootstrap with static libgmp
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-06-04 17:48 --- First off this is not a regression; I ran into this issue back a couple of years ago with libjava requiring libgmp. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44415
[Bug libgcj/44415] [4.6 regression] gmp multilib support broke bootstrap with static libgmp
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-06-04 17:49 --- See PR 39747. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||39747 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44415
[Bug testsuite/44418] FAIL: gcc.target/powerpc/recip-[123].c on powerpc-apple-darwin9
--- Comment #1 from dominiq at lps dot ens dot fr 2010-06-04 17:52 --- Created an attachment (id=20842) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20842action=view) assembly for recip-1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44418
[Bug testsuite/44418] FAIL: gcc.target/powerpc/recip-[123].c on powerpc-apple-darwin9
--- Comment #2 from dominiq at lps dot ens dot fr 2010-06-04 17:52 --- Created an attachment (id=20843) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20843action=view) assembly for recip-2.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44418
[Bug testsuite/44418] FAIL: gcc.target/powerpc/recip-[123].c on powerpc-apple-darwin9
--- Comment #3 from dominiq at lps dot ens dot fr 2010-06-04 17:52 --- Created an attachment (id=20844) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20844action=view) assembly for recip-3.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44418
[Bug c++/44244] Provide -f flags to turn on individual C++0x features
--- Comment #3 from jyasskin at gmail dot com 2010-06-04 17:56 --- Thanks for the prompt answers. I understand that you've picked the right direction for gcc as a whole, even though it'll inconvenience me temporarily. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44244
[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.
--- Comment #39 from dominiq at lps dot ens dot fr 2010-06-04 18:25 --- I confirm that the failures for libjava reported in comment #33 were due to some misconfiguration. With the patches in http://gcc.gnu.org/bugzilla/attachment.cgi?id=20762 and http://gcc.gnu.org/bugzilla/attachment.cgi?id=20822 , after a clean boostrap, I see the following new failures: FAIL: g++.dg/tls/init-2.C (internal compiler error) FAIL: g++.dg/tls/init-2.C (test for excess errors) FAIL: gcc.dg/tls/asm-1.c (internal compiler error) FAIL: gcc.dg/tls/asm-1.c (test for errors, line 7) FAIL: gcc.dg/tls/asm-1.c (test for excess errors) FAIL: obj-c++.dg/tls/init-2.mm -fgnu-runtime (internal compiler error) FAIL: obj-c++.dg/tls/init-2.mm -fnext-runtime (internal compiler error) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44132
[Bug c++/44362] Bogus set-but-not-used warning
--- Comment #7 from jakub at gcc dot gnu dot org 2010-06-04 18:43 --- Subject: Bug 44362 Author: jakub Date: Fri Jun 4 18:42:42 2010 New Revision: 160289 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160289 Log: PR c++/44362 * call.c (build_conditional_expr): If both arg2 and arg3 are lvalues with the same type, call mark_lvalue_use on both. * c-c++-common/Wunused-var-10.c: New test. Added: trunk/gcc/testsuite/c-c++-common/Wunused-var-10.c Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44362
[Bug target/44132] [4.6 Regression] emutls is broken under a range of circumstances.
--- Comment #40 from iains at gcc dot gnu dot org 2010-06-04 18:45 --- (In reply to comment #39) I confirm that the failures for libjava reported in comment #33 were due to some misconfiguration. With the patches in http://gcc.gnu.org/bugzilla/attachment.cgi?id=20762 and http://gcc.gnu.org/bugzilla/attachment.cgi?id=20822 , after a clean boostrap, I see the following new failures: FAIL: g++.dg/tls/init-2.C (internal compiler error) FAIL: g++.dg/tls/init-2.C (test for excess errors) FAIL: gcc.dg/tls/asm-1.c (internal compiler error) FAIL: gcc.dg/tls/asm-1.c (test for errors, line 7) FAIL: gcc.dg/tls/asm-1.c (test for excess errors) FAIL: obj-c++.dg/tls/init-2.mm -fgnu-runtime (internal compiler error) FAIL: obj-c++.dg/tls/init-2.mm -fnext-runtime (internal compiler error) right, that's what I expect. I think this : gcc.dg/tls/asm-1.c is because gimplify_asm () doesn't consider expansion of the parameter (hopefully Honza could help with that). I think that this : g++.dg/tls/init-2.C obj-c++.dg/tls/init-2.mm - (which are the same code) are down to two conflicting error responses from the C++ FE, -- there are two error messages that disagree. In other words, although these are regressions showing from the application of the patch - I think they might be latent problems outside emutls. I'll re-jig the patch to remove the ABI breakage and post over the next few days. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44132
[Bug c++/44412] [4.6 Regression] Another bogus set-but-not-used warning
--- Comment #3 from jakub at gcc dot gnu dot org 2010-06-04 18:46 --- Subject: Bug 44412 Author: jakub Date: Fri Jun 4 18:45:07 2010 New Revision: 160290 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=160290 Log: PR c++/44412 * typeck.c (build_class_member_access_expr): Call mark_exp_read on object for static data members. * g++.dg/warn/Wunused-var-10.C: New test. * g++.dg/warn/Wunused-var-11.C: New test. Added: trunk/gcc/testsuite/g++.dg/warn/Wunused-var-10.C trunk/gcc/testsuite/g++.dg/warn/Wunused-var-11.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44412
[Bug libstdc++/44417] make check-target-libstdc++-v3 fails due to undefined ptrdiff_t
--- Comment #8 from singler at gcc dot gnu dot org 2010-06-04 18:51 --- I can't help it, make check in the libstdc++-v3 directory still does not work for me, even after reconfiguring and recompiling everything from scratch, using vanilla rev 160275. Let's have a look at attached testsuite_abi.ii. The first typedef for std::ptrdiff_t is in line 49, but the first typedef for ptrdiff_t in the global scope is only in line 30203. The first error is in line 24823, however, this is in (sub?) namespace __cxxabiv1. Should this work anyway? I'm quite lost. -- singler at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WORKSFORME | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44417
[Bug libstdc++/44417] make check-target-libstdc++-v3 fails due to undefined ptrdiff_t
--- Comment #9 from singler at gcc dot gnu dot org 2010-06-04 18:51 --- Created an attachment (id=20845) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20845action=view) Failing test case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44417
[Bug libstdc++/44417] make check-target-libstdc++-v3 fails due to undefined ptrdiff_t
--- Comment #10 from paolo dot carlini at oracle dot com 2010-06-04 18:55 --- Something is broken in your system, I also tested on an Open Suse 11.1, to be sure, and everything works fine. Remove everything, fetch again the entire gcc mainline and try again. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44417
[Bug rtl-optimization/43632] [4.5/4.6 Regression] -g option became very slow after r157834
--- Comment #7 from jakub at gcc dot gnu dot org 2010-06-04 19:34 --- After the recent var-tracking.c PR41371 changes this is down to 67 seconds. -- 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=43632
[Bug preprocessor/7263] __extension__ keyword doesn't suppress warning on LL or ULL constants
--- Comment #25 from dodji at gcc dot gnu dot org 2010-06-04 19:36 ---
Created an attachment (id=20846)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20846action=view)
Fixes all regressions of C FE's testsuite
This update fixes all the regressions I have noticed in the test suite of the C
FE. I have done the testing and debugging with bootstrap disabled.
This patch merges Tom's initial patch and my additions and should apply to
recent trunk.
Next step is to bootstrap the C FE and see/fix the remaining bugs that I
encounter there.
Here is what the patch does at the moment:
$ cat test.c
1 #define OPERATE(OPRD1, OPRT, OPRD2) \
2 OPRD1 OPRT OPRD2;
3
4 #define SHIFTL(A,B) \
5OPERATE (A,,B)
6
7 #define MULT2(A) \
8SHIFTL (A,1)
9
10 void
11 g ()
12 {
13MULT2 (1.0);/* 1.0 1;*/
14 }
$ ./cc1 -quiet test.c
While expanding macro OPERATE at test.c:2:8
While expanding macro SHIFTL at test.c:5:14
While expanding macro MULT2 at test.c:8:3
test.c: In function 'g':
test.c:13:3: error: invalid operands to binary (have 'double' and 'int')
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7263
[Bug pch/14933] missing pre-compiled header depends with -MD
--- Comment #13 from kristiaan dot lenaerts at gmail dot com 2010-06-04 20:10 --- Created an attachment (id=20847) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20847action=view) Updated fix for improper PCH dependency tracking I got hit by this bug a few weeks ago when working on a C++ project. This project has a setup for which using -fpch-deps will not work, most pch files include local headers that have to be referenced by their complete path elsewhere. I rebased the proposed fix from Mario on the 4.5 branch (I created it when 4.5 was not yet out). I'm using this patch for about a month now without any obvious problems, but I would like to get this in mainline. What are the steps that I should take? I have not yet run the testsuite. (this is on a corporate laptop running under cygwin - windows XP and full hd-encryption - so compiling gcc was painfull, and I imagine running the testsuite will be worse) Would it be ok if I run the testsuite on cygwin with and without the patch, and if the results are the same submit this patch to gcc-patches (with meaningfull changelog entry)? I could also test on a x64_64-pc-linux-gnu machine at home, but it could take a while before I can test there. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14933
[Bug middle-end/44416] [4.6 regression] Failed to build 447.dealII in SPEC CPU 2006
--- Comment #9 from hjl dot tools at gmail dot com 2010-06-04 20:15 --- Created an attachment (id=20848) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=20848action=view) The src.alt for 447.dealII This works for me. Can someone try it? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44416
[Bug preprocessor/7263] __extension__ keyword doesn't suppress warning on LL or ULL constants
--- Comment #26 from manu at gcc dot gnu dot org 2010-06-04 20:22 --- (In reply to comment #25) $ ./cc1 -quiet test.c While expanding macro OPERATE at test.c:2:8 While expanding macro SHIFTL at test.c:5:14 While expanding macro MULT2 at test.c:8:3 test.c: In function 'g': test.c:13:3: error: invalid operands to binary (have 'double' and 'int') I find this output a bit confusing. I find clang's output clearer http://clang.llvm.org/diagnostics.html. In fact, clang's output actually follows more closely what GCC already does with templates/inline functions. This is from GCC: test.C:7:3: instantiated from âvoid SHIFTL(T1, T2) [with T1 = double, T2 = int]â test.C:10:3: instantiated from âvoid MULT2(T) [with T = double]â test.C:15:20: instantiated from here test.C:3:3: error: invalid operands of types âdoubleâ and âintâ to binary âoperator Also, what are the column numbers pointing to? They don't make sense to me. In any case, this is a huge step forward! Thanks for working on this. It would be an important marketing point if you manage to complete it for GCC 4.6. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7263
[Bug c/44419] New: ICE when building for Freescale e500v2
When building gcc for e500v2: --target=powerpc-unknown-linux-gnuspe --enable-e500_double The build stops with an ICE: /tmp/edmar/build_jobs/Xe500v2/obj_gccsys/./gcc/xgcc -B/tmp/edmar/build_jobs/Xe500v2/obj_gccsys/./gcc/ -B/tmp/edmar/build_jobs/installs_final/gnu-gcc-4.5-binutils-2.19-eglibc-2.9-Xe500v2-powerpc-unknown-linux-gnuspe/i686-pc-linux2.4/powerpc-unknown-linux-gnuspe/bin/ -B/tmp/edmar/build_jobs/installs_final/gnu-gcc-4.5-binutils-2.19-eglibc-2.9-Xe500v2-powerpc-unknown-linux-gnuspe/i686-pc-linux2.4/powerpc-unknown-linux-gnuspe/lib/ -isystem /tmp/edmar/build_jobs/installs_final/gnu-gcc-4.5-binutils-2.19-eglibc-2.9-Xe500v2-powerpc-unknown-linux-gnuspe/i686-pc-linux2.4/powerpc-unknown-linux-gnuspe/include -isystem /tmp/edmar/build_jobs/installs_final/gnu-gcc-4.5-binutils-2.19-eglibc-2.9-Xe500v2-powerpc-unknown-linux-gnuspe/i686-pc-linux2.4/powerpc-unknown-linux-gnuspe/sys-include-g -O2 -O2 -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fPIC -g -DHAVE_GTHR_DEFAULT -DIN_LIBGCC2 -D__GCC_FLOAT_NOT_NEEDED -mlong-double-128 -I. -I. -I../.././gcc -I../../../src_gcc/libgcc -I../../../src_gcc/libgcc/. -I../../../src_gcc/libgcc/../gcc -I../../../src_gcc/libgcc/../include -DHAVE_CC_TLS -o _powixf2.o -MT _powixf2.o -MD -MP -MF _powixf2.dep -DL_powixf2 -c ../../../src_gcc/libgcc/../gcc/libgcc2.c \ -fvisibility=hidden -DHIDE_EXPORTS ../../../src_gcc/libgcc/../gcc/libgcc2.c: In function '__powidf2': ../../../src_gcc/libgcc/../gcc/libgcc2.c:1739:1: internal compiler error: in rs6000_split_multireg_move, at config/rs6000/rs6000.c:16712 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[2]: *** [_powidf2.o] Error 1 make[2]: *** Waiting for unfinished jobs make[2]: Leaving directory `/tmp/edmar/build_jobs/Xe500v2/obj_gccsys/powerpc-unknown-linux-gnuspe/libgcc' make[1]: *** [all-target-libgcc] Error 2 make[1]: Leaving directory `/tmp/edmar/build_jobs/Xe500v2/obj_gccsys' make: *** [all] Error 2 I traced the problem back to revision 157530, which splits dp float point moves into 2 32 bit gpr. But on e500v2, the gpr are 64 bit wide, and dp floats are mapped to one single gpr. The problem does not exists in e500v1 which also has 64 bit gpr because this cpu does not have dp hardware and soft float ABI dictates dpfp values should be kept in 2 gpr. This problem also exists in the 4.5 branch. The following change fix the ICE for both gcc-4.5 and gcc-4.6. It was regression tested on 32 bits powerpc as well as on e500v2. --- gcc-20100425/gcc/config/rs6000/rs6000.md-orig 2010-04-26 09:58:41.0 -0500 +++ gcc-20100425/gcc/config/rs6000/rs6000.md2010-04-26 10:01:55.0 -0500 @@ -218,7 +218,8 @@ (TD TARGET_DFP)]) ; These modes do not fit in integer registers in 32-bit mode. -(define_mode_iterator DIFD [DI DF DD]) +; but on e500v2, the gpr are 64 bit registers +(define_mode_iterator DIFD [DI (DF !TARGET_E500_DOUBLE) DD]) ; Various instructions that come in SI and DI forms. ; A generic w/d attribute, for things like cmpw/cmpd. -- Summary: ICE when building for Freescale e500v2 Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: edmar at freescale dot com GCC host triplet: powerpc-unknown-linux-gnuspe GCC target triplet: powerpc-unknown-linux-gnuspe http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44419
[Bug middle-end/44420] New: [feature request] Warn for certain integer overflows
This is a follow-up to http://gcc.gnu.org/ml/gcc-help/2010-06/msg5.html : Consider the following case: uint32_t foo, bar; ... foo = bar 20; Of course, this operation can overflow and warning about this probably does not make sense as the programmer should be aware of this case. However, a warning in the following case could be appropriate IMO: uint32_t bar; uint64_t foo; ... foo = bar 20; The intension is to catch the overflow case, therefore the assignment to a 64-bit variable. The intended code would be uint32_t bar; uint64_t foo; ... foo = (uint64_t)bar 20; I think it would be a big help if gcc could warn in the 2nd case. -- Summary: [feature request] Warn for certain integer overflows Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fm3 at os dot inf dot tu-dresden dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44420
[Bug fortran/37131] inline matmul for small matrix sizes
--- Comment #9 from tkoenig at gcc dot gnu dot org 2010-06-04 22:31 --- I have thought a little bit about this, and the problem is a bit daunting ;-) Of course, this is at least partly because my experience with the scalarizer is close to non-existant, but you have to learn sometime. It seems that the functions for scalarizing do not help a lot here, because (for example) we need three nested loops for implementing the case where a and b are of rank 2. The preferred way would therefore be to state the rank 2 * rank 2 problem as do i=1,m do j=1,n c(i,j) = sum(a(i,:) * b(:,j)) end do end do with the inner dot product borrowed using the scalarizer (borrowing from dot_product), and the outer loops using either hand-crafted TREE code or calling the DO translation. Comments? Is this reasonable? -- tkoenig at gcc dot gnu dot org changed: What|Removed |Added CC||pault at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37131
[Bug fortran/44235] array temporary with high upper bound
--- Comment #1 from tkoenig at gcc dot gnu dot org 2010-06-04 22:39 --- The particular test case from comment #1 is now fixed. Here's one that still fails: subroutine foo(a, b) real :: a(40), b(40) a(1:20:3) = a(1:19:3) a(1:19:3) = a(1:19:3) end subroutine foo g...@linux-fd1f:/tmp gfortran -Warray-temporaries -S dep2.f90 dep2.f90:3.14: a(1:20:3) = a(1:19:3) 1 Warning: Creating array temporary at (1) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44235
