[Bug ipa/58398] [4.9 Regression] gcc.dg/attr-ifunc-4.c runfail regression after r202111
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58398 --- Comment #6 from Bernd Edlinger bernd.edlinger at hotmail dot de --- OK, this patch was posted at: http://gcc.gnu.org/ml/gcc-patches/2013-09/msg01260.html
[Bug other/58441] New: VTV headers are installed into the general include directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58441 Bug ID: 58441 Summary: VTV headers are installed into the general include directory Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: minor Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: d.g.gorbachev at gmail dot com When GCC is configured with --enable-version-specific-runtime-libs, header files for libstdc++, libgomp, libquadmath, etc. are installed in the compiler-specific directory ($libdir/gcc/$target/$version/include). But libvtv, somehow, stands out from this scheme. It seems to be a bug.
[Bug other/58441] VTV headers are installed into the general include directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58441 Dmitry Gorbachev d.g.gorbachev at gmail dot com changed: What|Removed |Added CC||cmtice at google dot com --- Comment #1 from Dmitry Gorbachev d.g.gorbachev at gmail dot com --- CC'ing the VTV maintainer.
[Bug target/56875] vax target miscompiles short negative constants for 64bit values
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56875 --- Comment #3 from Martin Husemann martin at netbsd dot org --- Of course I do not mind fixing gas, but the whole point of the D formatting code is to work around this assembler bug, and while this might be mostly irrelevant nowadays, isn't gcc supposed to work with other assemblers (like the VMS one) as well? Gas seems to be bug-compatible here. Overall, especially since this change is trivial, wouldn't it be best/easiest to apply it anyway?
[Bug target/56875] vax target miscompiles short negative constants for 64bit values
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56875 --- Comment #4 from Jan-Benedict Glaw jbg...@lug-owl.de --- You're quite right, Martin! It's a simple fix on the GCC side working around a buggy gas, and it would also work with a fixed gas. However, gas isn't too simple to fix, at least not with a well-architected fix.
[Bug tree-optimization/58432] [4.9 Regression] ICE: in insert_value_copy_on_edge, at tree-outof-ssa.c:233
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58432 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Tue Sep 17 07:47:49 2013 New Revision: 202644 URL: http://gcc.gnu.org/viewcvs?rev=202644root=gccview=rev Log: 2013-09-17 Richard Biener rguent...@suse.de PR tree-optimization/58432 * tree-loop-distribution.c (tree_loop_distribution): Also scan PHIs for outside loop uses and seed a partition from them. * gcc.dg/pr58432.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/pr58432.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-loop-distribution.c
[Bug bootstrap/58441] [4.9 Regression] VTV headers are installed into the general include directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58441 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Component|other |bootstrap Target Milestone|--- |4.9.0 Summary|VTV headers are installed |[4.9 Regression] VTV |into the general include|headers are installed into |directory |the general include ||directory --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Marking as to be fixed before the release.
[Bug tree-optimization/58432] [4.9 Regression] ICE: in insert_value_copy_on_edge, at tree-outof-ssa.c:233
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58432 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug ipa/58332] [4.9 Regression] error: inlined_to pointer is set but no predecessors found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58332 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0 Summary|error: inlined_to pointer |[4.9 Regression] error: |is set but no predecessors |inlined_to pointer is set |found |but no predecessors found
[Bug libstdc++/58437] [4.7/4.8/4.9 Regression] Sorting value in reverse order is much slower compare to gcc44
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58437 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.4 Summary|[4.7/4.7/4.9 Regression]|[4.7/4.8/4.9 Regression] |Sorting value in reverse|Sorting value in reverse |order is much slower|order is much slower |compare to gcc44|compare to gcc44
[Bug middle-end/58418] [4.9 Regression] wrong code at -O2 and -O3 on x86_64-linux-gnu (in 32-bit mode)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58418 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug libstdc++/58437] [4.7/4.8/4.9 Regression] Sorting value in reverse order is much slower compare to gcc44
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58437 --- Comment #7 from Chris Jefferson chris at bubblescope dot net --- I will look at this next week. Quicksorts are always suboptimal for mostly sorted (forwards or backwards) data, and it would be nice to fix that.
[Bug libstdc++/58437] [4.7/4.8/4.9 Regression] Sorting value in reverse order is much slower compare to gcc44
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58437 --- Comment #8 from Paolo Carlini paolo.carlini at oracle dot com --- Thanks Chris. Note that, according at least to the Dup bug, some slow down is noticeable in other less special cases too.
[Bug tree-optimization/58417] Incorrect optimization in SCEV const-prop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58417
--- Comment #6 from Richard Biener rguenth at gcc dot gnu.org ---
So we want the evolution of sum_11 in the following loop (for a use on the
exit edge):
# i_18 = PHI i_13(4), 1(2)
# sum_19 = PHI sum_11(4), 0(2)
# prevsum_21 = PHI prevsum_12(4), 0(2)
foo (sum_19);
_7 = i_18 + -1;
_8 = (long long int) _7;
_9 = arr[i_18];
_10 = _8 * _9;
sum_11 = _10 - prevsum_21;
prevsum_12 = prevsum_21 + _9;
i_13 = i_18 + 1;
if (i_13 = 5)
goto bb 4;
else
goto bb 5;
bb 4:
goto bb 3;
and we compute
_10 = {0, +, _9}_1
_prevsum_21 = {0, +, _9}_1
but that is really meaningless as _9 is not a loop invariant which means that
this two very CHRECs are not valid as far as I understand, not valid to
operate on at least.
Thus the following asserts should IMHO hold (and trigger on the testcase
and many others)
Index: gcc/tree-chrec.c
===
--- gcc/tree-chrec.c(revision 202644)
+++ gcc/tree-chrec.c(working copy)
@@ -268,9 +268,14 @@ chrec_fold_plus_1 (enum tree_code code,
switch (TREE_CODE (op0))
{
case POLYNOMIAL_CHREC:
+ gcc_checking_assert
+ (!chrec_contains_symbols_defined_in_loop (op0, CHREC_VARIABLE (op0)));
switch (TREE_CODE (op1))
{
case POLYNOMIAL_CHREC:
+ gcc_checking_assert
+ (!chrec_contains_symbols_defined_in_loop (op1,
+ CHREC_VARIABLE (op1)));
return chrec_fold_plus_poly_poly (code, type, op0, op1);
CASE_CONVERT:
@@ -298,6 +303,9 @@ chrec_fold_plus_1 (enum tree_code code,
switch (TREE_CODE (op1))
{
case POLYNOMIAL_CHREC:
+ gcc_checking_assert
+ (!chrec_contains_symbols_defined_in_loop (op1,
+ CHREC_VARIABLE (op1)));
if (code == PLUS_EXPR || code == POINTER_PLUS_EXPR)
return build_polynomial_chrec
(CHREC_VARIABLE (op1),
@@ -396,9 +404,14 @@ chrec_fold_multiply (tree type,
switch (TREE_CODE (op0))
{
case POLYNOMIAL_CHREC:
+ gcc_checking_assert
+ (!chrec_contains_symbols_defined_in_loop (op0, CHREC_VARIABLE (op0)));
switch (TREE_CODE (op1))
{
case POLYNOMIAL_CHREC:
+ gcc_checking_assert
+ (!chrec_contains_symbols_defined_in_loop (op1,
+ CHREC_VARIABLE (op1)));
return chrec_fold_multiply_poly_poly (type, op0, op1);
CASE_CONVERT:
@@ -431,6 +444,9 @@ chrec_fold_multiply (tree type,
switch (TREE_CODE (op1))
{
case POLYNOMIAL_CHREC:
+ gcc_checking_assert
+ (!chrec_contains_symbols_defined_in_loop (op1,
+ CHREC_VARIABLE (op1)));
return build_polynomial_chrec
(CHREC_VARIABLE (op1),
chrec_fold_multiply (type, CHREC_LEFT (op1), op0),
as of the recursion we can fix that by making the cache used to guard against
the recursion global (and maybe use instantiate_parameters instead of
resolve_mixers).
[Bug libstdc++/58338] Add noexcept to functions with a narrow contract
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58338 --- Comment #3 from Marc Glisse glisse at gcc dot gnu.org --- Author: glisse Date: Tue Sep 17 12:23:54 2013 New Revision: 202650 URL: http://gcc.gnu.org/viewcvs?rev=202650root=gccview=rev Log: 2013-09-17 Marc Glisse marc.gli...@inria.fr PR libstdc++/58338 * include/bits/stl_vector.h (vector::vector(), vector::vector(const allocator_type)): Merge. (_Vector_impl::_Vector_impl(_Tp_alloc_type const), _Vector_impl::_Vector_impl(_Tp_alloc_type), _Vector_impl::_M_swap_data, _Vector_base::_Vector_base(const allocator_type), _Vector_base::_Vector_base(allocator_type), _Vector_base::_Vector_base(_Vector_base), _Vector_base::~_Vector_base, vector::vector(const allocator_type), vector::operator[], vector::operator[] const, vector::front, vector::front const, vector::back, vector::back const, vector::pop_back, vector::_M_erase_at_end): Mark as noexcept. * include/debug/vector (vector::vector(const _Allocator), vector::operator[], vector::operator[] const, vector::front, vector::front const, vector::back, vector::back const, vector::pop_back, _M_requires_reallocation, _M_update_guaranteed_capacity, _M_invalidate_after_nth): Mark as noexcept. * include/profile/vector (vector::vector(const _Allocator), vector::operator[], vector::operator[] const, vector::front, vector::front const, vector::back, vector::back const): Mark as noexcept. (vector::vector(vector, const _Allocator)): Remove wrong noexcept. * testsuite/23_containers/vector/requirements/dr438/assign_neg.cc: Adjust line number. * testsuite/23_containers/vector/requirements/dr438/ constructor_1_neg.cc: Likewise. * testsuite/23_containers/vector/requirements/dr438/ constructor_2_neg.cc: Likewise. * testsuite/23_containers/vector/requirements/dr438/insert_neg.cc: Likewise. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_vector.h trunk/libstdc++-v3/include/debug/vector trunk/libstdc++-v3/include/profile/vector trunk/libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/assign_neg.cc trunk/libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/constructor_1_neg.cc trunk/libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/constructor_2_neg.cc trunk/libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/insert_neg.cc
[Bug tree-optimization/58088] [4.8/4.9 Regression] ICE in gcc.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58088 --- Comment #10 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Tue Sep 17 13:29:41 2013 New Revision: 202652 URL: http://gcc.gnu.org/viewcvs?rev=202652root=gccview=rev Log: [gcc/] 2013-09-17 Kyrylo Tkachov kyrylo.tkac...@arm.com PR tree-optimization/58088 * fold-const.c (mask_with_trailing_zeros): New function. (fold_binary_loc): Make sure we don't recurse infinitely when the X in (X C1) | C2 is a tree of the form (Y * K1) K2. Use mask_with_trailing_zeros where appropriate. [gcc/testsuite] 2013-09-17 Kyrylo Tkachov kyrylo.tkac...@arm.com PR tree-optimization/58088 * gcc.c-torture/compile/pr58088.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr58088.c Modified: trunk/gcc/ChangeLog trunk/gcc/fold-const.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/58359] __builtin_unreachable prevents vectorization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58359
--- Comment #2 from Marc Glisse glisse at gcc dot gnu.org ---
Another optimization prevented by __builtin_unreachable:
extern void f();
void g(int i){
if(i0){
f();
__builtin_unreachable();
}
}
misses that f is a tail call and generates at -O3 on x86_64:
testl%edi, %edi
jg.L6
rep ret
.L6:
pushq%rax
xorl%eax, %eax
callf
instead of (removing the builtin):
testl%edi, %edi
jle.L1
xorl%eax, %eax ( in C++ this line disappears )
jmpf
.L1:
rep ret
(it inverted the comparison, but my point is call vs jmp)
[Bug target/58442] New: bootstrapping vax crashes on NetBSD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58442 Bug ID: 58442 Summary: bootstrapping vax crashes on NetBSD Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: martin at netbsd dot org During stage1 build of libstc++ this call dies with a segfault: Reading symbols from /usr/pkgobj/lang/gcc48/work/build/gcc/cc1plus...done. (gdb) run -quiet -nostdinc++ -v -I /usr/pkgobj/lang/gcc48/work/gcc-4.8.1/libstdc++-v3/../libgcc -I /usr/pkgobj/lang/gcc48/work/build/vax--netbsdelf/libstdc++-v3/include/vax--netbsdelf -I /usr/pkgobj/lang/gcc48/work/build/vax--netbsdelf/libstdc++-v3/include -I /usr/pkgobj/lang/gcc48/work/gcc-4.8.1/libstdc++-v3/libsupc++ -I /usr/pkg/include -I /usr/include -iprefix /usr/pkgobj/lang/gcc48/work/build/gcc/../lib/gcc/vax--netbsdelf/4.8.1/ -isystem /usr/pkgobj/lang/gcc48/work/build/./gcc/include -isystem /usr/pkgobj/lang/gcc48/work/build/./gcc/include-fixed -D _GLIBCXX_SHARED -D PIC -D _GLIBCXX_SHARED -isystem /usr/pkg/gcc48/vax--netbsdelf/include -isystem /usr/pkg/gcc48/vax--netbsdelf/sys-include ../../../../../gcc-4.8.1/libstdc++-v3/src/c++98/locale-inst.cc -quiet -dumpbase locale-inst.cc -auxbase-strip locale-inst.o -g -O2 -O1 -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -version -fno-implicit-templates -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=locale-inst.lo -fgcse -fgcse-after-reload -fPIC -o /var/tmp//ccj04DGQ.s [..] GNU C++ (GCC) version 4.8.1 (vax--netbsdelf) compiled by GNU C version 4.1.3 20080704 prerelease (NetBSD nb3 2007), GMP version 5.0.1, MPFR version 3.1.2, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: e5b251aee23ceb19ee70c90a0aeb9824 Program received signal SIGSEGV, Segmentation fault. 0x0092cdb0 in recog_1 (x0=0x7e1b1a5c, insn=0x7e1b26c0, pnum_clobbers=0x0, 2115705436, 2115708608, 0) at ../../gcc-4.8.1/gcc/config/vax/vax.md:417 (gdb) bt #0 0x0092cdb0 in recog_1 (x0=0x7e1b1a5c, insn=0x7e1b26c0, pnum_clobbers=0x0, 2115705436, 2115708608, 0) at ../../gcc-4.8.1/gcc/config/vax/vax.md:417 #1 0x0092f180 in recog_2 (x0=0x7e1b1a5c, insn=0x7e1b26c0, pnum_clobbers=0x0, 2115705436, 2115708608, 0) at ../../gcc-4.8.1/gcc/config/vax/vax.md:529 #2 0x00932c1c in recog (x0=0x7e1b1a5c, insn=0x7e1b26c0, pnum_clobbers=0x0, 2115705436, 2115708608, 0) at ../../gcc-4.8.1/gcc/config/vax/vax.md:1462 #3 0x0066f5e3 in recog_memoized (insn=0x7e1b26c0, 2115708608) at ../../gcc-4.8.1/gcc/recog.h:155 #4 0x0066f83c in extract_insn (insn=0x7e1b26c0, 2115708608) at ../../gcc-4.8.1/gcc/recog.c:2148 #5 0x005066d1 in instantiate_virtual_regs_in_insn ( insn=0x7e1b26c0, 2115708608) at ../../gcc-4.8.1/gcc/function.c:1561 #6 0x00507cd3 in instantiate_virtual_regs () at ../../gcc-4.8.1/gcc/function.c:1928 #7 0x00646f2f in execute_one_pass (pass=0xef6974, 15690100) at ../../gcc-4.8.1/gcc/passes.c:2330 #8 0x00647108 in execute_pass_list (pass=0xef6974, 15690100) at ../../gcc-4.8.1/gcc/passes.c:2378 #9 0x0064713d in execute_pass_list (pass=0xef7194, 15692180) at ../../gcc-4.8.1/gcc/passes.c:2379 (gdb) list 412 (match_operand:VAXint 2 general_operand nrmT,nrmT)))] 413 414 @ 415subVAXint:isfx2 %2,%0 416subVAXint:isfx3 %2,%1,%0) 417 418 (define_expand subdi3 419 [(set (match_operand:DI 0 nonimmediate_operand =g) 420 (minus:DI (match_operand:DI 1 general_operand g) 421 (match_operand:DI 2 general_operand g)))] (gdb) p debug_rtx(x0) (set (zero_extract:SI (subreg:SI (reg/v:DI 71 [ __s ]) 4) (const_int 8 [0x8]) (const_int 0 [0])) (subreg:SI (reg:DI 108) 4))
[Bug target/58442] bootstrapping vax crashes on NetBSD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58442 --- Comment #1 from Martin Husemann martin at netbsd dot org --- (gdb) x/i 0x0092cdb0 = 0x92cdb0 recog_1(rtx, rtx, int*)+950: movb 0x14(r0),r0 (gdb) info reg r0 0x4 4 r1 0x8 8 r2 0x0 0 r3 0xf0c308 15778568 r4 0x0 0 r5 0x0 0 r6 0x9e 158 r7 0x7f7d6c72 2138926194 r8 0x7f7ca000 2138873856 r9 0x7ff0 2147483632 r100x7f7d 2138898432 r110xa1b08 662280 ap 0x7fffe1c4 2147475908 fp 0x7fffe1b0 2147475888 sp 0x7fffe110 2147475728 pc 0x92cdb0 9620912 ps 0x3c062914560
[Bug sanitizer/58443] ubsan doesn't properly honor fsanitize= flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58443 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-09-17 Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |4.9.0 Ever confirmed|0 |1
[Bug sanitizer/58443] New: ubsan doesn't properly honor fsanitize= flags
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58443
Bug ID: 58443
Summary: ubsan doesn't properly honor fsanitize= flags
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: mpolacek at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
$ cat z.c
int
main (void)
{
int i = 12;
i = 48;
return 0;
}
$ gcc -w -o z{,.c} -fsanitize=unreachable ./z
z.c:5:5: runtime error: shift exponent 48 is too large for 32-bit type int
We shouldn't instrument shifts, only __builtin_unreachable's in this case.
[Bug tree-optimization/58088] [4.8/4.9 Regression] ICE in gcc.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58088 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from ktkachov at gcc dot gnu.org --- Fixed on trunk and 4.8 branch.
[Bug tree-optimization/58088] [4.8/4.9 Regression] ICE in gcc.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58088 --- Comment #11 from ktkachov at gcc dot gnu.org --- Author: ktkachov Date: Tue Sep 17 13:59:42 2013 New Revision: 202653 URL: http://gcc.gnu.org/viewcvs?rev=202653root=gccview=rev Log: [gcc/] 2013-09-17 Kyrylo Tkachov kyrylo.tkac...@arm.com PR tree-optimization/58088 * fold-const.c (mask_with_trailing_zeros): New function. (fold_binary_loc): Make sure we don't recurse infinitely when the X in (X C1) | C2 is a tree of the form (Y * K1) K2. Use mask_with_trailing_zeros where appropriate. [gcc/testsuite/] 2013-09-17 Kyrylo Tkachov kyrylo.tkac...@arm.com PR tree-optimization/58088 * gcc.c-torture/compile/pr58088.c: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.c-torture/compile/pr58088.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/fold-const.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug tree-optimization/58444] New: [4.9 regression] Runfail on spec2006/434.zeusmp after r202516.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58444 Bug ID: 58444 Summary: [4.9 regression] Runfail on spec2006/434.zeusmp after r202516. Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: ysrumyan at gmail dot com We found out that phase loop distribution is responsible for it, namely wrong cfg is generated (after ldist) for pdv.f if it was compiled with options -Ofast -funroll-loops -march=corei7 and we can see that 1st loop is duplicated (after __buitin_memcpy bb we see 1st loop again).
[Bug lto/58084] [4.9 Regression] FAIL: gcc.dg/torture/pr8081.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58084 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from Jan Hubicka hubicka at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/58294] [4.9 Regression] ice in update_ssa_across_abnormal_edges, at tree-inline.c:1892
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58294 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #18 from Jan Hubicka hubicka at gcc dot gnu.org --- Fixed.
[Bug ipa/58329] [4.9 Regression] ld: Invalid symbol type for plabel (.libs/libstdc++.lax/libc++11convenience.a/system_error.o, std::error_category::default_error_condition(int) const [clone .localalia
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58329 --- Comment #11 from Jan Hubicka hubicka at gcc dot gnu.org --- Author: hubicka Date: Tue Sep 17 15:46:06 2013 New Revision: 202657 URL: http://gcc.gnu.org/viewcvs?rev=202657root=gccview=rev Log: PR middle-end/58329 * ipa-devirt.c (ipa_devirt): Be ready for symtab_nonoverwritable_alias to return NULL. * ipa.c (function_and_variable_visibility): Likewise. * ipa-profile.c (ipa_profile): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-devirt.c trunk/gcc/ipa-profile.c trunk/gcc/ipa.c
[Bug plugins/58445] New: dragonegg needs plugin/include/config/i386/stringop.def and plugin/include/config/i386/x86-tune.def installed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58445 Bug ID: 58445 Summary: dragonegg needs plugin/include/config/i386/stringop.def and plugin/include/config/i386/x86-tune.def installed Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: plugins Assignee: unassigned at gcc dot gnu.org Reporter: howarth at nitro dot med.uc.edu Currently gcc trunk breaks the build of the dragonegg 3.4svn plugin with the error... /sw/opt/llvm-3.4/bin/clang++ -c -I/sw/src/fink.build/dragonegg-gcc49-3.4-0/dragonegg-3.4/include/x86 -I/sw/src/fink.build/dragonegg-gcc49-3.4-0/dragonegg-3.4/include/darwin -g -DENABLE_BUILD_WITH_CXX -DENABLE_LTO -I/sw/include -I/sw/opt/llvm-3.4/include -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -fno-rtti -MD -MP -DIN_GCC -DLLVM_VERSION=\3.4svn\ -DTARGET_TRIPLE=\x86_64-apple-darwin12.5.0\ -DGCC_MAJOR=4 -DGCC_MINOR=9 -DGCC_MICRO=0 -I/sw/src/fink.build/dragonegg-gcc49-3.4-0/dragonegg-3.4/include -isystem/sw/lib/gcc4.9/lib/gcc/x86_64-apple-darwin12.5.0/4.9.0/plugin/include -DENABLE_BUILD_WITH_CXX -Wall -Wextra -DENABLE_LLVM_PLUGINS -I/sw/opt/llvm-3.4/include -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wmissing-field-initializers -pedantic -Wno-long-long -Wnon-virtual-dtor -O3 -DNDEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS /sw/src/fink.build/dragonegg-gcc49-3.4-0/dragonegg-3.4/src/Aliasing.cpp In file included from /sw/src/fink.build/dragonegg-gcc49-3.4-0/dragonegg-3.4/src/Aliasing.cpp:48: In file included from /sw/lib/gcc4.9/lib/gcc/x86_64-apple-darwin12.5.0/4.9.0/plugin/include/tm.h:13: In file included from /sw/lib/gcc4.9/lib/gcc/x86_64-apple-darwin12.5.0/4.9.0/plugin/include/options.h:8: /sw/lib/gcc4.9/lib/gcc/x86_64-apple-darwin12.5.0/4.9.0/plugin/include/config/i386/i386-opts.h:37:10: fatal error: 'stringop.def' file not found #include stringop.def ^ 1 error generated. ...and if /sw/lib/gcc4.9/lib/gcc/x86_64-apple-darwin12.5.0/4.9.0/plugin/include/config/i386/stringop.def is present with... /sw/opt/llvm-3.4/bin/clang++ -c -I/sw/src/fink.build/dragonegg-gcc49-3.4-0/dragonegg-3.4/include/x86 -I/sw/src/fink.build/dragonegg-gcc49-3.4-0/dragonegg-3.4/include/darwin -g -DENABLE_BUILD_WITH_CXX -DENABLE_LTO -I/sw/include -I/sw/opt/llvm-3.4/include -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -fno-rtti -MD -MP -DIN_GCC -DLLVM_VERSION=\3.4svn\ -DTARGET_TRIPLE=\x86_64-apple-darwin12.5.0\ -DGCC_MAJOR=4 -DGCC_MINOR=9 -DGCC_MICRO=0 -I/sw/src/fink.build/dragonegg-gcc49-3.4-0/dragonegg-3.4/include -isystem/sw/lib/gcc4.9/lib/gcc/x86_64-apple-darwin12.5.0/4.9.0/plugin/include -DENABLE_BUILD_WITH_CXX -Wall -Wextra -DENABLE_LLVM_PLUGINS -I/sw/opt/llvm-3.4/include -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wmissing-field-initializers -pedantic -Wno-long-long -Wnon-virtual-dtor -O3 -DNDEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS /sw/src/fink.build/dragonegg-gcc49-3.4-0/dragonegg-3.4/src/Aliasing.cpp In file included from /sw/src/fink.build/dragonegg-gcc49-3.4-0/dragonegg-3.4/src/Aliasing.cpp:48: In file included from /sw/lib/gcc4.9/lib/gcc/x86_64-apple-darwin12.5.0/4.9.0/plugin/include/tm.h:17: /sw/lib/gcc4.9/lib/gcc/x86_64-apple-darwin12.5.0/4.9.0/plugin/include/config/i386/i386.h:270:10: fatal error: 'x86-tune.def' file not found #include x86-tune.def The new stringop.def and x86-tune.def files in gcc/config/i386 should be installed in the plugin/include/config/i386 subdirectory. The config/i386/stringop.def file was introduced with the commit... http://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=9b868067b84b43c4094bdbe0ff0e0285c5b63d44 and the config/i386/x86-tune.def was introduced with the commit... http://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=db01d63a78959f0437107d350ed900bca8a40c08
[Bug ipa/58398] [4.9 Regression] gcc.dg/attr-ifunc-4.c runfail regression after r202111
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58398 --- Comment #7 from edlinger at gcc dot gnu.org --- Author: edlinger Date: Tue Sep 17 14:51:06 2013 New Revision: 202655 URL: http://gcc.gnu.org/viewcvs?rev=202655root=gccview=rev Log: 2013-09-17 Bernd Edlinger bernd.edlin...@hotmail.de PR ipa/58398 * cgraph.c (cgraph_function_body_availability): Check for ifunc attribute, and don't inline the resolver in this case. Modified: trunk/gcc/ChangeLog trunk/gcc/cgraph.c
[Bug target/58446] New: Support for musl libc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58446 Bug ID: 58446 Summary: Support for musl libc Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: gcc-bug-espfv4bhi9 at gregor dot im Created attachment 30829 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30829action=edit gcc/ arch-generic configuration and fixes for musl The attached patches add support for targeting the musl C library for Linux, http://musl-libc.org/ The patches are: gcc-config-musl.diff: Addition of -mmusl (akin to -mglibc, -muclibc, -mbionic) for musl libc support, as well as support for using the musl ld.so, patch to stddef.h for musl size_t support, etc. Most controversially, redefines the include dir ordering iff musl is the default target. gomp-posix.diff: Not directly related to musl, a fix to libgomp to make it properly specify required POSIX version. gcc-config-dliterate.diff: gcc_cv_target_dl_iterate_phdr=yes for musl libssp.diff: Support for libcs which provide libssp functions in libc (of which musl is the only example at present) x86.diff, arm.diff, mips.diff, powerpc.diff, aarch64.diff: ld.so specification for each target and related fixes.
[Bug target/58446] Support for musl libc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58446 --- Comment #1 from Gregor Richards gcc-bug-espfv4bhi9 at gregor dot im --- Created attachment 30830 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30830action=edit Fix for gomp to specify _POSIX_SOURCE requirements
[Bug target/58446] Support for musl libc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58446 --- Comment #2 from Gregor Richards gcc-bug-espfv4bhi9 at gregor dot im --- Created attachment 30831 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30831action=edit gcc_cv_target_dl_iterate_phdr=yes on musl (note that due to a bug in making these .diffs, the configure.ac change is in libssp.diff ...)
[Bug ipa/58329] [4.9 Regression] ld: Invalid symbol type for plabel (.libs/libstdc++.lax/libc++11convenience.a/system_error.o, std::error_category::default_error_condition(int) const [clone .localalia
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58329 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-09-17 Ever confirmed|0 |1 --- Comment #13 from Jan Hubicka hubicka at gcc dot gnu.org --- I hope the patch fixes the bootstrap failure. Can you, please, test?
[Bug target/58446] Support for musl libc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58446 --- Comment #3 from Gregor Richards gcc-bug-espfv4bhi9 at gregor dot im --- Created attachment 30832 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30832action=edit libssp support for musl
[Bug libstdc++/58437] [4.7/4.8/4.9 Regression] Sorting value in reverse order is much slower compare to gcc44
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58437 --- Comment #10 from Jeffrey M. Birnbaum jmbnyc at gmail dot com --- Tammy, Something must have been in the air because your timestamp on the bug submission means that right at the time you were reporting the bug I was actively looking into why I was seeing horrible sort performance. I am working on an algo that requires a post sort of something 1B entries so I wanted to see worst case for std::sort on 500M and was stunned to see how poor it was. My CPU was Haswell so wondered if there was an issue so I tried another bug (that happened to have gcc 4.4.7) and realized it appeared to be a compiler or std lib regression. Anyhow, given the length of time that this has been out there it is weird that we reported the same bug within hours of each other. Best, /JMB
[Bug target/58446] Support for musl libc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58446 --- Comment #6 from Gregor Richards gcc-bug-espfv4bhi9 at gregor dot im --- Created attachment 30835 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30835action=edit mips support for musl
[Bug target/58446] Support for musl libc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58446 --- Comment #5 from Gregor Richards gcc-bug-espfv4bhi9 at gregor dot im --- Created attachment 30834 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30834action=edit arm support for musl
[Bug target/58446] Support for musl libc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58446 --- Comment #8 from Gregor Richards gcc-bug-espfv4bhi9 at gregor dot im --- Created attachment 30837 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30837action=edit aarch64 support for musl
[Bug target/58446] Support for musl libc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58446 --- Comment #7 from Gregor Richards gcc-bug-espfv4bhi9 at gregor dot im --- Created attachment 30836 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30836action=edit powerpc support for musl
[Bug target/58446] Support for musl libc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58446 Rich Felker bugdal at aerifal dot cx changed: What|Removed |Added CC||bugdal at aerifal dot cx --- Comment #9 from Rich Felker bugdal at aerifal dot cx --- I don't know what the maintenance policy is for non-latest releases, but it would be wonderful if we could get these into the 4.7 series before it's closed, too. Bootstrapping new toolchains/systems with a different libc than the host system's libc, it's much easier to start with a GCC that doesn't need C++, and it would be a big help if our users could just start with GCC 4.7.x and have it work out of the box, rather than needing to apply third-party patches. (Speaking from the standpoint of musl maintainer.)
[Bug libstdc++/58437] [4.7/4.8/4.9 Regression] Sorting value in reverse order is much slower compare to gcc44
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58437 --- Comment #11 from Tammy Hsu tammy at Cadence dot COM --- Jeffrey, It's weird indeed. We are still using gcc445 for our production releases and are in the process of evaluating gcc481/gcc473. The performance tests show slowness in some tests I also don't have gcc45x available in house, so don't know if this bug exists in gcc45. BTW, it's really nice to know someone else encountered the same issue. Tammy
[Bug libstdc++/58437] [4.7/4.8/4.9 Regression] Sorting value in reverse order is much slower compare to gcc44
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58437 --- Comment #9 from Tammy Hsu tammy at Cadence dot COM --- Marc/Paolo/Chris, Thanks a lot for your help. It's awesome to see so many activities within hours after submitting the bug. Thanks, Tammy
[Bug target/58446] Support for musl libc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58446 --- Comment #4 from Gregor Richards gcc-bug-espfv4bhi9 at gregor dot im --- Created attachment 30833 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30833action=edit x86/x86_64 support for musl
[Bug bootstrap/58441] [4.9 Regression] VTV headers are installed into the general include directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58441 --- Comment #3 from Caroline Tice cmtice at google dot com --- Could you be a little more specific please? What header are you seeing where?
[Bug tree-optimization/58447] New: ICE: verify_gimple failed tree-cfg.c:4819
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58447
Bug ID: 58447
Summary: ICE: verify_gimple failed tree-cfg.c:4819
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: dimhen at gmail dot com
Created attachment 30838
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30838action=edit
testcase
gcc-4.9 rev.202642
Fedora 19/x86_64
ICE with -O3
PASS with -O2
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc_current/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/dimhen/src/gcc_current/configure
--prefix=/usr/local/gcc_current --with-multilib-list=m64
--enable-checking=yes,df,fold,rtl,tree --enable-languages=c,c++,lto
--enable-plugin --with-tune=native --with-arch=native
--enable-version-specific-runtime-libs
Thread model: posix
gcc version 4.9.0 20130917 (experimental) [trunk revision 202642] (GCC)
$ g++ -fpreprocessed -O3 -c SmallVectorTest.ii
SmallVectorTest.ii: In member function ‘void
{anonymous}::Qgtest_TypeParam_::TestBody() [with gtest_TypeParam_ =
N{anonymous}::M]’:
SmallVectorTest.ii:97:43: error: invalid PHI argument
template typename gtest_TypeParam_ void Qgtest_TypeParam_::TestBody() {
^
.MEM_22
SmallVectorTest.ii:97:43: error: incompatible types in PHI argument 0
int
void
e_lsm.27_29 = PHI .MEM_22(3)
SmallVectorTest.ii:97:43: internal compiler error: verify_gimple failed
0xc69c2d verify_gimple_in_cfg(function*)
/home/dimhen/src/gcc_current/gcc/tree-cfg.c:4819
0xb4a677 execute_function_todo
/home/dimhen/src/gcc_current/gcc/passes.c:1833
0xb4add7 execute_todo
/home/dimhen/src/gcc_current/gcc/passes.c:1866
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug target/58442] bootstrapping vax crashes on NetBSD
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58442 --- Comment #2 from Jan-Benedict Glaw jbg...@lug-owl.de --- So r0 is waay off. As we're far into the function (950) and fiddling with r0, I guess this is the final part, preparing to return from here. An assembler dump of the whole function would be helpful I hope.
[Bug ipa/58329] [4.9 Regression] ld: Invalid symbol type for plabel (.libs/libstdc++.lax/libc++11convenience.a/system_error.o, std::error_category::default_error_condition(int) const [clone .localalia
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58329 --- Comment #12 from Jan Hubicka hubicka at gcc dot gnu.org --- Author: hubicka Date: Tue Sep 17 16:07:21 2013 New Revision: 202658 URL: http://gcc.gnu.org/viewcvs?rev=202658root=gccview=rev Log: PR middle-end/58329 * ipa-devirt.c (ipa_devirt): Be ready for symtab_nonoverwritable_alias to return NULL. * ipa.c (function_and_variable_visibility): Likewise. * ipa-profile.c (ipa_profile): Likewise. Modified: trunk/gcc/symtab.c
[Bug tree-optimization/58380] [4.9 Regression] ice in fold_comparison
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58380 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #12 from Jeffrey A. Law law at redhat dot com --- Fixed on trunk.
[Bug ipa/58332] [4.9 Regression] error: inlined_to pointer is set but no predecessors found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58332 --- Comment #3 from Jan Hubicka hubicka at gcc dot gnu.org --- Author: hubicka Date: Tue Sep 17 17:45:00 2013 New Revision: 202661 URL: http://gcc.gnu.org/viewcvs?rev=202661root=gccview=rev Log: PR middle-end/58332 * gcc.c-torture/compile/pr58332.c: New testcase. * cif-code.def (FUNCTION_NOT_OPTIMIZED): New CIF code. * ipa-inline.c (can_inline_edge_p): Do not downgrade FUNCTION_NOT_OPTIMIZED. * ipa-inline-analysis.c (compute_inline_parameters): Function not optimized is not inlinable unless it is alwaysinline. (inline_analyze_function): Force calls in not optimized function not inlinable. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr58332.c Modified: trunk/gcc/ChangeLog trunk/gcc/cif-code.def trunk/gcc/ipa-inline-analysis.c trunk/gcc/ipa-inline.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/58387] [4.9 Regression] wrong code at -Os and above on x86_64-linux-gnu (both 32-bit and 64-bit modes)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58387 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #22 from Jeffrey A. Law law at redhat dot com --- Fixed on trunk.
[Bug libstdc++/58437] [4.7/4.8/4.9 Regression] Sorting value in reverse order is much slower compare to gcc44
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58437 --- Comment #12 from Jeffrey M. Birnbaum jmbnyc at gmail dot com --- Tammy, We tested gcc 4.7.2, 4.6.2 and 4.4.3/5 (the bug is not in either 4.4.3/5). I have gcc 4.8.1 on my laptop but have not tried it yet. I confirmed the issue by compiling my test (almost identical to the one you submitted but using 500M elements) on 4.4.5 and then moving the executable over to a box with 4.7.2 installed. the native compiled program performed poorly compared to the one compiled with 4.4.5 (this also ruled out chip issues, i.e. haswell vs sandybridge). I knew something was wrong when my own single threaded merge sort that produces a gradient instead of sorting the data in place was outperforming the std::sort using -D_GLIBCXX_PARALLEL, i.e. parallel sort of 500M entries. Best, /JMB
[Bug c++/58449] New: templated cast operator and failed template deduction on copy-construction via assign operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58449
Bug ID: 58449
Summary: templated cast operator and failed template deduction
on copy-construction via assign operator
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: forestshade at hotmail dot de
The following code produces a compiler error:
-
#include iostream
using namespace std;
struct S {
};
class A {
public:
A(void* ptr) : ptr(ptr) {}
void* ptr;
templatetypename T
operator const T() const {
return *static_castT*(ptr);
}
};
int main() {
S test;
A a(test);
S s = a;
return 0;
}
-
while this one doesn't:
-
#include iostream
using namespace std;
struct S {
};
class A {
public:
A(void* ptr) : ptr(ptr) {}
void* ptr;
operator const S() const {
return *static_castS*(ptr);
}
};
int main() {
S test;
A a(test);
S s = a;
return 0;
}
-
I'm not exactly sure if the standard allows the line S s = a; in this case
but the code above should either both succeed or both fail.
[Bug c++/58448] New: ICE on invalid: tree_class_check_failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58448
Bug ID: 58448
Summary: ICE on invalid: tree_class_check_failed
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: dimhen at gmail dot com
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc_current/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/dimhen/src/gcc_current/configure
--prefix=/usr/local/gcc_current --with-multilib-list=m64
--enable-checking=yes,df,fold,rtl,tree --enable-languages=c,c++,lto
--enable-plugin --with-tune=native --with-arch=native
--enable-version-specific-runtime-libs
Thread model: posix
gcc version 4.9.0 20130917 (experimental) [trunk revision 202642] (GCC)
$ cat tree_class_check_failed.ii
class SmallVector struct Types4;
template typename, typename, typename, typename struct Types {
typedef Types4::Constructable
} TypesSmallVector, SmallVector, SmallVector, SmallVector::
$ g++ -fpreprocessed -fsyntax-only tree_class_check_failed.ii
tree_class_check_failed.ii:1:26: error: multiple types in one declaration
class SmallVector struct Types4;
^
tree_class_check_failed.ii:3:11: error: ‘Types4’ is not a template
typedef Types4::Constructable
^
tree_class_check_failed.ii:3:21: error: typedef name may not be a
nested-name-specifier
typedef Types4::Constructable
^
tree_class_check_failed.ii:3:21: error: expected ‘;’ at end of member
declaration
tree_class_check_failed.ii: In instantiation of ‘struct TypesSmallVector,
SmallVector, SmallVector, SmallVector’:
tree_class_check_failed.ii:4:60: required from here
tree_class_check_failed.ii:3:21: internal compiler error: tree check: expected
class ‘type’, have ‘exceptional’ (error_mark) in tsubst_decl, at cp/pt.c:10745
0xe287c9 tree_class_check_failed(tree_node const*, tree_code_class, char
const*, int, char const*)
/home/dimhen/src/gcc_current/gcc/tree.c:9258
0x65f7c1 tree_class_check
/home/dimhen/src/gcc_current/gcc/tree.h:2727
0x65f7c1 tsubst_decl
/home/dimhen/src/gcc_current/gcc/cp/pt.c:10745
0x64b5c4 tsubst(tree_node*, tree_node*, int, tree_node*)
/home/dimhen/src/gcc_current/gcc/cp/pt.c:11285
0x677f61 instantiate_class_template_1
/home/dimhen/src/gcc_current/gcc/cp/pt.c:8952
0x677f61 instantiate_class_template(tree_node*)
/home/dimhen/src/gcc_current/gcc/cp/pt.c:9216
0x70302b complete_type(tree_node*)
/home/dimhen/src/gcc_current/gcc/cp/typeck.c:132
0x6e1a9a cp_parser_nested_name_specifier_opt
/home/dimhen/src/gcc_current/gcc/cp/parser.c:5309
0x6e23bb cp_parser_nested_name_specifier
/home/dimhen/src/gcc_current/gcc/cp/parser.c:5372
0x6e24f3 cp_parser_ptr_operator
/home/dimhen/src/gcc_current/gcc/cp/parser.c:17302
0x6e879e cp_parser_declarator
/home/dimhen/src/gcc_current/gcc/cp/parser.c:16653
0x6ef959 cp_parser_init_declarator
/home/dimhen/src/gcc_current/gcc/cp/parser.c:16258
0x6f0c54 cp_parser_single_declaration
/home/dimhen/src/gcc_current/gcc/cp/parser.c:22647
0x6f3830 cp_parser_template_declaration_after_export
/home/dimhen/src/gcc_current/gcc/cp/parser.c:22449
0x6fb5c1 cp_parser_declaration
/home/dimhen/src/gcc_current/gcc/cp/parser.c:10728
0x6fa1ed cp_parser_declaration_seq_opt
/home/dimhen/src/gcc_current/gcc/cp/parser.c:10650
0x6fbac7 cp_parser_translation_unit
/home/dimhen/src/gcc_current/gcc/cp/parser.c:3939
0x6fbac7 c_parse_file()
/home/dimhen/src/gcc_current/gcc/cp/parser.c:28893
0x80e184 c_common_parse_file()
/home/dimhen/src/gcc_current/gcc/c-family/c-opts.c:1046
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
[Bug c++/58435] Applying a type transformation to a list: const ignored
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58435 --- Comment #5 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Tue Sep 17 17:46:03 2013 New Revision: 202662 URL: http://gcc.gnu.org/viewcvs?rev=202662root=gccview=rev Log: /cp 2013-09-17 Paolo Carlini paolo.carl...@oracle.com PR c++/58435 * pt.c (tsubst, [BOUND_TEMPLATE_TEMPLATE_PARM]): Take into account the cp_type_quals (r) too. /testsuite 2013-09-17 Paolo Carlini paolo.carl...@oracle.com PR c++/58435 * g++.dg/cpp0x/alias-decl-38.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/alias-decl-38.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug c++/58448] ICE on invalid: tree_class_check_failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58448 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-17 Ever confirmed|0 |1
[Bug rtl-optimization/47521] Unnecessary usage of edx register
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47521 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Jeffrey A. Law law at redhat dot com --- Manually confirmed Tony's results in c#7. Could easily be the switch to LRA which occurred in gcc-4.8.
[Bug bootstrap/58350] libvtv/testsuite: Makefile:369: *** missing separator. Stop.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58350 Dmitry G. Dyachenko dimhen at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dmitry G. Dyachenko dimhen at gmail dot com --- fixed 2013-09-07
[Bug c++/58435] Applying a type transformation to a list: const ignored
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58435 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Assignee|paolo.carlini at oracle dot com|unassigned at gcc dot gnu.org --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com --- Fixed for 4.9.0.
[Bug bootstrap/58441] [4.9 Regression] VTV headers are installed into the general include directory
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58441 --- Comment #4 from Dmitry Gorbachev d.g.gorbachev at gmail dot com --- vtv_fail.h, vtv_malloc.h, vtv_map.h, vtv_rts.h, vtv_set.h, vtv_utils.h are installed to /usr/local/include. GCC is configured with --enable-version-specific-runtime-libs (and --disable-bootstrap). Host/target/build is i686-pc-linux-gnu.
[Bug target/35455] [4.7/4.8/4.9 Regression] h8300: internal compiler error: in compute_frame_pointer_to_fb_displacement, at dwarf2out.c:10984
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35455 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added CC||segher at kernel dot crashing.org --- Comment #11 from Jeffrey A. Law law at redhat dot com --- *** Bug 39766 has been marked as a duplicate of this bug. ***
[Bug target/58446] Support for musl libc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58446 --- Comment #10 from joseph at codesourcery dot com joseph at codesourcery dot com --- On Tue, 17 Sep 2013, gcc-bug-espfv4bhi9 at gregor dot im wrote: libssp.diff: Support for libcs which provide libssp functions in libc (of which musl is the only example at present) glibc provides libssp functions since version 2.4. Apparently some people have a use for building libssp anyway (see bug 58312), but I'd think the build / installation of libssp should be disabled by default for glibc targets. (Though given this is a per-multilib matter, disabling may mean just avoiding building / installing anything rather than completely disabling the directory at toplevel.) Likewise, according to gcc/configure.ac, Bionic, and uClibc configured with __UCLIBC_HAS_SSP__.
[Bug target/58450] New: -fno-trapping-math causes decrease in performance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58450
Bug ID: 58450
Summary: -fno-trapping-math causes decrease in performance
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: ylow at graphlab dot com
The program computes the Gregory Liebniz Pi approximation for 100M iterations.
The algorithm is simple:
double pi_apx() {
double val = 0.0;
for (size_t i = 0;i PI_ITERATIONS; ++i) {
if (i % 2 == 0) {
val += 4.0 / (2 * i + 1);
} else {
val -= 4.0 / (2 * i + 1);
}
}
return val;
}
Compiling with g++ -std=c++11 t.cpp -O3 outputs
3.14159
364339 microseconds
And adding the -fno-trapping-math option roughly doubles runtime with output:
3.14159
698326 microseconds
Disassembling the output:
-O3 only:
0x00400980 +0:mov$0x1,%edx
0x00400985 +5:xor%eax,%eax
0x00400987 +7:xorpd %xmm0,%xmm0
0x0040098b +11:movsd 0x105(%rip),%xmm1# 0x400a98
0x00400993 +19:jmp0x4009b4 _Z6pi_apxv+52
0x00400995 +21:nopl (%rax)
0x00400998 +24:movapd %xmm1,%xmm3
0x0040099c +28:add$0x1,%rax
0x004009a0 +32:add$0x2,%rdx
0x004009a4 +36:cmp$0x5f5e100,%rax
0x004009aa +42:divsd %xmm2,%xmm3
0x004009ae +46:addsd %xmm3,%xmm0
0x004009b2 +50:je 0x4009d9 _Z6pi_apxv+89
0x004009b4 +52:test $0x1,%al
0x004009b6 +54:cvtsi2sd %rdx,%xmm2
0x004009bb +59:je 0x400998 _Z6pi_apxv+24
0x004009bd +61:movapd %xmm1,%xmm4
0x004009c1 +65:add$0x1,%rax
0x004009c5 +69:add$0x2,%rdx
0x004009c9 +73:cmp$0x5f5e100,%rax
0x004009cf +79:divsd %xmm2,%xmm4
0x004009d3 +83:subsd %xmm4,%xmm0
0x004009d7 +87:jne0x4009b4 _Z6pi_apxv+52
0x004009d9 +89:repz retq
-O3 -fno-trapping-math:
0x00400980 +0:xorpd %xmm1,%xmm1
0x00400984 +4:mov$0x1,%edx
0x00400989 +9:movsd 0x107(%rip),%xmm3# 0x400a98
0x00400991 +17:xor%eax,%eax
0x00400993 +19:nopl 0x0(%rax,%rax,1)
0x00400998 +24:cvtsi2sd %rdx,%xmm0
0x0040099d +29:test $0x1,%al
0x0040099f +31:movapd %xmm3,%xmm4
0x004009a3 +35:divsd %xmm0,%xmm4
0x004009a7 +39:movapd %xmm4,%xmm2
0x004009ab +43:addsd %xmm1,%xmm2
0x004009af +47:subsd %xmm4,%xmm1
0x004009b3 +51:movapd %xmm1,%xmm0
0x004009b7 +55:jne0x4009bd _Z6pi_apxv+61
0x004009b9 +57:movapd %xmm2,%xmm0
0x004009bd +61:add$0x1,%rax
0x004009c1 +65:add$0x2,%rdx
0x004009c5 +69:cmp$0x5f5e100,%rax
0x004009cb +75:movapd %xmm0,%xmm1
0x004009cf +79:jne0x400998 _Z6pi_apxv+24
0x004009d1 +81:repz retq
The optimization options that turn on -fno-trapping-math also produces the slow
down. (-funsafe-math-optimizations and -ffast-math)
Interestingly, adding -march=core-avx-i (the native CPU type of my machine)
also causes the slow down, even in combination with -mtune=core-avx-i
Disassembly of -O3 -march=core-avx-i
0x00400980 +0:mov$0x1,%edx
0x00400985 +5:xor%eax,%eax
0x00400987 +7:vxorpd %xmm0,%xmm0,%xmm0
0x0040098b +11:vmovsd 0xf5(%rip),%xmm1# 0x400a88
0x00400993 +19:jmp0x4009ac _Z6pi_apxv+44
0x00400995 +21:nopl (%rax)
0x00400998 +24:add$0x1,%rax
0x0040099c +28:vaddsd %xmm2,%xmm0,%xmm0
0x004009a0 +32:add$0x2,%rdx
0x004009a4 +36:cmp$0x5f5e100,%rax
0x004009aa +42:je 0x4009cd _Z6pi_apxv+77
0x004009ac +44:vcvtsi2sd %rdx,%xmm2,%xmm2
0x004009b1 +49:test $0x1,%al
0x004009b3 +51:vdivsd %xmm2,%xmm1,%xmm2
0x004009b7 +55:je 0x400998 _Z6pi_apxv+24
0x004009b9 +57:add$0x1,%rax
0x004009bd +61:vsubsd %xmm2,%xmm0,%xmm0
0x004009c1 +65:add$0x2,%rdx
0x004009c5 +69:cmp$0x5f5e100,%rax
0x004009cb +75:jne0x4009ac _Z6pi_apxv+44
0x004009cd +77:repz retq
Other Information:
gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-4.8.1/configure --program-suffix=-4.8 --enable-threads
--enable-lto --disable-bootstrap
[Bug target/58446] Support for musl libc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58446 --- Comment #11 from Gregor Richards gcc-bug-espfv4bhi9 at gregor dot im --- Aha. I didn't realize such a setting already existed; I'll test and update my patch later today to use the existing mechanism. Thanks for the info.
[Bug debug/39766] internal compiler error: in compute_frame_pointer_to_fb_displacement, at dwarf2out.c:12179
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39766 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Jeffrey A. Law law at redhat dot com --- Same faulting point, highly likely to be a duplicate. *** This bug has been marked as a duplicate of bug 35455 ***
[Bug tree-optimization/19794] [meta-bug] Jump threading related bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19794 Bug 19794 depends on bug 23622, which changed state. Bug 23622 Summary: Dom jump threading at -O1 confuses branch prediction http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23622 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug tree-optimization/23622] Dom jump threading at -O1 confuses branch prediction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23622 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|NEW |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #5 from Jeffrey A. Law law at redhat dot com --- AFAICT this works fine in the 4.9 trunk.
[Bug target/58450] -fno-trapping-math causes decrease in performance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58450 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-09-17 CC||hjl.tools at gmail dot com Ever confirmed|0 |1 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com --- This is related to PR 57988. Without -fno-trapping-math, there are 0x004009b6 +54:cvtsi2sd %rdx,%xmm2 0x004009bb +59:je 0x400998 _Z6pi_apxv+24 0x004009bd +61:movapd %xmm1,%xmm4 0x004009c1 +65:add$0x1,%rax 0x004009c5 +69:add$0x2,%rdx 0x004009c9 +73:cmp$0x5f5e100,%rax 0x004009cf +79:divsd %xmm2,%xmm4 It hides the latency of cvtsi2sd %rdx,%xmm2 due to partial SSE register stall. Please try the current trunk.
[Bug target/58450] -fno-trapping-math causes decrease in performance
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58450 --- Comment #1 from Marc Glisse glisse at gcc dot gnu.org --- I do see this time difference with 4.7 and 4.8 (didn't try to analyze), but not with 4.9 which seems fine.
[Bug ipa/58332] [4.9 Regression] error: inlined_to pointer is set but no predecessors found
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58332 --- Comment #4 from Jan Smets jan.sm...@alcatel-lucent.com --- Verified
[Bug c++/58448] ICE on invalid: tree_class_check_failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58448 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Target Milestone|--- |4.9.0 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Mine.
[Bug tree-optimization/58451] New: ICE with segfault at -O3 on x86_64-linux-gnu (both 32-bit and 64-bit modes)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58451
Bug ID: 58451
Summary: ICE with segfault at -O3 on x86_64-linux-gnu (both
32-bit and 64-bit modes)
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: su at cs dot ucdavis.edu
The following code causes an ICE when compiled with the current gcc trunk at
-O3 on x86_64-linux in both 32-bit and 64-bit modes.
This is a regression from 4.8.x.
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/usr/local/gcc-trunk/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../gcc-trunk/configure
--enable-languages=c,c++,objc,obj-c++,fortran,lto
--with-gmp=/usr/local/gcc-trunk --with-mpfr=/usr/local/gcc-trunk
--with-mpc=/usr/local/gcc-trunk --with-cloog=/usr/local/gcc-trunk
--prefix=/usr/local/gcc-trunk
Thread model: posix
gcc version 4.9.0 20130917 (experimental) [trunk revision 202643] (GCC)
$ gcc-trunk -O2 -c small.c
$ gcc-4.8 -O3 -c small.c
$ gcc-trunk -O3 -c small.c
small.c: In function ‘foo’:
small.c:3:6: internal compiler error: Segmentation fault
void foo ()
^
0x9249bf crash_signal
../../gcc-trunk/gcc/toplev.c:335
0xa2719d find_uses_to_rename_use
../../gcc-trunk/gcc/tree-ssa-loop-manip.c:369
0xa273d6 find_uses_to_rename_bb
../../gcc-trunk/gcc/tree-ssa-loop-manip.c:427
0xa27b6d find_uses_to_rename
../../gcc-trunk/gcc/tree-ssa-loop-manip.c:451
0xa27b6d rewrite_into_loop_closed_ssa(bitmap_head_def*, unsigned int)
../../gcc-trunk/gcc/tree-ssa-loop-manip.c:513
0x995070 tree_loop_distribution
../../gcc-trunk/gcc/tree-loop-distribution.c:1738
0x995070 execute
../../gcc-trunk/gcc/tree-loop-distribution.c:1781
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
$
---
int *a[2], b, c, d, e;
void foo ()
{
for (b = 1; b = 0; b--)
if (e)
{
a[b] = 0;
c = d = 0;
}
}
[Bug c++/58449] templated cast operator and failed template deduction on copy initialization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58449 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-17 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- I think there's another bug similar to this but I can't find it now.
[Bug target/58452] New: GCC 4.8 and trunk do not compile simple powerpc-linuxpaired -O3 case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58452 Bug ID: 58452 Summary: GCC 4.8 and trunk do not compile simple powerpc-linuxpaired -O3 case Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: meissner at gcc dot gnu.org While doing some work on power8, I wanted to make sure that for existing systems, I was generating the same code. So I built some code and ran it through various -mcpu= options. When I built a powerpc-linuxpaired compiler, the compiler has trouble with a simple loop that should be vectorized: -bns- ./xgcc -B./ -O3 -S -mcpu=750 foo3.c -mpaired foo3.c: In function ‘float_extern_set3’: foo3.c:8:26: internal compiler error: in expand_insn, at optabs.c:8274 float_extern_mem3[i] = p[i]; ^ 0x10514c5b expand_insn(insn_code, unsigned int, expand_operand*) /home/meissner/fsf-src/gcc-4_8-branch/gcc/optabs.c:8274 0x1032c3e7 expand_assignment(tree_node*, tree_node*, bool) /home/meissner/fsf-src/gcc-4_8-branch/gcc/expr.c:4668 0x1020b457 expand_gimple_stmt_1 /home/meissner/fsf-src/gcc-4_8-branch/gcc/cfgexpand.c:2208 0x1020bb9f expand_gimple_stmt /home/meissner/fsf-src/gcc-4_8-branch/gcc/cfgexpand.c:2304 0x1020c427 expand_gimple_basic_block /home/meissner/fsf-src/gcc-4_8-branch/gcc/cfgexpand.c:4138 0x10210763 gimple_expand_cfg /home/meissner/fsf-src/gcc-4_8-branch/gcc/cfgexpand.c:4657 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. In looking at it, it looks like Andrew and I missed modifying paired.md back in April 2011, when the vectorizer started checking the predicates of movmisalign: -bns- ./xgcc -B./ -O3 -S -mcpu=750 foo3.c -mpaired foo3.c: In function ‘float_extern_set3’: foo3.c:8:26: internal compiler error: in expand_insn, at optabs.c:8274 float_extern_mem3[i] = p[i]; ^ 0x10514c5b expand_insn(insn_code, unsigned int, expand_operand*) /home/meissner/fsf-src/gcc-4_8-branch/gcc/optabs.c:8274 0x1032c3e7 expand_assignment(tree_node*, tree_node*, bool) /home/meissner/fsf-src/gcc-4_8-branch/gcc/expr.c:4668 0x1020b457 expand_gimple_stmt_1 /home/meissner/fsf-src/gcc-4_8-branch/gcc/cfgexpand.c:2208 0x1020bb9f expand_gimple_stmt /home/meissner/fsf-src/gcc-4_8-branch/gcc/cfgexpand.c:2304 0x1020c427 expand_gimple_basic_block /home/meissner/fsf-src/gcc-4_8-branch/gcc/cfgexpand.c:4138 0x10210763 gimple_expand_cfg /home/meissner/fsf-src/gcc-4_8-branch/gcc/cfgexpand.c:4657 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. Using the same fix as was used in vector.md to change the predicates.md fixes the problem.
[Bug target/58452] GCC 4.8 and trunk do not compile simple powerpc-linuxpaired -O3 case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58452 Michael Meissner meissner at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-09-17 Assignee|unassigned at gcc dot gnu.org |meissner at gcc dot gnu.org Ever confirmed|0 |1
[Bug target/58452] GCC 4.8 and trunk do not compile simple powerpc-linuxpaired -O3 case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58452 --- Comment #1 from Michael Meissner meissner at gcc dot gnu.org --- Created attachment 30839 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30839action=edit Example the shows the problem
[Bug target/58452] GCC 4.8 and trunk do not compile simple powerpc-linuxpaired -O3 case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58452 --- Comment #2 from Michael Meissner meissner at gcc dot gnu.org --- Created attachment 30840 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30840action=edit Proposed patch that fixes the problem
[Bug tree-optimization/58453] New: Revision 202431 results in miscompare for CPU2006 434.zeusmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58453 Bug ID: 58453 Summary: Revision 202431 results in miscompare for CPU2006 434.zeusmp Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: pthaugen at gcc dot gnu.org CC: bergner at gcc dot gnu.org, dje at gcc dot gnu.org, rguenth at gcc dot gnu.org Host: powerpc64-linux Target: powerpc64-linux Build: powerpc64-linux Miscompare of 434.zeusmp started on PowerPC with revision 202431. Richi suggested on irc to update to r202521 which contains fix for pr58396, but I'm still seeing the miscompare. Have not been able to track down to failing assembler yet but will attatch some files in hope that it may help.
[Bug tree-optimization/58453] Revision 202431 results in miscompare for CPU2006 434.zeusmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58453 --- Comment #1 from Pat Haugen pthaugen at gcc dot gnu.org --- Created attachment 30841 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30841action=edit Source file pdv.f source file from benchmark, which results in successful execution if compiled with prior revision (r202429). Should have noted in prior comment, compile options used when building the benchmark are: -m64 -O3 -mcpu=power7 -fno-tree-loop-distribution -fno-tree-vectorize (Note that failure still exists for just -m64 -O3 -mcpu=power7 other 2 options were just included while trying to narrow down dumps/assembler for debugging.) Compiling with -fno-tree-loop-distribute-patterns results in benchmark success.
[Bug tree-optimization/58453] Revision 202431 results in miscompare for CPU2006 434.zeusmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58453 --- Comment #2 from Pat Haugen pthaugen at gcc dot gnu.org --- Created attachment 30842 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30842action=edit r202429 ldist dump Loop distribution dump for pdv.f using rev 202429.
[Bug tree-optimization/58453] Revision 202431 results in miscompare for CPU2006 434.zeusmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58453 --- Comment #3 from Pat Haugen pthaugen at gcc dot gnu.org --- Created attachment 30843 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30843action=edit r202431 ldist dump Loop distribution dump for pdv.f using rev 202431.
[Bug c/58454] New: Potentially wrong(or at least weird/inconsistent) code generation with -O2 -fno-strict-overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58454 Bug ID: 58454 Summary: Potentially wrong(or at least weird/inconsistent) code generation with -O2 -fno-strict-overflow Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: mednafen at gmail dot com Created attachment 30844 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30844action=edit Testcase program. Working: XXX@willow:~/halt$ /usr/local/gcc-4.8.1/bin/gcc -Wall -O0 -o halt halt.c XXX@willow:~/halt$ ./halt IMm3: IMm2: *** IMm1: ** IM: * : XXX@willow:~/halt$ /usr/local/gcc-4.8.1/bin/gcc -Wall -O2 -o halt halt.c XXX@willow:~/halt$ ./halt IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: Aborted Working: XXX@willow:~/halt$ /usr/local/gcc-4.8.1/bin/gcc -Wall -O2 -fno-aggressive-loop-optimizations -o halt halt.c XXX@willow:~/halt$ ./halt IMm3: Aborted Broken: XXX@willow:~/halt$ /usr/local/gcc-4.8.1/bin/gcc -Wall -O2 -fno-strict-overflow -o halt halt.c XXX@willow:~/halt$ ./halt IMm3: IMm2: *** IMm1: *Aborted Broken: XXX@willow:~/halt$ /usr/local/gcc-4.8.1/bin/gcc -Wall -O2 -fno-aggressive-loop-optimizations -fno-strict-overflow -o halt halt.c XXX@willow:~/halt$ ./halt IMm3: IMm2: *** IMm1: *Aborted Working: XXX@willow:~/halt$ /usr/local/gcc-4.8.1/bin/gcc -Wall -O2 -fno-strict-overflow -fno-tree-vrp -o halt halt.c XXX@willow:~/halt$ ./halt IMm3: IMm2: *** IMm1: ** IM: * Working: XXX@willow:~/halt$ /usr/local/gcc-4.8.1/bin/gcc -Wall -O2 -fno-strict-overflow -fwrapv -o halt halt.c XXX@willow:~/halt$ ./halt IMm3: IMm2: *** IMm1: ** IM: * XXX@willow:~/halt$ /usr/local/gcc-4.8.1/bin/gcc -v Using built-in specs. COLLECT_GCC=/usr/local/gcc-4.8.1/bin/gcc COLLECT_LTO_WRAPPER=/usr/local/gcc-4.8.1/libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.8.1/configure --prefix=/usr/local/gcc-4.8.1 Thread model: posix gcc version 4.8.1 (GCC)
[Bug tree-optimization/58453] Revision 202431 results in miscompare for CPU2006 434.zeusmp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58453 --- Comment #4 from Pat Haugen pthaugen at gcc dot gnu.org --- Just discovered that -fwrapv results in successful execution also, so possibly bad source.
Re: [Bug c/58454] New: Potentially wrong(or at least weird/inconsistent) code generation with -O2 -fno-strict-overflow
All of these functions overflow the loop induction variable so only -fwrapv will provide the behavior you want for all of the functions. The inconsistent behavior is due to the overflows happening for induction variables. If it was not an induction variable then -fno-strict-overflow would have worked..-fno-strict-overflow is only defined to work for non loop variables. Thanks, Andrew On Sep 17, 2013, at 6:28 PM, mednafen at gmail dot com gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58454 Bug ID: 58454 Summary: Potentially wrong(or at least weird/inconsistent) code generation with -O2 -fno-strict-overflow Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: mednafen at gmail dot com Created attachment 30844 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30844action=edit Testcase program. Working: XXX@willow:~/halt$ /usr/local/gcc-4.8.1/bin/gcc -Wall -O0 -o halt halt.c XXX@willow:~/halt$ ./halt IMm3: IMm2: *** IMm1: ** IM: * : XXX@willow:~/halt$ /usr/local/gcc-4.8.1/bin/gcc -Wall -O2 -o halt halt.c XXX@willow:~/halt$ ./halt IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: Aborted Working: XXX@willow:~/halt$ /usr/local/gcc-4.8.1/bin/gcc -Wall -O2 -fno-aggressive-loop-optimizations -o halt halt.c XXX@willow:~/halt$ ./halt IMm3: Aborted Broken: XXX@willow:~/halt$ /usr/local/gcc-4.8.1/bin/gcc -Wall -O2 -fno-strict-overflow -o halt halt.c XXX@willow:~/halt$ ./halt IMm3: IMm2: *** IMm1: *Aborted Broken: XXX@willow:~/halt$ /usr/local/gcc-4.8.1/bin/gcc -Wall -O2 -fno-aggressive-loop-optimizations -fno-strict-overflow -o halt halt.c XXX@willow:~/halt$ ./halt IMm3: IMm2: *** IMm1: *Aborted Working: XXX@willow:~/halt$ /usr/local/gcc-4.8.1/bin/gcc -Wall -O2 -fno-strict-overflow -fno-tree-vrp -o halt halt.c XXX@willow:~/halt$ ./halt IMm3: IMm2: *** IMm1: ** IM: * Working: XXX@willow:~/halt$ /usr/local/gcc-4.8.1/bin/gcc -Wall -O2 -fno-strict-overflow -fwrapv -o halt halt.c XXX@willow:~/halt$ ./halt IMm3: IMm2: *** IMm1: ** IM: * XXX@willow:~/halt$ /usr/local/gcc-4.8.1/bin/gcc -v Using built-in specs. COLLECT_GCC=/usr/local/gcc-4.8.1/bin/gcc COLLECT_LTO_WRAPPER=/usr/local/gcc-4.8.1/libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.8.1/configure --prefix=/usr/local/gcc-4.8.1 Thread model: posix gcc version 4.8.1 (GCC)
[Bug c/58454] Potentially wrong(or at least weird/inconsistent) code generation with -O2 -fno-strict-overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58454 --- Comment #1 from pinskia at gmail dot com pinskia at gmail dot com --- All of these functions overflow the loop induction variable so only -fwrapv will provide the behavior you want for all of the functions. The inconsistent behavior is due to the overflows happening for induction variables. If it was not an induction variable then -fno-strict-overflow would have worked..-fno-strict-overflow is only defined to work for non loop variables. Thanks, Andrew On Sep 17, 2013, at 6:28 PM, mednafen at gmail dot com gcc-bugzi...@gcc.gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58454 Bug ID: 58454 Summary: Potentially wrong(or at least weird/inconsistent) code generation with -O2 -fno-strict-overflow Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: mednafen at gmail dot com Created attachment 30844 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30844action=edit Testcase program. Working: XXX@willow:~/halt$ /usr/local/gcc-4.8.1/bin/gcc -Wall -O0 -o halt halt.c XXX@willow:~/halt$ ./halt IMm3: IMm2: *** IMm1: ** IM: * : XXX@willow:~/halt$ /usr/local/gcc-4.8.1/bin/gcc -Wall -O2 -o halt halt.c XXX@willow:~/halt$ ./halt IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: IMm3: Aborted Working: XXX@willow:~/halt$ /usr/local/gcc-4.8.1/bin/gcc -Wall -O2 -fno-aggressive-loop-optimizations -o halt halt.c XXX@willow:~/halt$ ./halt IMm3: Aborted Broken: XXX@willow:~/halt$ /usr/local/gcc-4.8.1/bin/gcc -Wall -O2 -fno-strict-overflow -o halt halt.c XXX@willow:~/halt$ ./halt IMm3: IMm2: *** IMm1: *Aborted Broken: XXX@willow:~/halt$ /usr/local/gcc-4.8.1/bin/gcc -Wall -O2 -fno-aggressive-loop-optimizations -fno-strict-overflow -o halt halt.c XXX@willow:~/halt$ ./halt IMm3: IMm2: *** IMm1: *Aborted Working: XXX@willow:~/halt$ /usr/local/gcc-4.8.1/bin/gcc -Wall -O2 -fno-strict-overflow -fno-tree-vrp -o halt halt.c XXX@willow:~/halt$ ./halt IMm3: IMm2: *** IMm1: ** IM: * Working: XXX@willow:~/halt$ /usr/local/gcc-4.8.1/bin/gcc -Wall -O2 -fno-strict-overflow -fwrapv -o halt halt.c XXX@willow:~/halt$ ./halt IMm3: IMm2: *** IMm1: ** IM: * XXX@willow:~/halt$ /usr/local/gcc-4.8.1/bin/gcc -v Using built-in specs. COLLECT_GCC=/usr/local/gcc-4.8.1/bin/gcc COLLECT_LTO_WRAPPER=/usr/local/gcc-4.8.1/libexec/gcc/x86_64-unknown-linux-gnu/4.8.1/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.8.1/configure --prefix=/usr/local/gcc-4.8.1 Thread model: posix gcc version 4.8.1 (GCC)
[Bug fortran/58436] [4.9 Regression][OOP] ICE (segfault) in generate_finalization_wrapper for CLASS(*)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58436 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org --- Submitted patch: http://gcc.gnu.org/ml/fortran/2013-09/msg00031.html
[Bug c/58454] Potentially wrong(or at least weird/inconsistent) code generation with -O2 -fno-strict-overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58454 --- Comment #2 from mednafen at gmail dot com --- Your assertion conflicts with the gcc 4.2 release change-list at http://gcc.gnu.org/gcc-4.2/changes.html when the strict-overflow options were added. Additionally, -fwrapv produces unnecessarily bloated code compared to -fno-strict-overflow, in my experience.
