[patch mingw]: Add multilib support for i?86-w64-mingw32 target

[Kai Tietz]

2009/9/13 Kai Tietz <ktietz70@googlemail.com>:
> 2009/9/13 Joseph S. Myers <joseph@codesourcery.com>:
>> On Sat, 12 Sep 2009, Kai Tietz wrote:
>>
>>> Hello,
>>>
>>> this patch enables the build of the i?86-w64-mingw32 target for
>>> multilib version. Additional it fixes for the x86_64-*-mingw32 target
>>> the used hwint and the use_long_long_for_widest_fast_int. I added to
>>> cygwin host configuration in config.host the
>>> use_long_long_for_widest_fast_int, too. If there are objections about
>>> this please let me know (I'll remove it). But as far as I could see,
>>> it should cause any penalties for cygwin.
>>
>> Setting use_long_long_for_widest_fast_int for some i?86 hosts but others
>> seems misconceived.  Why should long long be faster on 32-bit Cygwin or
>> MinGW than on 32-bit GNU/Linux?  It should be set either for all 32-bit
>> i?86 hosts or none of them.  (Setting for *64-bit hosts where long is
>> 32-bit* is appropriate - x86_64-*-mingw* is one such, another case is the
>> preexisting setting for ia64-*-hpux*, and it would also be appropriate for
>> mips64*-*-linux* and mipsisa64*-*-linux*.)
>>
>> --
>> Joseph S. Myers
>> joseph@codesourcery.com
>>
>
> 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.

See for this comment in hwint.h of gcc.

"With a sane ABI, 'long' is the largest efficient host integer type.
Thus, we use that unless we have to use 'long long' or '__int64'
because we're targeting a 64-bit machine from a 32-bit host.  "


-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination