This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch mingw]: Add multilib support for i?86-w64-mingw32 target
On Sun, 13 Sep 2009, Kai Tietz wrote:
> The issue is not that 'long long' is faster, or not here. The issue
> is, if you build a multilib compiler with a 32-bit default target,
> hwint64 has to be set to true. If you don't set then additionally the
> use_long_long_for_widest_fast_int to yes, the hwint.h file will assume
> that 'long' type is wide enough. This is for win32 targets not true,
> as 'long' type remains 32-bits.
This is not a coherent explanation.
I fully agree that you need to set need_64bit_hwint for certain *targets*
which default to 32-bit. (In fact I think we should set it
unconditionally for all i?86-*-* targets, or even for all targets, but
that's another matter. HOST_WIDE_INT could also do with being renamed to
reflect that it's really a target setting not a host setting.)
This should be completely unrelated to the *host* setting
use_long_long_for_widest_fast_int. That setting is supposed purely to be
an efficiency setting, relating to the types used for various bitmaps.
If you need a particular setting of HOST_WIDEST_FAST_INT for certain MinGW
targets, those targets are seriously broken since they will not work with
cross compilers from other 32-bit hosts that use 32-bit
HOST_WIDEST_FAST_INT. There is no requirement for HOST_WIDEST_FAST_INT to
be as wide as HOST_WIDE_INT; if there were such a requirement it would
need to be implemented in host-dependent code rather than by putting
use_long_long_for_widest_fast_int settings in host-dependent configuration
(fundamentally wrong if the setting relates to a target issue). If long
long is not faster than long on these hosts, setting
use_long_long_for_widest_fast_int causes an unnecessary slowdown for
compilers on those hosts for all targets that do not need 64-bit
HOST_WIDEST_FAST_INT (which I claim should be every target).
--
Joseph S. Myers
joseph@codesourcery.com