date:20131007

[Bug libstdc++/58638] libstdc++ builds as non-PIC when --with-pic is specified

2013-10-07 Thread skunk at iskunk dot org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58638

--- Comment #1 from Daniel Richard G. skunk at iskunk dot org ---
A workaround for this issue is to build with CFLAGS=-fPIC CXXFLAGS=-fPIC
(presuming that one is building with GCC), in addition to --with-pic. This
results in a compiler build that does not fail as reported above.

[Bug libgomp/58642] gomp regression: not honoring anymore task set and numactl

2013-10-07 Thread vincenzo.innocente at cern dot ch

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58642

--- Comment #7 from vincenzo Innocente vincenzo.innocente at cern dot ch ---
getconf -a | grep _NPROCESSORS
_NPROCESSORS_CONF  32
_NPROCESSORS_ONLN  32


ls -l /sys/devices/system/cpu/
total 0
drwxr-xr-x 8 root root0 Sep  2 17:44 cpu0
drwxr-xr-x 8 root root0 Sep  2 17:44 cpu1
drwxr-xr-x 8 root root0 Sep  2 17:44 cpu10
drwxr-xr-x 8 root root0 Sep  2 17:44 cpu11
drwxr-xr-x 8 root root0 Sep  2 17:44 cpu12
drwxr-xr-x 8 root root0 Sep  2 17:44 cpu13
drwxr-xr-x 8 root root0 Sep  2 17:44 cpu14
drwxr-xr-x 8 root root0 Sep  2 17:44 cpu15
drwxr-xr-x 8 root root0 Sep  2 17:44 cpu16
drwxr-xr-x 8 root root0 Sep  2 17:44 cpu17
drwxr-xr-x 8 root root0 Sep  2 17:44 cpu18
drwxr-xr-x 8 root root0 Sep  2 17:44 cpu19
drwxr-xr-x 8 root root0 Sep  2 17:44 cpu2
drwxr-xr-x 8 root root0 Sep  2 17:44 cpu20
drwxr-xr-x 8 root root0 Sep  2 17:44 cpu21
drwxr-xr-x 8 root root0 Sep  2 17:44 cpu22
drwxr-xr-x 8 root root0 Sep  2 17:44 cpu23
drwxr-xr-x 8 root root0 Sep  2 17:44 cpu24
drwxr-xr-x 8 root root0 Sep  2 17:44 cpu25
drwxr-xr-x 8 root root0 Sep  2 17:44 cpu26
drwxr-xr-x 8 root root0 Sep  2 17:44 cpu27
drwxr-xr-x 8 root root0 Sep  2 17:44 cpu28
drwxr-xr-x 8 root root0 Sep  2 17:44 cpu29
drwxr-xr-x 8 root root0 Sep  2 17:44 cpu3
drwxr-xr-x 8 root root0 Sep  2 17:44 cpu30
drwxr-xr-x 8 root root0 Sep  2 17:44 cpu31
drwxr-xr-x 8 root root0 Sep  2 17:44 cpu4
drwxr-xr-x 8 root root0 Sep  2 17:44 cpu5
drwxr-xr-x 8 root root0 Sep  2 17:44 cpu6
drwxr-xr-x 8 root root0 Sep  2 17:44 cpu7
drwxr-xr-x 8 root root0 Sep  2 17:44 cpu8
drwxr-xr-x 8 root root0 Sep  2 17:44 cpu9
drwxr-xr-x 2 root root0 Sep  2 17:45 cpufreq
drwxr-xr-x 2 root root0 Sep  2 17:45 cpuidle
drwxr-xr-x 2 root root0 Oct  7 08:43 intel_pstate
-r--r--r-- 1 root root 4096 Oct  7 08:43 kernel_max
-r--r--r-- 1 root root 4096 Oct  7 08:43 modalias
-r--r--r-- 1 root root 4096 Oct  7 08:43 offline
-r--r--r-- 1 root root 4096 Sep  2 18:06 online
-r--r--r-- 1 root root 4096 Oct  7 08:43 possible
drwxr-xr-x 2 root root0 Oct  7 08:43 power
-r--r--r-- 1 root root 4096 Oct  7 08:43 present
--w--- 1 root root 4096 Oct  7 08:43 probe
--w--- 1 root root 4096 Oct  7 08:43 release
-rw-r--r-- 1 root root 4096 Oct  7 08:43 uevent

dmesg | grep 'Allowing.*CPUs'
smpboot: Allowing 128 CPUs, 96 hotplug CPUs

#include sched.h
#include stdio.h
#include errno.h

  int main(void)
  {
   cpu_set_t  k[32];
   sched_getaffinity(0, 8, k); 
   sched_getaffinity(0, 10, k);
   sched_getaffinity(0, 12, k);
   sched_getaffinity(0, 16, k);


strace ./a.out | grep affin
sched_getaffinity(0, 8, 0x7fffbcf19420) = -1 EINVAL (Invalid argument)
sched_getaffinity(0, 10, 0x7fffbcf19420) = -1 EINVAL (Invalid argument)
sched_getaffinity(0, 12, 0x7fffbcf19420) = -1 EINVAL (Invalid argument)
sched_getaffinity(0, 16,  { , 0 }) = 16

[Bug libgomp/58642] gomp regression: not honoring anymore task set and numactl

2013-10-07 Thread vincenzo.innocente at cern dot ch

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58642

--- Comment #8 from vincenzo Innocente vincenzo.innocente at cern dot ch ---
do you have access to a 32 cpu machine?
btw on XEON-PHI one can have 200 cpus

[Bug libgomp/58642] gomp regression: not honoring anymore task set and numactl

2013-10-07 Thread jakub at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58642

Jakub Jelinek jakub at gcc dot gnu.org 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 jakub at gcc dot gnu.org ---
Created attachment 30964
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30964action=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

2013-10-07 Thread burnus at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58652

Tobias Burnus burnus at gcc dot gnu.org 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 burnus at gcc dot gnu.org ---
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

2013-10-07 Thread vincenzo.innocente at cern dot ch

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58642

--- Comment #10 from vincenzo Innocente vincenzo.innocente at cern dot ch ---
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

2013-10-07 Thread jakub at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58642

--- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org ---
(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

2013-10-07 Thread jakub at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58642

--- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org ---
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

2013-10-07 Thread vincenzo.innocente at cern dot ch

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58642

--- Comment #13 from vincenzo Innocente vincenzo.innocente at cern dot ch ---
[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 } unfinished ...
[pid 72917] ... sched_setaffinity resumed ) = 0
[pid 72917] sched_setaffinity(72919, 8,  { 4 } unfinished ...
[pid 72917] ... sched_setaffinity resumed ) = 0
[pid 72917] sched_setaffinity(72920, 8,  { 8 } unfinished ...
[pid 72917] ... sched_setaffinity resumed ) = 0
[pid 72917] sched_setaffinity(72921, 8,  { 10 } unfinished ...
[pid 72917] ... sched_setaffinity resumed ) = 0
[pid 72917] sched_setaffinity(72922, 8,  { 20 } unfinished ...
[pid 72917] ... sched_setaffinity resumed ) = 0
[pid 72917] sched_setaffinity(72923, 8,  { 40 } unfinished ...
[pid 72917] ... sched_setaffinity resumed ) = 0
[pid 72917] sched_setaffinity(72924, 8,  { 80 } unfinished ...
[pid 72917] ... sched_setaffinity resumed ) = 0
[pid 72917] sched_setaffinity(72925, 8,  { 100 } unfinished ...
[pid 72917] ... sched_setaffinity resumed ) = 0
[pid 72917] sched_setaffinity(72926, 8,  { 200 } unfinished ...
[pid 72917] ... sched_setaffinity resumed ) = 0
[pid 72917] sched_setaffinity(72927, 8,  { 400 } unfinished ...
[pid 72917] ... sched_setaffinity resumed ) = 0
[pid 72917] sched_setaffinity(72928, 8,  { 800 } unfinished ...
[pid 72917] ... sched_setaffinity resumed ) = 0
[pid 72917] sched_setaffinity(72929, 8,  { 1000 } unfinished ...
[pid 72917] ... sched_setaffinity resumed ) = 0
[pid 72917] sched_setaffinity(72930, 8,  { 2000 } unfinished ...
[pid 72917] ... sched_setaffinity resumed ) = 0
[pid 72917] sched_setaffinity(72931, 8,  { 4000 } unfinished ...
[pid 72917] ... sched_setaffinity resumed ) = 0
[pid 72917] sched_setaffinity(72932, 8,  { 8000 } unfinished ...
[pid 72917] ... sched_setaffinity resumed ) = 0
[pid 72917] sched_setaffinity(72933, 8,  { 1 } unfinished ...
[pid 72917] ... sched_setaffinity resumed ) = 0
[pid 72917] sched_setaffinity(72934, 8,  { 2 } unfinished ...
[pid 72917] ... sched_setaffinity resumed ) = 0
[pid 72917] sched_setaffinity(72935, 8,  { 4 } unfinished ...
[pid 72917] ... sched_setaffinity resumed ) = 0
[pid 72917]

[Bug libgomp/58642] gomp regression: not honoring anymore task set and numactl

2013-10-07 Thread vincenzo.innocente at cern dot ch

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58642

--- Comment #14 from vincenzo Innocente vincenzo.innocente at cern dot ch ---
On 7 Oct, 2013, at 10:06 AM, jakub at gcc dot gnu.org
gcc-bugzi...@gcc.gnu.org wrote:

 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58642
 
 --- Comment #12 from Jakub Jelinek jakub at gcc dot gnu.org ---
 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

2013-10-07 Thread jakub at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58642

--- Comment #15 from Jakub Jelinek jakub at gcc dot gnu.org ---
(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

2013-10-07 Thread heiko.abra...@hella-gutmann.com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58617

--- Comment #2 from Heiko.Abraham heiko.abra...@hella-gutmann.com ---
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)

2013-10-07 Thread mpolacek at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58653

Marek Polacek mpolacek at gcc dot gnu.org 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 mpolacek at gcc dot gnu.org ---
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)

2013-10-07 Thread mpolacek at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58653

--- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org ---
It's the loop unswitching.

[Bug libgcc/55743] limits.h included unnecessarily in libgcc2.c - can break --without-headers bootstrap

2013-10-07 Thread rearnsha at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55743

Richard Earnshaw rearnsha at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |4.9.0

--- Comment #2 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
Fixed with:

http://gcc.gnu.org/ml/gcc-patches/2013-05/msg00828.html

[Bug c/58626] possible array wrong code bug

2013-10-07 Thread mpolacek at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58626

Marek Polacek mpolacek at gcc dot gnu.org 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

2013-10-07 Thread rearnsha at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55653

Richard Earnshaw rearnsha at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |4.8.0

--- Comment #2 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
Fixed with:

2013-01-08  Tejas Belagod  tejas.bela...@arm.com

* config/aarch64/aarch64-simd.md (vec_initmode): 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

2013-10-07 Thread gjl at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57503

Georg-Johann Lay gjl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #8 from Georg-Johann Lay gjl at gcc dot gnu.org ---
(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

2013-10-07 Thread rearnsha at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55653

--- Comment #3 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
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

2013-10-07 Thread paolo.carlini at oracle dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58654

Paolo Carlini paolo.carlini at oracle dot com changed:

   What|Removed |Added

 CC||xur at gcc dot gnu.org

--- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com ---
Adding Rong in CC, then.

[Bug libgomp/58642] gomp regression: not honoring anymore task set and numactl

2013-10-07 Thread vincenzo.innocente at cern dot ch

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58642

--- Comment #16 from vincenzo Innocente vincenzo.innocente at cern dot ch ---
./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

2013-10-07 Thread gjl at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57503

Georg-Johann Lay gjl at gcc dot gnu.org changed:

   What|Removed |Added

  Known to fail||4.7.2, 4.8.1, 4.9.0

--- Comment #9 from Georg-Johann Lay gjl at gcc dot gnu.org ---
(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
.identGCC: (GNU) 4.8.2 20131007 (prerelease)

[Bug libgomp/58642] gomp regression: not honoring anymore task set and numactl

2013-10-07 Thread jakub at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58642

--- Comment #17 from Jakub Jelinek jakub at gcc dot gnu.org ---
(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

2013-10-07 Thread vincenzo.innocente at cern dot ch

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58642

--- Comment #18 from vincenzo Innocente vincenzo.innocente at cern dot ch ---
On 7 Oct, 2013, at 12:27 PM, jakub at gcc dot gnu.org
gcc-bugzi...@gcc.gnu.org wrote:

 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58642
 
 --- Comment #17 from Jakub Jelinek jakub at gcc dot gnu.org ---
 (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

[Bug libgomp/58642] gomp regression: not honoring anymore task set and numactl

2013-10-07 Thread vincenzo.innocente at cern dot ch

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58642

--- Comment #19 from vincenzo Innocente vincenzo.innocente at cern dot ch ---
On 7 Oct, 2013, at 12:27 PM, jakub at gcc dot gnu.org
gcc-bugzi...@gcc.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 dlfcn.h 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 inttypes.h 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 memory.h 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 semaphore.h header file. */
#define HAVE_SEMAPHORE_H 1

/* Define to 1 if you have the stdint.h header file. */
#define HAVE_STDINT_H 1

/* Define to 1 if you have the stdlib.h header file. */
#define HAVE_STDLIB_H 1

/* Define to 1 if you have the strings.h header file. */
#define HAVE_STRINGS_H 1

/* Define to 1 if you have the string.h 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 sys/loadavg.h header file. */
/* #undef HAVE_SYS_LOADAVG_H */

/* Define to 1 if you have the sys/stat.h header file. */
#define HAVE_SYS_STAT_H 1

/* Define to 1 if you have the sys/time.h header file. */
#define HAVE_SYS_TIME_H 1

/* Define to 1 if you have the sys/types.h 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 unistd.h 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 string.h and strings.h. */
#define STRING_WITH_STRINGS 1

/* Define to 1 if you can safely include both sys/time.h and time.h. */
#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

2013-10-07 Thread gjl at gcc dot gnu.org

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

2013-10-07 Thread gjl at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58655

Georg-Johann Lay gjl at gcc dot gnu.org 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

2013-10-07 Thread Ganesh.Gopalasubramanian at amd dot com

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

2013-10-07 Thread jakub at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58642

--- Comment #20 from Jakub Jelinek jakub at gcc dot gnu.org ---
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

2013-10-07 Thread jakub at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58642

--- Comment #21 from Jakub Jelinek jakub at gcc dot gnu.org ---
Author: jakub
Date: Mon Oct  7 11:39:39 2013
New Revision: 203243

URL: http://gcc.gnu.org/viewcvs?rev=203243root=gccview=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

2013-10-07 Thread mpolacek at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58646

Marek Polacek mpolacek at gcc dot gnu.org 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 mpolacek at gcc dot gnu.org ---
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

2013-10-07 Thread vincenzo.innocente at cern dot ch

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58642

--- Comment #22 from vincenzo Innocente vincenzo.innocente at cern dot ch ---
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

[Bug libgomp/58642] gomp regression: not honoring anymore task set and numactl

2013-10-07 Thread jakub at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58642

--- Comment #23 from Jakub Jelinek jakub at gcc dot gnu.org ---
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

2013-10-07 Thread redi at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57226

Jonathan Wakely redi at gcc dot gnu.org 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)

2013-10-07 Thread mpolacek at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58635

Marek Polacek mpolacek at gcc dot gnu.org 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 mpolacek at gcc dot gnu.org ---
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

2013-10-07 Thread vincenzo.innocente at cern dot ch

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58642

--- Comment #24 from vincenzo Innocente vincenzo.innocente at cern dot ch ---
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 gcc-bugzi...@gcc.gnu.org
wrote:

 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58642
 
 --- Comment #23 from Jakub Jelinek jakub at gcc dot gnu.org ---
 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

2013-10-07 Thread jakub at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58642

--- Comment #25 from Jakub Jelinek jakub at gcc dot gnu.org ---
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

2013-10-07 Thread vincenzo.innocente at cern dot ch

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58642

--- Comment #26 from vincenzo Innocente vincenzo.innocente at cern dot ch ---
On 7 Oct, 2013, at 3:02 PM, jakub at gcc dot gnu.org gcc-bugzi...@gcc.gnu.org
wrote:

 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58642
 
 --- Comment #25 from Jakub Jelinek jakub at gcc dot gnu.org ---
 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

2013-10-07 Thread eladv6 at gmail dot com

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

2013-10-07 Thread eladv6 at gmail dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58657

--- Comment #1 from Elad Nachman eladv6 at gmail dot com ---
Created attachment 30965
  -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30965action=edit
proposed patch for sh4eb target under gcc 4.7.3

[Bug c++/58635] [c++11] ICE with __transaction_atomic and noexcept(false)

2013-10-07 Thread mpolacek at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58635

Marek Polacek mpolacek at gcc dot gnu.org 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 mpolacek at gcc dot gnu.org ---
Mine.

[Bug target/56313] aarch64 backend not using fmls instruction

2013-10-07 Thread rearnsha at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56313

Richard Earnshaw rearnsha at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |4.9.0

--- Comment #2 from Richard Earnshaw rearnsha at gcc dot gnu.org ---
Fixed on trunk.  Probably with:

2013-09-16  James Greenhalgh  james.greenha...@arm.com

* config/aarch64/aarch64-simd-builtins.def (fma): New.
* config/aarch64/aarch64-simd.md
(aarch64_mla_eltmode): New.
(aarch64_mla_elt_vswap_width_namemode): Likewise.
(aarch64_mls_eltmode): Likewise.
(aarch64_mls_elt_vswap_width_namemode): Likewise.
(aarch64_fma4_eltmode): Likewise.
(aarch64_fma4_elt_vswap_width_namemode): Likewise.
(aarch64_fma4_elt_to_128v2df): Likewise.
(aarch64_fma4_elt_to_64df): Likewise.
(fnmamode4): Likewise.
(aarch64_fnma4_eltmode): Likewise.
(aarch64_fnma4_elt_vswap_width_namemode): Likewise.
(aarch64_fnma4_elt_to_128v2df): Likewise.
(aarch64_fnma4_elt_to_64df): Likewise.
* config/aarch64/iterators.md (VDQSF): New.
* config/aarch64/arm_neon.h
(vfmassdq_laneq_f32, 64): Convert to C implementation.
(vmlsaq_laneq_fsu16, 32, 64): Likewise.

[Bug fortran/58658] New: Pointer assignment to allocatable unlimited polymorphic accepted

2013-10-07 Thread vladimir.fuka at gmail dot com

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

2013-10-07 Thread mikpelinux at gmail dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58509

--- Comment #5 from Mikael Pettersson mikpelinux at gmail dot com ---
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

2013-10-07 Thread burnus at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58658

Tobias Burnus burnus at gcc dot gnu.org 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 burnus at gcc dot gnu.org ---
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

2013-10-07 Thread sandra at codesourcery dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23623

--- Comment #17 from Sandra Loosemore sandra at codesourcery dot com ---
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

2013-10-07 Thread sandra at codesourcery dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48784

--- Comment #4 from Sandra Loosemore sandra at codesourcery dot com ---
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

2013-10-07 Thread sandra at codesourcery dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56341

--- Comment #13 from Sandra Loosemore sandra at codesourcery dot com ---
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

2013-10-07 Thread sandra at codesourcery dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56997

--- Comment #11 from Sandra Loosemore sandra at codesourcery dot com ---
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

2013-10-07 Thread jakub at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58642

--- Comment #27 from Jakub Jelinek jakub at gcc dot gnu.org ---
(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

2013-10-07 Thread burnus at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58658

--- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org ---
(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)

2013-10-07 Thread ebotcazou at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58570

Eric Botcazou ebotcazou at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-10-07
 Ever confirmed|0   |1

--- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org ---
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

2013-10-07 Thread ebotcazou at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58570

Eric Botcazou ebotcazou at gcc dot gnu.org 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 ebotcazou at gcc dot gnu.org ---
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

2013-10-07 Thread spencer at starscale dot com

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_ptrX u = std::unique_ptrX(new X);
  std::shared_ptrX 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:

templatetypename _Tp, typename _Del
  static _Sp_counted_base_Lp*
  _S_create_from_up(std::unique_ptr_Tp, _Del __r,
typename std::enable_if!std::is_reference_Del::value::type* =
  0)
  {
typedef typename unique_ptr_Tp, _Del::pointer _Ptr;
return new _Sp_counted_deleter_Ptr, _Del, std::allocatorvoid,
  _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

2013-10-07 Thread redi at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58659

Jonathan Wakely redi at gcc dot gnu.org 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 redi at gcc dot gnu.org ---
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

2013-10-07 Thread jifl-bugzilla at jifvik dot org

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=30966action=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  j...@ecoscentric.com

* 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

2013-10-07 Thread redi at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57641

--- Comment #7 from Jonathan Wakely redi at gcc dot gnu.org ---
Author: redi
Date: Mon Oct  7 23:21:58 2013
New Revision: 203256

URL: http://gcc.gnu.org/viewcvs?rev=203256root=gccview=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

2013-10-07 Thread redi at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57641

Jonathan Wakely redi at gcc dot gnu.org changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org ---
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).

2013-10-07 Thread redi at gcc dot gnu.org

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58357

Jonathan Wakely redi at gcc dot gnu.org 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

2013-10-07 Thread paolo.carlini at oracle dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58568

Paolo Carlini paolo.carlini at oracle dot com 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 paolo.carlini at oracle dot com ---
Mine.

[Bug target/56993] power gcc built 416.gamess generates wrong result

2013-10-07 Thread carrot at google dot com

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56993

--- Comment #3 from Carrot carrot at google dot com ---
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

2013-10-07 Thread zeratul976 at hotmail dot com

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)

2013-10-07 Thread su at cs dot ucdavis.edu

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;
}

63 matches

Mail list logo