Re: Diagnostics that should not be translated
On 03/12/2017 04:51 PM, Roland Illig wrote:
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.
AFAIK, internal errors are reported using the internal_error
or internal_error_no_backtrace APIs.
Would using the existing internal_error{,no_backtrace}, and
sorry work for this? (I.e., not translating those.) If my
count is right there are nearly 500 calls to these three in
GCC sources so I'm not sure that would put enough of a dent
in the 12K messages to translate but I'm even less sure that
adding yet another API would do even that much.
There are 20-some-odd functions to report diagnostics in GCC
(counting those in diagnostic-core.h). I haven't used them all
or even understand all their differences and use cases yet so
I would rather no add more to the list if it can be helped.
Martin
gcc-5-20170314 is now available
Snapshot gcc-5-20170314 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/5-20170314/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 5 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5-branch revision 246145 You'll find: gcc-5-20170314.tar.bz2 Complete GCC SHA256=f5939b41b7694ca8fcf8557d9265ceda014db5f76c9f91601e9f8ec9fa8330fb SHA1=3210d8798c8e8a607a850767ecda3fc886c5043a Diffs from 5-20170307 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-5 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.
Re: [PATCH] RISC-V documentation cleanups
On Mon, 13 Mar 2017, Palmer Dabbelt wrote: > A recent mailing list post about install.texi cleanup suggested I > take a look at ours, and there were a few problems: > > * No table of contents entries > * Not alphabetically ordered > * Missing a note about requiring binutils-2.28 This looks fine with a few changes, thank you. Perhaps a bit repetitive? I'm wondering, would it make sense to have general riscv64-*-* entries that cover the general items? > 2017-03-13 Palmer Dabbelt > * doc/install.texi (Specific) : Add table of contents > link. > : Likewise. > : Likewise > : Likewise. Here I'd just say * doc/install.texi (Specific): Add foo, bar, didl, doo to the table of contents. > : Add a note about requiring binutils-2.28. Here and in the text, binutils 2.28 (without the dash). Approved. Gerald PS: We usually send patches to the gcc-patches@ list.
Re: RFC: Treat plugins as first class citizens
On 03/14/2017 07:44 AM, Richard Biener wrote: On Tue, Mar 14, 2017 at 2:38 PM, Nick Clifton wrote: Hi Richard, I was thinking that it would be nice to make plugins a "first-class citizen" in the gcc world by having a proper directory structure and integration into the rest of gcc. I believe plugins are currently a hack due to the lack of a clearly defined API to access GCC internals. Unless that is resolved somehow, see various half-way finished patch prototypes from two (or three?) years ago treating them as "first class" would be a blatant labeling lie. It's at most "first class mess". One of the goals of this proposal is to help combat this mess by making plugins a respected and official part of gcc. Such that, when the plugins fail to build, test or install, the problem would be considered a blocker and it would have to be fixed before the sources are released. At the moment nobody (well almost nobody) cares about The most obvious "proof" of the broken current state is that plugins are broken all the time because at make install time we forget to install another of the GCC internal headers. The bug is of course that we need those at all. Presumably you are talking about the ability to build plugins using an installed version of gcc ? This is separate from this proposal which is about building and installing plugins at the same time that gcc is built and installed. One possible way to address this problem is to state that plugins should not be built outside of a gcc build tree. Or at least any plugins that require intimate access to gcc's internal headers. If you build sth as part of GCC then why is it a plugin in the first place? I think we want plugins for domain-specific analysis. Having a repository for well developed checkers makes sense to me, particularly for checkers which are useful across projects. One such checker would be Aldy's unencrypted function pointer checker which finds unencrypted function pointers living in memory (which are ripe for exploitation by hackers). It's currently most useful for glibc which has policies WRT unencrypted function pointers, but could well be used by other projects. We could also build checkers for resource allocation/deallocation, locking/unlocking, etc. I think those checkers are naturally plugins. jeff
Re: [wwwdocs, PATCH] C++ terminology: the One Definition Rule in diagnostics
On 03/14/2017 08:18 AM, David Malcolm wrote:
Looking at PR ipa/8, which notes that ipa-devirt.c has two trailing
spaces in:
if (warning_at (
DECL_SOURCE_LOCATION(TYPE_NAME (DECL_CONTEXT (vtable->decl))),
OPT_Wodr,
"virtual table of type %qD violates "
"one definition rule ",
DECL_CONTEXT (vtable->decl)))
and thus emits:
foo.cc: virtual table of type 'foo' violates one definition rule
...I think the wording here is a little confusing to a novice C++
coder: it could be misread that the compiler is complaining that there
are "definition rules", and that one of them has been somehow violated
("why aren't you telling me which one?"), as opposed to the correct
reading, that there is a rule that there must be one definition.
Heh. I never would have thought of that. But you're right.
It reminds me just how wide-spread the convention of dropping
articles is in diagnostics. Would it make sense to put in
place a guideline to use them consistently?
https://gcc.gnu.org/wiki/DiagnosticsGuidelines
There are 5 such diagnostics, all in ipa-devirt.c.
So I think the wording could be improved by adding a "the", and maybe
capitalizing, to make it:
foo.cc: virtual table of type 'foo' violates the One Definition Rule
(giving a big hint to the user that the "One Definition Rule" is the thing that they
should be typing into their search engine, and that "ODR" is an acronym form of it).
I've even seen it hyphenated in some places, which would make it:
foo.cc: virtual table of type 'foo' violates the One-Definition Rule
or:
foo.cc: virtual table of type 'foo' violates the one-definition rule
The gcc.po file has these forms:
msgid "Merge C++ types using One Definition Rule."
msgid "virtual table of type %qD violates one definition rule"
msgid "virtual table of type %qD violates one definition rule "
msgid "type %qT violates the C++ One Definition Rule"
msgid "type %qT itself violate the C++ One Definition Rule"
msgid "%qD violates the C++ One Definition Rule "
I like the last one. My only question is about capitalization.
GCC is inconsistent about it (not just in this case but in many
others). Most messages are all lowercase, but some capitalize
established terms or keywords (FORTRAN), some even start with
a capital letter (FORTRAN). The GCC Diagnostic Guidelines don't
mention capitalization and the GNU Coding Standard recommends
only that messages issued by interactive programs start with
a capital letter and others don't. It would be nice to have
clarity about what the convention is (or what we agree it
should be) and eventually converge on it in all sources.
Martin
Here's a patch to the terminology part of our conventions, which suggests adding a
"the" and capitalizing (but without the hyphen).
Thoughts?
Dave
Re: [wwwdocs, PATCH] C++ terminology: the One Definition Rule in diagnostics
On 14 March 2017 at 14:18, David Malcolm wrote:
> Looking at PR ipa/8, which notes that ipa-devirt.c has two trailing
> spaces in:
>
> if (warning_at (
> DECL_SOURCE_LOCATION(TYPE_NAME (DECL_CONTEXT (vtable->decl))),
> OPT_Wodr,
> "virtual table of type %qD violates "
> "one definition rule ",
> DECL_CONTEXT (vtable->decl)))
>
> and thus emits:
>
> foo.cc: virtual table of type 'foo' violates one definition rule
>
> ...I think the wording here is a little confusing to a novice C++
> coder: it could be misread that the compiler is complaining that there
> are "definition rules", and that one of them has been somehow violated
> ("why aren't you telling me which one?"), as opposed to the correct
> reading, that there is a rule that there must be one definition.
Agreed.
> There are 5 such diagnostics, all in ipa-devirt.c.
>
> So I think the wording could be improved by adding a "the", and maybe
> capitalizing, to make it:
>
> foo.cc: virtual table of type 'foo' violates the One Definition Rule
>
> (giving a big hint to the user that the "One Definition Rule" is the thing
> that they should be typing into their search engine, and that "ODR" is an
> acronym form of it).
>
> I've even seen it hyphenated in some places, which would make it:
>
> foo.cc: virtual table of type 'foo' violates the One-Definition Rule
>
> or:
>
> foo.cc: virtual table of type 'foo' violates the one-definition rule
>
>
> Here's a patch to the terminology part of our conventions, which suggests
> adding a "the" and capitalizing (but without the hyphen).
>
>
> Thoughts?
The draft C++ standard switched to consistently hyphenating it about
18 months ago, meaning C++14 doesn't have a hyphen, but C++17 will. So
all-lowercase with a hyphen ("the one-definition rule") matches the
usage in the current draft, and is still clear we're not talking about
one of a set of definition rules.
[wwwdocs, PATCH] C++ terminology: the One Definition Rule in diagnostics
Looking at PR ipa/8, which notes that ipa-devirt.c has two trailing
spaces in:
if (warning_at (
DECL_SOURCE_LOCATION(TYPE_NAME (DECL_CONTEXT (vtable->decl))),
OPT_Wodr,
"virtual table of type %qD violates "
"one definition rule ",
DECL_CONTEXT (vtable->decl)))
and thus emits:
foo.cc: virtual table of type 'foo' violates one definition rule
...I think the wording here is a little confusing to a novice C++
coder: it could be misread that the compiler is complaining that there
are "definition rules", and that one of them has been somehow violated
("why aren't you telling me which one?"), as opposed to the correct
reading, that there is a rule that there must be one definition.
There are 5 such diagnostics, all in ipa-devirt.c.
So I think the wording could be improved by adding a "the", and maybe
capitalizing, to make it:
foo.cc: virtual table of type 'foo' violates the One Definition Rule
(giving a big hint to the user that the "One Definition Rule" is the thing that
they should be typing into their search engine, and that "ODR" is an acronym
form of it).
I've even seen it hyphenated in some places, which would make it:
foo.cc: virtual table of type 'foo' violates the One-Definition Rule
or:
foo.cc: virtual table of type 'foo' violates the one-definition rule
Here's a patch to the terminology part of our conventions, which suggests
adding a "the" and capitalizing (but without the hyphen).
Thoughts?
Dave
Index: htdocs/codingconventions.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/codingconventions.html,v
retrieving revision 1.80
diff -u -p -r1.80 codingconventions.html
--- htdocs/codingconventions.html 13 Mar 2017 22:01:05 - 1.80
+++ htdocs/codingconventions.html 14 Mar 2017 14:08:01 -
@@ -448,6 +448,10 @@ and code. The following table lists som
"Objective C"
+"one definition rule"
+"the One Definition Rule" (capitalize and use "the")
+
+
"prologue"
"prolog"
Established convention
Re: November 2016 GNU Toolchain Update
Hi Gerald, > Thanks for that update, Nick. Surely interesting reading. > Are you planning another update for March or so? ;-) Thanks for the ping! I have been intending to write another update for the last month or so, but I keep on letting it slip. :-( I will make it my top priority for this week. Cheers Nick
Re: RFC: Treat plugins as first class citizens
On Tue, Mar 14, 2017 at 2:38 PM, Nick Clifton wrote: > Hi Richard, > >>> I was thinking that it would be nice to make plugins a "first-class >>> citizen" in the gcc world by having a proper directory structure and >>> integration into the rest of gcc. > >> I believe plugins are currently a hack due to the lack of a clearly defined >> API to access GCC internals. Unless that is resolved somehow, see various >> half-way finished patch prototypes from two (or three?) years ago treating >> them as "first class" would be a blatant labeling lie. It's at most >> "first class mess". > > One of the goals of this proposal is to help combat this mess by making > plugins > a respected and official part of gcc. Such that, when the plugins fail to > build, > test or install, the problem would be considered a blocker and it would have > to > be fixed before the sources are released. > > At the moment nobody (well almost nobody) cares about > > >> The most obvious "proof" of the broken current state is that plugins are >> broken >> all the time because at make install time we forget to install another >> of the GCC internal headers. The bug is of course that we need those at all. > > Presumably you are talking about the ability to build plugins using an > installed > version of gcc ? This is separate from this proposal which is about building > and > installing plugins at the same time that gcc is built and installed. One > possible > way to address this problem is to state that plugins should not be built > outside of > a gcc build tree. Or at least any plugins that require intimate access to > gcc's > internal headers. If you build sth as part of GCC then why is it a plugin in the first place? >> I'm still convinced that 99% of all (valid) plugin uses involve only >> introspection or well-defined instrumentation. > > I agree, and I would like to see a move towards officially accepting these > plugins > into gcc's ecosystem. I'd not like to have a "python plugin" but instead a well-defined C API to GCC internals that supports introspection. And then at some point extend it with instrumentation. Heck, such interface should be compiler-agnostic, so a smoke test for the API sanity is to implement it ontop of LLVM as well so you can share introspection plugins. Richard. > Cheers > Nick > >
Re: RFC: Treat plugins as first class citizens
Hi Richard, >> I was thinking that it would be nice to make plugins a "first-class >> citizen" in the gcc world by having a proper directory structure and >> integration into the rest of gcc. > I believe plugins are currently a hack due to the lack of a clearly defined > API to access GCC internals. Unless that is resolved somehow, see various > half-way finished patch prototypes from two (or three?) years ago treating > them as "first class" would be a blatant labeling lie. It's at most > "first class mess". One of the goals of this proposal is to help combat this mess by making plugins a respected and official part of gcc. Such that, when the plugins fail to build, test or install, the problem would be considered a blocker and it would have to be fixed before the sources are released. At the moment nobody (well almost nobody) cares about > The most obvious "proof" of the broken current state is that plugins are > broken > all the time because at make install time we forget to install another > of the GCC internal headers. The bug is of course that we need those at all. Presumably you are talking about the ability to build plugins using an installed version of gcc ? This is separate from this proposal which is about building and installing plugins at the same time that gcc is built and installed. One possible way to address this problem is to state that plugins should not be built outside of a gcc build tree. Or at least any plugins that require intimate access to gcc's internal headers. > I'm still convinced that 99% of all (valid) plugin uses involve only > introspection or well-defined instrumentation. I agree, and I would like to see a move towards officially accepting these plugins into gcc's ecosystem. Cheers Nick
GCC 7.1 Status report (2017-03-14)
Status == The trunk is in regression and documentation fixes mode (Stage 4) thus as if it were a release branch. We are feature complete since quite a while and just chasing down P1 bugs which block the release of GCC 7. Tentative release date is mid April which means, given past history, a branching target of early April. That leaves us about three weeks for chasing down the remaining P1 regressions. Please help with this task. Quality Data Priority # Change from last report --- --- P1 17 - 8 P2 108 - 19 P3 19 - 18 P4 138 + 4 P5 30 --- --- Total P1-P3 144 - 45 Total 312 - 41 Previous Report === https://gcc.gnu.org/ml/gcc/2017-01/msg00181.html
Re: RFC: Treat plugins as first class citizens
On Mon, Mar 13, 2017 at 6:12 PM, Nick Clifton wrote: > Hi Guys, > > I was thinking that it would be nice to make plugins a "first-class > citizen" in the gcc world by having a proper directory structure and > integration into the rest of gcc. For example: > > gcc/plugins <-- Everything plugin-y starts here > gcc/plugins/Make-lang.in <-- Makefile fragment. > gcc/plugins/src <-- Maybe move gcc/plugins.[c|h|def] here ? > gcc/plugins/doc <-- Actual documentation, wow! > gcc/plugins/testsuite <-- Tests for the plugins and their integration > into gcc > gcc/plugins/config<-- Subdirectories of this directory contain > each real plugin > gcc/plugins/config/annobin <-- For example, this is where my pet plugin > would go > > Plus there could be an official plugins maintainer. (I am willing to > volunteer, so is Aldy Hernandez). The documentation would be compiled > along with the rest of gcc's documentation and the testsuite would be > run as part of gcc's normal testing process. Ideally I would also > like to see plugin test failures be considered as blockers for new > releases, but that is something for the future. > > So, what do you think ? Should I create a patch and submit it for > official review ? I believe plugins are currently a hack due to the lack of a clearly defined API to access GCC internals. Unless that is resolved somehow, see various half-way finished patch prototypes from two (or three?) years ago treating them as "first class" would be a blatant labeling lie. It's at most "first class mess". The most obvious "proof" of the broken current state is that plugins are broken all the time because at make install time we forget to install another of the GCC internal headers. The bug is of course that we need those at all. I'm still convinced that 99% of all (valid) plugin uses involve only introspection or well-defined instrumentation. Richard. > Cheers > Nick
