gcc-7-20171019 is now available

Snapshot gcc-7-20171019 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/7-20171019/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 7 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7

Re: GNU Tools Cauldron 2017 follow up: "Reviewed-by" etc.

On 10/19/2017 09:45 AM, Joseph Myers wrote: > On Thu, 19 Oct 2017, Thomas Schwinge wrote: > >> Hi! >> >> Still waiting for any kind of reaction -- general process-change inertia, >> chicken-and-egg problem, I suppose. ;-/ >> >> I have now put the proposed text onto a wiki page, so that those >> i

Re: GNU Tools Cauldron 2017 follow up: "Reviewed-by" etc.

On 10/19/2017 09:45 AM, Joseph Myers wrote: > On Thu, 19 Oct 2017, Thomas Schwinge wrote: > >> Hi! >> >> Still waiting for any kind of reaction -- general process-change inertia, >> chicken-and-egg problem, I suppose. ;-/ >> >> I have now put the proposed text onto a wiki page, so that those >> i

Re: GNU Tools Cauldron 2017 follow up: "Reviewed-by" etc.

On Thu, 19 Oct 2017, Thomas Schwinge wrote: > Hi! > > Still waiting for any kind of reaction -- general process-change inertia, > chicken-and-egg problem, I suppose. ;-/ > > I have now put the proposed text onto a wiki page, so that those > interested have a convenient handle to use, >

Re: GNU Tools Cauldron 2017 follow up: "Reviewed-by" etc.

On 10/19/2017 09:57 AM, Thomas Schwinge wrote: Hi! Still waiting for any kind of reaction -- general process-change inertia, chicken-and-egg problem, I suppose. ;-/ I have now put the proposed text onto a wiki page, so that those interested have a convenient handle to use,

Re: GNU Tools Cauldron 2017 follow up: "Reviewed-by" etc.

On 10/19/2017 08:57 AM, Thomas Schwinge wrote: > Hi! > > Still waiting for any kind of reaction -- general process-change inertia, > chicken-and-egg problem, I suppose. ;-/ > > I have now put the proposed text onto a wiki page, so that those > interested have a convenient handle to use, >

Re: GNU Tools Cauldron 2017 follow up: "Reviewed-by" etc.

Hi! Still waiting for any kind of reaction -- general process-change inertia, chicken-and-egg problem, I suppose. ;-/ I have now put the proposed text onto a wiki page, so that those interested have a convenient handle to use, . Ping. On Wed, 4 Oct 2017 1

Re: atomic_thread_fence() semantics

On 19/10/17 14:04, Sebastian Huber wrote: > On 19/10/17 14:18, 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. >

Re: Global analysis of RTL

R0b0t1 writes: When I first looked at the GCC codebase, it seemed to me that most operations should be done on the GIMPLE representation as it contains the most information. Is there any reason you gravitated towards RTL? Naiveté, really. My team and I didn’t know much about the code base

Re: atomic_thread_fence() semantics

On 19/10/17 14:18, 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 operation X in thread A synchronizes

Re: atomic_thread_fence() semantics

On 2017-10-19 14:31, 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 report it. This bug is fixed on t

Re: atomic_thread_fence() semantics

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 report it. This bug is fixed on trunk, so should work from gcc-8 onwar

Re: atomic_thread_fence() semantics

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 operation X in thread A synchronizes-with an acquire fence F in thread B,

Re: atomic_thread_fence() semantics

On 19/10/17 12:58, Mattias Rönnblom wrote: > 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 -O3 -std=c11 on x86_64 it p

Re: atomic_thread_fence() semantics

On 19 October 2017 at 12:58, 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 -O3 -std=c11 on

atomic_thread_fence() semantics

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 -O3 -std=c11 on x86_64 it produces the following code: send_x4711: .LFB0: .LVL0: imu

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

On Thu, Oct 19, 2017 at 10:38:28AM +0200, Richard Biener wrote: > On Thu, Oct 19, 2017 at 9:22 AM, Denis Bakhvalov wrote: > > Hello! > > > > I have a hot inner loop which was vectorized by gcc, but I also want > > compiler to unroll this loop by some factor. > > It can be controled in clang with t

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

On Thu, Oct 19, 2017 at 9:22 AM, Denis Bakhvalov wrote: > Hello! > > I have a hot inner loop which was vectorized by gcc, but I also want > compiler to unroll this loop by some factor. > It can be controled in clang with this pragma: > #pragma clang loop vectorize(enable) vectorize_width(8) > Plea

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

Hello! I have a hot inner loop which was vectorized by gcc, but I also want compiler to unroll this loop by some factor. It can be controled in clang with this pragma: #pragma clang loop vectorize(enable) vectorize_width(8) Please see example here: https://godbolt.org/g/UJoUJn So I want to tell g