xtensa: Fix up fatal_error message strings in xtensa-dynconfig.c [PR108890]

Message ID Y/dBSvWvHlyViuhb@tucnak
State Unresolved
Headers
Series xtensa: Fix up fatal_error message strings in xtensa-dynconfig.c [PR108890] |

Checks

Context Check Description
snail/gcc-patch-check warning Git am fail log

Commit Message

Jakub Jelinek Feb. 23, 2023, 10:34 a.m. UTC
  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.


	Jakub
  

Comments

Max Filippov Feb. 23, 2023, 10:23 p.m. UTC | #1
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
  

Patch

--- 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);
 	}