Yeah it certainly seems like it ought to fail for a C++ standard reason on
both platforms.
I know C is often nominatively typed, so if types have different names,
they are different types. But it is done inconsistently. So this may be an
area of ambiguity, even in the standard.
Bill.
On 8 Augus
On 08/08/2013 13:43, Bill Hart wrote:
> On 8 August 2013 12:53, Brian Gladman wrote:
[snip]
>> where mpir_ui/si map to long types everywhere except on Windows x64
>> where they map to long long types.
>>
>>> So it comes down to the LP64 vs the LLP64, (long is 32-bit on Win and
>>> 64-bit on Lin)
On 8 August 2013 12:53, Brian Gladman wrote:
> On 08/08/2013 11:38, degski wrote:
>
> > "It is possible that 'long long' types and 'intmax_t' types are not
> > distinguishable so it sees two overloads that it cannot disambiguate."
> >
> > This is the problem:
> >
> > typedef long long intmax_t;
>
On 08/08/2013 11:38, degski wrote:
> "It is possible that 'long long' types and 'intmax_t' types are not
> distinguishable so it sees two overloads that it cannot disambiguate."
>
> This is the problem:
>
> typedef long long intmax_t;
> typedef unsigned long long uintmax_t;
>
> Is what going on
"It is possible that 'long long' types and 'intmax_t' types are not
distinguishable so it sees two overloads that it cannot disambiguate."
This is the problem:
typedef long long intmax_t;
typedef unsigned long long uintmax_t;
Is what going on on VS2012 c++11, x64.
signed long long int seems to
ICL does handle gcc-inline assembler, f.e.
int32_t bit_scan_reverse_asm64 ( uint64_t x ) {
__asm__ __volatile ( "bsrq %0, %0" : "=r" ( x ) : "0" ( x ) );
return ( int32_t ) x;
}
compiles just fine without doing anything in particular. Fast-call ABI is
different from linux, though, so at
