llvm dev - Jun 2019 - [RFC] Coding Standards: "prefer `int` for, regular arithmetic, use `unsigned` only for bitmask and when you, intend to rely on wrapping behavior."

> -----Original Message-----
> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of JF
> Bastien via llvm-dev
> Sent: Thursday, June 13, 2019 12:25 PM
> To: John Reagan
> Cc: llvm-dev at lists.llvm.org
> Subject: Re: [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 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.
The word-size migration is rare but not unique.  The HP/Tandem NonStop
line has moved from 16-bit to 32-bit to 64-bit over the decades, and we
needed to handle mixed-size pointers and "int" weirdness at each
stage.
OpenVMS is a special snowflake in terms of its LLVM bootstrapping process, 
and the mind just boggles at what John and his team have had to contend 
with. But the size part is certainly familiar to me, and actually simpler
than what NonStop had to deal with. (We weren't using LLVM, clearly, but
container size etc. is not a particularly LLVM-specific issue.)
--paulr
> 
> 
> > 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?
> >>
> >
> 
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

I have not chimed in on the general signed/unsigned discussion, but my
experience porting software to various embedded systems and game consoles over
the years has taught me to always prefer using explicitly sized integer types
except where size_t should be used.

While it is generally true that most modern 64-bit architectures all agree on
the meanings of `short`, `long`, `unsigned`, `int`, and others. There is no
guarantee of that. I would strongly support a coding standard that suggested
preferring explicitly sized integer types (i.e. int64_t) over `int`.

-Chris 
> On Jun 14, 2019, at 6:40 AM, via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
> 
> 
> 
>> -----Original Message-----
>> From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org
<mailto:llvm-dev-bounces at lists.llvm.org>] On Behalf Of JF
>> Bastien via llvm-dev
>> Sent: Thursday, June 13, 2019 12:25 PM
>> To: John Reagan
>> Cc: llvm-dev at lists.llvm.org <mailto:llvm-dev at
lists.llvm.org>
>> Subject: Re: [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 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.
> 
> The word-size migration is rare but not unique.  The HP/Tandem NonStop
> line has moved from 16-bit to 32-bit to 64-bit over the decades, and we
> needed to handle mixed-size pointers and "int" weirdness at each
stage.
> OpenVMS is a special snowflake in terms of its LLVM bootstrapping process, 
> and the mind just boggles at what John and his team have had to contend 
> with. But the size part is certainly familiar to me, and actually simpler
> than what NonStop had to deal with. (We weren't using LLVM, clearly,
but
> container size etc. is not a particularly LLVM-specific issue.)
> --paulr
> 
>> 
>> 
>>> 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?
>>>> 
>>> 
>> 
>> _______________________________________________
>> LLVM Developers mailing list
>> llvm-dev at lists.llvm.org
>> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
<https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20190614/80e7ec26/attachment.html>

+1.

                     -David

Chris Bieneman via llvm-dev <llvm-dev at lists.llvm.org> writes:
> I have not chimed in on the general signed/unsigned discussion, but my
experience porting software to various embedded systems and game consoles over
the
> years has taught me to always prefer using explicitly sized integer types
except where size_t should be used.
>
> While it is generally true that most modern 64-bit architectures all agree
on the meanings of `short`, `long`, `unsigned`, `int`, and others. There is no
guarantee of
> that. I would strongly support a coding standard that suggested preferring
explicitly sized integer types (i.e. int64_t) over `int`.
>
> -Chris 
>
>  On Jun 14, 2019, at 6:40 AM, via llvm-dev <llvm-dev at
lists.llvm.org> wrote:
>
>  -----Original Message-----
>  From: llvm-dev [mailto:llvm-dev-bounces at lists.llvm.org] On Behalf Of JF
>  Bastien via llvm-dev
>  Sent: Thursday, June 13, 2019 12:25 PM
>  To: John Reagan
>  Cc: llvm-dev at lists.llvm.org
>  Subject: Re: [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 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.
>
>  The word-size migration is rare but not unique.  The HP/Tandem NonStop
>  line has moved from 16-bit to 32-bit to 64-bit over the decades, and we
>  needed to handle mixed-size pointers and "int" weirdness at each
stage.
>  OpenVMS is a special snowflake in terms of its LLVM bootstrapping process,
>  and the mind just boggles at what John and his team have had to contend 
>  with. But the size part is certainly familiar to me, and actually simpler
>  than what NonStop had to deal with. (We weren't using LLVM, clearly,
but
>  container size etc. is not a particularly LLVM-specific issue.)
>  --paulr
>
>  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?
>
>  _______________________________________________
>  LLVM Developers mailing list
>  llvm-dev at lists.llvm.org
>  https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>  _______________________________________________
>  LLVM Developers mailing list
>  llvm-dev at lists.llvm.org
>  https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev