Re: RFC: Sphinx for GCC documentation
On 4/1/21 3:30 PM, Martin Liška wrote: That said, I'm asking the GCC community for a green light before I invest more time on it? Hello. So far, I've received just a small feedback about the transition. In most cases positive. May I understand it as green light for the transition? Thanks, Martin [1] https://splichal.eu/scripts/sphinx/
Re: Can I push code to GCC?
On 5/10/2021 7:01 AM, juzhe.zh...@rivai.ai wrote: Hi, I am a compiler engineer base on GCC in China. Recently, I develop a new pattern for vector widen multiply-accumulator(I call it widen fma) because the ISA in my project has the instruction (vwmacc). I develop a lot of code especiallly frontend (gimple&&generic) int GCC. This is useful for my project, but I am not sure whether it is useful for GCC overall. Can I deliver the code? And maybe you guys can check my code and refine it to have a better quality. Thank you! The process for contributing code is to post the patch to the gcc-patches mailing list for design/implementation review. For new contributors, if the patch is acceptable, someone will commit it for you. Over time if you make several contributions, then we'll set you up with write access to the repository. jeff
Why don't recently added -Wexceptions and -Winvalid-imported-macros use "Warning" flag?
Hello, While running my script[1] parsing gcc/c-family/c.opt to extract information about the new warnings for C++ programs, I've noticed that a couple of new warnings in gcc 11 don't use the "Warning" flag which, I had assumed, would be used for all warnings (with a couple of historical exceptions). Was this assumption wrong, or could this have been an oversight, i.e. should this flag be added to these warning too? For the reference, the commits adding the warning were: - 1d87302a8e2 (c++: Add -Wexceptions warning option [PR97675], 2020-11-03) - 10ee6da64c5 (C++ Module options, 2020-12-01) Thanks in advance, VZ pgp06calRorxF.pgp Description: PGP signature
gettext, _, N_, and G_
I understand that the difference between the _ macro and the N_ macro is that the former is used to force a gettext call on the argument and the latter is used for strings for which gettext will be called later. But I don't see any documentation about why/when we should use the G_ macro instead of one of the other two. It seems to be used for diagnostic messages, for which gettext will be called in the diagnostic machinery; why use G_ instead of N_ in such cases? Jason
Re: gettext, _, N_, and G_
On Thu, May 13, 2021 at 06:01:39PM -0400, Jason Merrill via Gcc wrote:
> I understand that the difference between the _ macro and the N_ macro is
> that the former is used to force a gettext call on the argument and the
> latter is used for strings for which gettext will be called later. But I
> don't see any documentation about why/when we should use the G_ macro
> instead of one of the other two. It seems to be used for diagnostic
> messages, for which gettext will be called in the diagnostic machinery; why
> use G_ instead of N_ in such cases?
See gcc/po/exgettext for details.
The two macros are:
# define N_(msgid) msgid
# define G_(gmsgid) gmsgid
and for exgettext the prefixes of the arguments determine the the kind
of format string:
if (args ~ /g$/)
format="gcc-internal-format"
else if (args ~ /noc$/)
format="no-c-format"
else if (args ~ /c$/)
format="c-format"
So, G_("...") results in the string being collected as
#, gcc-internal-format
while with N_("...") it is
", c-format
gettext has support for gcc-internal-format (though I wonder when that has
been updated last time) and for gcc diagnostic format specifiers will make
sure the translations handle that correctly.
Jakub
gcc-9-20210513 is now available
Snapshot gcc-9-20210513 is now available on https://gcc.gnu.org/pub/gcc/snapshots/9-20210513/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 9 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-9 revision 9f650694b6eee1dc22a64ac4a1cd0d9863262a6f You'll find: gcc-9-20210513.tar.xzComplete GCC SHA256=8f9d3f862b234a83c1ebe2ffc6bbd80c2234907f596102a4ad88e5ef93225f34 SHA1=4c08ac04e15177824456b29b2f490c72e5e65698 Diffs from 9-20210506 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-9 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: gettext, _, N_, and G_
On 5/13/21 6:13 PM, Jakub Jelinek wrote:
On Thu, May 13, 2021 at 06:01:39PM -0400, Jason Merrill via Gcc wrote:
I understand that the difference between the _ macro and the N_ macro is
that the former is used to force a gettext call on the argument and the
latter is used for strings for which gettext will be called later. But I
don't see any documentation about why/when we should use the G_ macro
instead of one of the other two. It seems to be used for diagnostic
messages, for which gettext will be called in the diagnostic machinery; why
use G_ instead of N_ in such cases?
See gcc/po/exgettext for details.
The two macros are:
# define N_(msgid) msgid
# define G_(gmsgid) gmsgid
and for exgettext the prefixes of the arguments determine the the kind
of format string:
if (args ~ /g$/)
format="gcc-internal-format"
else if (args ~ /noc$/)
format="no-c-format"
else if (args ~ /c$/)
format="c-format"
So, G_("...") results in the string being collected as
#, gcc-internal-format
while with N_("...") it is
", c-format
gettext has support for gcc-internal-format (though I wonder when that has
been updated last time) and for gcc diagnostic format specifiers will make
sure the translations handle that correctly.
Ah, I looked at exgettext but hadn't read it closely enough to
understand that bit. So does this look good to you?
>From 8718fbbf83978bd8ec4bf0a0e4164459158df182 Mon Sep 17 00:00:00 2001
From: Jason Merrill
Date: Thu, 13 May 2021 20:53:50 -0400
Subject: [PATCH] intl: add comments to _, N_, and G_
To: gcc-patc...@gcc.gnu.org
gcc/ChangeLog:
* intl.h: Add comments.
---
gcc/intl.h | 5 +
1 file changed, 5 insertions(+)
diff --git a/gcc/intl.h b/gcc/intl.h
index 829364ae905..f21ec11ada0 100644
--- a/gcc/intl.h
+++ b/gcc/intl.h
@@ -47,14 +47,19 @@ extern const char *fake_ngettext (const char *singular, const char *plural,
#endif
+/* Used to immediately translate the argument. */
#ifndef _
# define _(msgid) gettext (msgid)
#endif
+/* Used to mark strings that will be translated later. */
#ifndef N_
# define N_(msgid) msgid
#endif
+/* Like N_, but used for diagnostic strings, to tell gettext that this is a
+ gcc-internal-format string rather than standard c-format. exgettext gets
+ this from the 'g' in "gmsgid", which is also used in diagnostic.c. */
#ifndef G_
# define G_(gmsgid) gmsgid
#endif
--
2.27.0
