Re: GSoC 2018: Hrishikesh Kulkarni has been selected to work on LTO dumping tool

[Richard Biener]

On Wed, Apr 25, 2018 at 5:17 AM, Hrishikesh Kulkarni
 wrote:
> Hi,
>
> Thanks a lot for giving me this wonderful opportunity to work with GCC
> under your guidance and mentorship (GSOC 2018).
>
> Just a few starting queries
>
>1.
>
>As a starting point to read lto-object file, is it sufficient to only
>link with lto-object.c or shall I need other source files too ?

You will need a lot more source files - starting with libbackend.a is
probably easiest.  As said during the initial project discussion it
remains to be seen whether a fully standalone dump tool is
best or whether the actual work is to be done by lto1 and the dump
tool shall act merely as a driver around that and they communicate
via some special (set of) options to lto1.

IIRC we do not have any existing tool that builds trees or cgraph
nodes or reads gimple bodies, so picking pices that are required
is going to be "interesting" (and eventually will suggest some refactoring
to avoid pulling in unnecessary stuff).  You'll also run into issues expecting
some initialized global state.  So...

...for the first phase of experimenting with the code-base it's probably
easiest to add some testing option to gcc/lto/lang.opt and "do stuff"
within a if (flag_your_option) conditional from some point in
lto/lto.c:lto_main.

>2.
>
>Should the dump tool be under gcc or lto dir? Would I need to modify
>only gcc/Makefile.in to add entry for building the dump tool or any other
>Makefiles too ?

I'd say it most naturally would reside in gcc/lto/ and thus its Make-lang.in
would need to be adjusted.

>
> Also, I would proceed with copyright assignment as soon as I will receive
> the mentioned forms.
>
>
> Thanks,
>
> Hrishikesh
>
>
> On Tue, Apr 24, 2018 at 6:27 PM, Martin Jambor  wrote:
>
>> Hello,
>>
>> I am pleased to announce that Hrishikesh Kulkarni will be working on
>> "Textual Representation of LTO Object Files (Textual LTO dump tool
>> project)" as his Google Summer of Code 2018 project.  I believe I write
>> on behalf of everybody in the GCC community when I congratulate him and
>> wish him success in the upcoming work.  Hrishikesh's mentors are Martin
>> Liška and Jan Hubička, but the plan is to have most of the conversation
>> about the project on the mailing list and so I would like to encourage
>> everyone to help him out here if they can.
>>
>> According to the schedule of GSoC, we have entered "Community Bonding
>> period" which lasts until May 14th (when the first out of three "coding"
>> periods begin).  Hrishikesh, Martin and Honza will take over from me in
>> suggesting what technical things you should study/play with, but I'd
>> like to request that you make sure you get an FSF copyright assignment
>> quickly (see https://gcc.gnu.org/contribute.html#legal).  David, I
>> assume that Hrishikesh does not have the assignment yet, can you please
>> send him the necessary forms?  Hrishikesh, please fill them is when you
>> get and send them to FSF.  If at any moment it will appear that the
>> process got stuck, please let me know sooner rather than later.
>>
>> On a general note, GCC was given two student slots which we requested
>> after receiving two high-quality student proposals.  Unfortunately,
>> Sebastiaan has withdrawn from GSoC 2018 before selection was announced
>> and so we "only" have one student this year.
>>
>> I'm looking forward to the new tool,
>>
>> Martin
>>

GCC 8.0.1 Status Report (2018-04-25)

[Jakub Jelinek]

Status
==

We have reached zero P1 regressions today (and < 100 important
regressions) and branches/gcc-8-branch has been created;
GCC 8.1-rc1 will be built and announced later today.
The branch is now frozen for blocking regressions and documentation
fixes only, all changes to the branch require a RM approval now.

If no show stoppers appear, we'd like to release 8.1 late next week,
or soon after that, if any important issues are discovered and
fixed, rc2 could be released next week.

Quality Data


Priority  #   Change from last report
---   ---
P10   -  22
P2   79   -  25
P3   14   -   1
P4  173   -  10
P5   26
---   ---
Total P1-P3  93   -  48
Total   292   -  58


Previous Report
===

https://gcc.gnu.org/ml/gcc/2018-03/msg00247.html

GCC 9.0.0 Status Report (2018-04-25)

[Jakub Jelinek]

Status
==

The trunk has branched for the GCC 8 release and is now open
again for general development, stage 1.  Please consider not
disrupting it too much during the RC phase of GCC 8 so it
is possible to test important fixes for 8.1 on it.

Quality Data


Priority  #   Change from last report
---   ---
P13   -  19
P2  104
P3   23   +   8
P4  174   -   9
P5   26
---   ---
Total P1-P3 130   -  11
Total   330   -  20


Previous Report
===

https://gcc.gnu.org/ml/gcc/2018-03/msg00247.html

GCC 8.1 Release Candidate available from gcc.gnu.org

[Jakub Jelinek]

https://gcc.gnu.org/pub/gcc/snapshots/8.0.1-RC-20180425/
The first release candidate for GCC 8.1 is available from

 ftp://gcc.gnu.org/pub/gcc/snapshots/8.0.1-RC-20180425

and shortly its mirrors.  It has been generated from SVN revision 259636.

I have so far bootstrapped and tested the release candidate on
x86_64-linux and i686-linux.  Please test it and report any issues to
bugzilla.

If all goes well, I'd like to release 8.1 on Wednesday, May 2nd.

[RFC] Deprecate "implicit int" for main() in C++

[Jonathan Wakely]

G++ allows the 'main' function to be declared without a return type:

$ gcc-8 -x c++ - <<< 'main() { }'
:1:6: warning: ISO C++ forbids declaration of ‘main’ with no type 
[-Wreturn-type]

We enabled -Wreturn-type by default in GCC 8, so code using the
extension will get warnings even without -Wall now. Users might want
to use -Werror=return-type to ensure they aren't bitten by the new
optimizations that assume control never reaches the end of a non-void
function.

Should we deprecate the "implicit int" extension for GCC 9?

Deprecating it wouldn't mean we have to remove it any time soon, and
it could still be allowed by -fpermissive.

N.B. we also allow "implicit int" in system headers, which we might
need to continue doing because some OS headers are not C++-aware, and
users can't fix their OS headers. That isn't true for 'main' because
users control that, and can fix it, and fixing it has no downside.

Re: RFC: bash completion

[Martin Liška]

On 04/24/2018 06:27 PM, David Malcolm wrote:
> On Tue, 2018-04-24 at 16:45 +0200, Martin Liška wrote:
>> Hi.
>>
>> Some time ago, I investigated quite new feature of clang which
>> is support of --autocomplete argument. That can be run from bash
>> completion
>> script and one gets more precise completion hints:
>>
>> http://blog.llvm.org/2017/09/clang-bash-better-auto-completion-is.htm
>> l
>> https://www.youtube.com/watch?v=zLPwPdZBpSY
>>
>> I like the idea and I would describe how is that better to current
>> GCC completion
>> script sitting here:
>> https://github.com/scop/bash-completion/blob/master/completions/gcc
>>
>> 1) gcc -fsanitize=^ - no support for option enum values
>> 2) gcc -fno-sa^ - no support for negative options
>> 3) gcc --param=^ - no support for param names
>>
>> These are main limitations I see. I'm attaching working prototype,
>> which you
>> can test by installed GCC, setting it on $PATH and doing:
>> $ source gcc.sh
>>
>> Then bash completion is provided via the newly added option. Some
>> examples:
>>
>> 1)
>> $ gcc -fsanitize=
>> addressbounds enum   
>> integer-divide-by-zero nonnull-
>> attribute  pointer-
>> comparereturn shift-
>> base thread vla-bound
>> alignment  bounds-strict  float-cast-
>> overflowkernel-
>> address null   pointer-
>> overflow   returns-nonnull-attribute  shift-
>> exponent undefined  vptr
>> bool   builtinfloat-divide-
>> by-zero   leak   object-
>> sizepointer-
>> subtract   shift  signed-integer-
>> overflowunreachable
>>
>> 2)
>> $ gcc -fno-ipa-
>> -fno-ipa-bit-cp -fno-ipa-cp-alignment   -fno-ipa-
>> icf-fno-ipa-icf-variables  -fno-ipa-profile-fno-
>> ipa-pure-const -fno-ipa-reference  -fno-ipa-struct-reorg   
>> -fno-ipa-cp -fno-ipa-cp-clone   -fno-ipa-icf-
>> functions  -fno-ipa-matrix-reorg   -fno-ipa-pta-fno-ipa-
>> ra -fno-ipa-sra-fno-ipa-vrp
>>
>> 3)
>> $ gcc --param=lto-
>> lto-max-partition  lto-min-partition  lto-partitions
>>
>> 4)
>> gcc --param lto-
>> lto-max-partition  lto-min-partition  lto-partitions 
>>
>> The patch is quite lean and if people like, I will prepare a proper
>> patch submission. I know about some limitations that can be then
>> handled incrementally.
>>
>> Thoughts?
>> Martin
> 
> Overall, looks good (albeit with various nits).  I like how you're
> reusing the m_option_suggestions machinery from the misspelled options
> code.  There are some awkward issues e.g. arch-specific completions,
> lang-specific completions, custom option-handling etc, but given that
> as-is this patch seems to be an improvement over the status quo, I'd
> prefer to tackle those later.

I'm sending second version of the patch. I did isolation of 
m_option_suggestions machinery
to a separate file. Mainly due to selftests that are linked with cc1.

> 
> The patch doesn't have tests.  There would need to be some way to
> achieve test coverage for the completion code (especially as we start
> to tackle the more interesting cases).  I wonder what the best way to
> do that is; perhaps a combination of selftest and DejaGnu?  (e.g. what
> about arch-specific completions? what about the interaction with bash?
> etc)

For now I come up with quite some selftests. Integration with bash&DejaGNU
would be challenging.

> 
> A few nits:
> * Do we want to hardcode that logging path in gcc.sh?

Sure, that needs to be purged. Crucial question here is where the gcc.sh script
should live. Note that clang has it in: ./tools/clang/utils/bash-autocomplete.sh
and:

head -n1 ./tools/clang/utils/bash-autocomplete.sh
# Please add "source /path/to/bash-autocomplete.sh" to your .bashrc to use this.

Which is not ideal. I would prefer to integrate the script into:
https://github.com/scop/bash-completion/blob/master/completions/gcc

Thoughts?

> 
> * Looks like m_option_suggestions isn't needed for handling the "-
> param" case, so maybe put the param-handling case before the "Lazily
> populate m_option_suggestions" code.
> 
> * You use "l" ("ell") as a variable name in two places, which I don't
> like, as IMHO it's too close to "1" (one) in some fonts.

Fixed both notes.
Thanks for fast review.

Martin

> 
> Thanks
> Dave
> 

>From 80d34e28ac6db6e63a0efe7d389bd9bfde40e434 Mon Sep 17 00:00:00 2001
From: marxin 
Date: Fri, 23 Feb 2018 12:28:43 +0100
Subject: [PATCH] Come up with new --completion option.

---
 gcc.sh |  51 ++
 gcc/Makefile.in|   2 +-
 gcc/c-family/cppspec.c |   1 +
 gcc/common.opt |   4 +
 gcc/fortran/gfortranspec.c |   1 +
 gcc/gcc-mai

Re: RFC: bash completion

[Martin Liška]

On 04/24/2018 06:27 PM, David Malcolm wrote:
> The patch doesn't have tests.  There would need to be some way to
> achieve test coverage for the completion code (especially as we start
> to tackle the more interesting cases).  I wonder what the best way to
> do that is; perhaps a combination of selftest and DejaGnu?  (e.g. what
> about arch-specific completions? what about the interaction with bash?
> etc)

Maybe there's some hint how to test that:
https://brbsix.github.io/2015/11/29/accessing-tab-completion-programmatically-in-bash/

Martin

Re: [RFC] Deprecate "implicit int" for main() in C++

[Andrew Haley]

On 04/25/2018 01:23 PM, Jonathan Wakely wrote:

> We enabled -Wreturn-type by default in GCC 8, so code using the
> extension will get warnings even without -Wall now. Users might want
> to use -Werror=return-type to ensure they aren't bitten by the new
> optimizations that assume control never reaches the end of a
> non-void function.

But ISO C++ allows control to reach the end of main(), and
automagically returns 0.  I guess you didn't mean that, but your reply
was confusing.

N4659, Section 6.6.1 Para 5:

 If control flows off the end of the compound-statement of main, the
 effect is equivalent to a return with operand 0 (see also 18.3).

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

Re: [RFC] Deprecate "implicit int" for main() in C++

[Jason Merrill]

On Wed, Apr 25, 2018 at 9:53 AM, Andrew Haley  wrote:
> On 04/25/2018 01:23 PM, Jonathan Wakely wrote:
>
>> We enabled -Wreturn-type by default in GCC 8, so code using the
>> extension will get warnings even without -Wall now. Users might want
>> to use -Werror=return-type to ensure they aren't bitten by the new
>> optimizations that assume control never reaches the end of a
>> non-void function.
>
> But ISO C++ allows control to reach the end of main(), and
> automagically returns 0.  I guess you didn't mean that, but your reply
> was confusing.
>
> N4659, Section 6.6.1 Para 5:
>
>  If control flows off the end of the compound-statement of main, the
>  effect is equivalent to a return with operand 0 (see also 18.3).

Indeed, so that optimization doesn't affect main, because there is no
undefined behavior.

The warning by default seems sufficient to me.

Jason

Re: [RFC] Deprecate "implicit int" for main() in C++

[Andrew Haley]

On 04/25/2018 02:56 PM, Jason Merrill wrote:
> The warning by default seems sufficient to me.

Yes.  We've been bitten by this a few times, with mysterious crashes.
I'm not sure it even makes sense only to be a warning, but I guess
that's up to the C++ TC.

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

Re: [RFC] Deprecate "implicit int" for main() in C++

[Jonathan Wakely]

On 25/04/18 14:59 +0100, Andrew Haley wrote:

On 04/25/2018 02:56 PM, Jason Merrill wrote:

The warning by default seems sufficient to me.


Yes.  We've been bitten by this a few times, with mysterious crashes.
I'm not sure it even makes sense only to be a warning, but I guess
that's up to the C++ TC.


It's not always possible for the compiler to prove that flowing off
the end never happens, even if the program state ensures that it can't
(e.g. by all callers enforcing the function's preconditions
correctly). So making it ill-formed is deemed too draconian whenever
this gets discussed.

Re: [RFC] Deprecate "implicit int" for main() in C++

[Jonathan Wakely]

On 25/04/18 14:53 +0100, Andrew Haley wrote:

On 04/25/2018 01:23 PM, Jonathan Wakely wrote:


We enabled -Wreturn-type by default in GCC 8, so code using the
extension will get warnings even without -Wall now. Users might want
to use -Werror=return-type to ensure they aren't bitten by the new
optimizations that assume control never reaches the end of a
non-void function.


But ISO C++ allows control to reach the end of main(), and
automagically returns 0.  I guess you didn't mean that, but your reply
was confusing.

N4659, Section 6.6.1 Para 5:

If control flows off the end of the compound-statement of main, the
effect is equivalent to a return with operand 0 (see also 18.3).


Yes, I should have said "never reaches the end of a non-void function
other than main".

-Wreturn-type doesn't warn about flowing off the end of main, because
it's well-defined. There's definitely scope for confusion, because
-Wreturn-type gives the main function special treatment in two ways:

* Unlike normal functions, flowing off the end of main doesn't warn,
 because the standard defines what happens there.

* Unlike normal functions, G++ allows omitting the return type of
 main.
 This is a non-standard extension to C++ (implicit int return types
 are allowed by C89 but not by any version of C++).

What I'm proposing for deprecation is the non-standard extension that
allows:

main() { return 0; }

More concretely, deprecating it for a few releases would allow us to
apply the attached patch at some point in the future, so that instead
of:

rt.c:1:6: warning: ISO C++ forbids declaration of ‘main’ with no type 
[-Wreturn-type]
main() { return 0; }
 ^

We'd get:

rt.c:1:6: error: ISO C++ forbids declaration of 'main' with no type 
[-fpermissive]
main() { return 0; }
 ^

Re: [RFC] Deprecate "implicit int" for main() in C++

[Andrew Haley]

On 04/25/2018 03:04 PM, Jonathan Wakely wrote:
> On 25/04/18 14:59 +0100, Andrew Haley wrote:
>> On 04/25/2018 02:56 PM, Jason Merrill wrote:
>>> The warning by default seems sufficient to me.
>>
>> Yes.  We've been bitten by this a few times, with mysterious crashes.
>> I'm not sure it even makes sense only to be a warning, but I guess
>> that's up to the C++ TC.
> 
> It's not always possible for the compiler to prove that flowing off
> the end never happens, even if the program state ensures that it can't
> (e.g. by all callers enforcing the function's preconditions
> correctly). So making it ill-formed is deemed too draconian whenever
> this gets discussed.

Sure.  Having said that, the cases that bit me were those where control
always flowed off the end, i.e. the function contained no return statement.

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

Re: [RFC] Deprecate "implicit int" for main() in C++

[Jason Merrill]

On Wed, Apr 25, 2018 at 10:40 AM, Jonathan Wakely  wrote:
> On 25/04/18 14:53 +0100, Andrew Haley wrote:
>>
>> On 04/25/2018 01:23 PM, Jonathan Wakely wrote:
>>
>>> We enabled -Wreturn-type by default in GCC 8, so code using the
>>> extension will get warnings even without -Wall now. Users might want
>>> to use -Werror=return-type to ensure they aren't bitten by the new
>>> optimizations that assume control never reaches the end of a
>>> non-void function.
>>
>>
>> But ISO C++ allows control to reach the end of main(), and
>> automagically returns 0.  I guess you didn't mean that, but your reply
>> was confusing.
>>
>> N4659, Section 6.6.1 Para 5:
>>
>> If control flows off the end of the compound-statement of main, the
>> effect is equivalent to a return with operand 0 (see also 18.3).
>
>
> Yes, I should have said "never reaches the end of a non-void function
> other than main".
>
> -Wreturn-type doesn't warn about flowing off the end of main, because
> it's well-defined. There's definitely scope for confusion, because
> -Wreturn-type gives the main function special treatment in two ways:
>
> * Unlike normal functions, flowing off the end of main doesn't warn,
>  because the standard defines what happens there.
>
> * Unlike normal functions, G++ allows omitting the return type of
>  main.
>  This is a non-standard extension to C++ (implicit int return types
>  are allowed by C89 but not by any version of C++).
>
> What I'm proposing for deprecation is the non-standard extension that
> allows:
>
> main() { return 0; }
>
> More concretely, deprecating it for a few releases would allow us to
> apply the attached patch at some point in the future, so that instead
> of:
>
> rt.c:1:6: warning: ISO C++ forbids declaration of ‘main’ with no type
> [-Wreturn-type]
> main() { return 0; }
>  ^
>
> We'd get:
>
> rt.c:1:6: error: ISO C++ forbids declaration of 'main' with no type
> [-fpermissive]
> main() { return 0; }
>  ^

I'm still not sure what the advantage is of changing the warning to an
error, but I suppose I wouldn't object either.

Jason

Re: [RFC] Deprecate "implicit int" for main() in C++

[Jonathan Wakely]

On 25/04/18 16:30 +0100, Andrew Haley wrote:

On 04/25/2018 03:04 PM, Jonathan Wakely wrote:

On 25/04/18 14:59 +0100, Andrew Haley wrote:

On 04/25/2018 02:56 PM, Jason Merrill wrote:

The warning by default seems sufficient to me.


Yes.  We've been bitten by this a few times, with mysterious crashes.
I'm not sure it even makes sense only to be a warning, but I guess
that's up to the C++ TC.


It's not always possible for the compiler to prove that flowing off
the end never happens, even if the program state ensures that it can't
(e.g. by all callers enforcing the function's preconditions
correctly). So making it ill-formed is deemed too draconian whenever
this gets discussed.


Sure.  Having said that, the cases that bit me were those where control
always flowed off the end, i.e. the function contained no return statement.


I forget the "return *this;" in assignment operators embarrassingly
often. So often I've even contemplated a proposal to define flowing
off the end of an assignment operator equivalent to "return *this;"

Re: [RFC] Deprecate "implicit int" for main() in C++

[David Malcolm]

On Wed, 2018-04-25 at 16:54 +0100, Jonathan Wakely wrote:
> On 25/04/18 16:30 +0100, Andrew Haley wrote:
> > On 04/25/2018 03:04 PM, Jonathan Wakely wrote:
> > > On 25/04/18 14:59 +0100, Andrew Haley wrote:
> > > > On 04/25/2018 02:56 PM, Jason Merrill wrote:
> > > > > The warning by default seems sufficient to me.
> > > > 
> > > > Yes.  We've been bitten by this a few times, with mysterious
> > > > crashes.
> > > > I'm not sure it even makes sense only to be a warning, but I
> > > > guess
> > > > that's up to the C++ TC.
> > > 
> > > It's not always possible for the compiler to prove that flowing
> > > off
> > > the end never happens, even if the program state ensures that it
> > > can't
> > > (e.g. by all callers enforcing the function's preconditions
> > > correctly). So making it ill-formed is deemed too draconian
> > > whenever
> > > this gets discussed.
> > 
> > Sure.  Having said that, the cases that bit me were those where
> > control
> > always flowed off the end, i.e. the function contained no return
> > statement.
> 
> I forget the "return *this;" in assignment operators embarrassingly
> often. So often I've even contemplated a proposal to define flowing
> off the end of an assignment operator equivalent to "return *this;"

Could/should we offer a fix-it hint for such cases?

Re: [RFC] Deprecate "implicit int" for main() in C++

[Jonathan Wakely]

On 25/04/18 12:22 -0400, David Malcolm wrote:

On Wed, 2018-04-25 at 16:54 +0100, Jonathan Wakely wrote:

On 25/04/18 16:30 +0100, Andrew Haley wrote:
> On 04/25/2018 03:04 PM, Jonathan Wakely wrote:
> > On 25/04/18 14:59 +0100, Andrew Haley wrote:
> > > On 04/25/2018 02:56 PM, Jason Merrill wrote:
> > > > The warning by default seems sufficient to me.
> > >
> > > Yes.  We've been bitten by this a few times, with mysterious
> > > crashes.
> > > I'm not sure it even makes sense only to be a warning, but I
> > > guess
> > > that's up to the C++ TC.
> >
> > It's not always possible for the compiler to prove that flowing
> > off
> > the end never happens, even if the program state ensures that it
> > can't
> > (e.g. by all callers enforcing the function's preconditions
> > correctly). So making it ill-formed is deemed too draconian
> > whenever
> > this gets discussed.
>
> Sure.  Having said that, the cases that bit me were those where
> control
> always flowed off the end, i.e. the function contained no return
> statement.

I forget the "return *this;" in assignment operators embarrassingly
often. So often I've even contemplated a proposal to define flowing
off the end of an assignment operator equivalent to "return *this;"


Could/should we offer a fix-it hint for such cases?


Yes. For the general "missing return" that -Wreturn-type warns about
we can't know what a sensible return value would be. For assignment
operators 99.999% of them return *this and so a fix-it suggestion to
add exactly that would be good. This works:

@@ -15869,6 +15851,12 @@ finish_function (bool inline_p)
{
  warning (OPT_Wreturn_type,
  "no return statement in function returning non-void");
+  if (DECL_NAME (fndecl) == assign_op_identifier)
+   {
+ rich_location richloc (line_table, input_location);
+ richloc.add_fixit_insert_before (input_location, "return *this;");
+ inform (&richloc, "Oi, Wakely, you forgot to return something");
+   }
  TREE_NO_WARNING (fndecl) = 1;
}


But it should really check if *this is convertible to the return type,
just in case we have something unusual like:

struct X { int operator=(int) { } };

Re: [RFC] Deprecate "implicit int" for main() in C++

[Nathan Sidwell]

On 04/25/2018 12:45 PM, Jonathan Wakely wrote:


@@ -15869,6 +15851,12 @@ finish_function (bool inline_p)
     {
   warning (OPT_Wreturn_type,
   "no return statement in function returning non-void");
+  if (DECL_NAME (fndecl) == assign_op_identifier)


IDENTIFIER_ASSIGN_OP_P (DECL_NAME (fndecl)), so += and friends are also 
caught?


nathan

--
Nathan Sidwell

Re: [RFC] Deprecate "implicit int" for main() in C++

[Jonathan Wakely]

On 25/04/18 13:13 -0400, Nathan Sidwell wrote:

On 04/25/2018 12:45 PM, Jonathan Wakely wrote:


@@ -15869,6 +15851,12 @@ finish_function (bool inline_p)
    {
  warning (OPT_Wreturn_type,
  "no return statement in function returning non-void");
+  if (DECL_NAME (fndecl) == assign_op_identifier)


IDENTIFIER_ASSIGN_OP_P (DECL_NAME (fndecl)), so += and friends are 
also caught?


Thanks. I've included that in my patch and attached it to PR 85523.

Re: GCC 8.1 Release Candidate available from gcc.gnu.org

[Bill Seurer]

On 04/25/2018 05:04 AM, Jakub Jelinek wrote:

https://gcc.gnu.org/pub/gcc/snapshots/8.0.1-RC-20180425/
The first release candidate for GCC 8.1 is available from

  ftp://gcc.gnu.org/pub/gcc/snapshots/8.0.1-RC-20180425

and shortly its mirrors.  It has been generated from SVN revision 259636.

I have so far bootstrapped and tested the release candidate on
x86_64-linux and i686-linux.  Please test it and report any issues to
bugzilla.

If all goes well, I'd like to release 8.1 on Wednesday, May 2nd.



I bootstrapped and tested it on powerpc64 both LE (power 8 and power 9) 
and BE (power 8 and power 7) and it looks good.


--

-Bill Seurer

MIPS maintainership

[Moore, Catherine]

Hi all,

I need to resign as maintainer for the MIPS port.  My work commitments have 
taken me in a different direction and as a result I haven't been able to 
actively participate over the last year.  I don't see that changing anytime 
soon.  I hope that someone with the interest and the time is available and will 
volunteer.

Thanks,
Catherine

gcc-6-20180425 is now available

[gccadmin]

Snapshot gcc-6-20180425 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/6-20180425/
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 259657

You'll find:

 gcc-6-20180425.tar.xzComplete GCC

  SHA256=8a48e03ae99e7fe3143615bb1fa243949f8e256969f9866b9238ae8f4772e18f
  SHA1=a7519b696c9c9af1747b661221fbbc77a9431b39

Diffs from 6-20180418 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.

I'm waiting for your response

[Vincent Forbes via Nextdoor]

  Vincent Forbes has invited you to join Nextdoor.


Nextdoor is a private social network that helps neighbors connect with each 
other to build stronger communities.

To accept your invitation, follow the link below:
https://nextdoor.com/invitation/?i=ggkkfghlzxggthdsqdsl&stage=2

---
This message is intended for gcc@gcc.gnu.org and promotes membership in a free 
neighborhood social network. To stop receiving email reminders about this 
invitation, use the following link:
https://nextdoor.com/generic_nm_unsub/?k=b7682416fa2fc3e&e=gcc%40gcc.gnu.org&t=0

Nextdoor, 875 Stevenson Street, Suite 700, San Francisco, CA 94103