Re: gcc-4.9-20160803 is now available

[Gerald Pfeifer]

On Wed, 3 Aug 2016, gccad...@gcc.gnu.org wrote:
> Snapshot gcc-4.9-20160803 is now available on
>   ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20160803/
> and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

Is it possible you missed installing the updated 
maintainer-scripts/crontab file in the gccadmin account, Richi?

I did that now (after svn up-ing the copy in ~/scripts in the 
gccadmin account, the version in SVN already had the change) 
and removed traces of this snapshot from gcc.gnu.org.

Gerald

Re: gcc-4.9-20160803 is now available

[Richard Biener]

On Thu, 4 Aug 2016, Gerald Pfeifer wrote:

> On Wed, 3 Aug 2016, gccad...@gcc.gnu.org wrote:
> > Snapshot gcc-4.9-20160803 is now available on
> >   ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20160803/
> > and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
> 
> Is it possible you missed installing the updated 
> maintainer-scripts/crontab file in the gccadmin account, Richi?

Hmm, I do remember doing svn up there so not sure how I messed up
(I did this when creating the RC).

> I did that now (after svn up-ing the copy in ~/scripts in the 
> gccadmin account, the version in SVN already had the change) 
> and removed traces of this snapshot from gcc.gnu.org.

Thanks,
Richard.

-- 
Richard Biener 
SUSE LINUX GmbH, GF: Felix Imendoerffer, Jane Smithard, Graham Norton, HRB 
21284 (AG Nuernberg)

Re: [gimplefe] "Unknown tree: c_maybe_const_expr" error while parsing conditional expression

[Prasad Ghangal]

On 2 August 2016 at 14:29, Richard Biener  wrote:
> On Mon, Aug 1, 2016 at 4:52 PM, Prasad Ghangal  
> wrote:
>> Hi,
>>
>> I am trying to replace c_parser_paren_condition (parser) in
>> c_parser_gimple_if_stmt by c_parser_gimple_paren_condition (parser) as
>> described in the patch
>>
>> I am trying test case
>> void __GIMPLE () foo ()
>> {
>>   int a;
>> bb_2:
>>   if (a == 2)
>> goto bb_3;
>>   else
>> goto bb_4;
>> bb_3:
>>   a_2 = 4;
>> bb_4:
>>   return;
>> }
>>
>> but it fails to parse gimple expression and produces error as
>> /home/prasad/test3.c: In function ‘foo’:
>> /home/prasad/test3.c:1:18: error: invalid operands in gimple comparison
>>  void __GIMPLE () foo ()
>>   ^~~
>> if (<<< Unknown tree: c_maybe_const_expr
>>
>>   a >>> == 2) goto bb_3; else goto bb_4;
>> /home/prasad/test3.c:1:18: internal compiler error: verify_gimple failed
>>
>> I failed to debug where it is setting to C_MAYBE_CONST_EXPR
>
> It's in parsing the binary expression.  Btw, you don't need lvalue_to_rvalue
> conversion or truthvalue conversion - source that would require this would
> not be valid GIMPLE.  Let me try to debug:
>
>
> (gdb) p debug_tree (cond.value)
>   type  size 
> unit size 
> align 32 symtab 0 alias set -1 canonical type 0x7688b7e0
> precision 32 min  max
> 
> pointer_to_this >
>
> arg 0  0x7688b7e0 int>
>
> arg 1  int>
> used SI file t.c line 3 col 7 size  0x76887ee8 32> unit size 
> align 32 context >>
> arg 1  0x7688b7e0 int> constant 2>
> t.c:5:9 start: t.c:5:7 finish: t.c:5:12>
> $5 = void
> (gdb) b ggc-page.c:1444 if result == 0x76997938
> Breakpoint 6 at 0x8a0d3e: file
> /space/rguenther/src/gcc_gimple_fe/gcc/ggc-page.c, line 1444.
> (gdb) run
>
> Breakpoint 6, ggc_internal_alloc (size=40, f=0x0, s=0, n=1)
> at /space/rguenther/src/gcc_gimple_fe/gcc/ggc-page.c:1444
> 1444  return result;
> (gdb) fin (a few times)
> Run till exit from #0  0x011821b7 in build2_stat (
> code=C_MAYBE_CONST_EXPR, tt=,
> arg0=, arg1=)
> at /space/rguenther/src/gcc_gimple_fe/gcc/tree.c:4466
> 0x0081d263 in c_wrap_maybe_const (expr=,
> non_const=false)
> at /space/rguenther/src/gcc_gimple_fe/gcc/c-family/c-common.c:4359
> 4359  expr = build2 (C_MAYBE_CONST_EXPR, TREE_TYPE (expr), NULL, expr);
> Value returned is $11 = (tree_node *) 0x76997938
> (gdb) up
> #1  0x007b8e81 in build_binary_op (location=176833, code=EQ_EXPR,
> orig_op0=,
> orig_op1=, convert_p=1)
> at /space/rguenther/src/gcc_gimple_fe/gcc/c/c-typeck.c:11549
> 11549   op0 = c_wrap_maybe_const (op0, !op0_maybe_const);
>
> and this is guarded by !in_late_binary_op (which also seems to guard folding).
> So I suggest to somewhere at the start of parsing to set in_late_binary_op to
> true for -fgimple.  Not sure if it works for everything, but you
> should have accumulated
> quite some tests for -fgimple in the testsuite to make sure it doesn't
> regress anything.
>
I did bootstrap build for the trunk and testing is in progress. How
can I test with -fgimple flag enabled?


Thanks,
Prasad
> The following works for me:
>
> diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
> index 70800a2..c8c087a 100644
> --- a/gcc/c/c-parser.c
> +++ b/gcc/c/c-parser.c
> @@ -2158,7 +2159,10 @@ c_parser_declaration_or_fndef (c_parser
> *parser, bool fndef_ok,
>
>if (gimple_body_p && flag_gimple)
> {
> + bool saved = in_late_binary_op;
> + in_late_binary_op = true;
>   c_parser_parse_gimple_body (parser);
> + in_late_binary_op = saved;
>   cgraph_node::finalize_function (current_function_decl, false);
>   timevar_pop (tv);
>   return;
>
>
> Richard.
>
>>
>> Thanks,
>> Prasad

Re: [gimplefe] "Unknown tree: c_maybe_const_expr" error while parsing conditional expression

[Richard Biener]

On Thu, Aug 4, 2016 at 1:31 PM, Prasad Ghangal  wrote:
> On 2 August 2016 at 14:29, Richard Biener  wrote:
>> On Mon, Aug 1, 2016 at 4:52 PM, Prasad Ghangal  
>> wrote:
>>> Hi,
>>>
>>> I am trying to replace c_parser_paren_condition (parser) in
>>> c_parser_gimple_if_stmt by c_parser_gimple_paren_condition (parser) as
>>> described in the patch
>>>
>>> I am trying test case
>>> void __GIMPLE () foo ()
>>> {
>>>   int a;
>>> bb_2:
>>>   if (a == 2)
>>> goto bb_3;
>>>   else
>>> goto bb_4;
>>> bb_3:
>>>   a_2 = 4;
>>> bb_4:
>>>   return;
>>> }
>>>
>>> but it fails to parse gimple expression and produces error as
>>> /home/prasad/test3.c: In function ‘foo’:
>>> /home/prasad/test3.c:1:18: error: invalid operands in gimple comparison
>>>  void __GIMPLE () foo ()
>>>   ^~~
>>> if (<<< Unknown tree: c_maybe_const_expr
>>>
>>>   a >>> == 2) goto bb_3; else goto bb_4;
>>> /home/prasad/test3.c:1:18: internal compiler error: verify_gimple failed
>>>
>>> I failed to debug where it is setting to C_MAYBE_CONST_EXPR
>>
>> It's in parsing the binary expression.  Btw, you don't need lvalue_to_rvalue
>> conversion or truthvalue conversion - source that would require this would
>> not be valid GIMPLE.  Let me try to debug:
>>
>>
>> (gdb) p debug_tree (cond.value)
>>  > type > size 
>> unit size 
>> align 32 symtab 0 alias set -1 canonical type 0x7688b7e0
>> precision 32 min  max
>> 
>> pointer_to_this >
>>
>> arg 0 > 0x7688b7e0 int>
>>
>> arg 1 > int>
>> used SI file t.c line 3 col 7 size > 0x76887ee8 32> unit size 
>> align 32 context >>
>> arg 1 > 0x7688b7e0 int> constant 2>
>> t.c:5:9 start: t.c:5:7 finish: t.c:5:12>
>> $5 = void
>> (gdb) b ggc-page.c:1444 if result == 0x76997938
>> Breakpoint 6 at 0x8a0d3e: file
>> /space/rguenther/src/gcc_gimple_fe/gcc/ggc-page.c, line 1444.
>> (gdb) run
>>
>> Breakpoint 6, ggc_internal_alloc (size=40, f=0x0, s=0, n=1)
>> at /space/rguenther/src/gcc_gimple_fe/gcc/ggc-page.c:1444
>> 1444  return result;
>> (gdb) fin (a few times)
>> Run till exit from #0  0x011821b7 in build2_stat (
>> code=C_MAYBE_CONST_EXPR, tt=,
>> arg0=, arg1=)
>> at /space/rguenther/src/gcc_gimple_fe/gcc/tree.c:4466
>> 0x0081d263 in c_wrap_maybe_const (expr=,
>> non_const=false)
>> at /space/rguenther/src/gcc_gimple_fe/gcc/c-family/c-common.c:4359
>> 4359  expr = build2 (C_MAYBE_CONST_EXPR, TREE_TYPE (expr), NULL, expr);
>> Value returned is $11 = (tree_node *) 0x76997938
>> (gdb) up
>> #1  0x007b8e81 in build_binary_op (location=176833, code=EQ_EXPR,
>> orig_op0=,
>> orig_op1=, convert_p=1)
>> at /space/rguenther/src/gcc_gimple_fe/gcc/c/c-typeck.c:11549
>> 11549   op0 = c_wrap_maybe_const (op0, !op0_maybe_const);
>>
>> and this is guarded by !in_late_binary_op (which also seems to guard 
>> folding).
>> So I suggest to somewhere at the start of parsing to set in_late_binary_op to
>> true for -fgimple.  Not sure if it works for everything, but you
>> should have accumulated
>> quite some tests for -fgimple in the testsuite to make sure it doesn't
>> regress anything.
>>
> I did bootstrap build for the trunk and testing is in progress. How
> can I test with -fgimple flag enabled?

You can do

make check-gcc RUNTESTFLAGS="--target_board=unix/-fgimple"

Richard.

>
> Thanks,
> Prasad
>> The following works for me:
>>
>> diff --git a/gcc/c/c-parser.c b/gcc/c/c-parser.c
>> index 70800a2..c8c087a 100644
>> --- a/gcc/c/c-parser.c
>> +++ b/gcc/c/c-parser.c
>> @@ -2158,7 +2159,10 @@ c_parser_declaration_or_fndef (c_parser
>> *parser, bool fndef_ok,
>>
>>if (gimple_body_p && flag_gimple)
>> {
>> + bool saved = in_late_binary_op;
>> + in_late_binary_op = true;
>>   c_parser_parse_gimple_body (parser);
>> + in_late_binary_op = saved;
>>   cgraph_node::finalize_function (current_function_decl, false);
>>   timevar_pop (tv);
>>   return;
>>
>>
>> Richard.
>>
>>>
>>> Thanks,
>>> Prasad

[GCC Steering Committee attention] [PING] [PING] [PING] libgomp: In OpenACC testing, cycle though $offload_targets, and by default only build for the offload target that we're actually going to test

[Thomas Schwinge]

Hi!

Ping.

It has now been more than three months (!) that I first submitted this,
without receiving any meaningful review.  (Apart from one initial
"deprecative" comment by Jakub, which I then repeatedly detailed on,
without receiving any further response.)
.

I suppose, if I weren't paid for paid for this, I would have run away
long ago, and would have looked for another project to contribute to.
:-(

I'm CCing the GCC Steering Committee here -- not necessarily only because
of this one patch, but generally, I think it's a bad situation that
apparently Jakub (who I acknowledge is always very busy with all kinds of
tasks) has de facto become the single reviewer of
OpenACC/OpenMP/offloading patches.  I'm certainly not going in any way to
disapprove Jakub's help, skills and experience, but I'm more and more
worried about this "bus factor" of one single person
().

As I'm unable (huh?) to find an email address to reach the GCC Steering
Committee, I'm CCing  as suggested on
, and David Edelsohn, who seems to
handle most of the visible communication of the GCC Steering Committee.

When raising a similar concern months ago, an answer as given (by Jakub
himself, if I remember correctly), was that in addition to him, all
Global Reviewers are welcome to review OpenACC/OpenMP/offloading patches.
But that doesn't help if that's then not happening in reality.  (With the
exception of Bernd, who then did review such patches for a while, but
also seems to have stopped with that again.)

To the best of my knowledge, I'm following the procedures correctly
(please tell me if I'm not!), including pinging patches regularly (once a
week, typically).

Help.  I'm just trying to contribute my share for keeping GCC alive and
relevant.  :-)

On Wed, 27 Jul 2016 18:03:32 +0200, I wrote:
> Ping.
> 
> On Wed, 20 Jul 2016 13:52:20 +0200, I wrote:
> > Ping.
> > 
> > On Wed, 13 Jul 2016 12:37:07 +0200, I wrote:
> > > As discussed before, "offloading compilation is slow; I suppose because
> > > of having to invoke several tools (LTO streaming -> mkoffload -> offload
> > > compilers, assemblers, linkers -> combine the resulting images; but I
> > > have not done a detailed analysis on that)".  For this reason it is
> > > beneficial (that is, it is measurable in libgomp testing wall time) to
> > > limit offload compilation to the one (in the OpenACC case) offload target
> > > that we're actually going to test (that is, execute).  Another reason is
> > > that -foffload=-fdump-tree-[...] produces clashes (that is,
> > > unpredicatable outcome) in the file names of offload compilations' dump
> > > files' names.  Here is a patch to implement that, to specify
> > > -foffload=[...] during libgomp OpenACC testing.  As that has been
> > > challenged before:
> > > 
> > > | [...] there actually is a difference between offload_plugins and
> > > | offload_targets (for example, "intelmic"
> > > | vs. "x86_64-intelmicemul-linux-gnu"), and I'm using both variables --
> > > | to avoid having to translate the more specific
> > > | "x86_64-intelmicemul-linux-gnu" (which we required in the test harness)
> > > | into the less specific "intelmic" (for plugin loading) in
> > > | libgomp/target.c.  I can do that, so that we can continue to use just a
> > > | single offload_targets variable, but I consider that a less elegant
> > > | solution.
> > > 
> > > OK for trunk?
> > > 
> > > commit 5fdb515826769ebb36bc5c49a3ffac4d17a8a589
> > > Author: Thomas Schwinge 
> > > Date:   Wed Jul 13 11:37:16 2016 +0200
> > > 
> > > libgomp: In OpenACC testing, cycle though $offload_targets, and by 
> > > default only build for the offload target that we're actually going to 
> > > test
> > > 
> > >   libgomp/
> > >   * plugin/configfrag.ac: Enumerate both offload plugins and 
> > > offload
> > >   targets.
> > >   (OFFLOAD_PLUGINS): Renamed from OFFLOAD_TARGETS.
> > >   * target.c (gomp_target_init): Adjust to that.
> > >   * testsuite/lib/libgomp.exp: Likewise.
> > >   (offload_targets_s, offload_targets_s_openacc): Remove 
> > > variables.
> > >   (offload_target_to_openacc_device_type): New proc.
> > >   (check_effective_target_openacc_nvidia_accel_selected)
> > >   (check_effective_target_openacc_host_selected): Examine
> > >   $openacc_device_type instead of $offload_target_openacc.
> > >   * Makefile.in: Regenerate.
> > >   * config.h.in: Likewise.
> > >   * configure: Likewise.
> > >   * testsuite/Makefile.in: Likewise.
> > >   * testsuite/libgomp.oacc-c++/c++.exp: Cycle through
> > >   $offload_targets (plus "disable") instead of
> > >   $offload_targets_s_openacc, and add "-foffload=$offload_target" 
> > > to
> > >   tagopt.
> > >   * testsuite/libgomp.oacc-c/c.exp: Likewi

Re: [GCC Steering Committee attention] [PING] [PING] [PING] libgomp: In OpenACC testing, cycle though $offload_targets, and by default only build for the offload target that we're actually going to te

[Manuel López-Ibáñez]

On 04/08/16 15:49, Thomas Schwinge wrote:

I suppose, if I weren't paid for paid for this, I would have run away
long ago, and would have looked for another project to contribute to.
:-(


You are a *paid* developer for one of the most active companies in the GCC 
community. Imagine how it feels for someone who just convinced their company to 
let them contribute for the first time or a volunteer:


https://gcc.gnu.org/ml/gcc/2010-04/msg00667.html
https://gcc.gnu.org/ml/gcc-patches/2016-08/msg00093.html

They will never bother to send an email like this and just silently go away. 
People do give up and move somewhere else based on this problem only. (And 
nowadays, this decision is quite easy to make or sell to one's boss)



OpenACC/OpenMP/offloading patches.  I'm certainly not going in any way to
disapprove Jakub's help, skills and experience, but I'm more and more
worried about this "bus factor" of one single person
().


This is a problem throughout GCC. We have a single C++ maintainer, a single 
part-time C maintainer, none? for libiberty, no regular maintainer for build 
machinery, and so on and so forth.


This has been a problem for a very long time, but it seems to be getting worse 
now that fewer contributors are doing most of the work.


Note that it has been more than one year now that just Clang has more monthly 
contributors than the whole GCC project:


https://www.openhub.net/p/_compare?project_0=GNU+Compiler+Collection&project_1=LLVM%2FClang+C+family+frontend&project_2=The+LLVM+Compiler+Infrastructure



... if I remember correctly), was that in addition to him, all
Global Reviewers are welcome to review OpenACC/OpenMP/offloading patches.
But that doesn't help if that's then not happening in reality.  (With the
exception of Bernd, who then did review such patches for a while, but
also seems to have stopped with that again.)


At least half of the global reviewers in MAINTAINERS never review any patches. 
Most of them are not active any more and presumably do not read GCC emails.


I'm not sure how to address this problem, but there is definitely a problem. 
Some ideas:


a) Follow LLVM's model and allow changes to be reviewed after commit.

Advantages: Faster turnaround, less frustration. No more effort than now, 
possibly less by not requiring pinging. etc.


Disadvantages: code may go unreviewed; churn in the tree because of iterative 
changes or reverts.


b) Anyone with svn-write powers can approve patches.

Advantages: More reviewers, faster turn around, less frustration. Distribute 
the work.
Disadvantages: Poor patches may get accepted interfering with the work from the 
most-active contributors. There is no real incentive to review patches, thus 
the actual situation may not change significantly.


c) Everybody have to get their patches reviewed, promote a "Review-by" economy.

Advantages: Actively encourage people to review each other patches. Distribute 
effort. Ideally, faster turn-around and less frustration.


Disadvantages: It may slow down people that were able to self-approve. 
Additional work for people that contribute a lot in finding reviews. People 
that contribute little have little motivation to review.


d) Delegate hierarchically. Module owners should seek and delegate to people 
with svn-write powers and ask for reviews in exchange of reviews.


Advantages: No loss in quality, distribute work, creates an economy of reviews.

Disadvantages: More work required from module owners to keep track of patches, 
reviews and possible reviewers. Possibly offset by not having to do in-depth 
reviews themselves.


Cheers,
Manuel.

Re: [GCC Steering Committee attention] [PING] [PING] [PING] libgomp: In OpenACC testing, cycle though $offload_targets, and by default only build for the offload target that we're actually going to te

[DJ Delorie]

Manuel Lpez-Ibñez  writes:

> none? for libiberty, no regular maintainer for build machinery,

Perhaps this is a sign that I should step down as maintainers for those?

Re: [GCC Steering Committee attention] [PING] [PING] [PING] libgomp: In OpenACC testing, cycle though $offload_targets, and by default only build for the offload target that we're actually going to te

[Manuel López-Ibáñez]

On 4 August 2016 at 21:27, DJ Delorie  wrote:
> Manuel Lpez-Ibñez  writes:
>
>> none? for libiberty, no regular maintainer for build machinery,
>
> Perhaps this is a sign that I should step down as maintainers for those?

I don't see how that helps. Neither my message nor Thomas's is a
criticism of people. The question is how to get more people to help
and how to improve the situation. For sure, everybody is doing the
best that they can with the time that they have.

Cheers,

Manuel.

Re: [GCC Steering Committee attention] [PING] [PING] [PING] libgomp: In OpenACC testing, cycle though $offload_targets, and by default only build for the offload target that we're actually going to te

[Manuel López-Ibáñez]

On 4 August 2016 at 21:34, Manuel López-Ibáñez  wrote:
> On 4 August 2016 at 21:27, DJ Delorie  wrote:
>> Manuel Lpez-Ibñez  writes:
>>
>>> none? for libiberty, no regular maintainer for build machinery,
>>
>> Perhaps this is a sign that I should step down as maintainers for those?
>
> I don't see how that helps. Neither my message nor Thomas's is a
> criticism of people. The question is how to get more people to help
> and how to improve the situation. For sure, everybody is doing the
> best that they can with the time that they have.

Another question is how to help existing maintainers such that they
are more motivated to review patches. Is it a lack of time? lack of
Interest in the project? do patches simply fall through the cracks? is
it a dead-lock of people waiting for each other to comment?

There were some comments by Richard and Eric here:
https://gcc.gnu.org/ml/gcc/2010-04/msg00736.html
but they do not seem to apply in this case.

Re: [GCC Steering Committee attention] [PING] [PING] [PING] libgomp: In OpenACC testing, cycle though $offload_targets, and by default only build for the offload target that we're actually going to te

[DJ Delorie]

Manuel Lpez-Ibñez  writes:
> I don't see how that helps. Neither my message nor Thomas's is a
> criticism of people. The question is how to get more people to help
> and how to improve the situation. For sure, everybody is doing the
> best that they can with the time that they have.

You complained that there were no libiberty maintainers (there are two)
or build maintainers (there are many).  As I am listed as one of each of
those, this makes me wonder if there's no longer a need for such people
(we're involved so infrequently that nobody notices) or that I'm just
not able to put enough effort into it to be noticed (which may be true
anyway).

Either way, this is a part of your "problem" that I can address
directly, so I'm doing so.

> This is a problem throughout GCC. We have a single C++ maintainer, a
> single part-time C maintainer, none? for libiberty, no regular
> maintainer for build machinery, and so on and so forth.

Re: [GCC Steering Committee attention] [PING] [PING] [PING] libgomp: In OpenACC testing, cycle though $offload_targets, and by default only build for the offload target that we're actually going to te

[DJ Delorie]

Manuel Lpez-Ibñez  writes:
> Another question is how to help existing maintainers such that they
> are more motivated to review patches. Is it a lack of time? lack of
> Interest in the project? do patches simply fall through the cracks? is
> it a dead-lock of people waiting for each other to comment?

In my case, I became a build/libiberty maintainer a long time ago (20
years or so), when DJGPP was a much more active project, and it made
sense for me to be involved in parts of GCC that were sensitve to the
needs of DOS and NTFS filesystems and OSs.  This is not the case any
more, and my justification for maintaining those parts of gcc have
evaporated.  Fortunately, a very minimal effort was involved to
continue.  However, since then, I've not only taken on maintainerships
in other areas (mostly backends, which I need to wean off of eventually)
but I've also switched groups at work, and am no longer focused on gcc
(I'm focused on glibc now).

Also, I've always been opposed to libiberty being a "catch-all" for
cross-useful functionality, so I'm anti-motivated to work on those
portions of libiberty that aren't strictly portability-layer-related
(specifically, the demangler, which I leave to Ian).

So... considering your big-picture-problem, where do I fit in?  How can
I make the big picture better, given what you now know about my
situtation?  What changes do you think would make sense?

Re: [GCC Steering Committee attention] [PING] [PING] [PING] libgomp: In OpenACC testing, cycle though $offload_targets, and by default only build for the offload target that we're actually going to te

[Manuel López-Ibáñez]

On 4 August 2016 at 22:01, DJ Delorie  wrote:
>
> Manuel Lpez-Ibñez  writes:
>> I don't see how that helps. Neither my message nor Thomas's is a
>> criticism of people. The question is how to get more people to help
>> and how to improve the situation. For sure, everybody is doing the
>> best that they can with the time that they have.
>
> You complained that there were no libiberty maintainers (there are two)
> or build maintainers (there are many).  As I am listed as one of each of
> those, this makes me wonder if there's no longer a need for such people
> (we're involved so infrequently that nobody notices) or that I'm just
> not able to put enough effort into it to be noticed (which may be true
> anyway).

My perception is that the "official" libiberty and build maintainers
rarely review patches anymore. See:
https://gcc.gnu.org/ml/gcc-patches/2016-07/msg01973.html and the lack
of follow-up.
Jeff Law seems to be doing most of the reviewing work nowadays in both
areas (and many others).

This is not a criticism of them. They are not obliged to review
anything and much less anything in particular. I'm sure there are many
reasons for their lack of involvement. I have basically not
contributed any code in almost a year. Just wanted to point out that
Thomas's email is not an isolated outlier.

The answer is not "let's delete them/ask them to step down". Even if
someone reviews one patch once in a decade, there is no point in
preventing them from doing so by removing them from MAINTAINERS. Maybe
they will become more active in the future. From my point of view,
they may stay in MAINTAINERS as long as they wish and any little help
is welcome.

Cheers,

Manuel.

gcc-6-20160804 is now available

[gccadmin]

Snapshot gcc-6-20160804 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/6-20160804/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-6-branch 
revision 239156

You'll find:

 gcc-6-20160804.tar.bz2   Complete GCC

  MD5=848f821e8500032f2c564ef41081481e
  SHA1=f192184ccab7836ac7a648a3cf66ad4c5765923a

Diffs from 6-20160728 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-6
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.