This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]