John Reagan via llvm-dev
2019-Jun-12 21:01 UTC
[llvm-dev] [RFC] Coding Standards: "prefer `int` for, regular arithmetic, use `unsigned` only for bitmask and when you, intend to rely on wrapping behavior."
On Tue, Jun 11, 2019 at 12:26 PM Michael Kruse <llvmdev at meinersbur.de> wrote: vector.size() returns a size_t, which on 64-bit platforms can represent types values larger than those that can fit into an int64_t. So to turn your argument around, since it's theoretically possible to have a vector with more items than an int64_t can represent, isn't it already worth it to use size_t, which is an unsigned type? That's not true on my platform. I have 64-bit pointers so intptr_t is 64-bits, but the largest thing you can allocate is only 32-bits big so size_t (and ptrdiff_t) are 32-bits. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190612/7ecc6f56/attachment.sig>
JF Bastien via llvm-dev
2019-Jun-13 16:00 UTC
[llvm-dev] [RFC] Coding Standards: "prefer `int` for, regular arithmetic, use `unsigned` only for bitmask and when you, intend to rely on wrapping behavior."
> On Jun 12, 2019, at 2:01 PM, John Reagan via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On Tue, Jun 11, 2019 at 12:26 PM Michael Kruse <llvmdev at meinersbur.de> > wrote: > > vector.size() returns a size_t, which on 64-bit platforms can represent > types values larger than those that can fit into an int64_t. So to turn > your argument around, since it's theoretically possible to have a vector > with more items than an int64_t can represent, isn't it already worth it > to use size_t, which is an unsigned type? > > > That's not true on my platform. I have 64-bit pointers so intptr_t is > 64-bits, but the largest thing you can allocate is only 32-bits big so > size_t (and ptrdiff_t) are 32-bits.It runs LLVM?
John Reagan via llvm-dev
2019-Jun-13 16:19 UTC
[llvm-dev] [RFC] Coding Standards: "prefer `int` for, regular arithmetic, use `unsigned` only for bitmask and when you, intend to rely on wrapping behavior."
Yes. We currently build LLVM 3.4.2 on our OpenVMS Itanium box with an older EDG/Intel C++03 compiler to create legacy cross-compilers to our OpenVMS x86 box (well, VirtualBox). We do have a few tweaks to the relocations to access static data always through the GOT (including CodeGen's static data). Our linker sees references to code (which might be in 64-bit space) and creates trampolines in 32-bit space. That lets any legacy code from the VAX-days to continue to take the address of a routine and save it into some INTEGER*4 Fortran variable. So mostly a small memory model with a few things from medium/large. I've been unable to build the companion clang 3.4.2 however as its use of templates seems to push our old compiler over the edge of sanity. We're working on bootstrapping 8.0.0. Compile 8.0.0 on Linux, move objects to our OpenVMS Itanium box to use the cross-linker (which can handle Linux objects as well as our own), move the resulting image to our OpenVMS x86 box... (and the same thing for libcxx, compiler-rt, libcxxabi, etc.) and with a wave of a magic wand, we end up with a native clang. And with a little more waving, our other legacy compilers (our C, BLISS, Pascal, COBOL, BASIC, and Fortran) I'm planning on submitting a lightning talk for this fall on "When 3 memory models isn't enough." On 6/13/19 12:00 PM, JF Bastien wrote:> > >> On Jun 12, 2019, at 2:01 PM, John Reagan via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> On Tue, Jun 11, 2019 at 12:26 PM Michael Kruse <llvmdev at meinersbur.de> >> wrote: >> >> vector.size() returns a size_t, which on 64-bit platforms can represent >> types values larger than those that can fit into an int64_t. So to turn >> your argument around, since it's theoretically possible to have a vector >> with more items than an int64_t can represent, isn't it already worth it >> to use size_t, which is an unsigned type? >> >> >> That's not true on my platform. I have 64-bit pointers so intptr_t is >> 64-bits, but the largest thing you can allocate is only 32-bits big so >> size_t (and ptrdiff_t) are 32-bits. > > It runs LLVM? >-------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 833 bytes Desc: OpenPGP digital signature URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20190613/97fa1baa/attachment.sig>
Apparently Analagous Threads
- [RFC] Coding Standards: "prefer `int` for, regular arithmetic, use `unsigned` only for bitmask and when you, intend to rely on wrapping behavior."
- [RFC] Coding Standards: "prefer `int` for, regular arithmetic, use `unsigned` only for bitmask and when you, intend to rely on wrapping behavior."
- [RFC] Coding Standards: "prefer `int` for regular arithmetic, use `unsigned` only for bitmask and when you intend to rely on wrapping behavior."
- [RFC] Coding Standards: "prefer `int` for regular arithmetic, use `unsigned` only for bitmask and when you intend to rely on wrapping behavior."
- [RFC] Coding Standards: "prefer `int` for regular arithmetic, use `unsigned` only for bitmask and when you intend to rely on wrapping behavior."