Target maintainers: doc/install.texi love and care
I noticed that the target-specific sections in doc/install.texi need a little lover and care. It would be great could you have a look and streamline/update before the GCC 7 release. Thanks! Also, I'm offering help around one particular aspect I noticed: References to dependencies on really, really old versions of binutils (talking 10+ years here) which I think we can remove. Let me follow-up with some of you with concrete suggestions around that. Gerald
Design question LWG 2861: basic_string should require that charT match traits::char_type
I'm now working on
http://cplusplus.github.io/LWG/lwg-defects.html#2861
The new wording state is now equivalent to basic_string_view, whose
current implementation doesn't bother verifying the requirement, so
this code (which as UB) currently compiles just fine:
#include
#include
struct MyTraits : std::char_traits
{
typedef unsigned char char_type;
};
int main()
{
std::basic_string my_string;
std::basic_string_view my_string_view;
}
So the least I could do is just - nothing. But it seems to me that we
could protect users from doing such silly things by adding a
static_assert to both basic_string and basic_string_view, the former
being equivalent to
#if __cplusplus >= 201103L
static_assert(__are_same::value,
"traits_type::char_type must be equal to _CharT");
#endif
and the latter an unconditional
static_assert(is_same::value,
"traits_type::char_type must be equal to _CharT");
Would you agree with that course of action?
Thanks,
- Daniel
Re: terminology: zero character vs. null character
On Fri, 10 Mar 2017, Manuel López-Ibáñez wrote: >> I am currently translating GCC into German. During that, I noticed that >> in some places the term "zero character" means '\0'. The official term >> though is "null character", as per the C standard. > I don't see anything explicit here: https://gcc.gnu.org/codingconventions.html > But I believe we follow standards' language and it should always be "null > character". Agreed. Joseph, do you also agree (and with the patch below to document this)? Gerald Index: codingconventions.html === RCS file: /cvs/gcc/wwwdocs/htdocs/codingconventions.html,v retrieving revision 1.79 diff -u -r1.79 codingconventions.html --- codingconventions.html 1 Mar 2017 12:53:57 - 1.79 +++ codingconventions.html 12 Mar 2017 21:26:56 - @@ -439,6 +439,11 @@ +"null character" +"zero character" + + + "Objective-C" "Objective C"
Re: November 2016 GNU Toolchain Update
On Tue, 15 Nov 2016, Nick Clifton wrote: > That's all for now. Hopefully the next update will be a bit sooner in > arriving. Thanks for that update, Nick. Surely interesting reading. Are you planning another update for March or so? ;-) On Wed, 16 Nov 2016, Joseph Myers wrote: > Many of the GCC features listed here are not mentioned in > gcc-7/changes.html. We all need to expand that to be more thorough in > covering features that are new in GCC 7 compared to GCC 6. In the meantime there have been many additions to gcc-7/changes.html, and I believe except for + -Wbool-operation warns about suspicious operations on expressions of a boolean type. For instance, bitwise negation of a boolean is very likely a bug in the program. For C, this warning also warns about incrementing or decrementing a boolean, which rarely makes sense. everything should be more or less covered now. Still, additions very welcome, guys. Let me know if you need help. Gerald
gcc-7-20170312 is now available
Snapshot gcc-7-20170312 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/7-20170312/ 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/trunk revision 246079 You'll find: gcc-7-20170312.tar.bz2 Complete GCC SHA256=2acc6f5cf4b6396009f4d6476efb8189213d6e85c39dd3f55b38e3a0498be509 SHA1=6ebee5f126bf92c43469a4be1650701ad26e883d Diffs from 7-20170305 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.
PATCH for Re: Release notes for GCC 7?
On Wed, 24 Aug 2016, Richard Biener wrote: > We've been creating those lazily over the last decade. We can change > that, an entry for releasing.html is appreciated then so we don't forget. And here we go, in time for the release of GCC 7 / branching of GCC 8. (Except, this time I went ahead and already created gcc-8/changes.html so that you guys don't have to worry about that. ;-) Note, I added this to branching.html, not releasing.html, not the least since branching.html already had the creation of other web pages for the new release series and that also seems the more appropriate point time- wise. Agreed? Gerald Index: branching.html === RCS file: /cvs/gcc/wwwdocs/htdocs/branching.html,v retrieving revision 1.32 diff -u -r1.32 branching.html --- branching.html 28 Jun 2014 10:34:16 - 1.32 +++ branching.html 12 Mar 2017 22:37:59 - @@ -7,6 +7,8 @@ This page documents the procedure for making a new release branch. +Preparations + Execute the following commands, substituting appropriate version numbers: @@ -38,15 +40,25 @@ for the next major release in the wwwdocs repository and populate it with initial copies of changes.html and criteria.html. + -Add index.html and buildstat.html pages -to the directory corresponding to the newly created release branch. -Update the toplevel buildstat.html accordingly. +Web Site Updates + + +Add index.html and changes.html pages +based on the previous release branch to the directory corresponding to +the newly created release branch. + +Add buildstat.html and update the toplevel +buildstat.html accordingly. Update the toplevel index.html page to show the new active release branch, the current release series, and active development (mainline). Update the version and development stage for mainline. + + Update maintainer-scripts/crontab on the mainline by adding an entry to make snapshots of the new branch and adjusting the version number of the mainline snapshots. @@ -67,7 +79,11 @@ Send them to the translation project if no snapshot of this version was sent during development stage 3 or 4. + +Bugzilla Updates + + Create new versions in Bugzilla corresponding to the new mainline version. This can be accomplished by choosing "products", choosing "gcc", and editing the versions. Please do not delete old @@ -85,7 +101,6 @@ Ask Daniel Berlin to adjust all PRs with the just-branched version in their summary to also contain the new version corresponding to mainline. -
Diagnostics that should not be translated
Hi,
the gcc.pot file currently contains more than 12000 messages to be
translated, which is a very high number. Many of these messages are
diagnostics, and they can be categorized as follows:
* errors in user programs, reported via error ()
* additional info for internal errors, reported via error ()
* internal errors, reported via gfc_internal_error ()
* others
In my opinion, there is no point in having internal error messages
translated, since their only purpose is to be sent back to the GCC
developers, instead of being interpreted and acted upon by the GCC user.
By not translating the internal errors, the necessary work for
translators can be cut down by several hundred messages.
Therefore the internal errors should not be translated at all.
https://gcc.gnu.org/codingconventions.html#Diagnostics currently
mentions a few ways of emitting diagnostics, but there is no way to
produce untranslated diagnostics. Therefore I'd like to have a new
function error_no_i18n that is used instead of error for nonfatal
internal errors, like this:
@code{error_no_i18n} is for diagnostics that are printed before invoking
internal_error. They are not translated.
(I don't care about the exact function name, though. :))
Regards,
Roland
Re: Target maintainers: doc/install.texi love and care
On Sun, 12 Mar 2017 04:27:26 PDT (-0700), ger...@pfeifer.com wrote: > I noticed that the target-specific sections in doc/install.texi > need a little lover and care. It would be great could you have > a look and streamline/update before the GCC 7 release. I looked at our stuff (RISC-V) and there's almost nothing in there. Is there something I should add? I looked at the aarch64 stuff in the "host/target specific issues start here" section and there's some notes about binutils-2.24. We'll require binutils-2.28 (the first version that we're upstream in), I can add a note in that section about RISC-V as well if you think it's appropriate.
