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

[Denis Bakhvalov]

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 gcc something like this:
"I want you to vectorize the loop. After that I want you to unroll
this vectorized loop by some defined factor."

I was playing with #pragma omp simd with the safelen clause, and
#pragma GCC optimize("unroll-loops") with no success. Compiler option
-fmax-unroll-times is not suitable for me, because it will affect
other parts of the code.

Is it possible to achieve this somehow?

-- 
Best regards,
Denis.

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

[Richard Biener]

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)
> Please see example here:
> https://godbolt.org/g/UJoUJn
>
> So I want to tell gcc something like this:
> "I want you to vectorize the loop. After that I want you to unroll
> this vectorized loop by some defined factor."
>
> I was playing with #pragma omp simd with the safelen clause, and
> #pragma GCC optimize("unroll-loops") with no success. Compiler option
> -fmax-unroll-times is not suitable for me, because it will affect
> other parts of the code.
>
> Is it possible to achieve this somehow?

No.

Richard.

>
> --
> Best regards,
> Denis.

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

[Jakub Jelinek]

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 this pragma:
> > #pragma clang loop vectorize(enable) vectorize_width(8)
> > Please see example here:
> > https://godbolt.org/g/UJoUJn
> >
> > So I want to tell gcc something like this:
> > "I want you to vectorize the loop. After that I want you to unroll
> > this vectorized loop by some defined factor."
> >
> > I was playing with #pragma omp simd with the safelen clause, and
> > #pragma GCC optimize("unroll-loops") with no success. Compiler option
> > -fmax-unroll-times is not suitable for me, because it will affect
> > other parts of the code.
> >
> > Is it possible to achieve this somehow?
> 
> No.

#pragma omp simd has simdlen clause which is a hint on the preferable
vectorization factor, but the vectorizer doesn't use it so far;
probably it wouldn't be that hard to at least use that as the starting
factor if the target has multiple ones if it is one of those.
The vectorizer has some support for using wider vectorization factors
if there are mixed width types within the same loop, so perhaps
supporting 2x/4x/8x etc. sizes of the normally chosen width might not be
that hard.
What we don't have right now is support for using smaller
vectorization factors, which might be sometimes beneficial for -O2
vectorization of mixed width type loops.  We always use the vf derived
from the smallest width type, say when using SSE2 and there is a char type,
we try to use vf of 16 and if there is also int type, do operations on those
in 4x as many instructions, while there is also an option to use
vf of 4 and for operations on char just do something meaningful only in 1/4
of vector elements.  The various x86 vector ISAs have instructions to
widen or narrow for conversions.

In any case, no is the right answer right now, we don't have that
implemented.

Jakub

atomic_thread_fence() semantics

[Mattias Rönnblom]

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:
imuledi, edi, 4711
.LVL1:
mov DWORD PTR ready[rip], 1
mov DWORD PTR message[rip], edi
ret

I expected the store to 'message' and 'ready' to be in program order.

Did I misunderstand the semantics of 
atomic_thread_fence+memory_order_release?


Regards,
Mattias

Re: atomic_thread_fence() semantics

[Jonathan Wakely]

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 x86_64 it produces the
> following code:
>
> send_x4711:
> .LFB0:
> .LVL0:
> imuledi, edi, 4711
> .LVL1:
> mov DWORD PTR ready[rip], 1
> mov DWORD PTR message[rip], edi
> ret
>
> I expected the store to 'message' and 'ready' to be in program order.
>
> Did I misunderstand the semantics of
> atomic_thread_fence+memory_order_release?

There are no atomic operations on atomic objects here, so the fence
doesn't synchronize with anything.

Re: atomic_thread_fence() semantics

[Andrew Haley]

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 produces the 
> following code:
> 
> send_x4711:
> .LFB0:
> .LVL0:
>  imuledi, edi, 4711
> .LVL1:
>  mov DWORD PTR ready[rip], 1
>  mov DWORD PTR message[rip], edi
>  ret
> 
> I expected the store to 'message' and 'ready' to be in program order.
> 
> Did I misunderstand the semantics of 
> atomic_thread_fence+memory_order_release?

No, you did not.  This looks like a bug.  Please report it.

The tree dump looks OK:

send_x4711 (int m)
{
  int _1;

   [100.00%]:
  _1 = m_2(D) * 4711;
  message = _1;
  __atomic_thread_fence (3);
  ready = 1;
  return;

}

It looks like a bug in the lowering pass.

;; __atomic_thread_fence (3);

is lowered to

(nil)

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. 
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: atomic_thread_fence() semantics

[Andrew Haley]

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, if

there exists an atomic read Y (with any memory order)
Y reads the value written by X (or by the release sequence headed by X)
Y is sequenced-before F in thread B

In this case, all non-atomic and relaxed atomic stores that
happen-before X in thread A will be synchronized-with all non-atomic
and relaxed atomic loads from the same locations made in thread B
after F.

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. 
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

Re: atomic_thread_fence() semantics

[Alexander Monakov]

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 onwards (PR 80640).

Alexander

Re: atomic_thread_fence() semantics

[Mattias Rönnblom]

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 trunk, so should work from gcc-8 onwards (PR 80640).



OK, thanks!

Regards,
Mattias

Re: atomic_thread_fence() semantics

[Sebastian Huber]

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-with an acquire
fence F in thread B, if

 there exists an atomic read Y (with any memory order)
 Y reads the value written by X (or by the release sequence headed by X)
 Y is sequenced-before F in thread B

In this case, all non-atomic and relaxed atomic stores that
happen-before X in thread A will be synchronized-with all non-atomic
and relaxed atomic loads from the same locations made in thread B
after F.



Where is the acquire fence or a load in the example?

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax : +49 89 189 47 41-09
E-Mail  : sebastian.hu...@embedded-brains.de
PGP : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

Re: Global analysis of RTL

[Geoff Wozniak]

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 when we started 
looking at the problem, although we knew a little about the 
intermediate formats. GIMPLE makes the analysis more complicated, 
although not impossible, and it can make the cost model difficult 
to pin down. Raw assembly/machine code is ideal, but then we have 
to deal with different platforms and would likely have to do all 
the work in the linker. RTL is sufficiently low-level enough (as 
far as we know) to start counting instructions, and platform 
independent enough that we don’t have to parse machine code.


Essentially, working with RTL makes the implementation a little 
easier but we didn’t know that the pass infrastructure wasn’t in 
our favour.


It’s likely we’ll turn our attention to GIMPLE and 
assembler/machine code, unless we can come up with something (or 
anyone has a suggestion).


-- Geoff

Re: atomic_thread_fence() semantics

[Andrew Haley]

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.
>>
>> An atomic release operation X in thread A synchronizes-with an acquire
>> fence F in thread B, if
>>
>>  there exists an atomic read Y (with any memory order)
>>  Y reads the value written by X (or by the release sequence headed by X)
>>  Y is sequenced-before F in thread B
>>
>> In this case, all non-atomic and relaxed atomic stores that
>> happen-before X in thread A will be synchronized-with all non-atomic
>> and relaxed atomic loads from the same locations made in thread B
>> after F.
> 
> Where is the acquire fence or a load in the example?

In another thread.  :-)

-- 
Andrew Haley
Java Platform Lead Engineer
Red Hat UK Ltd. 
EAC8 43EB D3EF DB98 CC77 2FAD A5CD 6035 332F A671

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

[Thomas Schwinge]

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 15:47:30 +0200, I wrote:
> Ping.
> 
> On Fri, 22 Sep 2017 20:37:50 +0200, I wrote:
> > On Thu, 21 Sep 2017 12:18:39 -0600, Carlos O'Donell  
> > wrote:
> > > On 09/21/2017 11:56 AM, Richard Biener wrote:
> > > > On Thu, 21 Sep 2017 11:38:29 -0600, Carlos O'Donell  
> > > > wrote:
> > > > > On 09/21/2017 10:50 AM, Thomas Schwinge wrote:
> > > > > > So my question is, if I've gotten a patch reviewed by someone who 
> > > > > > is not
> > > > > > yet ;-) familiar with that new process, and I nevertheless want to
> > > > > > acknowledge their time invested in review by putting "Reviewed-by" 
> > > > > > into
> > > > > > the commit log, is it fine to do that if the reviewer just answered 
> > > > > > with
> > > > > > "OK" (or similar) instead of an explicit "Reviewed-by: NAME "
> > > > > > statement?
> > > > > You should instead ask the author to give their "Reviewed-by:" and 
> > > > > point
> > > > > out what the Reviewed-by statement means.
> > > > > 
> > > > > > That is, is it fine to assume that our current patch review's 
> > > > > > standard
> > > > > > "OK" (or similar) answer matches the more formal "Reviewer's 
> > > > > > statement of
> > > > > > oversight"?
> > > > > 
> > > > > Not yet.
> > > > 
> > > > I think given an OK from an official reviewer entitles you to commit
> > > > it indeed IS matching the formal statement. It better does...
> > 
> > I certainly understand your rationale, and do agree to that -- yet, I can
> > see how somebody might get offended if turning a casual "OK" into a
> > formal "Reviewed-by: NAME ", so...
> > 
> > > Isn't it better to be explicit about this; rather than assuming?
> > 
> > ..., yeah, that makes sense.
> > 
> > Anyway: aside from starting to use them, we should also document such new
> > processes, so we might do it as follows, where I had the idea that the
> > *submitter* 'should encourage the reviewer to "earn" this
> > acknowledgement'.
> > 
> > Gerald, OK to commit?  If approving this patch, please respond with
> > "Reviewed-by: NAME " so that your effort will be recorded.  See
> > .  There you go.  ;-)
> > 
> > Index: htdocs/contribute.html
> > ===
> > RCS file: /cvs/gcc/wwwdocs/htdocs/contribute.html,v
> > retrieving revision 1.87
> > diff -u -p -r1.87 contribute.html
> > --- htdocs/contribute.html  9 Apr 2015 21:49:31 -   1.87
> > +++ htdocs/contribute.html  22 Sep 2017 18:20:04 -
> > @@ -23,7 +23,7 @@ contributions must meet:
> >  Testing Patches
> >  Documentation Changes
> >  Web Site Changes
> > -Submitting Patches
> > +Preparing Patches
> >  Announcing Changes (to our Users)
> >  
> >  
> > @@ -164,7 +164,7 @@ file" mode of the validator.
> >  More about our web pages.
> >  
> >  
> > -Submitting Patches
> > +Preparing Patches
> >  
> >  Every patch must have several pieces of information, before we
> >  can properly evaluate it:
> > @@ -257,6 +257,71 @@ bzip2ed and uuencoded or encoded as a  >  acceptable, as long as the ChangeLog is still posted as plain text.
> >  
> >  
> > +
> > +Acknowledge Patch Review
> > +
> > +Patch review often is a time-consuming effort.  It is appreciated to
> > +  acknowledge this in the commit log.  We are adapting
> > +  the Reviewed-by: tag as established by the Linux kernel 
> > patch
> > +  review process.
> > +
> > +As this is not yet an established process in GCC, you, as the submitter,
> > +  should encourage the reviewer to "earn" this acknowledgement.  For 
> > example,
> > +  include the following in your patch submission:
> > +
> > +
> > +  If approving this patch, please respond with "Reviewed-by: NAME
> > +" so that your effort will be recorded.  See
> > +;.
> > +  
> > +
> > +
> > +For reference, reproduced from
> > +  the  > href="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v4.13#n560";>Linux
> > +  kernel 4.13's 
> > Documentation/process/submitting-patches.rst:
> > +
> > +
> > + > cite="https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v4.13#n560";>
> > +  Reviewed-by: [...] indicates that the patch has been reviewed
> > +and found acceptable according to the Reviewer's Statement:
> > +
> > +Reviewer's statement of oversight
> > +
> > +By offering my Reviewed-by: tag, I state that:
> > +
> > +(a) I have carried out a technical review of this patch to
> > +evaluate its appropriateness and readiness for inclusion [...].
> > +
> > +
> > +(b) Any problems, con

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

[Carlos O'Donell]

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,
> .

I've started using Reviewed-by: Carlos O'Donell 
and Signed-off-by: Carlos O'Donell  in all my
glibc reviews.

Since then I've seen 5 such items go into the git commit messages.

Progress? :-)

-- 
Cheers,
Carlos.

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

[Martin Sebor]

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,
.


Quoting from the Wiki:

   If approving this patch, please respond with "Reviewed-by:...

Often several people provide helpful feedback on patches that
only one person ultimately approves.  As per the GCC process,
the approver is also one of the maintainers for the area
affected by the patch, and so had to demonstrate the value of
their own contribution to the area by committing many high
quality changes of their own.  Their sustained and valuable
effort has already been recognized (they are prominently
mentioned in the MAINTAINERs file).  So without in any way
diminishing their continued contribution by reviewing and
approving other people's work in addition to making valuable
improvements of their own, I think by focusing on approvals,
the Reviewed-by proposal neglects to acknowledge the hard
work of all the others who contribute to the project.

Martin




Ping.

On Wed, 4 Oct 2017 15:47:30 +0200, I wrote:

Ping.

On Fri, 22 Sep 2017 20:37:50 +0200, I wrote:

On Thu, 21 Sep 2017 12:18:39 -0600, Carlos O'Donell  wrote:

On 09/21/2017 11:56 AM, Richard Biener wrote:

On Thu, 21 Sep 2017 11:38:29 -0600, Carlos O'Donell  wrote:

On 09/21/2017 10:50 AM, Thomas Schwinge wrote:

So my question is, if I've gotten a patch reviewed by someone who is not
yet ;-) familiar with that new process, and I nevertheless want to
acknowledge their time invested in review by putting "Reviewed-by" into
the commit log, is it fine to do that if the reviewer just answered with
"OK" (or similar) instead of an explicit "Reviewed-by: NAME "
statement?

You should instead ask the author to give their "Reviewed-by:" and point
out what the Reviewed-by statement means.


That is, is it fine to assume that our current patch review's standard
"OK" (or similar) answer matches the more formal "Reviewer's statement of
oversight"?


Not yet.


I think given an OK from an official reviewer entitles you to commit
it indeed IS matching the formal statement. It better does...


I certainly understand your rationale, and do agree to that -- yet, I can
see how somebody might get offended if turning a casual "OK" into a
formal "Reviewed-by: NAME ", so...


Isn't it better to be explicit about this; rather than assuming?


..., yeah, that makes sense.

Anyway: aside from starting to use them, we should also document such new
processes, so we might do it as follows, where I had the idea that the
*submitter* 'should encourage the reviewer to "earn" this
acknowledgement'.

Gerald, OK to commit?  If approving this patch, please respond with
"Reviewed-by: NAME " so that your effort will be recorded.  See
.  There you go.  ;-)

Index: htdocs/contribute.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/contribute.html,v
retrieving revision 1.87
diff -u -p -r1.87 contribute.html
--- htdocs/contribute.html  9 Apr 2015 21:49:31 -   1.87
+++ htdocs/contribute.html  22 Sep 2017 18:20:04 -
@@ -23,7 +23,7 @@ contributions must meet:
 Testing Patches
 Documentation Changes
 Web Site Changes
-Submitting Patches
+Preparing Patches
 Announcing Changes (to our Users)
 

@@ -164,7 +164,7 @@ file" mode of the validator.
 More about our web pages.


-Submitting Patches
+Preparing Patches

 Every patch must have several pieces of information, before we
 can properly evaluate it:
@@ -257,6 +257,71 @@ bzip2ed and uuencoded or encoded as a 

+
+Acknowledge Patch Review
+
+Patch review often is a time-consuming effort.  It is appreciated to
+  acknowledge this in the commit log.  We are adapting
+  the Reviewed-by: tag as established by the Linux kernel patch
+  review process.
+
+As this is not yet an established process in GCC, you, as the submitter,
+  should encourage the reviewer to "earn" this acknowledgement.  For example,
+  include the following in your patch submission:
+
+
+  If approving this patch, please respond with "Reviewed-by: NAME
+" so that your effort will be recorded.  See
+;.
+  
+
+
+For reference, reproduced from
+  the https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v4.13#n560";>Linux
+  kernel 4.13's Documentation/process/submitting-patches.rst:
+
+
+https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/process/submitting-patches.rst?h=v4.13#n560";>
+  Reviewed-by: [...] indicates that the patch has been reviewed
+and found acceptable according to the Reviewer's Statement:
+
+Reviewer's statement of oversight
+
+By offering my Reviewed-b

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

[Joseph Myers]

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,
> .

That wiki page refers to Reviewed-by as being about crediting reviewers.  
But the specification appears to be oriented to something else entirely 
(i.e. convincing a committer - in a Linux-kernel-like context with a very 
limited set of committers to a particular tree, much smaller than the set 
of reviewers - that a patch is worthy of commit).  It doesn't cover 
reviews that request changes, or only relate to part of a patch, or relate 
to a previous version of a patch - only the limited special case of a 
review approving the entirety of a patch as posted.  If the aim is credit, 
a substantially different specification is needed.

-- 
Joseph S. Myers
jos...@codesourcery.com

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

[Carlos O'Donell]

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
>> interested have a convenient handle to use,
>> .
> 
> That wiki page refers to Reviewed-by as being about crediting reviewers.  
> But the specification appears to be oriented to something else entirely 
> (i.e. convincing a committer - in a Linux-kernel-like context with a very 
> limited set of committers to a particular tree, much smaller than the set 
> of reviewers - that a patch is worthy of commit).  It doesn't cover 
> reviews that request changes, or only relate to part of a patch, or relate 
> to a previous version of a patch - only the limited special case of a 
> review approving the entirety of a patch as posted.  If the aim is credit, 
> a substantially different specification is needed.
 
This is the purpose of Acked-by: ...

Which we could also include.

linux/Documentation/process/submitting-patches.rst
...

Acked-by: does not necessarily indicate acknowledgement of the entire patch.
For example, if a patch affects multiple subsystems and has an Acked-by: from
one subsystem maintainer then this usually indicates acknowledgement of just
the part which affects that maintainer's code.  Judgement should be used here.
When in doubt people should refer to the original discussion in the mailing
list archives.

...

-- 
Cheers,
Carlos.

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

[Carlos O'Donell]

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
>> interested have a convenient handle to use,
>> .
> 
> That wiki page refers to Reviewed-by as being about crediting reviewers.  
> But the specification appears to be oriented to something else entirely 
> (i.e. convincing a committer - in a Linux-kernel-like context with a very 
> limited set of committers to a particular tree, much smaller than the set 
> of reviewers - that a patch is worthy of commit).  It doesn't cover 
> reviews that request changes, or only relate to part of a patch, or relate 
> to a previous version of a patch - only the limited special case of a 
> review approving the entirety of a patch as posted.  If the aim is credit, 
> a substantially different specification is needed.
 
If a person is requesting changes, they should after accepting the changes,
submit a 'Reviewed-by:' tag or 'Acked-by:' tag to indicate they are happy
with the results?

-- 
Cheers,
Carlos.

gcc-7-20171019 is now available

[gccadmin]

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-branch 
revision 253913

You'll find:

 gcc-7-20171019.tar.xzComplete GCC

  SHA256=d6188faf1ac5e88a12ab76c61a92a9f6e7936a715c3baf50f65e9ac0ec066d9d
  SHA1=1f9896b0547c2053466c331911b1e585a588985b

Diffs from 7-20171012 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-7
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.