[Bug libgomp/58642] gomp regression: not "honoring" anymore task set and numactl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58642 --- Comment #29 from Jakub Jelinek --- Created attachment 30967 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30967&action=edit Y Ah, thanks, I can see where the failing sched_getaffinity calls are coming from, hopefully this patch should fix that. That doesn't explain the libgomp errors you were getting though (if you can still reproduce them). To track that perhaps we could instrument libgomp to tell us more details.
[Bug libgomp/58642] gomp regression: not "honoring" anymore task set and numactl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58642
--- Comment #30 from vincenzo Innocente ---
better: as usual nastier bugs are in the tests!
[innocent@olsnba04 parallel]$ strace ./affinity-1.exe | & grep affin
execve("./affinity-1.exe", ["./affinity-1.exe"], [/* 61 vars */]) = 0
sched_getaffinity(110481, 8, 0x7b8010) = -1 EINVAL (Invalid argument)
sched_getaffinity(110481, 128, { , 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0 }) = 128
sched_getaffinity(110481, 128, { , 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0, 0, 0 }) = 128
sched_setaffinity(110481, 8, { 1 })= 0
sched_getaffinity(110481, 128, { 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0 }) = 128
sched_setaffinity(110482, 8, { 4 })= 0
sched_setaffinity(110483, 8, { 10 }) = 0
sched_setaffinity(110484, 8, { 40 }) = 0
sched_getaffinity(110481, 128, { 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0 }) = 128
sched_setaffinity(110503, 8, { 80 }) = 0
sched_getaffinity(110481, 128, { 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0 }) = 128
sched_setaffinity(110518, 8, { 1 })= 0
sched_setaffinity(110519, 8, { 1 })= 0
sched_getaffinity(110481, 128, { 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0 }) = 128
sched_setaffinity(110542, 8, { 2 })= 0
sched_setaffinity(110543, 8, { 4 })= 0
sched_setaffinity(110544, 8, { 8 })= 0
sched_setaffinity(110545, 8, { 10 }) = 0
sched_getaffinity(110481, 128, { 1, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0,
0 }) = 128
[innocent@olsnba04 parallel]$ ./affinity-1.exe
OMP_PROC_BIND='spread,master,close' OMP_PLACES='{0}:8'
Initial thread bound to {0}, verified
#1 thread 0 bound to {0}, verified
#1 thread 1 bound to {2}, verified
#1 thread 2 bound to {4}, verified
#1 thread 3 bound to {6}, verified
#1,#1 thread 3,0 bound to {6}, verified
#1,#1 thread 3,2 bound to {6}, verified
#1,#1 thread 3,1 bound to {6}, verified
#1,#2 thread 3,0 bound to {6}, verified
#1,#2 thread 3,3 bound to {7}, verified
#1,#2 thread 3,4 bound to {6}, verified
#1,#2 thread 3,2 bound to {7}, verified
#1,#2 thread 3,1 bound to {6}, verified
#1,#2,#1 thread 3,3,0 bound to {7}, verified
#1,#2,#1 thread 3,3,4 bound to {7}, verified
#1,#2,#1 thread 3,3,3 bound to {7}, verified
#1,#2,#1 thread 3,3,2 bound to {7}, verified
#1,#2,#1 thread 3,3,1 bound to {7}, verified
#1,#3 thread 3,0 bound to {6}, verified
#1,#3 thread 3,3 bound to {6}, verified
#1,#3 thread 3,2 bound to {6}, verified
#1,#3 thread 3,1 bound to {6}, verified
#1,#4 thread 3,4 bound to {7}, verified
#1,#4 thread 3,0 bound to {6}, verified
#1,#4 thread 3,3 bound to {7}, verified
#1,#4 thread 3,2 bound to {6}, verified
#1,#4 thread 3,5 bound to {7}, verified
#1,#4 thread 3,1 bound to {6}, verified
#2 thread 0 bound to {0}, verified
#2 thread 1 bound to {2}, verified
#2 thread 3 bound to {6}, verified
#2 thread 4 bound to {7}, verified
#2 thread 2 bound to {4}, verified
#2,#1 thread 3,0 bound to {6}, verified
#2,#1 thread 3,2 bound to {6}, verified
#2,#1 thread 3,1 bound to {6}, verified
#2,#2 thread 3,0 bound to {6}, verified
#2,#2 thread 3,4 bound to {6}, verified
#2,#2 thread 3,3 bound to {6}, verified
#2,#2 thread 3,2 bound to {6}, verified
#2,#2 thread 3,1 bound to {6}, verified
#2,#3 thread 3,0 bound to {6}, verified
#2,#3 thread 3,3 bound to {6}, verified
#2,#3 thread 3,2 bound to {6}, verified
#2,#3 thread 3,1 bound to {6}, verified
#2,#4 thread 3,0 bound to {6}, verified
#2,#4 thread 3,5 bound to {6}, verified
#2,#4 thread 3,4 bound to {6}, verified
#2,#4 thread 3,3 bound to {6}, verified
#2,#4 thread 3,2 bound to {6}, verified
#2,#4 thread 3,1 bound to {6}, verified
#3 thread 0 bound to {0}, verified
#3 thread 2 bound to {0}, verified
#3 thread 1 bound to {0}, verified
#3,#1 thread 2,0 bound to {0}, verified
#3,#1 thread 2,3 bound to {0}, verified
#3,#1 thread 2,2 bound to {0}, verified
#3,#1 thread 2,1 bound to {0}, verified
#3,#2 thread 2,2 bound to {4}, verified
#3,#2 thread 2,1 bound to {2}, verified
#3,#2 thread 2,0 bound to {0}, verified
#3,#2 thread 2,3 bound to {6}, verified
#3,#2,#1 thread 2,0,1 bound to {0}, verified
#3,#2,#1 thread 2,0,0 bound to {0}, verified
#3,#2,#1 thread 2,0,3 bound to {1}, verified
#3,#2,#1 thread 2,0,4 bound to {0}, verified
#3,#2,#1 thread 2,0,2 bound to {1}, verified
#3,#2,#2 thread 2,3,0 bound to {6}, verified
#3,#2,#2 thread 2,3,3 bound to {7}, verified
#3,#2,#2 thread 2,3,2 bound to {7}, verified
#3,#2,#2 thread 2,3,4 bound to {6}, verified
#3,#2,#2 thread 2,3,1 bound to {6}, verified
#3,#3 thread 2,0 bound to {0}, verified
#3,#3 thread 2,3 bound to {0}, verified
#3,#3 thread 2,2 bound to {0}, verified
#3,#3 thread 2,1 bound to {0}, verified
#3,#4 thread 2,1 bound to {1}, verified
#3,#4 thread 2,5 bound to {5}, verified
#3,#4 thread 2,3 bound to {3}, verified
#3,#4 thread 2,0 bound to {0}, verified
#3,#4 thread 2,2 bound to {2}, verified
#3,#4 thread 2,4 bound to {4}, verified
#4 thread 1 bound to {1}, verified
#4 thread 2 bound to {2}, verified
#4 thread 3 bound to {3}, verified
#4 thread 4 boun
[Bug tree-optimization/58662] wrong code at -O2 and -O3 on x86_64-linux-gnu (in 64-bit mode)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58662 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-10-08 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |4.9.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed. It seems to be the VRP; adding -fno-tree-vrp makes trunk behave as 4.8.
[Bug target/58423] [ARM]ICE with shrink-wrap-sibcall.c on a15/neon/hard
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58423 --- Comment #2 from xuepeng guo --- Author: xguo Date: Tue Oct 8 07:58:08 2013 New Revision: 203267 URL: http://gcc.gnu.org/viewcvs?rev=203267&root=gcc&view=rev Log: 2013-10-08 Zhenqiang Chen PR target/58423 * config/arm/arm.c (arm_emit_ldrd_pop): Attach RTX_FRAME_RELATED_P on INSN. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/arm.c
[Bug tree-optimization/58570] [4.9 Regression] wrong code for bitfields at -O2 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58570 --- Comment #7 from Eric Botcazou --- > What if both bit fields have different DECL_BIT_FIELD_REPRESENTATIVE? > > Then they can't possibly overlap? Probably, yes, that could be a nice enhancement.
[Bug middle-end/58570] [4.9 Regression] wrong code for bitfields at -O2 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58570 Eric Botcazou changed: What|Removed |Added Component|tree-optimization |middle-end --- Comment #8 from Eric Botcazou --- Recategorizing.
[Bug tree-optimization/58662] wrong code at -O2 and -O3 on x86_64-linux-gnu (in 64-bit mode)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58662 Marek Polacek changed: What|Removed |Added CC||rguenth at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Started with r202944.
[Bug tree-optimization/58619] ICE building in gen_combined_adhoc_loc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58619 --- Comment #4 from Ramana Radhakrishnan --- Author: ramana Date: Tue Oct 8 08:34:28 2013 New Revision: 203269 URL: http://gcc.gnu.org/viewcvs?rev=203269&root=gcc&view=rev Log: PR tree-optimization/58619 2013-10-08 Dehao Chen * tree-inline.c (copy_phis_for_bb): Combine location data only if non-null. Modified: trunk/gcc/ChangeLog trunk/gcc/tree-inline.c
[Bug libgcc/58660] ARM/Thumb non-interworking code broken in libgcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58660 --- Comment #1 from Richard Earnshaw --- Please post patches to gcc-patc...@gcc.gnu.org and x-ref this PR.
[Bug c++/58661] Definition of inherited nested class should be invalid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58661 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-10-08 Ever confirmed|0 |1
[Bug rtl-optimization/54300] [4.7, 4.8, 4.9 Regression] regcprop incorrectly looks through parallel register swap operation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54300 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot gnu.org --- Comment #10 from Eric Botcazou --- > and regcprop substitues d19 for d18 in insn 27, missing the fact that insn > 73 is swapping the two values (thus clobbering the old d19 value). It's probably fooled by single_set returning the first set of the insn because of the REG_UNUSED note. I wonder whether it's a generic pitfall of single_set.
[Bug testsuite/58645] FAIL: gnat.dg/specs/linker_alias.ads (test for errors, line 6)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58645 Eric Botcazou changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2013-10-08 CC||ebotcazou at gcc dot gnu.org --- Comment #1 from Eric Botcazou --- Sure, but you can just skip the testcase like on Darwin.
[Bug rtl-optimization/54300] [4.7, 4.8, 4.9 Regression] regcprop incorrectly looks through parallel register swap operation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54300 --- Comment #11 from Richard Earnshaw --- (In reply to Eric Botcazou from comment #10) > > and regcprop substitues d19 for d18 in insn 27, missing the fact that insn > > 73 is swapping the two values (thus clobbering the old d19 value). > > It's probably fooled by single_set returning the first set of the insn > because of the REG_UNUSED note. I wonder whether it's a generic pitfall of > single_set. Hmm, interesting. Perhaps single_set should not do this if the dead set clobbers an input.
[Bug tree-optimization/58480] Use attribute((nonnull)) to optimize callers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58480
--- Comment #1 from Marc Glisse ---
Author: glisse
Date: Tue Oct 8 10:39:49 2013
New Revision: 203271
URL: http://gcc.gnu.org/viewcvs?rev=203271&root=gcc&view=rev
Log:
2013-10-08 Marc Glisse
PR tree-optimization/58480
gcc/
* tree-vrp.c (infer_nonnull_range): New function.
(infer_value_range): Call infer_nonnull_range.
gcc/testsuite/
* gcc.dg/tree-ssa/pr58480.c: New file.
Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/pr58480.c (with props)
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-vrp.c
Propchange: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr58480.c
('svn:eol-style' added)
Propchange: trunk/gcc/testsuite/gcc.dg/tree-ssa/pr58480.c
('svn:keywords' added)
[Bug tree-optimization/58480] Use attribute((nonnull)) to optimize callers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58480 Marc Glisse changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Assignee|unassigned at gcc dot gnu.org |glisse at gcc dot gnu.org --- Comment #2 from Marc Glisse --- Done for 4.9.
[Bug tree-optimization/58483] missing optimization opportunity for const std::vector compared to std::array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58483 Bug 58483 depends on bug 58480, which changed state. Bug 58480 Summary: Use attribute((nonnull)) to optimize callers http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58480 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED
[Bug rtl-optimization/54300] [4.7, 4.8, 4.9 Regression] regcprop incorrectly looks through parallel register swap operation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54300 --- Comment #12 from Eric Botcazou --- > Hmm, interesting. Perhaps single_set should not do this if the dead set > clobbers an input. Yes, that seems to be a sensible proposal, but single_set is an old thing.
[Bug tree-optimization/58662] wrong code at -O2 and -O3 on x86_64-linux-gnu (in 64-bit mode)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58662
--- Comment #3 from Marek Polacek ---
Actually, I think it's the uncprop:
--- Q.c.139t.crited22013-10-08 13:03:04.169955615 +0200
+++ Q.c.141t.uncprop12013-10-08 13:03:04.169955615 +0200
@@ -51,7 +51,7 @@
_13 = (int) _8;
:
- # iftmp.3_1 = PHI <0(5), _13(3)>
+ # iftmp.3_1 = PHI <_7(5), _13(3)>
b = iftmp.3_1;
printf ("%d\n", iftmp.3_1);
return 0;
so -fno-tree-dominator-opts makes the bug go away.
[Bug libstdc++/58659] Construction of shared_ptr from unique_ptr mismatches new/delete and std::allocator for __shared_ptr_count
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58659 --- Comment #2 from Jonathan Wakely --- Author: redi Date: Tue Oct 8 12:33:37 2013 New Revision: 203274 URL: http://gcc.gnu.org/viewcvs?rev=203274&root=gcc&view=rev Log: PR libstdc++/58659 * include/bits/shared_ptr_base.h (__shared_count::__shared_count(P,D)): Delegate to constructor taking allocator. (__shared_count::_S_create_from_up): Inline into ... (__shared_count::__shared_count(unique_ptr&&): Here. Use std::conditional instead of constrained overloads. Allocate memory using the allocator type that will be used for deallocation. * testsuite/20_util/shared_ptr/cons/58659.cc: New. * testsuite/20_util/shared_ptr/cons/43820_neg.cc: Adjust. Added: trunk/libstdc++-v3/testsuite/20_util/shared_ptr/cons/58659.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/shared_ptr_base.h trunk/libstdc++-v3/testsuite/20_util/shared_ptr/cons/43820_neg.cc
[Bug debug/58663] New: entry-value: missing DW_TAG_GNU_call_site for libasan calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58663 Bug ID: 58663 Summary: entry-value: missing DW_TAG_GNU_call_site for libasan calls Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug Assignee: unassigned at gcc dot gnu.org Reporter: jan.kratochvil at redhat dot com Target: x86_64-unknown-linux-gnu FAIL: gcc (GCC) 4.9.0 20131008 (experimental) <1><5b4>: Abbrev Number: 5 (DW_TAG_subprogram) <5b5> DW_AT_name: (indirect string, offset: 0x2d16): main <5d1> DW_AT_GNU_all_tail_call_sites: 1 <2><5d5>: Abbrev Number: 6 (DW_TAG_variable) <2><5e1>: Abbrev Number: 0 .s: movq%rax, %rdi call__asan_report_store1 In practice one does not see the passed values: #4 0x0040f447 in __asan::__asan_report_store1 (addr=) #5 0x0041aafe in main () at old/test9.c:4 (gdb) set debug entry-values 1 (gdb) print addr DW_OP_GNU_entry_value resolving cannot find DW_TAG_GNU_call_site 0x41aafe in main Tried also -static-libasan, it does not / cannot help. (I am not sure entry-values would be valid here if the call site was present.)
[Bug fortran/42118] Slow forall
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42118 Lionel GUEZ changed: What|Removed |Added CC||ebay.20.tedlap@spamgourmet. ||com --- Comment #6 from Lionel GUEZ --- There is also the problem of the order of indices in a forall. I guess this is in close relation to the comparison of do and forall. Consider the following test program : program test_forall implicit none integer, parameter:: n = 1000 integer i, j, k double precision S(n, n, n) forall (i = 1: n, j = 1: n, k = 1: n) S(i, j, k) = i * j * k print *, "ijk, sum(s) = ", sum(s) end program test_forall According to the Fortran standard, the order of indices in the forall header is of no consequence. So, in the above program, we should be able to write equivalently : forall (k = 1: n, j = 1: n, i = 1: n) S(i, j, k) = i * j * k There is no way for the writer of the program to predict which of the two versions should be faster. It is interesting to note that, with gfortran, the forall with kji is much slower, while the inverse is true with the NAG compiler (version 5.3). I think the two versions should have the same run time. I have actually tested the two versions of the program with four compilers : -- gfortran 4.4.6 with -O3 kji, sum(s) = 1.253753751250046E+017 real1m32.511s user1m22.342s sys0m8.368s ijk, sum(s) = 1.253753751250046E+017 real0m12.962s user0m7.416s sys0m5.427s -- nagfor 5.3 with -O4 kji, sum(s) =1.2537537512500458E+17 real0m13.396s user0m6.833s sys0m6.054s ijk, sum(s) =1.2537537512500458E+17 real2m37.943s user2m27.723s sys0m7.873s -- pgf95 11.10 with -fast kji, sum(s) =1.253753751248E+017 real0m12.119s user0m6.051s sys0m5.910s ijk, sum(s) =1.253753751248E+017 real0m11.979s user0m5.854s sys0m5.939s -- ifort 12.1 with -O3 : kji, sum(s) = 1.25375375125E+017 real0m5.210s user0m3.028s sys0m2.150s ijk, sum(s) = 1.25375375125E+017 real0m5.114s user0m2.981s sys0m2.115s So we see that PG Fortran and Intel Fortran behave well : the two versions take about the same time. Also Intel Fortran is much faster than other compilers on this test. I would also like to comment on the use of the forall. Tobias Burnus says that improving the forall in Gfortran is not worth the effort. I think the forall is useful. It is an elegant way to write some assignments. There is no idea of time sequence in a forall and the forall can only contain an assignement while, as you know, the do construct could contain call to subroutines, input-output, recursive computations, anything. So when one reads a program and sees the forall it is much more quickly clear to understand what is going on than when one reads a do loop. Also the fact that assignments are independent (comment of Harald Anlauf) should make it easier for the compiler to produce a fast code.
[Bug libstdc++/58659] Construction of shared_ptr from unique_ptr mismatches new/delete and std::allocator for __shared_ptr_count
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58659 --- Comment #3 from Jonathan Wakely --- Author: redi Date: Tue Oct 8 13:38:21 2013 New Revision: 203277 URL: http://gcc.gnu.org/viewcvs?rev=203277&root=gcc&view=rev Log: PR libstdc++/58659 * include/bits/shared_ptr_base.h (__shared_count::__shared_count(P,D)): Delegate to constructor taking allocator. (__shared_count::_S_create_from_up): Inline into ... (__shared_count::__shared_count(unique_ptr&&): Here. Use std::conditional instead of constrained overloads. Allocate memory using the allocator type that will be used for deallocation. * testsuite/20_util/shared_ptr/cons/58659.cc: New. * testsuite/20_util/shared_ptr/cons/43820_neg.cc: Adjust. Added: branches/gcc-4_8-branch/libstdc++-v3/testsuite/20_util/shared_ptr/cons/58659.cc Modified: branches/gcc-4_8-branch/libstdc++-v3/ChangeLog branches/gcc-4_8-branch/libstdc++-v3/include/bits/shared_ptr_base.h branches/gcc-4_8-branch/libstdc++-v3/testsuite/20_util/shared_ptr/cons/43820_neg.cc
[Bug libstdc++/58659] Construction of shared_ptr from unique_ptr mismatches new/delete and std::allocator for __shared_ptr_count
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58659 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Jonathan Wakely --- I'm not going to backport this to the 4.7 branch, as it works fine in the default configuration.
[Bug c++/57850] [4.8/4.9 Regression] Option -fdump-translation-unit not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57850 --- Comment #12 from Dima --- Is this going to be applied for 4.9 & 4.8 series?
[Bug debug/58663] entry-value: missing DW_TAG_GNU_call_site for libasan calls
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58663
--- Comment #1 from Jan Kratochvil ---
#include
int main(void) {
char *p=malloc(1);
p[1]=1;
return 0;
}
[Bug rtl-optimization/58542] [4.7/4.8/4.9 Regression] subreg splitting pass mishandles TImode immediates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58542
--- Comment #5 from Uroš Bizjak ---
The problem actually starts in expand_atomic_compare_and_swap, in:
(gdb) list
7339 create_convert_operand_to (&ops[3], expected, mode, true);
7340 create_convert_operand_to (&ops[4], desired, mode, true);
7341 create_integer_operand (&ops[5], is_weak);
7342 create_integer_operand (&ops[6], succ_model);
7343 create_integer_operand (&ops[7], fail_model);
7344 expand_insn (icode, 8, ops);
ops[4] is converted in unsigned mode, so from "desired" operand:
(gdb) p debug_rtx (desired)
(const_int -1 [0x])
we got:
(gdb) p ops[4]
$45 = {type = EXPAND_CONVERT_TO, unsigned_p = 1, unused = 0, mode = TImode,
value = 0x7fffeffc21e0}
(gdb) p debug_rtx (ops[4].value)
(const_double -1 [0x] 0 [0] 0 [0] 0 [0])
So, it is actually expansion of atomic_compare_and_swap, which doesn't account
for signedness of "desired" operand.
Manually changing the argument from "true" to "false" for ops[4] generates
correct code.
[Bug tree-optimization/58619] ICE building in gen_combined_adhoc_loc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58619 --- Comment #5 from dehao at gcc dot gnu.org --- Author: dehao Date: Tue Oct 8 16:22:57 2013 New Revision: 203284 URL: http://gcc.gnu.org/viewcvs?rev=203284&root=gcc&view=rev Log: Backport r203269. PR tree-optimization/58619 2013-10-08 Dehao Chen * tree-inline.c (copy_phis_for_bb): Combine location data only if non-null. Modified: branches/google/gcc-4_8/gcc/tree-inline.c
[Bug fortran/42118] Slow forall
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42118 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #7 from Tobias Burnus --- (In reply to Harald Anlauf from comment #5) > Do not forget that there are constraints for FORALL statements that are > not required for DO loops so that all assignments are independent. > This guarantees vectorization Not quite: The Fortran standard requires that the RHS is evaluated before the assignment to the LHS is done. This might even imply the generation of a temporary variable. By contrast, DO CONCURRENT is much better: The user guarantees that the is no order dependence, while constraints ensure that the many violations of this are detected at compile time. In addition, DO CONCURRENT permits more things within its body. By the way, the Fortran committee is considering to deprecate FORALL in the next standard (Fortran 2015) because it considers FORALL superior in nearly all aspects. For DO CONCURRENT, I have a pending patch which sets the vectorization safelen to infinity (well INT_MAX). I wonder whether one could do likewise for FORALL; that probably needs some dependency fine tuning to ensure that there is dependency at all between the LHS and RHS. To avoid temporaries, it is sufficient to be either forward or backward dependency free. (Setting the safelen for whole-array operations probably also makes sense. There, the same applies.) (In reply to Lionel GUEZ from comment #6) > There is also the problem of the order of indices in a forall. I guess this > is in close relation to the comparison of do and forall. Try compiling with -floop-interchange (requires a GCC built with Graphite). Deciding which order is best is not a trivial task, although in simple cases as yours, it shouldn't be that difficult. Maybe someone finds the time to do it. [Presumably the same issue comes up with DO CONCURRENT, if one places multiple iteration variables into that statement (opposed to using multiple DO CONCURRENT statements with one iteration variable).] > According to the Fortran standard, the order of indices in the forall header > is of no consequence. Well, it doesn't with any of the compilers: The resulting value is always the same. The standard doesn't tell anything about the performance (not about the index walking order).
[Bug fortran/42118] Slow forall
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42118 --- Comment #8 from Tobias Burnus --- (In reply to Tobias Burnus from comment #7) > By the way, the Fortran committee is considering to deprecate FORALL in the > next standard (Fortran 2015) because it considers FORALL superior in nearly > all aspects. Change "FORALL" to "DO CONCURRENT" in the last line and "deprecate" to "obsolescent". See http://j3-fortran.org/doc/year/13/13-323.txt The proposal has not been accepted yet, but I also didn't see much opposition to it. Quoting the reasoning (proposed for Appendix B of the next Fortran standard): "The FORALL construct and statement were added to the language in the expectation that they would enable highly efficient execution, especially on parallel processors. However, the experience with them indicates that they are too complex and have too many restrictions for compilers to take advantage of them. They are redundant with the DO CONCURRENT loop, and may of the manipulations for which they might be used may be done more efficiently by use of pointers, especially using pointer rank remapping."
[Bug tree-optimization/58619] ICE building in gen_combined_adhoc_loc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58619 Ramana Radhakrishnan changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #6 from Ramana Radhakrishnan --- Fixed.
[Bug middle-end/58570] [4.9 Regression] wrong code for bitfields at -O2 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58570
--- Comment #9 from Bernd Edlinger ---
Eric,
there is one more thing to consider for your proposed patch,
that is the damned -fstrict-volatile-bitfields:
if strict_volatile_bitfields>0 and the BIT_FIELD access
is _volatile_ it does not respect the BIT_FIELD_REPRESENTATIVE at all.
that means for instance:
struct
{
int a:24;
char b;
} s;
s.a=1;
s.b=2;
we have a INT32 read-modify-write over b.
even worse:
struct
{
int a:24;
} __attribute__((packed)) s;
s.a=1;
uses an (unaligned) INT32 read-modify-write and may overwrite
one member of an adjacent structure.
Note that at least the second example should no longer write beyond
the structure if this patch is applied:
http://gcc.gnu.org/ml/gcc-patches/2013-09/msg02058.html
So you should expect an alias if either field is a VOLATILE
bit-field access and flag_strict_volatile_bitfields > 0.
Bernd.
[Bug c++/58633] [4.7/4.8/4.9 Regression] ICE with decltype of destructor call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58633 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-10-08 Ever confirmed|0 |1 --- Comment #1 from Paolo Carlini --- Mine.
[Bug middle-end/58570] [4.9 Regression] wrong code for bitfields at -O2 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58570 --- Comment #10 from Eric Botcazou --- > there is one more thing to consider for your proposed patch, > that is the damned -fstrict-volatile-bitfields: > > if strict_volatile_bitfields>0 and the BIT_FIELD access > is _volatile_ it does not respect the BIT_FIELD_REPRESENTATIVE at all. My patch as written doesn't use BIT_FIELD_REPRESENTATIVE so it isn't affected.
[Bug middle-end/58570] [4.9 Regression] wrong code for bitfields at -O2 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58570 --- Comment #11 from Bernd Edlinger --- (In reply to Eric Botcazou from comment #10) > > there is one more thing to consider for your proposed patch, > > that is the damned -fstrict-volatile-bitfields: > > > > if strict_volatile_bitfields>0 and the BIT_FIELD access > > is _volatile_ it does not respect the BIT_FIELD_REPRESENTATIVE at all. > > My patch as written doesn't use BIT_FIELD_REPRESENTATIVE so it isn't affected. No. You only assume an alias if _both_ fields are bit fields. But in my example only one "a" is a volatile bit field the other is a normal member "b".
[Bug rtl-optimization/58542] [4.7/4.8/4.9 Regression] subreg splitting pass mishandles TImode immediates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58542 Uroš Bizjak changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com --- Comment #6 from Uroš Bizjak --- Created attachment 30968 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30968&action=edit patch that converts arguments to __atomic builtins in signed mode Patch in testing.
[Bug rtl-optimization/58542] [4.7/4.8/4.9 Regression] Arguments of __atomic_* functions are converted in unsigned mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58542 Uroš Bizjak changed: What|Removed |Added Summary|[4.7/4.8/4.9 Regression]|[4.7/4.8/4.9 Regression] |subreg splitting pass |Arguments of __atomic_* |mishandles TImode |functions are converted in |immediates |unsigned mode --- Comment #7 from Uroš Bizjak --- Update summary (again).
[Bug rtl-optimization/58542] [4.7/4.8/4.9 Regression] Arguments of __atomic_* functions are converted in unsigned mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58542 Uroš Bizjak changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2013-10/msg00496.htm ||l --- Comment #8 from Uroš Bizjak --- Patch at [1]. [1] http://gcc.gnu.org/ml/gcc-patches/2013-10/msg00496.html
[Bug middle-end/58570] [4.9 Regression] wrong code for bitfields at -O2 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58570 --- Comment #12 from Eric Botcazou --- > No. You only assume an alias if _both_ fields are bit fields. > But in my example only one "a" is a volatile bit field the other > is a normal member "b". Then they won't be affected by the bug, see my explanation to Richard.
[Bug c++/58664] New: [c++11] ICE initializing array of incomplete type within union
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58664
Bug ID: 58664
Summary: [c++11] ICE initializing array of incomplete type
within union
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following invalid code snippet (compiled with "-std=c++11") triggers an ICE
since GCC 4.7.0 (when non-static data member initializers were introduced):
=
union U
{
U u[1] = { 0 };
};
=
bug.cc:1:7: internal compiler error: Segmentation fault
union U
^
0xaef9cf crash_signal
../../gcc/gcc/toplev.c:335
0x90292f contains_struct_check
../../gcc/gcc/tree.h:2722
0x90292f size_binop_loc(unsigned int, tree_code, tree_node*, tree_node*)
../../gcc/gcc/fold-const.c:1497
0xae7199 place_union_field
../../gcc/gcc/stor-layout.c:1038
0xae7199 place_field(record_layout_info_s*, tree_node*)
../../gcc/gcc/stor-layout.c:1101
0x5e8b3a layout_nonempty_base_or_field
../../gcc/gcc/cp/class.c:4020
0x5f8935 layout_class_type
../../gcc/gcc/cp/class.c:6082
0x60402c finish_struct_1(tree_node*)
../../gcc/gcc/cp/class.c:6419
0x6063b4 finish_struct(tree_node*, tree_node*)
../../gcc/gcc/cp/class.c:6713
0x635a1b cp_parser_class_specifier_1
../../gcc/gcc/cp/parser.c:18903
0x638370 cp_parser_class_specifier
../../gcc/gcc/cp/parser.c:19111
0x638370 cp_parser_type_specifier
../../gcc/gcc/cp/parser.c:14090
0x64d879 cp_parser_decl_specifier_seq
../../gcc/gcc/cp/parser.c:11337
0x651929 cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:10927
0x653950 cp_parser_block_declaration
../../gcc/gcc/cp/parser.c:10876
0x65c97e cp_parser_declaration
../../gcc/gcc/cp/parser.c:10773
0x65b6ea cp_parser_declaration_seq_opt
../../gcc/gcc/cp/parser.c:10659
0x65cfb6 cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:3939
0x65cfb6 c_parse_file()
../../gcc/gcc/cp/parser.c:28911
0x770ac3 c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1046
Please submit a full bug report, [etc.]
[Bug c++/58664] [c++11] ICE initializing array of incomplete type within union
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58664 Volker Reichelt changed: What|Removed |Added Keywords||ice-on-invalid-code Known to fail||4.7.0, 4.8.0, 4.9.0 --- Comment #1 from Volker Reichelt --- Related to PR58596.
[Bug c++/58665] New: [4.9 Regression] ICE with using incomplete struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58665
Bug ID: 58665
Summary: [4.9 Regression] ICE with using incomplete struct
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: reichelt at gcc dot gnu.org
The following invalid code snippet triggers an ICE on trunk:
struct A;
template struct B
{
static void foo(A) {}
};
void bar()
{
B<0>::foo(A());
}
bug.cc: In static member function 'static void B< >::foo(A)':
bug.cc:5:19: error: '' has incomplete type
static void foo(A) {}
^
bug.cc:1:8: error: forward declaration of 'struct A'
struct A;
^
bug.cc: In function 'void bar()':
bug.cc:10:15: error: invalid use of incomplete type 'struct A'
B<0>::foo(A());
^
bug.cc:1:8: error: forward declaration of 'struct A'
struct A;
^
bug.cc: In instantiation of 'static void B< >::foo(A) [with int
= 0]':
bug.cc:10:9: required from here
bug.cc:5:15: internal compiler error: tree check: expected tree that contains
'decl minimal' structure, have 'error_mark' in regenerate_decl_from_template,
at cp/pt.c:18839
static void foo(A) {}
^
0xcd9947 tree_contains_struct_check_failed(tree_node const*,
tree_node_structure_enum, char const*, int, char const*)
../../gcc/gcc/tree.c:9348
0x5a04ff contains_struct_check
../../gcc/gcc/tree.h:2723
0x5a04ff regenerate_decl_from_template
../../gcc/gcc/cp/pt.c:18839
0x5a04ff instantiate_decl(tree_node*, int, bool)
../../gcc/gcc/cp/pt.c:19303
0x5dc53f instantiate_pending_templates(int)
../../gcc/gcc/cp/pt.c:19495
0x617966 cp_write_global_declarations()
../../gcc/gcc/cp/decl2.c:4065
Please submit a full bug report, [etc.]
The ICE appeared between 4.9.0-20131004 and 4.9.0-20131005.
[Bug c++/58665] [4.9 Regression] ICE with using incomplete struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58665 Paolo Carlini changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-10-08 Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com Ever confirmed|0 |1 --- Comment #1 from Paolo Carlini --- I'm fixing this by reverting the fix for PR58448.
[Bug c++/58665] [4.9 Regression] ICE with using incomplete struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58665 --- Comment #2 from paolo at gcc dot gnu.org --- Author: paolo Date: Tue Oct 8 21:54:06 2013 New Revision: 203288 URL: http://gcc.gnu.org/viewcvs?rev=203288&root=gcc&view=rev Log: /cp 2013-10-08 Paolo Carlini PR c++/58665 Revert: 2013-10-04 Paolo Carlini PR c++/58448 * pt.c (tsubst): Use error_operand_p on parameter t. /testsuite 2013-10-08 Paolo Carlini PR c++/58665 Revert: 2013-10-04 Paolo Carlini PR c++/58448 * g++.dg/template/crash117.C: New. Removed: trunk/gcc/testsuite/g++.dg/template/crash117.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 --- Comment #4 from paolo at gcc dot gnu.org --- Author: paolo Date: Tue Oct 8 21:54:06 2013 New Revision: 203288 URL: http://gcc.gnu.org/viewcvs?rev=203288&root=gcc&view=rev Log: /cp 2013-10-08 Paolo Carlini PR c++/58665 Revert: 2013-10-04 Paolo Carlini PR c++/58448 * pt.c (tsubst): Use error_operand_p on parameter t. /testsuite 2013-10-08 Paolo Carlini PR c++/58665 Revert: 2013-10-04 Paolo Carlini PR c++/58448 * g++.dg/template/crash117.C: New. Removed: trunk/gcc/testsuite/g++.dg/template/crash117.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog
[Bug c++/58665] [4.9 Regression] ICE with using incomplete struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58665 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #3 from Paolo Carlini --- Done.
[Bug c++/58448] ICE on invalid: tree_class_check_failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58448 Paolo Carlini changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #5 from Paolo Carlini --- Patch reverted.
[Bug c++/58568] [4.8/4.9 Regression] [c++11] ICE with lambda in invalid template variable definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58568 --- Comment #4 from paolo at gcc dot gnu.org --- Author: paolo Date: Tue Oct 8 21:58:58 2013 New Revision: 203289 URL: http://gcc.gnu.org/viewcvs?rev=203289&root=gcc&view=rev Log: /cp 2013-10-08 Paolo Carlini PR c++/58568 * lambda.c (begin_lambda_type): Check return value of xref_tag for error_mark_node; tidy. * decl.c (grokdeclarator): Tweak error message. /testsuite 2013-10-08 Paolo Carlini PR c++/58568 * g++.dg/cpp0x/lambda/lambda-ice10.C: New. * g++.old-deja/g++.mike/misc9.C: Adjust. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice10.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c trunk/gcc/cp/lambda.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.old-deja/g++.mike/misc9.C
[Bug c++/58568] [4.8/4.9 Regression] [c++11] ICE with lambda in invalid template variable definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58568 --- Comment #5 from paolo at gcc dot gnu.org --- Author: paolo Date: Tue Oct 8 22:29:49 2013 New Revision: 203290 URL: http://gcc.gnu.org/viewcvs?rev=203290&root=gcc&view=rev Log: /cp 2013-10-08 Paolo Carlini PR c++/58568 * semantics.c (begin_lambda_type): Check return value of xref_tag for error_mark_node; tidy. * decl.c (grokdeclarator): Tweak error message. /testsuite 2013-10-08 Paolo Carlini PR c++/58568 * g++.dg/cpp0x/lambda/lambda-ice10.C: New. * g++.old-deja/g++.mike/misc9.C: Adjust. Added: branches/gcc-4_8-branch/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice10.C Modified: branches/gcc-4_8-branch/gcc/cp/ChangeLog branches/gcc-4_8-branch/gcc/cp/decl.c branches/gcc-4_8-branch/gcc/cp/semantics.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/g++.old-deja/g++.mike/misc9.C
[Bug c++/54367] [meta-bug] lambda expressions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54367 Bug 54367 depends on bug 58568, which changed state. Bug 58568 Summary: [4.8/4.9 Regression] [c++11] ICE with lambda in invalid template variable definition http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58568 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/58568] [4.8/4.9 Regression] [c++11] ICE with lambda in invalid template variable definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58568 Paolo Carlini changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Paolo Carlini --- Fixed for 4.8.2 and 4.9.0.
[Bug target/57310] [4.7/4.8/4.9 Regression] segfault with -O2 or higher on x86_64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57310 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |INVALID --- Comment #3 from Jakub Jelinek --- Invalid.
