* [PATCH] xtensa: Fix up fatal_error message strings in xtensa-dynconfig.c [PR108890]
@ 2023-02-23 10:34 Jakub Jelinek
2023-02-23 22:23 ` Max Filippov
0 siblings, 1 reply; 2+ messages in thread
From: Jakub Jelinek @ 2023-02-23 10:34 UTC (permalink / raw)
To: Max Filippov; +Cc: gcc-patches
Hi!
The translation PR complains that these 4 messages from xtensa-dynconfig.c
are marked in po/gcc.pot as c-format (which doesn't allow %qs) while they
should be gcc-internal-format.
The problem is in the manual translation of the strings with _(),
that should be both unnecessary because fatal_error invokes _() on its
argument already, but also incorrect for the above reason, for
gcc-internal-format strings one should use G_("...") instead if really
needed.
The following patch drops those _("..."), tested by regenerating po/gcc.pot
to see they are now gcc-internal-format, but not really tested on xtensa
target.
Ok for trunk?
BTW, why is the file using .c extension rather than .cc? Why isn't t-xtensa
using $(COMPILE) and $(POSTCOMPILE) to compile it like for most other
extra_objs on other targets? And, why does that file use <> style includes
of gcc internal headers rather than "" style which is used everywhere else
in gcc?
2023-02-23 Jakub Jelinek <jakub@redhat.com>
PR translation/108890
* config/xtensa/xtensa-dynconfig.c (xtensa_load_config): Drop _()s
around fatal_error format strings.
--- gcc/config/xtensa/xtensa-dynconfig.c.jj 2023-01-16 11:52:16.056734462 +0100
+++ gcc/config/xtensa/xtensa-dynconfig.c 2023-02-23 10:57:17.325259182 +0100
@@ -87,14 +87,14 @@ const void *xtensa_load_config (const ch
if (!handle)
{
fatal_error (input_location,
- _("%qs is defined but could not be loaded: %s"),
+ "%qs is defined but could not be loaded: %s",
CONFIG_ENV_NAME, dlerror ());
exit (FATAL_EXIT_CODE);
}
if (dlsym (handle, "plugin_is_GPL_compatible") == NULL)
{
fatal_error (input_location,
- _("%qs plugin is not licensed under a GPL-compatible license"),
+ "%qs plugin is not licensed under a GPL-compatible license",
CONFIG_ENV_NAME);
exit (FATAL_EXIT_CODE);
}
@@ -111,7 +111,7 @@ const void *xtensa_load_config (const ch
return no_name_def;
fatal_error (input_location,
- _("%qs is loaded but symbol %qs is not found: %s"),
+ "%qs is loaded but symbol %qs is not found: %s",
CONFIG_ENV_NAME, name, dlerror ());
exit (FATAL_EXIT_CODE);
}
@@ -125,7 +125,7 @@ const void *xtensa_load_config (const ch
if (path)
{
fatal_error (input_location,
- _("%qs is defined but plugin support is disabled"),
+ "%qs is defined but plugin support is disabled",
CONFIG_ENV_NAME);
exit (FATAL_EXIT_CODE);
}
Jakub
^ permalink raw reply [flat|nested] 2+ messages in thread
* Re: [PATCH] xtensa: Fix up fatal_error message strings in xtensa-dynconfig.c [PR108890]
2023-02-23 10:34 [PATCH] xtensa: Fix up fatal_error message strings in xtensa-dynconfig.c [PR108890] Jakub Jelinek
@ 2023-02-23 22:23 ` Max Filippov
0 siblings, 0 replies; 2+ messages in thread
From: Max Filippov @ 2023-02-23 22:23 UTC (permalink / raw)
To: Jakub Jelinek; +Cc: gcc-patches
Hi Jakub,
On Thu, Feb 23, 2023 at 2:34 AM Jakub Jelinek <jakub@redhat.com> wrote:
> The translation PR complains that these 4 messages from xtensa-dynconfig.c
> are marked in po/gcc.pot as c-format (which doesn't allow %qs) while they
> should be gcc-internal-format.
>
> The problem is in the manual translation of the strings with _(),
> that should be both unnecessary because fatal_error invokes _() on its
> argument already, but also incorrect for the above reason, for
> gcc-internal-format strings one should use G_("...") instead if really
> needed.
>
> The following patch drops those _("..."), tested by regenerating po/gcc.pot
> to see they are now gcc-internal-format, but not really tested on xtensa
> target.
>
> Ok for trunk?
Ok.
> BTW, why is the file using .c extension rather than .cc?
It was initially developed when backend code was still in .c
files and I failed to update this part during forward porting.
I'll fix it.
> Why isn't t-xtensa using $(COMPILE) and $(POSTCOMPILE)
> to compile it like for most other extra_objs on other targets?
> And, why does that file use <> style includes of gcc internal
> headers rather than "" style which is used everywhere else
> in gcc?
No real reason for either. I'll fix it.
Thanks for your review.
-- Max
^ permalink raw reply [flat|nested] 2+ messages in thread
end of thread, other threads:[~2023-02-23 22:23 UTC | newest]
Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-02-23 10:34 [PATCH] xtensa: Fix up fatal_error message strings in xtensa-dynconfig.c [PR108890] Jakub Jelinek
2023-02-23 22:23 ` Max Filippov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).