[llvm-dev] [RFC] Coding Standards: "prefer `int` for, regular arithmetic, use `unsigned` only for bitmask and when you, intend to rely on wrapping behavior."
JF Bastien via llvm-dev
llvm-dev at lists.llvm.org
Thu Jun 13 09:25:11 PDT 2019
> On Jun 13, 2019, at 9:19 AM, John Reagan <john.reagan at vmssoftware.com> wrote:
> 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.”
This is a rare occurrence… but you leave me speechless. I don’t even know where to start.
> 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>
>>> 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?
More information about the llvm-dev