search for: __int128_t

Hi all: I'm porting RISC-V[1] for compiler-rt recently, and I've got a problem when adding soft float routine for rv32, RISC-V ABI required 128 bits bits for long double, but it's implemented by int128_t, however rv32 don't support __int128_t. Of cause, it not hard thing to support __int128_t by overriding TargetInfo::hasInt128Type for LLVM, but its will cause some ABI incompatible with GCC, because GCC don't support __int128_t for 32 bits target. So I guess I've few option here: 1. Implement 128 bits soft-float with int64_t....

...s.llvm.org> wrote: > Hi all: > > I'm porting RISC-V[1] for compiler-rt recently, and I've got a problem > when adding soft float routine for rv32, RISC-V ABI required 128 bits > bits for long double, but it's implemented by int128_t, however rv32 > don't support __int128_t. > > Of cause, it not hard thing to support __int128_t by overriding > TargetInfo::hasInt128Type for LLVM, but its will cause some ABI > incompatible with GCC, because GCC don't support __int128_t for 32 > bits target. > > So I guess I've few option here: > > 1. I...

...gt;> import clang.cindex >>> 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....

Hello all, I get unresolved external symbol __muloti4 when attempting to compile GNU m4 for Windows commandline. See details in bug: https://bugs.llvm.org/show_bug.cgi?id=16404#c22 Looking into this, I see that some parts of compiler-rt are disabled for Windows due to the __LP64__ define. The code seem not portable as is to the MS compiler, but according to my tests the code compiles and links

...t;>> 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 > 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...

...;>> 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 > > 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 t...

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

...recall that intmax_t is no longer really the maximum possible int > (because of int128) and so it's always 64 bit on platforms we care > about. Can Eric comment? intmax_t was supposed to be whatever the compiler supports as its largest integer type; but you are right that when gcc added __int128_t, they did NOT change intmax_t at the time (arguably by using weasel-words that as an implementation-defined type, it was not an integer type merely because you can't write integer literals of that type, even though it behaves integral in every other aspect). We're kind of in a frozen state...

Hi, My current understanding of the problem (based on https://reviews.llvm.org/D49774) is that we have a type, file_time_type, which is part of the ABI and is currently defined as std::chrono::time_point<_FileSystemClock>, where _FileSystemClock is an internal type represented using a __int128_t. However, C++20 will add a type called file_clock and redefine file_time_type to be std::chrono::time_point<std::chrono::file_clock> instead, which is an ABI break. Is this correct, and is this the only concern we have with respect to the ABI stability of Filesystem as currently included in...

...sentially two different errors: 1) In file included from /home/fceldiener/vcs/llvm/include/llvm/Support/SwapByteOrder.h:20: /usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/limits:1404:27: error: use of undeclared identifier '__int128'; did you mean '__int128_t'? struct numeric_limits<__int128> ^ /usr/bin/../lib/gcc/x86_64-redhat-linux/4.7.2/../../../../include/c++/4.7.2/limits:1478:36: error: expected '>' struct numeric_limits<unsigned __int128> ^ /usr/bi...

...ontains some declarations which were not there before. Using "clang -Xclang -ast-dump” on a c++ file, I get the following result: TranslationUnitDecl 0x8e41ab0 <<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>> <i...

...11). ## Clang commits * 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](ht...

...= 0 = unknown type D D = double D E = long (under some ABIs) E D = long long (under some ABIs) E E = long double (under some ABIs) D F = pointer (under some ABIs) F D = hole (I) E F = hole (J) F E = hole F F = hole ... 1111 1111 1111 1111 = 65535 = all other types 16 Bytes: 0 = unknown type | | = __int128_t I J = long long (under some ABIs) J I = long double (under some ABIs) J J = hole ... -1 = all other types For pointers, this scheme would consider all pointers to be the same (regardless of pointee type). Doing otherwise would mostly requiring putting pointer-type checking on the slow path (i.e....

...col:8 M1 undefined | `-MacroDecl 0x11c03a0 <line:5:9> col:9 M1 defined `-MacroDecl 0x11c03f8 <mainfile.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...

...of the problem (based on >> https://reviews.llvm.org/D49774) is that we have a type, file_time_type, >> which is part of the ABI and is currently defined as >> std::chrono::time_point<_FileSystemClock>, where _FileSystemClock is an >> internal type represented using a __int128_t. However, C++20 will add a >> type called file_clock and redefine file_time_type to be >> std::chrono::time_point<std::chrono::file_clock> instead, which is an ABI >> break. >> >> Is this correct, and is this the only concern we have with respect to the >>...

...E E = long double (under some ABIs) > D F = pointer (under some ABIs) > F D = hole (I) > E F = hole (J) > F E = hole > F F = hole > ... > 1111 1111 1111 1111 = 65535 = all other types > > 16 Bytes: > 0 = unknown type > | | = __int128_t > I J = long long (under some ABIs) > J I = long double (under some ABIs) > J J = hole > ... > -1 = all other types > > For pointers, this scheme would consider all pointers to be the > same (regardless of pointee type). Doing otherwise would most...

...s) >> F D = hole (I) >> E F = hole (J) >> F E = hole >> F F = hole >> ... >> 1111 1111 1111 1111 = 65535 = all other types >> >> 16 Bytes: >> 0 = unknown type >> | | = __int128_t >> I J = long long (under some ABIs) >> J I = long double (under some ABIs) >> J J = hole >> ... >> -1 = all other types >> >> For pointers, this scheme would consider all pointers to be >> the s...

...but all I get is -- snip -- In file included from /home/birdspider/vmkit-test/llvm/include/llvm/Support/SwapByteOrder.h:20: /usr/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/limits:1404:27: error: use of undeclared identifier '__int128'; did you mean '__int128_t'? struct numeric_limits<__int128> ^ /usr/bin/../lib/gcc/x86_64-unknown-linux-gnu/4.7.0/../../../../include/c++/4.7.0/limits:1478:36: error: expected '>' struct numeric_limits<unsigned __int128> ^ /u...

...t; F D = hole (I) > >>> E F = hole (J) > >>> F E = hole > >>> F F = hole > >>> ... > >>> 1111 1111 1111 1111 = 65535 = all other types > >>> > >>> 16 Bytes: > >>> 0 = unknown type > >>> | | = __int128_t > >>> I J = long long (under some ABIs) > >>> J I = long double (under some ABIs) > >>> J J = hole > >>> ... > >>> -1 = all other types > >>> > >>> For pointers, this scheme would consider all pointers to be the sam...

...E = hole > > > >>> F F = hole > > > >>> ... > > > >>> 1111 1111 1111 1111 = 65535 = all other types > > > >>> > > > >>> 16 Bytes: > > > >>> 0 = unknown type > > > >>> | | = __int128_t > > > >>> I J = long long (under some ABIs) > > > >>> J I = long double (under some ABIs) > > > >>> J J = hole > > > >>> ... > > > >>> -1 = all other types > > > >>> > > > >>&g...