similar to: [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

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

This whole debate seems kind of odd to me. I don't know that cases where it isn't clear what type to use come up that often. If a value can truly never be negative you should use an unsigned value. If a value can be negative, you should use a signed value. Anecdotal evidence in my case is that the vast majority of values are unsigned by this rule. Is there a reason to use a signed value

James Henderson via llvm-dev <llvm-dev at lists.llvm.org> writes: > Maybe it's just because I work in code around the binary file formats > almost exclusively, but unsigned (or more often uint64_t) is FAR more > common than int everywhere I go. I don't have time right now to read > up on the different links you provided, and I expect this is covered > in them, but it

Am Sa., 8. Juni 2019 um 13:12 Uhr schrieb Tim Northover via llvm-dev <llvm-dev at lists.llvm.org>: > I'd prefer us to have something neater than static_cast<int> for the > loop problem before we made that change. Perhaps add an ssize (or > equivalent) method to all of our internal data structures? They're a > lot more common than std::* containers. +1 Since C++20

FWIW, the talks linked by Mehdi really do talk about these things and why I don't think the really are the correct trade-off. Even if you imagine an unsigned type that doesn't allow wrapping, I think this is a really bad type. The problem is that you have made the most common value of the type (zero in every study I'm aware of) be a boundary condition. Today, it wraps to a huge value

On Tue, Jun 11, 2019, 9:59 PM Zachary Turner <zturner at roblox.com> wrote: > On Tue, Jun 11, 2019 at 12:24 PM Mehdi AMINI <joker.eph at gmail.com> wrote: > >> I agree that readability, maintainability, and ability to debug/find >> issues are key. >> I haven't found myself in a situation where unsigned was helping my >> readability: on the opposite

Hi, The LLVM coding style does not specify anything about the use of signed/unsigned integer, and the codebase is inconsistent (there is a majority of code that is using unsigned index in loops today though). I'd like to suggest that we specify to prefer `int` when possible and use `unsigned` only for bitmask and when you intend to rely on wrapping behavior, see:

I'm in the same situation James is in and thus have the same bias but I'll +1 that comment nevertheless. I think I prefer using size_t or the uintX_t types where applicable. Only when I need a signed value do I use one. On Mon, Jun 10, 2019, 9:59 AM James Henderson via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Maybe it's just because I work in code around the binary

On Mon, Jun 10, 2019 at 10:32 AM Aaron Ballman via llvm-dev < llvm-dev at lists.llvm.org> wrote: > > > On Mon, Jun 10, 2019, 7:16 PM Jake Ehrlich via llvm-dev < > llvm-dev at lists.llvm.org> wrote: > >> I'm in the same situation James is in and thus have the same bias but >> I'll +1 that comment nevertheless. I think I prefer using size_t or the

On Tue, Jun 11, 2019 at 1:01 AM Aaron Ballman <aaron.ballman at gmail.com> wrote: > > > On Tue, Jun 11, 2019, 9:51 AM Mehdi AMINI <joker.eph at gmail.com> wrote: > >> >> >> On Tue, Jun 11, 2019 at 12:37 AM Aaron Ballman <aaron.ballman at gmail.com> >> wrote: >> >>> Sorry for the brevity, I am currently travelling and responding

On Tue, Jun 11, 2019 at 12:37 AM Aaron Ballman <aaron.ballman at gmail.com> wrote: > Sorry for the brevity, I am currently travelling and responding on a cell > phone. I won't be able to give you a full accounting until later, > There is no hurry right now! > but 1) I don't see a motivating problem this churn solves, 2) signed int > does not represent the full size

Am Di., 11. Juni 2019 um 11:45 Uhr schrieb Zachary Turner via llvm-dev <llvm-dev at lists.llvm.org>: > > I'm personally against changing everything to signed integers. To me, this is an example of making code strictly less readable and more confusing in order to fight deficiencies in the language standard. I get the problem that it's solving, but I view this as mostly a

Hello, I'd like to introduce myself, my company, and our upcoming use of LLVM. My name is John Reagan. I've been working on compilers and assemblers since 1983 (yes, 31 years). Most of that time was spent on compilers for VAX/VMS (later renamed to OpenVMS), then OpenVMS on Alpha, and OpenVMS on Itanium. I've also worked with the HP NonStop platform and was directly involved

As one of the OS' without current CMake support, I'm closely watching this discussion. We currently have LLVM 3.4.2 hosted on OpenVMS Itanium (as a host only, x86 target) using configure/make with little hassle. We plan to port CMake to OpenVMS, but that has been trickier than you'd think (others have tried, I haven't found anybody who has done it). Looks like I'll want to

I'm not sure if they are doing an x86 to IA64 cross compile, but in any event I'm going to guess they may need an ancient version to avoid any C++11 dependencies. In terms of IA64 compilers you have afaik 3 choices HP compiler, Open64 and Intel? (Does gcc still support it and how up-to-date or EOL is the Intel compiler IA64 support?) I really hope nobody decides not to move to a more

On Wed, May 18, 2016 at 01:10:50PM +0000, Daniel Sanders via llvm-dev wrote: > It's my understanding that llvm-mc is intended to be a testing tool > for LLVM developers rather than an assembler for end users. Users > should be assembling with clang. Not all LLVM users are clang users. For example, we're using LLVM to build OpenVMS cross-compilers to x86 for our porting effort.

As somebody who's currently hosting LLVM on a platform (OpenVMS Itanium) that has configure but not a working CMake (we're working to fix that but there are some tricky issues), I would appreciate if you didn't scrub the existence of configure from the source or the documentation. Perhaps keep pointers to the older pages and link to them from the downloads pages or something with an

Hello all, Pardon me if this has already been covered elsewhere, however I have not been able to find such documentation. Is there a consolidated set of documentation that clearly explains what's necessary to port LLVM to other OSes & how to add support for building executables (& libraries) for those OSes? I'm searching through the source in an attempt to understand what needs to

Hi all, We're at the point in our port of OpenVMS to x86-64 that we're working on the unwind code.  The current ABI and the current codebase doesn't have enough support for true asynchronous unwinding from any point (most notably in the prologue/epilogue) in the code that OpenVMS needs.  We're working on a set of changes to the compact unwind information to handle the additional