[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]

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