[Bug libgomp/58642] gomp regression: not "honoring" anymore task set and numactl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58642 Jakub Jelinek changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-10-07 Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #9 from Jakub Jelinek --- Created attachment 30964 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30964&action=edit gomp-pr58642.patch Can you please try this patch? From the above it seems there is no easy way to find out what is the minimum size to make pthread_getaffinity_np pass, on the other side it should be fine to pass smaller size to pthread_setaffinity_np. So, what the patch tries to do is if the initial pthread_getaffinity_np failed with EINVAL, it will retry with larger sizes, and, once it succeeds, tries to find out the required minimum size that covers all the currently available CPUs. The minimum size for successful pthread_getaffinity_np will then be used for further pthread_getaffinity_np calls, while gomp_cpuset_size will be used for the places bitmasks and pthread_setaffinity_np calls.
[Bug fortran/58652] ICE with move_alloc and unlimited polymorphic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58652 Tobias Burnus changed: What|Removed |Added Keywords||ice-on-valid-code, ||rejects-valid Status|UNCONFIRMED |NEW Last reconfirmed||2013-10-07 CC||burnus at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||4.8.1, 4.9.0 --- Comment #2 from Tobias Burnus --- I see the same error with 4.9 - and both code snippets seem to be valid -> ICE on valid + rejects valid.
[Bug libgomp/58642] gomp regression: not "honoring" anymore task set and numactl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58642 --- Comment #10 from vincenzo Innocente --- seems working [innocent@olsnba04 parallel]$ c++ -std=c++11 -Ofast -fopenmp simpleOMP.cpp [innocent@olsnba04 parallel]$ ./a.out max thread 32 [innocent@olsnba04 parallel]$ taskset -c 0-3 ./a.out max thread 4 [innocent@olsnba04 parallel]$ taskset -c 0-3 strace ./a.out |& grep aff sched_getaffinity(72698, 8, 0x855010) = -1 EINVAL (Invalid argument) sched_getaffinity(72698, 128, { f, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }) = 128 [innocent@olsnba04 parallel]$ taskset -c 0-15 strace ./a.out | & grep aff sched_getaffinity(72702, 8, 0x1b2e010) = -1 EINVAL (Invalid argument) sched_getaffinity(72702, 128, { , 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }) = 128 [innocent@olsnba04 parallel]$ strace ./a.out | & grep aff sched_getaffinity(72705, 8, 0x25ff010) = -1 EINVAL (Invalid argument) sched_getaffinity(72705, 128, { , 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }) = 128
[Bug libgomp/58642] gomp regression: not "honoring" anymore task set and numactl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58642 --- Comment #11 from Jakub Jelinek --- (In reply to vincenzo Innocente from comment #10) > seems working Thanks. Can you please also try some simple (with -fopenmp): int main (void) { #pragma omp parallel num_threads (32) asm volatile ("" : : : "memory"); return 0; } with OMP_PROC_BIND=true and OMP_PLACES='threads' (resp. cores resp. sockets resp. say {0:4}:4:8) and post the strace -f sched_[sg]etaffinity syscalls from that? I'd like to see whether it managed to properly use just size 8 for the setaffinity syscalls, while 128 for getaffinity.
[Bug libgomp/58642] gomp regression: not "honoring" anymore task set and numactl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58642 --- Comment #12 from Jakub Jelinek --- Ah, and can you also do make check RUNTESTFLAGS=c.exp=affinity-1.c in the libgomp build directory and see whether it was PASS and, if testsuite/libgomp.log contains any lines ending with verified and none matching 'expected.*instead' regexp?
[Bug libgomp/58642] gomp regression: not "honoring" anymore task set and numactl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58642 --- Comment #13 from vincenzo Innocente --- [innocent@olsnba04 parallel]$ setenv OMP_PROC_BIND true; setenv OMP_PLACES 'threads' [innocent@olsnba04 parallel]$ gcc -fopenmp trivialOMP.cpp [innocent@olsnba04 parallel]$ ./a.out [innocent@olsnba04 parallel]$ stace ./a.out |& grep aff [innocent@olsnba04 parallel]$ strace ./a.out | & grep aff sched_getaffinity(72881, 8, 0xc5c010) = -1 EINVAL (Invalid argument) sched_getaffinity(72881, 128, { , 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }) = 128 sched_getaffinity(72881, 128, { , 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }) = 128 sched_setaffinity(72881, 8, { 1 }) = 0 sched_setaffinity(72882, 8, { 2 }) = 0 sched_setaffinity(72883, 8, { 4 }) = 0 sched_setaffinity(72884, 8, { 8 }) = 0 sched_setaffinity(72885, 8, { 10 })= 0 sched_setaffinity(72886, 8, { 20 })= 0 sched_setaffinity(72887, 8, { 40 })= 0 mmap(NULL, 8392704, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS|MAP_STACK, -1, 0) = 0x7f5e9aff5000 mprotect(0x7f5e9aff5000, 4096, PROT_NONE) = 0 sched_setaffinity(72888, 8, { 80 })= 0 clone(child_stack=0x7f5e9aff3f90, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID|CLONE_DETACHED, parent_tidptr=0x7f5e9aff49d0, tls=0x7f5e9aff4700, child_tidptr=0x7f5e9aff49d0) = 72889 sched_setaffinity(72889, 8, { 100 }) = 0 futex(0x7f5e9aff4d18, FUTEX_WAKE_PRIVATE, 1) = 1 sched_setaffinity(72890, 8, { 200 }) = 0 sched_setaffinity(72891, 8, { 400 }) = 0 sched_setaffinity(72892, 8, { 800 }) = 0 sched_setaffinity(72893, 8, { 1000 }) = 0 sched_setaffinity(72894, 8, { 2000 }) = 0 sched_setaffinity(72895, 8, { 4000 }) = 0 sched_setaffinity(72896, 8, { 8000 }) = 0 sched_setaffinity(72897, 8, { 1 }) = 0 sched_setaffinity(72898, 8, { 2 }) = 0 sched_setaffinity(72899, 8, { 4 }) = 0 sched_setaffinity(72900, 8, { 8 }) = 0 sched_setaffinity(72901, 8, { 10 }) = 0 sched_setaffinity(72902, 8, { 20 }) = 0 sched_setaffinity(72903, 8, { 40 }) = 0 sched_setaffinity(72904, 8, { 80 }) = 0 sched_setaffinity(72905, 8, { 100 }) = 0 sched_setaffinity(72906, 8, { 200 }) = 0 sched_setaffinity(72907, 8, { 400 }) = 0 sched_setaffinity(72908, 8, { 800 }) = 0 sched_setaffinity(72909, 8, { 1000 }) = 0 sched_setaffinity(72910, 8, { 2000 }) = 0 sched_setaffinity(72911, 8, { 4000 }) = 0 sched_setaffinity(72912, 8, { 8000 }) = 0 [innocent@olsnba04 parallel]$ strace -f ./a.out | & grep aff sched_getaffinity(72917, 8, 0x1bd8010) = -1 EINVAL (Invalid argument) sched_getaffinity(72917, 128, { , 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }) = 128 sched_getaffinity(72917, 128, { , 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }) = 128 sched_setaffinity(72917, 8, { 1 }) = 0 [pid 72917] sched_setaffinity(72918, 8, { 2 } [pid 72917] <... sched_setaffinity resumed> ) = 0 [pid 72917] sched_setaffinity(72919, 8, { 4 } [pid 72917] <... sched_setaffinity resumed> ) = 0 [pid 72917] sched_setaffinity(72920, 8, { 8 } [pid 72917] <... sched_setaffinity resumed> ) = 0 [pid 72917] sched_setaffinity(72921, 8, { 10 } [pid 72917] <... sched_setaffinity resumed> ) = 0 [pid 72917] sched_setaffinity(72922, 8, { 20 } [pid 72917] <... sched_setaffinity resumed> ) = 0 [pid 72917] sched_setaffinity(72923, 8, { 40 } [pid 72917] <... sched_setaffinity resumed> ) = 0 [pid 72917] sched_setaffinity(72924, 8, { 80 } [pid 72917] <... sched_setaffinity resumed> ) = 0 [pid 72917] sched_setaffinity(72925, 8, { 100 } [pid 72917] <... sched_setaffinity resumed> ) = 0 [pid 72917] sched_setaffinity(72926, 8, { 200 } [pid 72917] <... sched_setaffinity resumed> ) = 0 [pid 72917] sched_setaffinity(72927, 8, { 400 } [pid 72917] <... sched_setaffinity resumed> ) = 0 [pid 72917] sched_setaffinity(72928, 8, { 800 } [pid 72917] <... sched_setaffinity resumed> ) = 0 [pid 72917] sched_setaffinity(72929, 8, { 1000 } [pid 72917] <... sched_setaffinity resumed> ) = 0 [pid 72917] sched_setaffinity(72930, 8, { 2000 } [pid 72917] <... sched_setaffinity resumed> ) = 0 [pid 72917] sched_setaffinity(72931, 8, { 4000 } [pid 72917] <... sched_setaffinity resumed> ) = 0 [pid 72917] sched_setaffinity(72932, 8, { 8000 } [pid 72917] <... sched_setaffinity resumed> ) = 0 [pid 72917] sched_setaffinity(72933, 8, { 1 } [pid 72917] <... sched_setaffinity resumed> ) = 0 [pid 72917] sched_setaffinity(72934, 8, { 2 } [pid 72917] <... sched_setaffinity resumed> ) = 0 [pid 72917] sched_setaffinity(72935, 8, { 4 } [pid 72917] <... sched_setaffinity resumed> ) = 0 [pid 72917] sched_setaffinity(72936, 8, { 8 } [pid 72917] <... sched_setaffinity resumed> ) = 0 [pid 72917] sched_setaffinity(72937, 8, { 10 } [pid 72917] <... sched_setaffinity resumed> ) = 0 [pid 72917] sched_setaffinity(72938, 8, { 20 } [pid 72917] <... s
[Bug libgomp/58642] gomp regression: not "honoring" anymore task set and numactl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58642 --- Comment #14 from vincenzo Innocente --- On 7 Oct, 2013, at 10:06 AM, jakub at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58642 > > --- Comment #12 from Jakub Jelinek --- > Ah, and can you also do make check RUNTESTFLAGS=c.exp=affinity-1.c > in the libgomp build directory and see whether it was PASS and, if > testsuite/libgomp.log contains any lines ending with verified and none > matching > 'expected.*instead' regexp? > for "historical reason" I build gcc on my local workstation not on the XEON. Also I do not have the gcc test infrastructure… can I copy any of those test on the 32 cpu machine and run it locally? v. >
[Bug libgomp/58642] gomp regression: not "honoring" anymore task set and numactl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58642 --- Comment #15 from Jakub Jelinek --- (In reply to vincenzo Innocente from comment #14) > for "historical reason" I build gcc on my local workstation not on the XEON. > Also I do not have the gcc test infrastructure… > > can I copy any of those test on the 32 cpu machine and run it locally? Sure, do make check RUNTESTFLAGS=c.exp=affinity-1.c on your build box then, then cd testsuite/ grep affinity-1.exe libgomp.log and copy the gcc command line to compile/link it, paste into shell, scp affinity-1.exe to your 32way box, and run with OMP_PROC_BIND=false ./affinity-1.exp (against the new libgomp.so.1 of course).
[Bug c/58617] gcc crashed on compile arithmetic (or) expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58617 --- Comment #2 from Heiko.Abraham --- I can confirm, r202652 resolve this bug.
[Bug tree-optimization/58653] [4.7/4.8/4.9 Regression] wrong code (segfaults) at -O3 on x86_64-linux-gnu in 64-bit mode (affecting gcc 4.6 to trunk)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58653 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-10-07 CC||mpolacek at gcc dot gnu.org Summary|wrong code (segfaults) at |[4.7/4.8/4.9 Regression] |-O3 on x86_64-linux-gnu in |wrong code (segfaults) at |64-bit mode (affecting gcc |-O3 on x86_64-linux-gnu in |4.6 to trunk) |64-bit mode (affecting gcc ||4.6 to trunk) Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- Confirmed.
[Bug tree-optimization/58653] [4.7/4.8/4.9 Regression] wrong code (segfaults) at -O3 on x86_64-linux-gnu in 64-bit mode (affecting gcc 4.6 to trunk)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58653 --- Comment #2 from Marek Polacek --- It's the loop unswitching.
[Bug libgcc/55743] limits.h included unnecessarily in libgcc2.c - can break --without-headers bootstrap
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55743 Richard Earnshaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #2 from Richard Earnshaw --- Fixed with: http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00828.html
[Bug c/58626] possible array wrong code bug
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58626 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-10-07 CC||mpolacek at gcc dot gnu.org Target Milestone|--- |4.9.0 Ever confirmed|0 |1
[Bug middle-end/55653] Unnecessary initialization of vector register
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55653 Richard Earnshaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.8.0 --- Comment #2 from Richard Earnshaw --- Fixed with: 2013-01-08 Tejas Belagod * config/aarch64/aarch64-simd.md (vec_init): New. * config/aarch64/aarch64-protos.h (aarch64_expand_vector_init): Declare. * config/aarch64/aarch64.c (aarch64_simd_dup_constant, aarch64_simd_make_constant, aarch64_expand_vector_init): New.
[Bug middle-end/57503] [4.7/4.8 Regression] Expand uses wrong multiply routine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57503 Georg-Johann Lay changed: What|Removed |Added Status|WAITING |NEW --- Comment #8 from Georg-Johann Lay --- (In reply to Richard Biener from comment #7) > Can you please investigate the behavior on current trunk and the top of the > 4.8 branch? Using the code from comment #7 the problem persists $ avr-gcc -S -Os pr57503.c -mmcu=atmega8 -dP long func1 (unsigned char a, unsigned char b, int c) { unsigned ab = a * b; return (long) ab * c; } The code is a bit different but still wrong: func1: ; (insn 10 5 25 (set (reg:HI 18 r18 [orig:44 D.1450 ] [44]) ; (mult:HI (zero_extend:HI (reg:QI 24 r24 [ a ])) ; (zero_extend:HI (reg/v:QI 22 r22 [orig:50 b ] [50] pr57503.c:4 168 {umulqihi3} ; (expr_list:REG_DEAD (reg:QI 24 r24 [ a ]) ; (expr_list:REG_DEAD (reg/v:QI 22 r22 [orig:50 b ] [50]) ; (nil mul r24,r22 ; 10umulqihi3[length = 3] movw r18,r0 clr __zero_reg__ ; (insn 25 10 26 (set (reg:HI 26 r26) ; (reg/v:HI 20 r20 [orig:51 c ] [51])) pr57503.c:5 82 {*movhi} ; (expr_list:REG_DEAD (reg/v:HI 20 r20 [orig:51 c ] [51]) ; (nil))) movw r26,r20 ; 25*movhi/1[length = 1] ; (insn 26 25 21 (set (reg:SI 22 r22) ; (mult:SI (sign_extend:SI (reg:HI 18 r18)) ; (sign_extend:SI (reg:HI 26 r26 pr57503.c:5 231 {*mulhisi3_call} ; (expr_list:REG_DEAD (reg:HI 26 r26) ; (expr_list:REG_DEAD (reg:HI 18 r18) ; (nil rcall __mulhisi3 ; 26*mulhisi3_call[length = 1] ; (jump_insn 31 21 30 (return) pr57503.c:6 451 {return} ; (nil) ; -> return) ret ; 31return[length = 1] Insn 26 sign-extends both inputs but R18 (unsigned ab) should be zero-extended. Tested with SVN 203240 gcc version 4.9.0 20131007 (experimental) (GCC)
[Bug middle-end/55653] Unnecessary initialization of vector register
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55653 --- Comment #3 from Richard Earnshaw --- On the secondary issue of initializing FP vectors to zero, we now generate for typedef double f __attribute__((vector_size(16))); f g() { f a = {0.0, 0.0}; return a; } g: moviv0.2d, 0 ret
[Bug tree-optimization/58654] [4.9 Regression] ICE: abort compiling libstdc++-v3/src/c ++98/sstream-inst.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58654 Paolo Carlini changed: What|Removed |Added CC||xur at gcc dot gnu.org --- Comment #2 from Paolo Carlini --- Adding Rong in CC, then.
[Bug libgomp/58642] gomp regression: not "honoring" anymore task set and numactl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58642 --- Comment #16 from vincenzo Innocente --- ./affinity-1.exe Initial thread #1 thread 1 #1 thread 0 #1 thread 3 #1 thread 2 #1,#1 thread 3,1 #1,#1 thread 3,0 #1,#1 thread 3,2 #1,#2 thread 3,4 #1,#2 thread 3,0 #1,#2 thread 3,1 #1,#2 thread 3,3 #1,#2 thread 3,2 #1,#2,#1 thread 3,3,0 #1,#2,#1 thread 3,3,4 #1,#2,#1 thread 3,3,1 #1,#2,#1 thread 3,3,2 #1,#2,#1 thread 3,3,3 #1,#3 thread 3,2 #1,#3 thread 3,3 #1,#3 thread 3,1 #1,#3 thread 3,0 #1,#4 thread 3,2 #1,#4 thread 3,5 #1,#4 thread 3,4 #1,#4 thread 3,1 #1,#4 thread 3,3 #1,#4 thread 3,0 #2 thread 3 #2 thread 0 #2 thread 1 #2 thread 2 #2 thread 4 #2,#1 thread 3,0 #2,#1 thread 3,2 #2,#1 thread 3,1 #2,#2 thread 3,0 #2,#2 thread 3,1 #2,#2 thread 3,2 #2,#2 thread 3,3 #2,#2 thread 3,4 #2,#3 thread 3,0 #2,#3 thread 3,1 #2,#3 thread 3,3 #2,#3 thread 3,2 #2,#4 thread 3,2 #2,#4 thread 3,4 #2,#4 thread 3,3 #2,#4 thread 3,5 #2,#4 thread 3,1 #2,#4 thread 3,0 #3 thread 1 #3 thread 0 #3 thread 2 #3,#1 thread 2,1 #3,#1 thread 2,3 #3,#1 thread 2,0 #3,#1 thread 2,2 #3,#2 thread 2,1 #3,#2 thread 2,3 #3,#2 thread 2,0 #3,#2 thread 2,2 #3,#2,#1 thread 2,0,0 #3,#2,#1 thread 2,0,3 #3,#2,#1 thread 2,0,4 #3,#2,#1 thread 2,0,2 #3,#2,#1 thread 2,0,1 #3,#2,#2 thread 2,3,3 #3,#2,#2 thread 2,3,4 #3,#2,#2 thread 2,3,0 #3,#2,#2 thread 2,3,1 #3,#2,#2 thread 2,3,2 #3,#3 thread 2,0 #3,#3 thread 2,1 #3,#3 thread 2,2 #3,#3 thread 2,3 #3,#4 thread 2,2 #3,#4 thread 2,0 #3,#4 thread 2,5 #3,#4 thread 2,3 #3,#4 thread 2,4 #3,#4 thread 2,1 #4 thread 3 #4 thread 2 #4 thread 4 #4 thread 1 #4 thread 0 #4,#1 thread 2,0 #4,#1 thread 2,2 #4,#1 thread 2,3 #4,#1 thread 2,1 #4,#2 thread 2,2 #4,#2 thread 2,0 #4,#2 thread 2,1 #4,#2 thread 2,3 #4,#2,#1 thread 2,0,0 #4,#2,#1 thread 2,0,4 #4,#2,#1 thread 2,0,3 #4,#2,#1 thread 2,0,2 #4,#2,#1 thread 2,0,1 #4,#2,#2 thread 2,2,1 #4,#2,#2 thread 2,2,3 #4,#2,#2 thread 2,2,4 #4,#2,#2 thread 2,2,2 #4,#2,#2 thread 2,2,0 #4,#2,#3 thread 2,3,0 #4,#2,#3 thread 2,3,3 #4,#2,#3 thread 2,3,1 #4,#2,#3 thread 2,3,2 #4,#2,#3 thread 2,3,4 #4,#3 thread 2,2 #4,#3 thread 2,0 #4,#3 thread 2,3 #4,#3 thread 2,1 #4,#4 thread 2,1 #4,#4 thread 2,2 #4,#4 thread 2,0 #4,#4 thread 2,5 #4,#4 thread 2,4 #4,#4 thread 2,3 [innocent@olsnba04 parallel]$ setenv OMP_PROC_BIND false [innocent@olsnba04 parallel]$ ./affinity-1.exe OMP_PROC_BIND='false' Initial thread #1 thread 1 #1 thread 3 #1 thread 2 #1 thread 0 #1,#1 thread 3,0 #1,#1 thread 3,1 #1,#1 thread 3,2 #1,#2 thread 3,1 #1,#2 thread 3,3 #1,#2 thread 3,0 #1,#2 thread 3,4 #1,#2 thread 3,2 #1,#2,#1 thread 3,3,0 #1,#2,#1 thread 3,3,3 #1,#2,#1 thread 3,3,1 #1,#2,#1 thread 3,3,4 #1,#2,#1 thread 3,3,2 #1,#3 thread 3,1 #1,#3 thread 3,3 #1,#3 thread 3,0 #1,#3 thread 3,2 #1,#4 thread 3,0 #1,#4 thread 3,5 #1,#4 thread 3,4 #1,#4 thread 3,3 #1,#4 thread 3,2 #1,#4 thread 3,1 #2 thread 0 #2 thread 4 #2 thread 3 #2 thread 2 #2 thread 1 #2,#1 thread 3,0 #2,#1 thread 3,2 #2,#1 thread 3,1 #2,#2 thread 3,2 #2,#2 thread 3,3 #2,#2 thread 3,1 #2,#2 thread 3,0 #2,#2 thread 3,4 #2,#3 thread 3,3 #2,#3 thread 3,2 #2,#3 thread 3,1 #2,#3 thread 3,0 #2,#4 thread 3,4 #2,#4 thread 3,5 #2,#4 thread 3,3 #2,#4 thread 3,1 #2,#4 thread 3,0 #2,#4 thread 3,2 #3 thread 1 #3 thread 2 #3 thread 0 #3,#1 thread 2,1 #3,#1 thread 2,2 #3,#1 thread 2,3 #3,#1 thread 2,0 #3,#2 thread 2,0 #3,#2 thread 2,1 #3,#2 thread 2,2 #3,#2 thread 2,3 #3,#2,#1 thread 2,0,2 #3,#2,#1 thread 2,0,3 #3,#2,#1 thread 2,0,4 #3,#2,#1 thread 2,0,1 #3,#2,#1 thread 2,0,0 #3,#2,#2 thread 2,3,3 #3,#2,#2 thread 2,3,2 #3,#2,#2 thread 2,3,4 #3,#2,#2 thread 2,3,0 #3,#2,#2 thread 2,3,1 #3,#3 thread 2,2 #3,#3 thread 2,1 #3,#3 thread 2,3 #3,#3 thread 2,0 #3,#4 thread 2,3 #3,#4 thread 2,1 #3,#4 thread 2,4 #3,#4 thread 2,2 #3,#4 thread 2,0 #3,#4 thread 2,5 #4 thread 3 #4 thread 2 #4 thread 1 #4 thread 4 #4 thread 0 #4,#1 thread 2,0 #4,#1 thread 2,1 #4,#1 thread 2,2 #4,#1 thread 2,3 #4,#2 thread 2,0 #4,#2 thread 2,2 #4,#2 thread 2,1 #4,#2 thread 2,3 #4,#2,#1 thread 2,0,0 #4,#2,#1 thread 2,0,1 #4,#2,#1 thread 2,0,3 #4,#2,#1 thread 2,0,2 #4,#2,#1 thread 2,0,4 #4,#2,#2 thread 2,2,2 #4,#2,#2 thread 2,2,4 #4,#2,#2 thread 2,2,3 #4,#2,#2 thread 2,2,0 #4,#2,#2 thread 2,2,1 #4,#2,#3 thread 2,3,1 #4,#2,#3 thread 2,3,0 #4,#2,#3 thread 2,3,4 #4,#2,#3 thread 2,3,2 #4,#2,#3 thread 2,3,3 #4,#3 thread 2,1 #4,#3 thread 2,0 #4,#3 thread 2,3 #4,#3 thread 2,2 #4,#4 thread 2,0 #4,#4 thread 2,3 #4,#4 thread 2,4 #4,#4 thread 2,5 #4,#4 thread 2,2 #4,#4 thread 2,1 [innocent@olsnba04 parallel]$
[Bug middle-end/57503] [4.7/4.8 Regression] Expand uses wrong multiply routine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57503 Georg-Johann Lay changed: What|Removed |Added Known to fail||4.7.2, 4.8.1, 4.9.0 --- Comment #9 from Georg-Johann Lay --- (In reply to Richard Biener from comment #7) > Can you please investigate the behavior on current trunk and the top of the > 4.8 branch? Same applies to the 4.8 branch, again it is insn 26 that is wrong: func1: ; (insn 10 5 25 (set (reg:HI 18 r18 [orig:44 D.1447 ] [44]) ; (mult:HI (zero_extend:HI (reg:QI 24 r24 [ a ])) ; (zero_extend:HI (reg/v:QI 22 r22 [orig:50 b ] [50] pr57503.c:4 168 {umulqihi3} ; (expr_list:REG_DEAD (reg:QI 24 r24 [ a ]) ; (expr_list:REG_DEAD (reg/v:QI 22 r22 [orig:50 b ] [50]) ; (nil mul r24,r22 ; 10umulqihi3[length = 3] movw r18,r0 clr __zero_reg__ ; (insn 25 10 26 (set (reg:HI 26 r26) ; (reg/v:HI 20 r20 [orig:51 c ] [51])) pr57503.c:5 82 {*movhi} ; (expr_list:REG_DEAD (reg/v:HI 20 r20 [orig:51 c ] [51]) ; (nil))) movw r26,r20 ; 25*movhi/1[length = 1] ; (insn 26 25 21 (set (reg:SI 22 r22) ; (mult:SI (sign_extend:SI (reg:HI 18 r18)) ; (sign_extend:SI (reg:HI 26 r26 pr57503.c:5 231 {*mulhisi3_call} ; (expr_list:REG_DEAD (reg:HI 26 r26) ; (expr_list:REG_DEAD (reg:HI 18 r18) ; (nil rcall __mulhisi3 ; 26*mulhisi3_call[length = 1] ; (jump_insn 31 21 30 (return) pr57503.c:6 451 {return} ; (nil) ; -> return) ret ; 31return[length = 1] .sizefunc1, .-func1 .ident"GCC: (GNU) 4.8.2 20131007 (prerelease)"
[Bug libgomp/58642] gomp regression: not "honoring" anymore task set and numactl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58642 --- Comment #17 from Jakub Jelinek --- (In reply to vincenzo Innocente from comment #16) > [innocent@olsnba04 parallel]$ setenv OMP_PROC_BIND false > [innocent@olsnba04 parallel]$ ./affinity-1.exe > OMP_PROC_BIND='false' > Initial thread > #1 thread 1 > #1 thread 3 > #1 thread 2 > #1 thread 0 ... Thanks, though not what I was hoping to see. What glibc do you have on the build box where you compiled the testcase? If it is too old (doesn't have CPU_ALLOC_SIZE macro defined), or -DINTERPOSE_GETAFFINITY -DDO_FORK isn't defined, or config.h doesn't defined HAVE_PTHREAD_AFFINITY_NP, then that's expected. Or is the output running under taskset -c 0-3 ? The test verifies things only if the initial affinity bitmask contains at least logical CPUs from 0 to 7 inclusive. What I'm getting and expect is something like: OMP_PROC_BIND='true' OMP_PLACES='{0,1},{3,2,4},{6,5,!6},{6},{7:2:-1,!6}' Initial thread bound to {0:2}, verified #1 thread 2 bound to {5} #1 thread 0 bound to {0:2} #1 thread 3 bound to {6} #1 thread 1 bound to {2:3} ... #1,#4 thread 3,5 bound to {6} #2 thread 0 bound to {0:2}, verified #2 thread 2 bound to {5}, verified #2 thread 1 bound to {2:3}, verified ... #4,#4 thread 2,0 bound to {5}, verified #4,#4 thread 2,5 bound to {5}, verified OMP_PROC_BIND='true' OMP_PLACES='{1}:7:1' Initial thread bound to {1}, verified ... (", verified" shouldn't be on lines starting with #1 if the header says OMP_PROC_BIND='true').
[Bug libgomp/58642] gomp regression: not "honoring" anymore task set and numactl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58642 --- Comment #18 from vincenzo Innocente --- On 7 Oct, 2013, at 12:27 PM, jakub at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58642 > > --- Comment #17 from Jakub Jelinek --- > (In reply to vincenzo Innocente from comment #16) >> [innocent@olsnba04 parallel]$ setenv OMP_PROC_BIND false >> [innocent@olsnba04 parallel]$ ./affinity-1.exe >> OMP_PROC_BIND='false' >> Initial thread >> #1 thread 1 >> #1 thread 3 >> #1 thread 2 >> #1 thread 0 > ... > > Thanks, though not what I was hoping to see. What glibc do you have on the > build box where you compiled the testcase? on the build machine [innocent@vinavx0 testsuite]$ /home/data/newsoft/gcc-build/gcc/xgcc -B/home/data/newsoft/gcc-build/gcc/ /home/data/newsoft/gcc-gomp4/libgomp/testsuite/libgomp.c/affinity-1.c -B/home/data/newsoft/gcc-build/x86_64-unknown-linux-gnu/./libgomp/ -B/home/data/newsoft/gcc-build/x86_64-unknown-linux-gnu/./libgomp/.libs -I/home/data/newsoft/gcc-build/x86_64-unknown-linux-gnu/./libgomp -I/home/data/newsoft/gcc-gomp4/libgomp/testsuite/.. -fmessage-length=0 -fno-diagnostics-show-caret -fopenmp -O2 -DINTERPOSE_GETAFFINITY -DDO_FORK -ldl -L/home/data/newsoft/gcc-build/x86_64-unknown-linux-gnu/./libgomp/.libs -lm -o ./affinity-1.exe [innocent@vinavx0 testsuite]$ ls Makefile affinity-1.exe libgomp.log libgomp.sum site.exp [innocent@vinavx0 testsuite]$ ./affinity-1.exe Initial thread bound to {0:8} #1 thread 1 bound to {0:8} #1 thread 3 bound to {0:8} #1 thread 0 bound to {0:8} #1 thread 2 bound to {0:8} #1,#1 thread 3,1 bound to {0:8} #1,#1 thread 3,0 bound to {0:8} #1,#1 thread 3,2 bound to {0:8} #1,#2 thread 3,3 bound to {0:8} #1,#2 thread 3,1 bound to {0:8} #1,#2 thread 3,0 bound to {0:8} #1,#2 thread 3,2 bound to {0:8} #1,#2 thread 3,4 bound to {0:8} #1,#2,#1 thread 3,3,0 bound to {0:8} #1,#2,#1 thread 3,3,4 bound to {0:8} #1,#2,#1 thread 3,3,2 bound to {0:8} #1,#2,#1 thread 3,3,3 bound to {0:8} #1,#2,#1 thread 3,3,1 bound to {0:8} #1,#3 thread 3,0 bound to {0:8} #1,#3 thread 3,1 bound to {0:8} #1,#3 thread 3,3 bound to {0:8} #1,#3 thread 3,2 bound to {0:8} #1,#4 thread 3,1 bound to {0:8} #1,#4 thread 3,5 bound to {0:8} #1,#4 thread 3,2 bound to {0:8} #1,#4 thread 3,3 bound to {0:8} #1,#4 thread 3,0 bound to {0:8} #1,#4 thread 3,4 bound to {0:8} #2 thread 0 bound to {0:8} #2 thread 2 bound to {0:8} #2 thread 4 bound to {0:8} #2 thread 1 bound to {0:8} #2 thread 3 bound to {0:8} #2,#1 thread 3,0 bound to {0:8} #2,#1 thread 3,2 bound to {0:8} #2,#1 thread 3,1 bound to {0:8} #2,#2 thread 3,2 bound to {0:8} #2,#2 thread 3,1 bound to {0:8} #2,#2 thread 3,4 bound to {0:8} #2,#2 thread 3,3 bound to {0:8} #2,#2 thread 3,0 bound to {0:8} #2,#3 thread 3,2 bound to {0:8} #2,#3 thread 3,0 bound to {0:8} #2,#3 thread 3,1 bound to {0:8} #2,#3 thread 3,3 bound to {0:8} #2,#4 thread 3,2 bound to {0:8} #2,#4 thread 3,0 bound to {0:8} #2,#4 thread 3,1 bound to {0:8} #2,#4 thread 3,4 bound to {0:8} #2,#4 thread 3,5 bound to {0:8} #2,#4 thread 3,3 bound to {0:8} #3 thread 1 bound to {0:8} #3 thread 2 bound to {0:8} #3 thread 0 bound to {0:8} #3,#1 thread 2,2 bound to {0:8} #3,#1 thread 2,0 bound to {0:8} #3,#1 thread 2,3 bound to {0:8} #3,#1 thread 2,1 bound to {0:8} #3,#2 thread 2,1 bound to {0:8} #3,#2 thread 2,3 bound to {0:8} #3,#2 thread 2,2 bound to {0:8} #3,#2 thread 2,0 bound to {0:8} #3,#2,#1 thread 2,0,1 bound to {0:8} #3,#2,#1 thread 2,0,0 bound to {0:8} #3,#2,#1 thread 2,0,2 bound to {0:8} #3,#2,#1 thread 2,0,3 bound to {0:8} #3,#2,#1 thread 2,0,4 bound to {0:8} #3,#2,#2 thread 2,3,1 bound to {0:8} #3,#2,#2 thread 2,3,0 bound to {0:8} #3,#2,#2 thread 2,3,2 bound to {0:8} #3,#2,#2 thread 2,3,3 bound to {0:8} #3,#2,#2 thread 2,3,4 bound to {0:8} #3,#3 thread 2,1 bound to {0:8} #3,#3 thread 2,0 bound to {0:8} #3,#3 thread 2,3 bound to {0:8} #3,#3 thread 2,2 bound to {0:8} #3,#4 thread 2,0 bound to {0:8} #3,#4 thread 2,3 bound to {0:8} #3,#4 thread 2,4 bound to {0:8} #3,#4 thread 2,2 bound to {0:8} #3,#4 thread 2,5 bound to {0:8} #3,#4 thread 2,1 bound to {0:8} #4 thread 3 bound to {0:8} #4 thread 1 bound to {0:8} #4 thread 4 bound to {0:8} #4 thread 2 bound to {0:8} #4 thread 0 bound to {0:8} #4,#1 thread 2,2 bound to {0:8} #4,#1 thread 2,0 bound to {0:8} #4,#1 thread 2,3 bound to {0:8} #4,#1 thread 2,1 bound to {0:8} #4,#2 thread 2,2 bound to {0:8} #4,#2 thread 2,3 bound to {0:8} #4,#2 thread 2,0 bound to {0:8} #4,#2 thread 2,1 bound to {0:8} #4,#2,#1 thread 2,0,0 bound to {0:8} #4,#2,#1 thread 2,0,3 bound to {0:8} #4,#2,#1 thread 2,0,2 bound to {0:8} #4,#2,#1 thread 2,0,1 bound to {0:8} #4,#2,#1 thread 2,0,4 bound to {0:8} #4,#2,#2 thread 2,2,1 bound to {0:8} #4,#2,#2 thread 2,2,2 bound to {0:8} #4,#2,#2 thread 2,2,0 bound to {0:8} #4,#2,#2 thread 2,2,3 bound to {0:8} #4,#2,#2 thread 2,2,4 bound to {0:8} #4,#2,#3 thread 2,3,1 bound to {0:8} #4,#2,#3 thread 2,3,4 bound to {0:8} #4,#2,#3 thread 2,3,0 bound to {0:8} #4,#2,#3 thread 2,3,2 bound to {0:8} #
[Bug libgomp/58642] gomp regression: not "honoring" anymore task set and numactl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58642 --- Comment #19 from vincenzo Innocente --- On 7 Oct, 2013, at 12:27 PM, jakub at gcc dot gnu.org wrote: > or config.h doesn't defined HAVE_PTHREAD_AFFINITY_NP, then that's > expected. innocent@vinavx0 testsuite]$ cat ../config.h /* config.h. Generated from config.h.in by configure. */ /* config.h.in. Generated from configure.ac by autoheader. */ /* Define to 1 if the target assembler supports .symver directive. */ #define HAVE_AS_SYMVER_DIRECTIVE 1 /* Define to 1 if the target supports __attribute__((alias(...))). */ #define HAVE_ATTRIBUTE_ALIAS 1 /* Define to 1 if the target supports __attribute__((dllexport)). */ /* #undef HAVE_ATTRIBUTE_DLLEXPORT */ /* Define to 1 if the target supports __attribute__((visibility(...))). */ #define HAVE_ATTRIBUTE_VISIBILITY 1 /* Define if the POSIX Semaphores do not work on your system. */ /* #undef HAVE_BROKEN_POSIX_SEMAPHORES */ /* Define to 1 if the target assembler supports thread-local storage. */ /* #undef HAVE_CC_TLS */ /* Define to 1 if you have the `clock_gettime' function. */ #define HAVE_CLOCK_GETTIME 1 /* Define to 1 if you have the header file. */ #define HAVE_DLFCN_H 1 /* Define to 1 if you have the `getloadavg' function. */ #define HAVE_GETLOADAVG 1 /* Define to 1 if you have the header file. */ #define HAVE_INTTYPES_H 1 /* Define to 1 if you have the `dl' library (-ldl). */ #define HAVE_LIBDL 1 /* Define to 1 if you have the header file. */ #define HAVE_MEMORY_H 1 /* Define if pthread_{,attr_}{g,s}etaffinity_np is supported. */ #define HAVE_PTHREAD_AFFINITY_NP 1 /* Define to 1 if you have the header file. */ #define HAVE_SEMAPHORE_H 1 /* Define to 1 if you have the header file. */ #define HAVE_STDINT_H 1 /* Define to 1 if you have the header file. */ #define HAVE_STDLIB_H 1 /* Define to 1 if you have the header file. */ #define HAVE_STRINGS_H 1 /* Define to 1 if you have the header file. */ #define HAVE_STRING_H 1 /* Define to 1 if you have the `strtoull' function. */ #define HAVE_STRTOULL 1 /* Define to 1 if the target runtime linker supports binding the same symbol to different versions. */ #define HAVE_SYMVER_SYMBOL_RENAMING_RUNTIME_SUPPORT 1 /* Define to 1 if the target supports __sync_*_compare_and_swap */ #define HAVE_SYNC_BUILTINS 1 /* Define to 1 if you have the header file. */ /* #undef HAVE_SYS_LOADAVG_H */ /* Define to 1 if you have the header file. */ #define HAVE_SYS_STAT_H 1 /* Define to 1 if you have the header file. */ #define HAVE_SYS_TIME_H 1 /* Define to 1 if you have the header file. */ #define HAVE_SYS_TYPES_H 1 /* Define to 1 if the target supports thread-local storage. */ #define HAVE_TLS 1 /* Define to 1 if you have the header file. */ #define HAVE_UNISTD_H 1 /* Define to 1 if GNU symbol versioning is used for libgomp. */ #define LIBGOMP_GNU_SYMBOL_VERSIONING 1 /* Define to the sub-directory in which libtool stores uninstalled libraries. */ #define LT_OBJDIR ".libs/" /* Name of package */ #define PACKAGE "libgomp" /* Define to the address where bug reports for this package should be sent. */ #define PACKAGE_BUGREPORT "" /* Define to the full name of this package. */ #define PACKAGE_NAME "GNU OpenMP Runtime Library" /* Define to the full name and version of this package. */ #define PACKAGE_STRING "GNU OpenMP Runtime Library 1.0" /* Define to the one symbol short name of this package. */ #define PACKAGE_TARNAME "libgomp" /* Define to the home page for this package. */ #define PACKAGE_URL "http://www.gnu.org/software/libgomp/"; /* Define to the version of this package. */ #define PACKAGE_VERSION "1.0" /* Define if all infrastructure, needed for plugins, is supported. */ #define PLUGIN_SUPPORT 1 /* The size of `char', as computed by sizeof. */ /* #undef SIZEOF_CHAR */ /* The size of `int', as computed by sizeof. */ /* #undef SIZEOF_INT */ /* The size of `long', as computed by sizeof. */ /* #undef SIZEOF_LONG */ /* The size of `short', as computed by sizeof. */ /* #undef SIZEOF_SHORT */ /* The size of `void *', as computed by sizeof. */ /* #undef SIZEOF_VOID_P */ /* Define to 1 if you have the ANSI C header files. */ #define STDC_HEADERS 1 /* Define if you can safely include both and . */ #define STRING_WITH_STRINGS 1 /* Define to 1 if you can safely include both and . */ #define TIME_WITH_SYS_TIME 1 /* Version number of package */ #define VERSION "1.0" -- Il est bon de suivre sa pente, pourvu que ce soit en montant. A.G. http://www.flickr.com/photos/vin60/1320965757/
[Bug target/58655] New: [avr] -mfract-convert-truncate not documented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58655 Bug ID: 58655 Summary: [avr] -mfract-convert-truncate not documented Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: documentation Severity: minor Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: gjl at gcc dot gnu.org Target: avr avr specific command option -mfract-convert-truncate should be documented in the users guide (gcc/doc/invoke.texi) and in the release notes (http://gcc.gnu.org/gcc-4.9/changes.html).
[Bug target/58655] [avr] -mfract-convert-truncate not documented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58655 Georg-Johann Lay changed: What|Removed |Added Priority|P3 |P5 Status|UNCONFIRMED |NEW Last reconfirmed||2013-10-07 CC||amylaar at gcc dot gnu.org Ever confirmed|0 |1
[Bug tree-optimization/58656] New: rnflow regressing after r202826
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58656 Bug ID: 58656 Summary: rnflow regressing after r202826 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: Ganesh.Gopalasubramanian at amd dot com Seems the fix for 58464 is regressing rnflow of pb11. Runtime log of rnflow Before revision 202826 0:35.558 -> Completed program execution After revision 202826 (after fix) 0:53.023 -> Completed program execution The suse polyhedron benchmark log also shows this (after sep23). http://gcc.opensuse.org/c++bench/polyhedron/polyhedron-summary.txt
[Bug libgomp/58642] gomp regression: not "honoring" anymore task set and numactl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58642 --- Comment #20 from Jakub Jelinek --- I'll commit the patch anyway, it is a step forward. Anyway, the way the testcase is written is that if you run it with OMP_PROC_BIND=false in the environment and OMP_PLACES unset, then it should fork and exec /proc/self/exe with various settings of those two environment variables. Can you perhaps see in the debugger what value has contig_cpucount variable at the start of main, and why it decided not to fork (or, has it failed to exec /proc/self/exe)?
[Bug libgomp/58642] gomp regression: not "honoring" anymore task set and numactl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58642 --- Comment #21 from Jakub Jelinek --- Author: jakub Date: Mon Oct 7 11:39:39 2013 New Revision: 203243 URL: http://gcc.gnu.org/viewcvs?rev=203243&root=gcc&view=rev Log: PR libgomp/58642 * config/linux/proc.c: Include errno.h. (gomp_get_cpuset_size): New variable. (gomp_cpuset_popcount): Add cpusetsize argument, use it instead of gomp_cpuset_size. (gomp_init_num_threads): If CPU_ALLOC_SIZE is defined and pthread_getaffinity_np returned EINVAL, increase gomp_cpuset_size and retry. After successful pthread_getaffinity_np copy gomp_cpuset_size to gomp_get_cpuset_size and try to find out minimum gomp_cpuset_size that covers all the CPUs set in gomp_cpusetp. (get_num_procs): Pass gomp_get_cpuset_size rather than gomp_cpuset_size to pthread_getaffinity_np, adjust gomp_cpuset_popcount caller. * config/linux/proc.h (gomp_cpuset_popcount): Add cpusetsize argument. * config/linux/affinity.c (gomp_affinity_finalize_place_list, gomp_affinity_init_level): Adjust gomp_cpuset_popcount callers. * testsuite/libgomp.c/affinity-1.c (pthread_getaffinity_np): Set contig_cpucount from the first successful pthread_getaffinity_np call, rather than just first call. Modified: branches/gomp-4_0-branch/libgomp/ChangeLog.gomp branches/gomp-4_0-branch/libgomp/config/linux/affinity.c branches/gomp-4_0-branch/libgomp/config/linux/proc.c branches/gomp-4_0-branch/libgomp/config/linux/proc.h branches/gomp-4_0-branch/libgomp/testsuite/libgomp.c/affinity-1.c
[Bug c++/58646] ICEs initializing VLAs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58646 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-10-07 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Marek Polacek --- All of them are probably related to r198745 (N3639 C++1y VLA support).
[Bug libgomp/58642] gomp regression: not "honoring" anymore task set and numactl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58642 --- Comment #22 from vincenzo Innocente --- on the XEON setenv OMP_PROC_BIND false reakpoint 1, main () at /home/data/newsoft/gcc-gomp4/libgomp/testsuite/libgomp.c/affinity-1.c:181 181/home/data/newsoft/gcc-gomp4/libgomp/testsuite/libgomp.c/affinity-1.c: No such file or directory. in /home/data/newsoft/gcc-gomp4/libgomp/testsuite/libgomp.c/affinity-1.c Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.107.el6_4.4.x86_64 (gdb) print contig_cpucount $1 = 32 it fork only if it is 8… (ok on the build machine indeed) 180#ifdef DO_FORK 181 if (env_places == NULL && contig_cpucount == 8 && test_false 182 && getenv ("GOMP_AFFINITY") == NULL) so (see below full output ) taskset -c 0-7 gdb ./affinity-1.exe GNU gdb (GDB) Red Hat Enterprise Linux (7.2-60.el6_4.1) (gdb) b /home/data/newsoft/gcc-gomp4/libgomp/testsuite/libgomp.c/affinity-1.c:179 Breakpoint 1 at 0x400d5f: file /home/data/newsoft/gcc-gomp4/libgomp/testsuite/libgomp.c/affinity-1.c, line 179. (gdb) run Starting program: /afs/cern.ch/user/i/innocent/public/ctest/parallel/affinity-1.exe warning: no loadable sections found in added symbol-file system-supplied DSO at 0x77ffd000 [Thread debugging using libthread_db enabled] Breakpoint 1, main () at /home/data/newsoft/gcc-gomp4/libgomp/testsuite/libgomp.c/affinity-1.c:181 181/home/data/newsoft/gcc-gomp4/libgomp/testsuite/libgomp.c/affinity-1.c: No such file or directory. in /home/data/newsoft/gcc-gomp4/libgomp/testsuite/libgomp.c/affinity-1.c Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.107.el6_4.4.x86_64 (gdb) print contig_cpucount $1 = 8 BUT taskset -c 24-31 gdb ./affinity-1.exe Breakpoint 1, main () at /home/data/newsoft/gcc-gomp4/libgomp/testsuite/libgomp.c/affinity-1.c:181 181/home/data/newsoft/gcc-gomp4/libgomp/testsuite/libgomp.c/affinity-1.c: No such file or directory. in /home/data/newsoft/gcc-gomp4/libgomp/testsuite/libgomp.c/affinity-1.c Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.107.el6_4.4.x86_64 (gdb) print contig_cpucount $1 = 0 taskset -c 0-7 ./affinity-1.exe libgomp: Number of places reduced from 5 to 1 because some places didn't contain any usable logical CPUs OMP_PROC_BIND='true' OMP_PLACES='{0,1},{3,2,4},{6,5,!6},{6},{7:2:-1,!6}' Initial thread #1 thread 0 #1 thread 3 #1 thread 2 #1 thread 1 #1,#1 thread 3,0 #1,#1 thread 3,2 #1,#1 thread 3,1 #1,#2 thread 3,0 #1,#2 thread 3,4 #1,#2 thread 3,3 #1,#2 thread 3,2 #1,#2 thread 3,1 #1,#2,#1 thread 3,3,0 #1,#2,#1 thread 3,3,4 #1,#2,#1 thread 3,3,3 #1,#2,#1 thread 3,3,2 #1,#2,#1 thread 3,3,1 #1,#3 thread 3,0 #1,#3 thread 3,3 #1,#3 thread 3,2 #1,#3 thread 3,1 #1,#4 thread 3,0 #1,#4 thread 3,5 #1,#4 thread 3,4 #1,#4 thread 3,3 #1,#4 thread 3,2 #1,#4 thread 3,1 #2 thread 3 #2 thread 0 #2 thread 2 #2 thread 1 #2 thread 4 #2,#1 thread 3,0 #2,#1 thread 3,2 #2,#1 thread 3,1 #2,#2 thread 3,0 #2,#2 thread 3,4 #2,#2 thread 3,3 #2,#2 thread 3,2 #2,#2 thread 3,1 #2,#3 thread 3,0 #2,#3 thread 3,3 #2,#3 thread 3,2 #2,#3 thread 3,1 #2,#4 thread 3,0 #2,#4 thread 3,5 #2,#4 thread 3,4 #2,#4 thread 3,3 #2,#4 thread 3,2 #2,#4 thread 3,1 #3 thread 1 #3 thread 2 #3 thread 0 #3,#1 thread 2,0 #3,#1 thread 2,3 #3,#1 thread 2,2 #3,#1 thread 2,1 #3,#2 thread 2,0 #3,#2 thread 2,3 #3,#2 thread 2,2 #3,#2 thread 2,1 #3,#2,#1 thread 2,0,0 #3,#2,#1 thread 2,0,4 #3,#2,#1 thread 2,0,3 #3,#2,#1 thread 2,0,2 #3,#2,#1 thread 2,0,1 #3,#2,#2 thread 2,3,0 #3,#2,#2 thread 2,3,4 #3,#2,#2 thread 2,3,3 #3,#2,#2 thread 2,3,2 #3,#2,#2 thread 2,3,1 #3,#3 thread 2,0 #3,#3 thread 2,3 #3,#3 thread 2,2 #3,#3 thread 2,1 #3,#4 thread 2,0 #3,#4 thread 2,5 #3,#4 thread 2,4 #3,#4 thread 2,3 #3,#4 thread 2,2 #3,#4 thread 2,1 #4 thread 2 #4 thread 0 #4 thread 1 #4 thread 4 #4 thread 3 #4,#1 thread 2,0 #4,#1 thread 2,3 #4,#1 thread 2,2 #4,#1 thread 2,1 #4,#2 thread 2,0 #4,#2 thread 2,3 #4,#2 thread 2,2 #4,#2 thread 2,1 #4,#2,#1 thread 2,0,0 #4,#2,#1 thread 2,0,4 #4,#2,#1 thread 2,0,3 #4,#2,#1 thread 2,0,2 #4,#2,#1 thread 2,0,1 #4,#2,#2 thread 2,2,0 #4,#2,#2 thread 2,2,4 #4,#2,#2 thread 2,2,3 #4,#2,#2 thread 2,2,2 #4,#2,#2 thread 2,2,1 #4,#2,#3 thread 2,3,0 #4,#2,#3 thread 2,3,4 #4,#2,#3 thread 2,3,3 #4,#2,#3 thread 2,3,2 #4,#2,#3 thread 2,3,1 #4,#3 thread 2,0 #4,#3 thread 2,3 #4,#3 thread 2,2 #4,#3 thread 2,1 #4,#4 thread 2,0 #4,#4 thread 2,5 #4,#4 thread 2,4 #4,#4 thread 2,3 #4,#4 thread 2,2 #4,#4 thread 2,1 libgomp: None of the places contain usable logical CPUs libgomp: Invalid value for environment variable OMP_PLACES OMP_PROC_BIND='true' OMP_PLACES='{1}:7:1' Initial thread #1 thread 1 #1 thread 2 #1 thread 0 #1 thread 3 #1,#1 thread 3,2 #1,#1 thread 3,0 #1,#1 thread 3,1 #1,#2 thread 3,4 #1,#2 thread 3,2 #1,#2 thread 3,3 #1,#2 thread 3,1 #1,#2 thread 3,0 #1,#2,#1 thread 3,3,4 #1,#2,#1 thread 3,3,0 #1,#2,#1 thread 3,3,2 #1,#2,#1 thread 3,3,3 #1,#2,#1 thread 3,3,1 #1,#3 thread 3,0 #1,#3 thread 3,3 #1,#3 thread 3,2 #1,#3 thread 3,1
[Bug libgomp/58642] gomp regression: not "honoring" anymore task set and numactl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58642 --- Comment #23 from Jakub Jelinek --- Ah, right, obviously I meant --- libgomp/testsuite/libgomp.c/affinity-1.c2013-10-07 09:31:53.884695701 +0200 +++ libgomp/testsuite/libgomp.c/affinity-1.c2013-10-07 14:09:52.475331358 +0200 @@ -178,7 +178,7 @@ main () int test_places = 0; #ifdef DO_FORK - if (env_places == NULL && contig_cpucount == 8 && test_false + if (env_places == NULL && contig_cpucount >= 8 && test_false && getenv ("GOMP_AFFINITY") == NULL) { int i, j, status; (the other spot already correctly uses >= 8 - all the testcase cares about is that the first 8 logical CPUs can be used for affinity). That answers the not seeing fork case, but if it doesn't print any verified lines even with that, there would be some other issue.
[Bug libstdc++/57226] The installation of pretty printers is not documented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57226 Jonathan Wakely changed: What|Removed |Added Status|RESOLVED|ASSIGNED Last reconfirmed||2013-10-07 Resolution|INVALID |--- Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1
[Bug c++/58635] [c++11] ICE with __transaction_atomic and noexcept(false)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58635 Marek Polacek changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-10-07 CC||mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Marek Polacek --- For the first two it needs the same fix as for PR58516: --- a/gcc/cp/semantics.c +++ b/gcc/cp/semantics.c @@ -5221,7 +5221,8 @@ build_transaction_expr (location_t loc, tree expr, int flags, tree if (noex) { expr = build_must_not_throw_expr (expr, noex); - SET_EXPR_LOCATION (expr, loc); + if (EXPR_P (expr)) + SET_EXPR_LOCATION (expr, loc); TREE_SIDE_EFFECTS (expr) = 1; } ret = build1 (TRANSACTION_EXPR, TREE_TYPE (expr), expr);
[Bug libgomp/58642] gomp regression: not "honoring" anymore task set and numactl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58642 --- Comment #24 from vincenzo Innocente --- ok, modified to ">=" taskset -c 0-31 gdb ./affinity-1.exe GNU gdb (GDB) Red Hat Enterprise Linux (7.2-60.el6_4.1) (gdb) b /home/data/newsoft/gcc-gomp4/libgomp/testsuite/libgomp.c/affinity-1.c:179 Breakpoint 1 at 0x400d5f: file /home/data/newsoft/gcc-gomp4/libgomp/testsuite/libgomp.c/affinity-1.c, line 179. (gdb) run Breakpoint 1, main () at /home/data/newsoft/gcc-gomp4/libgomp/testsuite/libgomp.c/affinity-1.c:181 181/home/data/newsoft/gcc-gomp4/libgomp/testsuite/libgomp.c/affinity-1.c: No such file or directory. in /home/data/newsoft/gcc-gomp4/libgomp/testsuite/libgomp.c/affinity-1.c Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.107.el6_4.4.x86_64 (gdb) print contig_cpucount $1 = 32 and then spawn etc but taskset -c 24-31 gdb ./affinity-1.exe Breakpoint 1, main () at /home/data/newsoft/gcc-gomp4/libgomp/testsuite/libgomp.c/affinity-1.c:181 181/home/data/newsoft/gcc-gomp4/libgomp/testsuite/libgomp.c/affinity-1.c: No such file or directory. in /home/data/newsoft/gcc-gomp4/libgomp/testsuite/libgomp.c/affinity-1.c Missing separate debuginfos, use: debuginfo-install glibc-2.12-1.107.el6_4.4.x86_64 (gdb) print contig_cpucount $1 = 0 I see anyhow where contig_cpucount is set. up to you to generalize the test… v. On 7 Oct, 2013, at 2:16 PM, jakub at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58642 > > --- Comment #23 from Jakub Jelinek --- > Ah, right, obviously I meant > --- libgomp/testsuite/libgomp.c/affinity-1.c2013-10-07 09:31:53.884695701 > +0200 > +++ libgomp/testsuite/libgomp.c/affinity-1.c2013-10-07 14:09:52.475331358 > +0200 > @@ -178,7 +178,7 @@ main () > int test_places = 0; > > #ifdef DO_FORK > - if (env_places == NULL && contig_cpucount == 8 && test_false > + if (env_places == NULL && contig_cpucount >= 8 && test_false > && getenv ("GOMP_AFFINITY") == NULL) > { > int i, j, status; > (the other spot already correctly uses >= 8 - all the testcase cares about is > that the first 8 logical CPUs can be used for affinity). > That answers the not seeing fork case, but if it doesn't print any verified > lines even with that, there would be some other issue. > > -- > You are receiving this mail because: > You reported the bug. -- Il est bon de suivre sa pente, pourvu que ce soit en montant. A.G. http://www.flickr.com/photos/vin60/1320965757/
[Bug libgomp/58642] gomp regression: not "honoring" anymore task set and numactl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58642 --- Comment #25 from Jakub Jelinek --- It is fine if the testcase doesn't fork and doesn't verify for taskset -c 24-31, that would be too hard to support, the testcase doesn't fail because of that. But, do you get the ", verified" strings in the lines for taskset -c 0-31 run?
[Bug libgomp/58642] gomp regression: not "honoring" anymore task set and numactl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58642 --- Comment #26 from vincenzo Innocente --- On 7 Oct, 2013, at 3:02 PM, jakub at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58642 > > --- Comment #25 from Jakub Jelinek --- > It is fine if the testcase doesn't fork and doesn't verify for taskset -c > 24-31, that would be too hard to support, the testcase doesn't fail because of > that. > But, do you get the ", verified" strings in the lines for taskset -c 0-31 run? > on the build machine yes echo $OMP_PROC_BIND false [innocent@vinavx0 testsuite]$ ./affinity-1.exe | grep veri | wc 10657445 44193 on the XEON nope echo $OMP_PROC_BIND false [innocent@olsnba04 parallel]$ ./affinity-1.exe | grep veri libgomp: Number of places reduced from 5 to 1 because some places didn't contain any usable logical CPUs libgomp: None of the places contain usable logical CPUs libgomp: Invalid value for environment variable OMP_PLACES libgomp: Number of places reduced from 3 to 1 because some places didn't contain any usable logical CPUs libgomp: None of the places contain usable logical CPUs libgomp: Invalid value for environment variable OMP_PLACES libgomp: Number of places reduced from 8 to 1 because some places didn't contain any usable logical CPUs libgomp: Number of places reduced from 5 to 1 because some places didn't contain any usable logical CPUs libgomp: None of the places contain usable logical CPUs libgomp: Invalid value for environment variable OMP_PLACES libgomp: Number of places reduced from 3 to 1 because some places didn't contain any usable logical CPUs libgomp: None of the places contain usable logical CPUs libgomp: Invalid value for environment variable OMP_PLACES libgomp: Number of places reduced from 8 to 1 because some places didn't contain any usable logical CPUs same for taskset -c 0-8 ./affinity-1.exe | grep veri > -- > You are receiving this mail because: > You reported the bug. -- Il est bon de suivre sa pente, pourvu que ce soit en montant. A.G. http://www.flickr.com/photos/vin60/1320965757/
[Bug bootstrap/58657] New: bootstrapping cross compiler for sh4eb-*.* target wrongly creates a compiler with emulated TLS support instead of native TLS support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58657 Bug ID: 58657 Summary: bootstrapping cross compiler for sh4eb-*.* target wrongly creates a compiler with emulated TLS support instead of native TLS support Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: eladv6 at gmail dot com When building cross compiler for a sh4eb-*.* target (sh4eb-linux-gnu for example) ./gcc/configure detects no TLS assembler for the architecture and chooses TLS emulation (which in turn creates a broken toolchain with GLIBC and/or uclibc, but this is unrelated to GCC). When sh4-*.* is the target, native TLS is correctly used and not the emulation and a working toolchain is produced. The culprit is in ./gcc/configure. The TLS detection script only considers sh-*.* and sh[34]-*.* as SH targets supporting TLS and not target with sheb-*.* or sh[34]eb-*.* . Obviously the only consideration for TLS support is the CPU architecture and not its endianess. I propose the following patch to GCC 4.7.3 (./gcc/configure) : --- ./gcc/configure-buggy 2013-02-06 17:23:55.0 +0200 +++ ./gcc/configure 2013-10-06 15:12:16.526961100 +0200 @@ -23554,7 +23554,7 @@ tls_first_minor=14 tls_as_opt="-m64 -Aesame --fatal-warnings" ;; - sh-*-* | sh[34]-*-*) + sh-*-* | sh[34]-*-* | sheb-*-* | sh[34]eb-*-*) conftest_s=' .section ".tdata","awT",@progbits foo: .long 25 The bug also occurs in GCC 4.8.1. Elad.
[Bug bootstrap/58657] bootstrapping cross compiler for sh4eb-*.* target wrongly creates a compiler with emulated TLS support instead of native TLS support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58657 --- Comment #1 from Elad Nachman --- Created attachment 30965 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30965&action=edit proposed patch for sh4eb target under gcc 4.7.3
[Bug c++/58635] [c++11] ICE with __transaction_atomic and noexcept(false)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58635 Marek Polacek changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek --- Mine.
[Bug target/56313] aarch64 backend not using fmls instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56313 Richard Earnshaw changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #2 from Richard Earnshaw --- Fixed on trunk. Probably with: 2013-09-16 James Greenhalgh * config/aarch64/aarch64-simd-builtins.def (fma): New. * config/aarch64/aarch64-simd.md (aarch64_mla_elt): New. (aarch64_mla_elt_): Likewise. (aarch64_mls_elt): Likewise. (aarch64_mls_elt_): Likewise. (aarch64_fma4_elt): Likewise. (aarch64_fma4_elt_): Likewise. (aarch64_fma4_elt_to_128v2df): Likewise. (aarch64_fma4_elt_to_64df): Likewise. (fnma4): Likewise. (aarch64_fnma4_elt): Likewise. (aarch64_fnma4_elt_): Likewise. (aarch64_fnma4_elt_to_128v2df): Likewise. (aarch64_fnma4_elt_to_64df): Likewise. * config/aarch64/iterators.md (VDQSF): New. * config/aarch64/arm_neon.h (vfm_lane_f<32, 64>): Convert to C implementation. (vml_lane_<16, 32, 64>): Likewise.
[Bug fortran/58658] New: Pointer assignment to allocatable unlimited polymorphic accepted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58658 Bug ID: 58658 Summary: Pointer assignment to allocatable unlimited polymorphic accepted Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: vladimir.fuka at gmail dot com subroutine sub(a) class(*),allocatable :: a a => null() end subroutine is accepted by gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gcc-4.8/lib/gcc/x86_64-unknown-linux-gnu/4.8.1/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.8-20130509/configure --enable-languages=c,c++,fortran --with-cloog --prefix=/usr/local/gcc-4.8 Thread model: posix gcc version 4.8.1 20130509 (prerelease) (GCC)
[Bug bootstrap/58509] [4.9 regression] ICE in calc_dfs_tree, at dominance.c:397 during Ada runtime build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58509 --- Comment #5 from Mikael Pettersson --- This bootstrap error still occurs with gcc-4.9-20131006. I've now decided to stop testing Ada on SPARC.
[Bug fortran/58658] [OOP] Pointer assignment to allocatable unlimited polymorphic accepted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58658 Tobias Burnus changed: What|Removed |Added Keywords||accepts-invalid Status|UNCONFIRMED |NEW Last reconfirmed||2013-10-07 CC||burnus at gcc dot gnu.org Summary|Pointer assignment to |[OOP] Pointer assignment to |allocatable unlimited |allocatable unlimited |polymorphic accepted|polymorphic accepted Ever confirmed|0 |1 Known to fail||4.8.1, 4.9.0 --- Comment #1 from Tobias Burnus --- Confirmed. Untested patch: --- a/gcc/fortran/primary.c +++ b/gcc/fortran/primary.c @@ -2147,5 +2147,5 @@ gfc_variable_attr (gfc_expr *expr, gfc_typespec *ts) attr = sym->attr; - if (sym->ts.type == BT_CLASS && sym->attr.class_ok) + if (sym->ts.type == BT_CLASS && (sym->attr.class_ok || UNLIMITED_POLY (sym))) { dimension = CLASS_DATA (sym)->attr.dimension;
[Bug middle-end/23623] volatile keyword changes bitfield access size from 32bit to 8bit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23623 --- Comment #17 from Sandra Loosemore --- Updated patch series: http://gcc.gnu.org/ml/gcc-patches/2013-09/msg02057.html http://gcc.gnu.org/ml/gcc-patches/2013-09/msg02058.html http://gcc.gnu.org/ml/gcc-patches/2013-09/msg02059.html Unfortunately, it seems that fixing bugs with -fstrict-volatile-bitfields has been blocked by disagreement between global reviewers and target maintainers who can't agree on whether the C/C++11 memory model should take precedence over target-specific ABIs by default. :-(
[Bug middle-end/48784] #pragma pack(1) + -fstrict-volatile-bitfields = bad codegen
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48784 --- Comment #4 from Sandra Loosemore --- Updated patch series: http://gcc.gnu.org/ml/gcc-patches/2013-09/msg02057.html http://gcc.gnu.org/ml/gcc-patches/2013-09/msg02058.html http://gcc.gnu.org/ml/gcc-patches/2013-09/msg02059.html Unfortunately, it seems that fixing bugs with -fstrict-volatile-bitfields has been blocked by disagreement between global reviewers and target maintainers who can't agree on whether the C/C++11 memory model should take precedence over target-specific ABIs by default. :-(
[Bug middle-end/56341] GCC produces unaligned data access
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56341 --- Comment #13 from Sandra Loosemore --- Updated patch series: http://gcc.gnu.org/ml/gcc-patches/2013-09/msg02057.html http://gcc.gnu.org/ml/gcc-patches/2013-09/msg02058.html http://gcc.gnu.org/ml/gcc-patches/2013-09/msg02059.html Unfortunately, it seems that fixing bugs with -fstrict-volatile-bitfields has been blocked by disagreement between global reviewers and target maintainers who can't agree on whether the C/C++11 memory model should take precedence over target-specific ABIs by default. :-(
[Bug target/56997] Incorrect write to packed field when strict-volatile-bitfields enabled on aarch32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56997 --- Comment #11 from Sandra Loosemore --- Updated patch series: http://gcc.gnu.org/ml/gcc-patches/2013-09/msg02057.html http://gcc.gnu.org/ml/gcc-patches/2013-09/msg02058.html http://gcc.gnu.org/ml/gcc-patches/2013-09/msg02059.html Unfortunately, it seems that fixing bugs with -fstrict-volatile-bitfields has been blocked by disagreement between global reviewers and target maintainers who can't agree on whether the C/C++11 memory model should take precedence over target-specific ABIs by default. :-(
[Bug libgomp/58642] gomp regression: not "honoring" anymore task set and numactl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58642 --- Comment #27 from Jakub Jelinek --- (In reply to vincenzo Innocente from comment #26) > [innocent@olsnba04 parallel]$ ./affinity-1.exe | grep veri > > libgomp: Number of places reduced from 5 to 1 because some places didn't > contain any usable logical CPUs > > libgomp: None of the places contain usable logical CPUs > > libgomp: Invalid value for environment variable OMP_PLACES Ugh, none of these look expected. Can you cut'n'paste the OMP_PROC_BIND=... OMP_PLACES=... line from before some of these errors and see if you can reproduce it with running ./affinity-1.exe with those two env vars? Can you strace | grep affinity it? The == 8 to >= 8 change is already in the gomp-4_0-branch BTW.
[Bug fortran/58658] [OOP] Pointer assignment to allocatable unlimited polymorphic accepted
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58658 --- Comment #2 from Tobias Burnus --- (In reply to Tobias Burnus from comment #1) > Confirmed. Untested patch: Which of course doesn't work. What helps is the following patch (not regtested). I wonder why there is the unlimited check. - It looks completely bogus. --- a/gcc/fortran/expr.c +++ b/gcc/fortran/expr.c @@ -4693,7 +4693,6 @@ gfc_check_vardef_context (gfc_expr* e, bool pointer, bool alloc_obj, bool is_pointer; bool check_intentin; bool ptr_component; - bool unlimited; symbol_attribute attr; gfc_ref* ref; int i; @@ -4709,8 +4708,6 @@ gfc_check_vardef_context (gfc_expr* e, bool pointer, bool alloc_obj, sym = e->value.function.esym ? e->value.function.esym : e->symtree->n.sym; } - unlimited = e->ts.type == BT_CLASS && UNLIMITED_POLY (sym); - attr = gfc_expr_attr (e); if (!pointer && e->expr_type == EXPR_FUNCTION && attr.pointer) { @@ -4750,7 +4747,7 @@ gfc_check_vardef_context (gfc_expr* e, bool pointer, bool alloc_obj, /* Find out whether the expr is a pointer; this also means following component references to the last one. */ is_pointer = (attr.pointer || attr.proc_pointer); - if (pointer && !is_pointer && !unlimited) + if (pointer && !is_pointer) { if (context) gfc_error ("Non-POINTER in pointer association context (%s)"
[Bug tree-optimization/58570] [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=58570 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-10-07 Ever confirmed|0 |1 --- Comment #4 from Eric Botcazou --- Ouch. The tree-ssa-alias.c changes were not intended to affect alias.c, but they of course do nowadays...
[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 Eric Botcazou changed: What|Removed |Added CC|bernd.edlinger at hotmail dot de | Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org Summary|[4.9 Regression] wrong code |[4.9 Regression] wrong code |at -Os and above on |for bitfields at -O2 and |x86_64-linux-gnu (both |above |32-bit and 64-bit modes)| --- Comment #5 from Eric Botcazou --- I think we just want to copy the following from nonoverlapping_component_refs_p: /* If we're left with accessing different fields of a structure, then no possible overlap, unless they are both bitfields. */ if (TREE_CODE (typex) == RECORD_TYPE && fieldx != fieldy) return !(DECL_BIT_FIELD (fieldx) && DECL_BIT_FIELD (fieldy)); over to nonoverlapping_component_refs_of_decl_p.
[Bug libstdc++/58659] New: 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 Bug ID: 58659 Summary: Construction of shared_ptr from unique_ptr mismatches new/delete and std::allocator for __shared_ptr_count Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: spencer at starscale dot com CC: jwakely.gcc at gmail dot com Using gcc-4.8.1 configured with --enable-threads=single --enable-libstdcxx-allocator=mt, I'm seeing the following tiny program crash: int main() { std::unique_ptr u = std::unique_ptr(new X); std::shared_ptr s(std::move(u)); return 0; } Note that I am using a different default std::allocator base class (not new/delete). I think the bug is that the shared_ptr count object is being allocated with new and deleted with std::allocator. This will work when std::allocator is new/delete, but not otherwise. I haven't had time to prove it or work up a patch yet; I can if that helps: please let me know. Look at __shared_ptr_base's __S_create_from_up: template static _Sp_counted_base<_Lp>* _S_create_from_up(std::unique_ptr<_Tp, _Del>&& __r, typename std::enable_if::value>::type* = 0) { typedef typename unique_ptr<_Tp, _Del>::pointer _Ptr; return new _Sp_counted_deleter<_Ptr, _Del, std::allocator, _Lp>(__r.get(), __r.get_deleter()); } It always uses "new" to allocate an _Sp_counted_deleter (in both overloads). I think this is the bug, because _Sp_counted_deleter always uses std::allocator to dispose of itself: virtual void _M_destroy() noexcept { typedef typename allocator_traits<_Alloc>::template rebind_traits<_Sp_counted_deleter> _Alloc_traits; typename _Alloc_traits::allocator_type __a(_M_del); _Alloc_traits::destroy(__a, this); _Alloc_traits::deallocate(__a, this, 1); } CC Jonathan Wakely who has already analyzed this with a test case for the stock std::allocator on the mailing list.
[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|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-10-07 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Target Milestone|--- |4.8.2 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Thanks for the report (it's easier to track and find in future if it's in bugzilla) I'll fix this asap.
[Bug libgcc/58660] New: ARM/Thumb non-interworking code broken in libgcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58660 Bug ID: 58660 Summary: ARM/Thumb non-interworking code broken in libgcc Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: jifl-bugzilla at jifvik dot org Created attachment 30966 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30966&action=edit libgcc patch to correct operation with non-interworking thumb builds I have included a multilib in my GCC for ARM to generate thumb code with interworking disabled, intended for an ARMv4T CPU (e.g. ARM7T or ARM9). In other words, -mcpu=arm9 -mthumb -mno-thumb-interwork. However this fails to work because of a problem in libgcc making it incorrect for non-interworking operation. A specific example is aeabi_uldivmod in bpabi.S which is an ARM (not thumb) function, which includes a bl to __gnu_uldivmod_helper. __gnu_uldivmod_helper is from bpabi.c and is in Thumb mode. The linker helpfully adds a little trampoline to switch to Thumb mode with the bx instruction (gnu_uldivmod_helper_from_arm). However GCC returns from __gnu_uldivmod_helper with: pop {r3, r4, r5, r6, r7, pc} This means that no mode switch happens on the return from the Thumb mode function to the ARM mode aeabi_uldivmod function. As well as the obvious aeabi_ldivmod, someone may want to double-check whether this sort of problem may apply to other functions (although I haven't found any others yet myself, but I'm not sure about how functions like those in unaligned-funcs.c would be called). I am attaching a potential fix for the problem with aeabi_ldivmod and aeabi_uldivmod, so it would be good for that to be applied at least, including on the 4.7 branch. 2013-10-07 Jonathan Larmour * config/arm/bpabi.S (aeabi_ldivmod, aeabi_uldivmod): Allow for non-interworking Thumb builds. Thanks, Jifl
[Bug libstdc++/57641] std::timed_mutex.try_lock_until() is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57641 --- Comment #7 from Jonathan Wakely --- Author: redi Date: Mon Oct 7 23:21:58 2013 New Revision: 203256 URL: http://gcc.gnu.org/viewcvs?rev=203256&root=gcc&view=rev Log: PR libstdc++/57641 * include/std/mutex (timed_mutex, recursive_timed_mutex): Add overloaded _M_try_lock_until to handle conversion between different clocks. Replace constrained __try_lock_for_impl overloads with conditional increment. * testsuite/30_threads/timed_mutex/try_lock_until/57641.cc: New. Added: branches/gcc-4_8-branch/libstdc++-v3/testsuite/30_threads/timed_mutex/try_lock_until/57641.cc Modified: branches/gcc-4_8-branch/libstdc++-v3/ChangeLog branches/gcc-4_8-branch/libstdc++-v3/include/std/mutex
[Bug libstdc++/57641] std::timed_mutex.try_lock_until() is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57641 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from Jonathan Wakely --- fixed for 4.8.2
[Bug libstdc++/58357] In C++11 std::rotate(first, middle, last) now should return a forward iterator to first + (last - middle).
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58357 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-10-07 Ever confirmed|0 |1
[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|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #3 from Paolo Carlini --- Mine.
[Bug target/56993] power gcc built 416.gamess generates wrong result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56993 --- Comment #3 from Carrot --- I don't have a reduced test case. But I have a reduced config file. ### ext = Linux64 backup_config = 0 makeflags = -j64 default=default=default=default: # Set the path that the compiler is located at. CC_PATH = /usr/local/google/carrot/bin/trunkbin/bin CC = $(CC_PATH)/gcc CXX = $(CC_PATH)/g++ FC = $(CC_PATH)/gfortran OPTIMIZE = -O2 -m64 CPORTABILITY = -DSPEC_CPU_LP64 CXXPORTABILITY = -DSPEC_CPU_LP64 FPPPORTABILITY = -DSPEC_CPU_LP64
[Bug c++/58661] New: Definition of inherited nested class should be invalid
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58661 Bug ID: 58661 Summary: Definition of inherited nested class should be invalid Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: zeratul976 at hotmail dot com GCC accepts the following code without any errors: struct A { struct nested; }; struct B : public A {}; struct B::nested {}; I believe that this code is invalid according to [class] p11: "If a class-head-name contains a nested-name-specifier, the class-specifier shall refer to a class that was previously declared directly in the class or namespace to which the nested-name-specifier refers, or in an element of the inline namespace set (7.3.1) of that namespace (i.e., not merely inherited or introduced by a using-declaration)" Note that clang rejects the above code, with the error: test.cpp:8:11: error: no struct named 'nested' in 'B' struct B::nested {}; ~~~^
[Bug tree-optimization/58662] New: 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 Bug ID: 58662 Summary: wrong code at -O2 and -O3 on x86_64-linux-gnu (in 64-bit mode) 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 current gcc trunk miscompiles the attached testcase on x86_64-linux-gnu at -O2 and -O3 in 64-bit mode. It 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 --disable-werror --enable-checking=release --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 20131007 (experimental) [trunk revision 203235] (GCC) $ $ gcc-trunk -Os small.c; a.out 0 $ gcc-trunk -O2 small.c; a.out -1008071096 $ gcc-trunk -O3 small.c; a.out 86090104 $ $ gcc-4.8 -O2 small.c; a.out 0 $ gcc-4.8 -O3 small.c; a.out 0 $ - int printf (const char *, ...); int a, b, c, d; int foo (int p1, short p2) { return p1 / p2; } int main () { char e; d = foo (a == 0, (0, 35536)); e = d % 14; b = e && c; printf ("%d\n", b); return 0; }
[Bug libgomp/58642] gomp regression: not "honoring" anymore task set and numactl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58642 --- Comment #28 from vincenzo Innocente --- updated to the new revision gcc version 4.9.0 20131007 (experimental) [gomp-4_0-branch revision 203250] (GCC) [innocent@olsnba04 parallel]$ setenv OMP_PROC_BIND 'spread,master,close'; setenv OMP_PLACES '{0}:8' [innocent@olsnba04 parallel]$ printenv | grep OMP OMP_PROC_BIND=spread,master,close OMP_PLACES={0}:8 [innocent@olsnba04 parallel]$ strace ./affinity-1.exe | & grep affin execve("./affinity-1.exe", ["./affinity-1.exe"], [/* 61 vars */]) = 0 sched_getaffinity(109733, 8, 0x1dc8010) = -1 EINVAL (Invalid argument) sched_getaffinity(109733, 128, { , 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }) = 128 sched_getaffinity(109733, 128, { , 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }) = 128 sched_setaffinity(109733, 8, { 1 })= 0 sched_getaffinity(109733, 8, 0x7fff71425940) = -1 EINVAL (Invalid argument) sched_setaffinity(109734, 8, { 4 })= 0 sched_setaffinity(109735, 8, { 10 }) = 0 sched_setaffinity(109736, 8, { 40 }) = 0 sched_getaffinity(109733, 8, 0x7fff714258c0) = -1 EINVAL (Invalid argument) sched_setaffinity(109755, 8, { 80 }) = 0 sched_getaffinity(109733, 8, 0x7fff714258b0) = -1 EINVAL (Invalid argument) sched_setaffinity(109770, 8, { 1 })= 0 sched_setaffinity(109771, 8, { 1 })= 0 sched_getaffinity(109733, 8, 0x7fff714258c0) = -1 EINVAL (Invalid argument) sched_setaffinity(109794, 8, { 2 })= 0 sched_setaffinity(109795, 8, { 4 })= 0 sched_setaffinity(109796, 8, { 8 })= 0 sched_setaffinity(109797, 8, { 10 }) = 0 sched_getaffinity(109733, 8, 0x7fff714258b0) = -1 EINVAL (Invalid argument) [innocent@olsnba04 parallel]$ ./affinity-1.exe OMP_PROC_BIND='spread,master,close' OMP_PLACES='{0}:8' Initial thread #1 thread 0 #1 thread 2 #1 thread 1 #1 thread 3 #1,#1 thread 3,0 #1,#1 thread 3,2 #1,#1 thread 3,1 #1,#2 thread 3,3 #1,#2 thread 3,0 #1,#2 thread 3,2 #1,#2 thread 3,4 #1,#2 thread 3,1 #1,#2,#1 thread 3,3,0 #1,#2,#1 thread 3,3,4 #1,#2,#1 thread 3,3,3 #1,#2,#1 thread 3,3,2 #1,#2,#1 thread 3,3,1 #1,#3 thread 3,0 #1,#3 thread 3,3 #1,#3 thread 3,2 #1,#3 thread 3,1 #1,#4 thread 3,5 #1,#4 thread 3,0 #1,#4 thread 3,4 #1,#4 thread 3,2 #1,#4 thread 3,3 #1,#4 thread 3,1 #2 thread 0 #2 thread 3 #2 thread 1 #2 thread 2 #2 thread 4 #2,#1 thread 3,0 #2,#1 thread 3,2 #2,#1 thread 3,1 #2,#2 thread 3,0 #2,#2 thread 3,4 #2,#2 thread 3,3 #2,#2 thread 3,2 #2,#2 thread 3,1 #2,#3 thread 3,0 #2,#3 thread 3,3 #2,#3 thread 3,2 #2,#3 thread 3,1 #2,#4 thread 3,0 #2,#4 thread 3,5 #2,#4 thread 3,4 #2,#4 thread 3,3 #2,#4 thread 3,2 #2,#4 thread 3,1 #3 thread 0 #3 thread 2 #3 thread 1 #3,#1 thread 2,0 #3,#1 thread 2,3 #3,#1 thread 2,2 #3,#1 thread 2,1 #3,#2 thread 2,2 #3,#2 thread 2,1 #3,#2 thread 2,0 #3,#2 thread 2,3 #3,#2,#1 thread 2,0,0 #3,#2,#1 thread 2,0,4 #3,#2,#1 thread 2,0,2 #3,#2,#1 thread 2,0,3 #3,#2,#1 thread 2,0,1 #3,#2,#2 thread 2,3,0 #3,#2,#2 thread 2,3,2 #3,#2,#2 thread 2,3,3 #3,#2,#2 thread 2,3,4 #3,#2,#2 thread 2,3,1 #3,#3 thread 2,0 #3,#3 thread 2,3 #3,#3 thread 2,2 #3,#3 thread 2,1 #3,#4 thread 2,5 #3,#4 thread 2,1 #3,#4 thread 2,0 #3,#4 thread 2,2 #3,#4 thread 2,3 #3,#4 thread 2,4 #4 thread 1 #4 thread 2 #4 thread 3 #4 thread 4 #4 thread 0 #4,#1 thread 2,0 #4,#1 thread 2,3 #4,#1 thread 2,2 #4,#1 thread 2,1 #4,#2 thread 2,1 #4,#2 thread 2,3 #4,#2 thread 2,2 #4,#2 thread 2,0 #4,#2,#1 thread 2,0,0 #4,#2,#1 thread 2,0,4 #4,#2,#1 thread 2,0,1 #4,#2,#1 thread 2,0,2 #4,#2,#1 thread 2,0,3 #4,#2,#2 thread 2,2,0 #4,#2,#2 thread 2,2,3 #4,#2,#2 thread 2,2,2 #4,#2,#2 thread 2,2,4 #4,#2,#2 thread 2,2,1 #4,#2,#3 thread 2,3,3 #4,#2,#3 thread 2,3,0 #4,#2,#3 thread 2,3,4 #4,#2,#3 thread 2,3,1 #4,#2,#3 thread 2,3,2 #4,#3 thread 2,0 #4,#3 thread 2,3 #4,#3 thread 2,2 #4,#3 thread 2,1 #4,#4 thread 2,2 #4,#4 thread 2,5 #4,#4 thread 2,4 #4,#4 thread 2,0 #4,#4 thread 2,1 #4,#4 thread 2,3 [innocent@olsnba04 parallel]$ setenv OMP_PROC_BIND 'spread,master,close'; setenv OMP_PLACES '{7,6}:2:-3' [innocent@olsnba04 parallel]$ printenv | grep OMP OMP_PROC_BIND=spread,master,close OMP_PLACES={7,6}:2:-3 strace ./affinity-1.exe |& grep affin execve("./affinity-1.exe", ["./affinity-1.exe"], [/* 61 vars */]) = 0 sched_getaffinity(109640, 8, 0x24e9010) = -1 EINVAL (Invalid argument) sched_getaffinity(109640, 128, { , 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }) = 128 sched_getaffinity(109640, 128, { , 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0, 0 }) = 128 sched_setaffinity(109640, 8, { c0 }) = 0 sched_getaffinity(109640, 8, 0x7fffaeaeda40) = -1 EINVAL (Invalid argument) sched_setaffinity(109641, 8, { c0 }) = 0 sched_setaffinity(109642, 8, { 18 }) = 0 sched_setaffinity(109643, 8, { 18 }) = 0 sched_getaffinity(109640, 8, 0x7fffaeaed9c0) = -1 EINVAL (Invalid argument) sched_setaffinity(109662, 8, { c0 }) = 0 sched_getaffinity(109640, 8, 0x7fffaeaed9b
[Bug target/58630] [4.9 Regression] Revision 203171 breaks several MS-ABI tests
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58630 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-10-08 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Seen on x86_64-apple-darwin10 and x86_64-unknown-linux-gnu, thus confirmed.
[Bug target/58641] [4.9 Regression] FAIL: gcc.target/i386/pr49002-2.c scan-assembler vmovapd[\t ]*%ymm[0-9]+,[^,]*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58641 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-10-08 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Seen on x86_64-apple-darwin10 and x86_64-unknown-linux-gnu, thus confirmed.
[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 #6 from Bernd Edlinger --- (In reply to Eric Botcazou from comment #5) > I think we just want to copy the following from > nonoverlapping_component_refs_p: > > /* If we're left with accessing different fields of a structure, then > no >possible overlap, unless they are both bitfields. */ > if (TREE_CODE (typex) == RECORD_TYPE && fieldx != fieldy) > return !(DECL_BIT_FIELD (fieldx) && DECL_BIT_FIELD (fieldy)); > > over to nonoverlapping_component_refs_of_decl_p. Yes. Just one idea: What if both bit fields have different DECL_BIT_FIELD_REPRESENTATIVE? Then they can't possibly overlap?