RE: [EXTERNAL] Re: GCC selftest improvements
> From: David Malcolm > > Thanks Modi. > > Before looking at the updated patch in detail, we ought to also address the > legal prerequisites for contributing. > > Does your employer have legal paperwork in place with the FSF for such > contributions? See: > > https://gcc.gnu.org/contribute.html#legal > > I'm not sure what the threshold is for a contribution to be regarded as > "significant", but it seems that we ought to be fastidious here, given > historical > attitudes between Microsoft and the FLOSS community. > > (I'm not speaking on behalf of anyone other than myself here, as a GCC > maintainer, and I don't mean for this to come across as personal) > > Thanks > Dave Guidance from my side is to get an individual's license to proceed. Can you send me over the forms to get that done? Modi
Re: [EXTERNAL] Re: GCC selftest improvements
Thanks, Dave. We will work on the legal papers with FSF. -- Gaby From: David Malcolm Sent: Tuesday, February 25, 2020 2:10:59 PM To: Modi Mo ; l...@redhat.com ; Nicholas Krause ; Eric Gallager ; Pedro Alves Cc: Gabriel Dos Reis ; Andrew Dean ; gcc@gcc.gnu.org ; r...@cebitec.uni-bielefeld.de ; mikest...@comcast.net ; ja...@redhat.com ; Jonathan Wakely ; Richard Biener Subject: Re: [EXTERNAL] Re: GCC selftest improvements On Tue, 2020-02-25 at 19:58 +, Modi Mo wrote: > > On 2/12/20 8:53 PM, David Malcolm wrote: > > The patch will need an update to the docs; search for > > "Tools/packages necessary for building GCC" in > > gcc/doc/install.texi, which currently has some paragraphs labelled: > >@item ISO C++98 compiler > > that will need changing. > > Added this change in the attached patch. Thanks Modi. Before looking at the updated patch in detail, we ought to also address the legal prerequisites for contributing. Does your employer have legal paperwork in place with the FSF for such contributions? See: https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc.gnu.org%2Fcontribute.html%23legaldata=02%7C01%7Cgdr%40microsoft.com%7C78624c908d354c815f9d08d7ba3fa1f6%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C63718265478884sdata=8GiCH%2FijVByqeO6e9qdRw3C09o0Suh62Gf8kq2HYe%2B4%3Dreserved=0 I'm not sure what the threshold is for a contribution to be regarded as "significant", but it seems that we ought to be fastidious here, given historical attitudes between Microsoft and the FLOSS community. (I'm not speaking on behalf of anyone other than myself here, as a GCC maintainer, and I don't mean for this to come across as personal) Thanks Dave
Re: [EXTERNAL] Re: GCC selftest improvements
On Tue, 2020-02-25 at 19:58 +, Modi Mo wrote: > > On 2/12/20 8:53 PM, David Malcolm wrote: > > The patch will need an update to the docs; search for > > "Tools/packages necessary for building GCC" in > > gcc/doc/install.texi, which currently has some paragraphs labelled: > >@item ISO C++98 compiler > > that will need changing. > > Added this change in the attached patch. Thanks Modi. Before looking at the updated patch in detail, we ought to also address the legal prerequisites for contributing. Does your employer have legal paperwork in place with the FSF for such contributions? See: https://gcc.gnu.org/contribute.html#legal I'm not sure what the threshold is for a contribution to be regarded as "significant", but it seems that we ought to be fastidious here, given historical attitudes between Microsoft and the FLOSS community. (I'm not speaking on behalf of anyone other than myself here, as a GCC maintainer, and I don't mean for this to come across as personal) Thanks Dave
RE: [EXTERNAL] Re: GCC selftest improvements
> On 2/12/20 8:53 PM, David Malcolm wrote: > The patch will need an update to the docs; search for > "Tools/packages necessary for building GCC" in > gcc/doc/install.texi, which currently has some paragraphs labelled: >@item ISO C++98 compiler > that will need changing. Added this change in the attached patch. I looked through the rest of the docs folder for "C++98" mentions and found only those pertaining to using it in GCC rather than anything related to bootstrapping. Also did a grep for "C++98" in gcc as a whole and didn’t see any other places regarding bootstrapping. I modified how we check for C++11 to use "__cplusplus" since type_traits.h can be present even without full C++11 support. Testing on x86_64 on Ubuntu 18.04 with gcc 7.4.0 passes. Forcing bootstrap to use gcc 4.7 results in the following configure time error: **checking that the compiler supports c++11... configure: error: Building GCC requires a compiler that supports c++11, such as GCC 4.8.5 or newer** I believe RedHat has access to bootstrapping on a variety of platforms/native targets so if I can get someone to validate on those that would be great! That will also give a preview of what targets may have issues before this goes live. > From: gcc-ow...@gcc.gnu.org On Behalf Of Mike > Stump > Sent: Friday, February 14, 2020 12:50 PM > I think we should pick not on the basis something unspecific, rather, I'd list > the 3 5 or 9 systems we check against, and then pick the minimum of them. > Above I picked 7.4 because it's on 18.04. I think this makes for a better > policy as it's predicable, stable, and in 100 years, I don't think I see the > need > to change the policy. I agree with Mike on having a policy in place to guide future efforts in this area. I'm not certain what type of upgrade cadence is needed (check versioning every major Release? Every 2? Note: this doesn't have to be part of the policy) but something consistent means (echoing Mike) there's a default mechanism and a "schedule" of when things are likely to come down the pipeline. Also Segher earlier in the thread linked to a great list compiled by Arnd Bergmann that shows Linux recommendations for GCC versioning which looks like a reasonable set of systems to check against. Here's the link again for ease of finding: https://lore.kernel.org/lkml/CAK8P3a3JfUjm88CLqkvAmCoEA1FsmQ33sfHGK4=y5iuhwxe...@mail.gmail.com/ Changelog entry for this patch: ChangeLog: 2020-02-25 Di Mo * configure.ac: Change bootstrap to test for and require C++11 support * configure: regenerate * gcc/doc/install.texi: Change bootstrapping requirement to C++11 Modi c++11.patch Description: c++11.patch
Re: [EXTERNAL] Re: GCC selftest improvements
On Thu, 2020-02-13 at 22:18 +, Modi Mo wrote: > > On 2/12/20 8:53 PM, David Malcolm wrote: > > > Thanks for the patch. > > > > > > Some nitpicks: > > > > > > Timing-wise, the GCC developer community is focusing on gcc 10 > > > bugfixing right now (aka "stage 4" of the release cycle). So this > > > patch won't be suitable to commit to master until stage 1 of the > > > release cycle for gcc 11 (in April, hopefully). > > > > > Ah I should've looked a bit harder for timelines before asking > https://gcc.gnu.org/develop.html. Appreciate the response here! > > > > But yes, it's probably a good idea to get feedback on the patch given > > > the breadth of platforms we support. > > > > > > The patch will need an update to the docs; search for "Tools/packages > > > necessary for building GCC" in gcc/doc/install.texi, which currently > > > has some paragraphs labelled: > > >@item ISO C++98 compiler > > > that will need changing. > > > > > > I think Richi mentioned that the minimum gcc version should be 4.8.2 > > > as he recalled issues with .1, so maybe the error message and docs > > > should reflect that? > > > > > > https://gcc.gnu.org/ml/gcc/2019-10/msg00180.html > > > > > Segher here suggests 4.8.5 instead of 4.8.2: > https://gcc.gnu.org/ml/gcc/2019-11/msg00192.html > > Looking at release dates 4.8.5 was in June 2015 while 4.8.2 in October 2013 > which is a pretty big gap. I'd for moving the needle as far as we reasonably > can since this is a leap anyways. @Segher do you have a reason in mind for > the higher versioning? I doubt there's a lot of functional difference between 4.8.5 and 4.8.2. It really should just be bugfixes.While I'd prefer 4.8.5 over 4.8.2, I could live with either. Jeff
Re: [EXTERNAL] Re: GCC selftest improvements
Hi!
On Thu, Feb 13, 2020 at 10:18:27PM +, Modi Mo via gcc wrote:
> Segher here suggests 4.8.5 instead of 4.8.2:
> https://gcc.gnu.org/ml/gcc/2019-11/msg00192.html
I said as long as 4.8.5 works, it is fine with me. If 4.8.2 can be made
to work easily that is useful for the few people who would want to run
GCC 11 on Ubuntu 14 ("Trusty") (note this is EOL already).
> Looking at release dates 4.8.5 was in June 2015 while 4.8.2 in October 2013
> which is a pretty big gap. I'd for moving the needle as far as we reasonably
> can since this is a leap anyways. @Segher do you have a reason in mind for
> the higher versioning?
It's just that that is the latest 4.8 release, and it is what I see on
all still supported systems that use 4.8.
Arnd Bergmann made a neat overview showing this (and many other things):
https://lore.kernel.org/lkml/CAK8P3a3JfUjm88CLqkvAmCoEA1FsmQ33sfHGK4=y5iuhwxe...@mail.gmail.com/
Segher
RE: [EXTERNAL] Re: GCC selftest improvements
> On 2/12/20 8:53 PM, David Malcolm wrote: > > Thanks for the patch. > > > > Some nitpicks: > > > > Timing-wise, the GCC developer community is focusing on gcc 10 > > bugfixing right now (aka "stage 4" of the release cycle). So this > > patch won't be suitable to commit to master until stage 1 of the > > release cycle for gcc 11 (in April, hopefully). > > Ah I should've looked a bit harder for timelines before asking https://gcc.gnu.org/develop.html. Appreciate the response here! > > But yes, it's probably a good idea to get feedback on the patch given > > the breadth of platforms we support. > > > > The patch will need an update to the docs; search for "Tools/packages > > necessary for building GCC" in gcc/doc/install.texi, which currently > > has some paragraphs labelled: > >@item ISO C++98 compiler > > that will need changing. > > > > I think Richi mentioned that the minimum gcc version should be 4.8.2 > > as he recalled issues with .1, so maybe the error message and docs > > should reflect that? > > > > https://gcc.gnu.org/ml/gcc/2019-10/msg00180.html > > Segher here suggests 4.8.5 instead of 4.8.2: https://gcc.gnu.org/ml/gcc/2019-11/msg00192.html Looking at release dates 4.8.5 was in June 2015 while 4.8.2 in October 2013 which is a pretty big gap. I'd for moving the needle as far as we reasonably can since this is a leap anyways. @Segher do you have a reason in mind for the higher versioning? > > This may be opening a can of worms that should wait until we're done > > with the GCC 10 release, but there's probably an eventual wider > > discussion about what parts of C++11 we should use; pragmatically > > we're also limited by gengtype, the tool that scrapes the source code > > looking for garbage-collector markup, as that imposes a subset of C++ on us. > > > > I'd love to be able to rely on move semantics and thus use e.g. > > std::unique_ptr to capture more of our memory-management in the type > > system (we currently have a limited C++98-compatible implementation in > > the tree in the form of gnu::unique_ptr). > > > > How much of the stdlib do we see ourselves using? I think we've > > avoided std::string and the <<-style stream APIs; is there a case for > > using some of the other data structures? > > > > For reference, see > > > > https://gcc.gnu.org/codingconventions.html#Cxx_Conventions > > > > Hope this is constructive. > > Dave > Dave, > > I recall originally bringing up the move. From memory I recall that these were > the features we wanted or the people in the discussion wanted from C++11: > 1. Better Rounding and Stricter Integer and other number type rules 2. > Template > Aliasing 3. Auto and for each style loops 4. Move and R Value Semantics > Agreed on these features. I really like having access to 'for (const auto & foo : bar)' > There was a little discussion about lambas and anonymous functions but I don't > recall that being clear in terms of one of the above areas for sure. > > Maybe that helps, > Nick
Re: [EXTERNAL] Re: GCC selftest improvements
On 2/12/20 8:53 PM, David Malcolm wrote: On Thu, 2020-02-13 at 00:49 +, Modi Mo wrote: Hey all, I'm picking this work up from Andrew. Last time it was decided that the timing wasn't right to upgrade the minimum version to C++11. Is the timing better now to get this change through? I've attached the patch Andrew prepared. Can I get feedback on the change and some help testing on the broader range of architectures/platforms? Thanks, Modi Hi Modi Thanks for the patch. Some nitpicks: Timing-wise, the GCC developer community is focusing on gcc 10 bugfixing right now (aka "stage 4" of the release cycle). So this patch won't be suitable to commit to master until stage 1 of the release cycle for gcc 11 (in April, hopefully). But yes, it's probably a good idea to get feedback on the patch given the breadth of platforms we support. The patch will need an update to the docs; search for "Tools/packages necessary for building GCC" in gcc/doc/install.texi, which currently has some paragraphs labelled: @item ISO C++98 compiler that will need changing. I think Richi mentioned that the minimum gcc version should be 4.8.2 as he recalled issues with .1, so maybe the error message and docs should reflect that? https://gcc.gnu.org/ml/gcc/2019-10/msg00180.html This may be opening a can of worms that should wait until we're done with the GCC 10 release, but there's probably an eventual wider discussion about what parts of C++11 we should use; pragmatically we're also limited by gengtype, the tool that scrapes the source code looking for garbage-collector markup, as that imposes a subset of C++ on us. I'd love to be able to rely on move semantics and thus use e.g. std::unique_ptr to capture more of our memory-management in the type system (we currently have a limited C++98-compatible implementation in the tree in the form of gnu::unique_ptr). How much of the stdlib do we see ourselves using? I think we've avoided std::string and the <<-style stream APIs; is there a case for using some of the other data structures? For reference, see https://gcc.gnu.org/codingconventions.html#Cxx_Conventions (looks like that page would need an update also for the version bump; it's in the website git repo IIRC) Hope this is constructive. Dave Dave, I recall originally bringing up the move. From memory I recall that these were the features we wanted or the people in the discussion wanted from C++11: 1. Better Rounding and Stricter Integer and other number type rules 2. Template Aliasing 3. Auto and for each style loops 4. Move and R Value Semantics There was a little discussion about lambas and anonymous functions but I don't recall that being clear in terms of one of the above areas for sure. Maybe that helps, Nick
Re: [EXTERNAL] Re: GCC selftest improvements
On Thu, 2020-02-13 at 00:49 +, Modi Mo wrote: > Hey all, > > I'm picking this work up from Andrew. Last time it was decided that > the timing wasn't right to upgrade the minimum version to C++11. Is > the timing better now to get this change through? > > I've attached the patch Andrew prepared. Can I get feedback on the > change and some help testing on the broader range of > architectures/platforms? > > Thanks, > Modi Hi Modi Thanks for the patch. Some nitpicks: Timing-wise, the GCC developer community is focusing on gcc 10 bugfixing right now (aka "stage 4" of the release cycle). So this patch won't be suitable to commit to master until stage 1 of the release cycle for gcc 11 (in April, hopefully). But yes, it's probably a good idea to get feedback on the patch given the breadth of platforms we support. The patch will need an update to the docs; search for "Tools/packages necessary for building GCC" in gcc/doc/install.texi, which currently has some paragraphs labelled: @item ISO C++98 compiler that will need changing. I think Richi mentioned that the minimum gcc version should be 4.8.2 as he recalled issues with .1, so maybe the error message and docs should reflect that? https://gcc.gnu.org/ml/gcc/2019-10/msg00180.html This may be opening a can of worms that should wait until we're done with the GCC 10 release, but there's probably an eventual wider discussion about what parts of C++11 we should use; pragmatically we're also limited by gengtype, the tool that scrapes the source code looking for garbage-collector markup, as that imposes a subset of C++ on us. I'd love to be able to rely on move semantics and thus use e.g. std::unique_ptr to capture more of our memory-management in the type system (we currently have a limited C++98-compatible implementation in the tree in the form of gnu::unique_ptr). How much of the stdlib do we see ourselves using? I think we've avoided std::string and the <<-style stream APIs; is there a case for using some of the other data structures? For reference, see https://gcc.gnu.org/codingconventions.html#Cxx_Conventions (looks like that page would need an update also for the version bump; it's in the website git repo IIRC) Hope this is constructive. Dave
RE: [EXTERNAL] Re: GCC selftest improvements
Hey all, I'm picking this work up from Andrew. Last time it was decided that the timing wasn't right to upgrade the minimum version to C++11. Is the timing better now to get this change through? I've attached the patch Andrew prepared. Can I get feedback on the change and some help testing on the broader range of architectures/platforms? Thanks, Modi c++11.patch Description: c++11.patch
