similar to: [LLVMdev] How do downcast signed integers?

Hello > I was looking at "trunc" to downcast a signed integer, say sint32 to sint16, > but it seems to handle unsigned integers only. No. In twos-complement notation (which LLVM assumes) there no difference between signed and unsigned truncation - you just throw out the spare sign bits and that's all. Please note that that the "numbers" in LLVM IR is neither signed

In order to compile the latest Vorbis library on the Macintosh, the change appended to this message needs to be made to os_types.h.in. Then, anyone who wants to actually build it must first copy os_types.h.in to os_types.h by hand, since MacOS does not include a command line and thus cannot run configure. It really bugs me that the whole "platforms which don't support configure

Please change all longs to int, and never use them in the future :) They arent needed as on most platforms they are the same size. (which is the assumption made in the ogg code anyway) The reason for this is i will have vorbis support on playstation 2, but long is 64 bits, and they are excruciatingly slow. cheers Brett Paterson --- >8 ---- List archives: http://www.xiph.org/archives/ Ogg

I've been debugging some strange happenings over here and I put an assert in APInt to catch what I think is the source of the problem: int64_t getSExtValue() const { // An i1 -1 is unrepresentable. assert(BitWidth != 1 && "Signed i1 value is not representable!"); To me an i1 -1 makes no sense whatsoever. It is not representable in twos-complement form. It cannot

On 9/17/18 3:38 PM, Richard W.M. Jones wrote: > These are used at various places in the code already. This > refactoring simply moves them to a common header file and should have > no other effect. > --- > common/include/rounding.h | 59 +++++++++++++++++++++++++++++++++++++ > filters/cache/Makefile.am | 3 +- > filters/cache/cache.c | 2 +- >

How can I check if a particular Integer Type is signed/unsigned? Arushi -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20100916/baea061d/attachment.html>

> On 2016-Jul-11, at 09:05, Ulrich Weigand <ulrich.weigand at de.ibm.com> wrote: > > uweigand accepted this revision. > uweigand added a comment. > This revision is now accepted and ready to land. > > I'll defer to your expertise on that. Patch looks good to me. > > I guess I'm not fully familiar with some of the C++ language details here. Would you

On Aug 22, 2008, at 9:34 AM, Chris Lattner wrote: > C has a way to express this: signed integers are defined to never > overflow, unsigned integers are defined to wrap gracefully on > overflow. And gcc has yet more fun in it: -fstrict-overflow Allow the compiler to assume strict signed overflow rules, depending on the language being compiled. For C

In the language I am working on, there are cases where the call flow graph can affect the type of a variable. A simple example is a "nullable" type (a pointer which is allowed to be NULL), which can be converted into a non-nullable type via an if-test. So for example if x is nullable, and I test x != NULL, then inside the conditional block the type of x is no longer nullable.

On May 23, 2008, at 11:53 PM, Talin wrote: > In the language I am working on, there are cases where the call flow > graph can affect the type of a variable. Ok. > A simple example is a > "nullable" type (a pointer which is allowed to be NULL), which can be > converted into a non-nullable type via an if-test. So for example if x > is nullable, and I test x != NULL,

On Aug 22, 2008, at 9:30 AM, Vikram S. Adve wrote: > In the general case, I think you have to be conservative about this > because programmers may deliberately want this kind of "wraparound" > behavior, e.g., with periodic boundary conditions. But 99.9% of > programs probably don't need that so it would be bad to penalize them > for this corner case. In such a

I am acquiring some sampled data that is time-stamped (with a POSIXct). Some of the data is in the form of "counters" -- that is, what is interesting isn't value of a given counter at a given time, but the change in the counter from one sample to a later one. As the counters are only incremented, they would be perceived to be monotonically increasing -- ideally. Unfortunately, the

On Wed, Feb 15, 2017 at 04:37:49PM -0500, Waiman Long wrote: > The cpu argument in the function prototype of vcpu_is_preempted() > is changed from int to long. That makes it easier to provide a better > optimized assembly version of that function. > > For Xen, vcpu_is_preempted(long) calls xen_vcpu_stolen(int), the > downcast from long to int is not a problem as vCPU number

On Wed, Feb 15, 2017 at 04:37:49PM -0500, Waiman Long wrote: > The cpu argument in the function prototype of vcpu_is_preempted() > is changed from int to long. That makes it easier to provide a better > optimized assembly version of that function. > > For Xen, vcpu_is_preempted(long) calls xen_vcpu_stolen(int), the > downcast from long to int is not a problem as vCPU number

On Thu, Feb 25, 2016 at 04:46:50PM -0800, Hans Boehm wrote: > If carries_dependency affects semantics, then it should not be an attribute. I am not picky about the form of the marking. > 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

- Replaced blanket #define of 8 & 64 bit types with typedefs for each platform to match 16 & 32 bit types. - Updated existing typedefs for each platform to fix odd values and improve consistency. --- include/opus_types.h | 125 ++++++++++++++++++++++++++++++++++++++++----------- 1 file changed, 100 insertions(+), 25 deletions(-) diff --git a/include/opus_types.h

On Feb 27, 2016 09:06, "Paul E. McKenney" <paulmck at linux.vnet.ibm.com> wrote: > > > But we do already have something very similar with signed integer > overflow. If the compiler can see a way to generate faster code that > does not handle the overflow case, then the semantics suddenly change > from twos-complement arithmetic to something very strange. The

On Sat, Feb 27, 2016 at 11:16:51AM -0800, Linus Torvalds wrote: > On Feb 27, 2016 09:06, "Paul E. McKenney" <paulmck at linux.vnet.ibm.com> > wrote: > > > > > > But we do already have something very similar with signed integer > > overflow. If the compiler can see a way to generate faster code that > > does not handle the overflow case, then the

On 24/11/2012, at 10:21 PM, Nick Lewycky wrote: > > Passing an uninitialized value as a function argument is undefined behaviour on the spot, regardless of what the callee does (even if it never references that argument). Cite reference? No? Then you're guessing ;) > > That aside, there is no way that 'i' has the same value, since it has no value. This is definitely

"Duncan P. N. Exon Smith via llvm-dev" <llvm-dev at lists.llvm.org> writes: >> On 2015-Oct-20, at 11:23, Reid Kleckner <rnk at google.com> wrote: >> >> I think the implicit iterator conversions are much less important >> now that we have range based for loops, but I still like having >> them. > > IMO, if a developer has an ilist iterator