As I read it, the front end has functions with names such as error, but no
useful i18n will actually occur because the functions in d-diagnostic.cc
format the messages with xvasprintf before passing to the common
diagnostic code.
But will exgettext nevertheless extract messages from the dfrontend code,
if the functions happen to have string arguments in the same position as
the generic diagnostic functions do? If so, I think that should be
disabled, to avoid putting a lot of messages in gcc.pot that won't
actually be translated. (If actual i18n support is desired, it should be
shared with other users of the front end, which would mean using dgettext
to extract translations in a different domain from the default GCC one,
and so the messages shouldn't go in gcc.pot anyway.)
In d-target.cc you have code like:
+ else if (global.params.isLinux)
+ {
+ /* sizeof(pthread_mutex_t) for Linux. */
+ if (global.params.is64bit)
+ return global.params.isLP64 ? 40 : 32;
+ else
+ return global.params.isLP64 ? 40 : 24;
+ }
which feels like it belongs in the config/ configuration for each target
(as a target hook returning the required information), not in the D front
end code. I'm not clear what global.params.is64bit is meant to mean; it
looks like "this is x86_64, possibly x32" in this patch. These values
aren't correct in general anyway; on AArch64, glibc has pthread_mutex_t of
size 48 for LP64 and 32 for ILP32; on HPPA (only ILP32 supported for
Linux) it's 48.
You have two new target macros TARGET_CPU_D_BUILTINS and
TARGET_OS_D_BUILTINS. You're missing any documentation for them in
tm.texi.in. And we prefer target hooks to macros. So please try to
convert them to (documented) target hooks. (See c-family/c-target.def,
and c_target_objs etc., for how there can be hooks that are specific to
particular front ends. See the comment in config/default-c.c regarding
how to deal with a mixture of OS-dependent and architecture-dependent
hooks.)
--
Joseph S. Myers
jos...@codesourcery.com
