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

Greetings everyone, I am Abhay Raj Singh, a 2nd-year student at NIT Hamirpur, Bharat(India). I am very interested in the project titled "Improve parallelism-aware analyses and optimizations" I would like to apologize for contacting so late I had midterm examination, finished recently. I have taken a course on OpenMP from YouTube which was supported by Intel I have ~4-5 years of

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

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

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

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

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

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

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

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

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

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

LLVM Weekly - #155, Dec 19th 2016 ================================= If you prefer, you can read a HTML version of this email at <http://llvmweekly.org/issue/155>. Welcome to the one hundred and fifty-fifth issue of LLVM Weekly, a weekly newsletter (published every Monday) covering developments in LLVM, Clang, and related projects. LLVM Weekly is brought to you by [Alex

On Fri, Feb 19, 2016 at 09:15:16PM -0500, Tony V E wrote: > There's at least one easy answer in there: > > > ‎If implementations must support annotation, what form should that > annotation take?  P0190R0 recommends the [[carries_dependency]] > attribute, but I am not picky as long as it can be (1) applied > to all relevant pointer-like objects and (2) used in C as well

If carries_dependency affects semantics, then it should not be an attribute. The original design, or at least my understanding of it, was that it not have semantics; it was only a suggestion to the compiler that it should preserve dependencies instead of inserting a fence at the call site. Dependency-based ordering would be preserved in either case. But I think we're moving away from that

I have windows version of R v1.6.2 I have downloaded the qtoolbox.zip from http://www.cmis.csiro.au/S-PLUS/qtoolbox/ My R command line is > install.packages("C:/Program Files/R/qtoolbox.zip", .libPaths()[1], CRAN = NULL) and I get the following error message: updating HTML package descriptions Warning message: error -1 in extracting from zip file > Is there another way to

Using the input below, can I do something more elegant (and more efficient) than the loop also listed below to pad strings to a width of 5? The true matrix is about 300K rows and 31 columns. ####################### #INPUT ####################### > temp DX1 DX2 DX3 1 13761 8125 49178 2 63371 v75 22237 3 51745 77703 93500 4 64081 32826 v72 5 78477 43828 87645 >

Hello! A proposal (quaintly identified as P0190R0) for a new memory_order_consume definition may be found here: http://www2.rdrop.com/users/paulmck/submission/consume.2016.02.10b.pdf As requested at the October C++ Standards Committee meeting, this is a follow-on to P0098R1 that picks one alternative and describes it in detail. This approach focuses on existing practice, with the goal of