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

..., Kito Cheng via llvm-dev <llvm-dev at lists.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...

....h */ typedef unsigned __int64 uint64_t; typedef unsigned __int32 uint32_t; typedef unsigned __int16 uint16_t; typedef unsigned __int8 uint8_t; typedef __int64 int64_t; typedef __int32 int32_t; typedef __int16 int16_t; typedef __int8 int8_t; #if defined(_M_IX64) typedef unsigned __int128 uint128_t; typedef __int128 int128_t; #endif

...64 uint64_t; typedef unsigned __int32 uint32_t; typedef >> unsigned __int16 uint16_t; typedef unsigned __int8 uint8_t; >> typedef __int64 int64_t; typedef __int32 int32_t; typedef __int16 >> int16_t; typedef __int8 int8_t; #if defined(_M_IX64) typedef >> unsigned __int128 uint128_t; typedef __int128 int128_t; #endif > > Also, I agree with the consensus that developers have to #include > such a file before using including FLAC/all.h This is because many > Windows developers (such as myself) are likely to already have a > stdint.h replacement defined somewhere i...

Hi Duncan- > does this also check that writes are atomic: that they are performed in > one processor operation? Can you elaborate a bit? I don't think volatile has any atomicity requirements. Of course I can make a struct, an int128_t, or whatever volatile (on AVR even an int16_t is updated non-atomically!). Lack of atomicity is one of many problems with using volatile as a basis for creating correct systems code... Thanks, John

...mong the folks on the list. However, I was unable to actually come up with an example where this inhibits optimizations coming from C code. I myself have this problem as a real problem in a non-C frontend, which allows for more stringent AA. With that in mind, consider void foo(unsigned int *data, int128_t *value) { for (int i = 1; i < 100; ++i) { data[i] += (int)*value; } } This will get lowered to something like (pseudo llvm IR here) for.body: %l = load i128, i128* %value, !tbaa !1 %t = trunc %l to i32 %gep = ... %old = load i32, i32* %gep, !tbaa !2 %new = add i32 %t, %old stor...

...; typedef unsigned __int32 uint32_t; > typedef unsigned __int16 uint16_t; > typedef unsigned __int8 uint8_t; > typedef __int64 int64_t; > typedef __int32 int32_t; > typedef __int16 int16_t; > typedef __int8 int8_t; > #if defined(_M_IX64) > typedef unsigned __int128 uint128_t; > typedef __int128 int128_t; > #endif Also, I agree with the consensus that developers have to #include such a file before using including FLAC/all.h This is because many Windows developers (such as myself) are likely to already have a stdint.h replacement defined somewhere in their projec...

Hi John, > A "volatile error" indicates a case where a compiler failed to respect > the volatile invariant. The volatile invariant is simply that changing > the optimization level of a strictly conforming C program must not > change the number of dynamic loads or stores to any variable that is > volatile-qualified in the compiler's input. We check this with a hacked

Hi John, > > does this also check that writes are atomic: that they are performed in > > one processor operation? > > Can you elaborate a bit? I don't think volatile has any atomicity > requirements. Of course I can make a struct, an int128_t, or whatever > volatile (on AVR even an int16_t is updated non-atomically!). that's not entirely true in practice: if I do a 32 bit volatile write to a memory-mapped i/o location, then I'd be annoyed if that got turned into four 8 bit volatile writes. And the hardware might react funn...

Hi folks, We recently generated some data that seemed interesting enough to share here. This is a comparison between compilers that ignores the performance of the generated code and focuses only on compiler correctness. volatile checksum errors errors avr-gcc-3.4 1.879% 0.378% avr-gcc-4.1 0.037% 0.256% avr-gcc-4.2