Re: How to force gcc to vectorize the loop with particular vectorization width

2017-10-20 Thread Denis Bakhvalov
Thank you for the reply! Regarding last part of your message, this is also what clang will do when you are passing vf of 4 (with the pragma from my first message) for the loop operating on chars plus using SSE2. It will do meaningful work only for 4 chars per iteration (a[0], zero, zero, zero, a[1

Re: How to force gcc to vectorize the loop with particular vectorization width

2017-10-20 Thread Richard Biener
On Fri, Oct 20, 2017 at 12:13 PM, Denis Bakhvalov wrote: > Thank you for the reply! > > Regarding last part of your message, this is also what clang will do > when you are passing vf of 4 (with the pragma from my first message) > for the loop operating on chars plus using SSE2. It will do meaningf

Have "gcc -v" print information about slow run-time checking?

2017-10-20 Thread Thomas Schwinge
Hi! In , we got a user wonder about released vs. trunk GCC execution times, not knowing that the latter has more run-time checking enabled. Once that got clarified, the discussion proceeded: (In reply to petschy from comment #6) > Would it be sensible to put an extra

Re: atomic_thread_fence() semantics

2017-10-20 Thread Torvald Riegel
On Thu, 2017-10-19 at 13:58 +0200, Mattias Rönnblom wrote: > Hi. > > I have this code: > > #include > > int ready; > int message; > > void send_x4711(int m) { > message = m*4711; > atomic_thread_fence(memory_order_release); > ready = 1; > } > > When I compile it with GCC 7.2 -O

Re: atomic_thread_fence() semantics

2017-10-20 Thread Torvald Riegel
On Thu, 2017-10-19 at 15:31 +0300, Alexander Monakov wrote: > On Thu, 19 Oct 2017, Andrew Haley wrote: > > On 19/10/17 12:58, Mattias Rönnblom wrote: > > > Did I misunderstand the semantics of > > > atomic_thread_fence+memory_order_release? > > > > No, you did not. This looks like a bug. Please

Re: atomic_thread_fence() semantics

2017-10-20 Thread Torvald Riegel
On Thu, 2017-10-19 at 13:18 +0100, Andrew Haley wrote: > On 19/10/17 13:10, Jonathan Wakely wrote: > > There are no atomic operations on atomic objects here, so the fence > > doesn't synchronize with anything. > > Really? This seems rather unhelpful, to say the least. > > An atomic release opera

Re: Have "gcc -v" print information about slow run-time checking?

2017-10-20 Thread Richard Biener
On Fri, Oct 20, 2017 at 12:40 PM, Thomas Schwinge wrote: > Hi! > > In , we got a user wonder about released vs. > trunk GCC execution times, not knowing that the latter has more run-time > checking enabled. Once that got clarified, the discussion proceeded: > > (In re

Re: atomic_thread_fence() semantics

2017-10-20 Thread Torvald Riegel
On Fri, 2017-10-20 at 12:47 +0200, Torvald Riegel wrote: > On Thu, 2017-10-19 at 13:58 +0200, Mattias Rönnblom wrote: > > Hi. > > > > I have this code: > > > > #include > > > > int ready; > > int message; > > > > void send_x4711(int m) { > > message = m*4711; > > atomic_thread_fence(

Re: atomic_thread_fence() semantics

2017-10-20 Thread Alexander Monakov
On Fri, 20 Oct 2017, Torvald Riegel wrote: > On Thu, 2017-10-19 at 15:31 +0300, Alexander Monakov wrote: > > On Thu, 19 Oct 2017, Andrew Haley wrote: > > > No, you did not. This looks like a bug. Please report it. > > > > This bug is fixed on trunk, so should work from gcc-8 onwards (PR 80640).