search for: __uint128_t

...he MS-ABI don't conform to it! Data types beyond 64 bit MUST BE returned by the callee via the hidden first argument allocated by the caller, NOT in XMM0! Demo/proof: from this source --- llvm-bug.c --- #ifndef __clang__ typedef struct { unsigned __int64 low; unsigned __int64 high; } __uint128_t; #else __attribute__((ms_abi)) #endif __uint128_t __udivmodti4(__uint128_t dividend, __uint128_t divisor, __uint128_t *remainder) { if (remainder != 0) *remainder = divisor; return dividend; } --- EOF --- clang -c -O1 generates the following INCOMPATIBLE and WRONG code: __udivmod...

...but not implemented for uint128_t. So, I implemented the function, and the code is working correctly. But the only way I manage to make the linker to find the function, and to build the code is to declare my function as: " extern "C" bool __sync_bool_compare_and_swap_16(volatile __uint128_t * destination, __uint128_t comperand, __uint128_t exchange) {...} " Though the code is linked and is working properly, the warnings are generated: " .../src/sync.cpp:205: warning: new declaration 'bool __sync_bool_compare_and_swap_16(volatile __uint128_t*, __uint128_t, __uint128_t)&...

I think from the C compiler's point of view, it is going to want it to work for any size above an i64, i.e. all the way up to an i128 so that if the user of the C compiler does this computation with __uint128_t's then it will Do The Right Thing TM. Basically, you want unsigned long a, b, c, d; .... const __uint128_t u = (__uint128_t) a + b; const unsigned long v = u >> 64; const __uint128_t w = (__uint128_t) c + d + v; to do the right thing, namely do the first addition with an ADD, the car...

...ider this short C > program: > > > #include <stdlib.h> > #include <stdio.h> > > #define BITS 64 > > /**************************************** > >   Types > > ****************************************/ > > typedef unsigned long ul; > typedef __uint128_t ull; > typedef ulong mp_size; > typedef const ulong * mp_src; > typedef ulong * mp_dst; > typedef ulong * mp_ptr; > > > /**************************************** > >   Random routines > > ****************************************/ > > ull __randval = (ull) 1399...

...mportant to be able to retrieve the carry and do an add with carry. Consider this short C program: #include <stdlib.h> #include <stdio.h> #define BITS 64 /**************************************** Types ****************************************/ typedef unsigned long ul; typedef __uint128_t ull; typedef ulong mp_size; typedef const ulong * mp_src; typedef ulong * mp_dst; typedef ulong * mp_ptr; /**************************************** Random routines ****************************************/ ull __randval = (ull) 13993185049168412078UL; const ull __randprime = (ull) 922337203...

...lt;stdio.h> >>> >>> #define BITS 64 >>> >>> /**************************************** >>> >>>   Types >>> >>> ****************************************/ >>> >>> typedef unsigned long ul; >>> typedef __uint128_t ull; >>> typedef ulong mp_size; >>> typedef const ulong * mp_src; >>> typedef ulong * mp_dst; >>> typedef ulong * mp_ptr; >>> >>> >>> /**************************************** >>> >>>   Random routines >>> &gt...

...de <stdlib.h> >> #include <stdio.h> >> >> #define BITS 64 >> >> /**************************************** >> >> Types >> >> ****************************************/ >> >> typedef unsigned long ul; >> typedef __uint128_t ull; >> typedef ulong mp_size; >> typedef const ulong * mp_src; >> typedef ulong * mp_dst; >> typedef ulong * mp_ptr; >> >> >> /**************************************** >> >> Random routines >> >> ******************************...

> Yeah I had a think about it, and I think intrinsics are the wrong way > to do it. So I'd say you are likely right. For this to work well, the way the code generators handle flags will need to be improved: currently it is suboptimal, in fact kind of a hack. Ciao, Duncan.

...;> idx = clang.cindex.Index.create() >>> tu = idx.parse('/usr/include/math.h', ['-x', 'c++-header']) >>> c = tu.cursor >>> for d in c.get_children(): ... print d.kind, d.spelling ... CursorKind.TYPEDEF_DECL __int128_t CursorKind.TYPEDEF_DECL __uint128_t CursorKind.TYPEDEF_DECL __builtin_va_list CursorKind.UNEXPOSED_DECL >>> print len(tu.diagnostics) 0 Now that list clearly does not represent the contents of math.h. However, as you can see, I don't get an error, and the list of diagnostics is empty. When I use C mode, I instead get t...

...te() > >>> tu = idx.parse('/usr/include/math.h', ['-x', 'c++-header']) > >>> c = tu.cursor > >>> for d in c.get_children(): > ... print d.kind, d.spelling > ... > CursorKind.TYPEDEF_DECL __int128_t > CursorKind.TYPEDEF_DECL __uint128_t > CursorKind.TYPEDEF_DECL __builtin_va_list > CursorKind.UNEXPOSED_DECL > It would seem that the contents on the entire module are hidden inside this UNEXPOSED_DECL. I'd be interesting in knowing why that is, but for now at least I seem to have solved my problem. > >>> p...

RPM: http://bits.gluster.org/pub/gluster/glusterfs/3.5qa2/ SRC: http://bits.gluster.org/pub/gluster/glusterfs/src/glusterfs-3.5qa2.tar.gz This release is made off jenkins-release-48 -- Gluster Build System

...e() > >>> tu = idx.parse('/usr/include/math.h', ['-x', 'c++-header']) > >>> c = tu.cursor > >>> for d in c.get_children(): > ... print d.kind, d.spelling > ... > CursorKind.TYPEDEF_DECL __int128_t > CursorKind.TYPEDEF_DECL __uint128_t > CursorKind.TYPEDEF_DECL __builtin_va_list > CursorKind.UNEXPOSED_DECL > > It would seem that the contents on the entire module are hidden inside this UNEXPOSED_DECL. I'd be interesting in knowing why that is, but for now at least I seem to have solved my problem. I am not sure...

On Fri, Jun 11, 2010 at 3:28 PM, Bill Hart <goodwillhart at googlemail.com> wrote: > Hi Eli, > > On 11 June 2010 22:44, Eli Friedman <eli.friedman at gmail.com> wrote: >> On Fri, Jun 11, 2010 at 10:37 AM, Bill Hart <goodwillhart at googlemail.com> wrote: >>> a) What plans are there to support addition, subtraction, >>> multiplication, division,

...1 >> 32) + (p2 >> 32) + > + ((((a_lo * b_lo) >> 32) + (u32)p1 + (u32)p2) >> 32); > + > +} Unless GCC is waaay more clever than I think, this is hugely suboptimal on 64-bit. x86 can do this in a single instruction, and gcc can express it cleanly using __uint128_t. I wouldn't be terribly surprised if the 32-bit generated code was fine, too. > + > +static notrace u64 vread_hvclock(int *mode) > +{ > + const struct ms_hyperv_tsc_page *tsc_pg = > + (const struct ms_hyperv_tsc_page *)&pvclock_page; > + u64 seq...

...1 >> 32) + (p2 >> 32) + > + ((((a_lo * b_lo) >> 32) + (u32)p1 + (u32)p2) >> 32); > + > +} Unless GCC is waaay more clever than I think, this is hugely suboptimal on 64-bit. x86 can do this in a single instruction, and gcc can express it cleanly using __uint128_t. I wouldn't be terribly surprised if the 32-bit generated code was fine, too. > + > +static notrace u64 vread_hvclock(int *mode) > +{ > + const struct ms_hyperv_tsc_page *tsc_pg = > + (const struct ms_hyperv_tsc_page *)&pvclock_page; > + u64 seq...

Hi all, After searching for a decent compiler backend for ages (google sometimes isn't helpful), I recently stumbled upon LLVM. Woot!! I work on bignum arithmetic (I'm a professional mathematician) and have recently decided to switch from developing GPL'd bignum code to BSD licensed code. (See http://www.mpir.org/ which I contributed to for a while - a fork of GMP). Please bear with

...x8e41ab0 <<invalid sloc>> <invalid sloc> |-TypedefDecl 0x8e41fe8 <<invalid sloc>> <invalid sloc> implicit __int128_t '__int128' | `-BuiltinType 0x8e41d00 '__int128' |-TypedefDecl 0x8e42048 <<invalid sloc>> <invalid sloc> implicit __uint128_t 'unsigned __int128' | `-BuiltinType 0x8e41d20 'unsigned __int128' |-TypedefDecl 0x8e42378 <<invalid sloc>> <invalid sloc> implicit __NSConstantString 'struct __NSConstantString_tag' | `-RecordType 0x8e42130 'struct __NSConstantString_tag' | `-CXXR...

...ommits * Initial ('naive') support for cross translation unit analysis with the Clang Static Analyzer has been added. [r326323](http://reviews.llvm.org/rL326323). * The flags `-fforce-enable-int128` and `-fno-force-enable-int128` were added to 'force' support for `__int128_t` and `__uint128_t` for a target. [r326045](http://reviews.llvm.org/rL326045). * A heuristic was added so the static analyzer skips yacc/bison-generated files. [r326135](http://reviews.llvm.org/rL326135). ## Other project commits * Initial PPC64 instruction emulation landed in LLDB. [r326224](http://reviews.llvm....

...c:3:9> col:9 M2 defined TranslationUnitDecl 0xd6c078 <<invalid sloc>> <invalid sloc> |-TypedefDecl 0xd6c330 <<invalid sloc>> <invalid sloc> implicit __int128_t '__int128' |-TypedefDecl 0xd6c370 <<invalid sloc>> <invalid sloc> implicit __uint128_t 'unsigned __int128' |-TypedefDecl 0xd6c3c8 <<invalid sloc>> <invalid sloc> implicit __builtin_ms_va_list 'char *' `-TypedefDecl 0xd6c590 <<invalid sloc>> <invalid sloc> implicit __builtin_va_list 'struct __va_list_tag [1]' ================...

...c:3:9> col:9 M2 defined TranslationUnitDecl 0xd6c078 <<invalid sloc>> <invalid sloc> |-TypedefDecl 0xd6c330 <<invalid sloc>> <invalid sloc> implicit __int128_t '__int128' |-TypedefDecl 0xd6c370 <<invalid sloc>> <invalid sloc> implicit __uint128_t 'unsigned __int128' |-TypedefDecl 0xd6c3c8 <<invalid sloc>> <invalid sloc> implicit __builtin_ms_va_list 'char *' `-TypedefDecl 0xd6c590 <<invalid sloc>> <invalid sloc> implicit __builtin_va_list 'struct __va_list_tag [1]' ================...