similar to: [LLVMdev] The size of char

On Fri, 20 Aug 2004, Reid Spencer wrote: > On Fri, 2004-08-20 at 18:43, Chris Lattner wrote: > > > I don't understand what you're getting at here. You can change char to > > default to unsigned right now with llvm-gcc -funsigned-char. I don't > > understand how that would change anything to be more useful though. > > The only thing it would change is

On Fri, 2004-08-20 at 18:43, Chris Lattner wrote: > I don't understand what you're getting at here. You can change char to > default to unsigned right now with llvm-gcc -funsigned-char. I don't > understand how that would change anything to be more useful though. The only thing it would change is that character constants with values > 63 would get encoded in 1 byte

On Fri, 2004-08-20 at 19:10, Chris Lattner wrote: > On Fri, 20 Aug 2004, Reid Spencer wrote: > > > > The only thing it would change is that character constants with values > > > 63 would get encoded in 1 byte instead of 2 (with current > > implementation). I'm making a change that will ALWAYS encode UByteTyID > > and SByteTyID constants in 1 byte which would

Robert Mykland wrote: > Dear Chris and Reid: Hi Robert. > > Some other random ideas I've had as I've been sifting through the new > bytecode format. Please let me know what you think. > > 1) ANSI C allows for char to default to unsigned char. This is I guess > not how it normally is in GCC. If char defaulted to unsigned char > several things would be

At 05:09 PM 8/20/2004, you wrote: >On Fri, 20 Aug 2004, Reid Spencer wrote: > > > defined would be almost always stored in one byte instead of the present > > > usual two. > > > > So, if I get you correctly, you're advocating the creation of a > Type::CharTyID > > in the TypeID enumeration that is always written as a single byte? Note > that >

On Fri, 20 Aug 2004, Reid Spencer wrote: > > defined would be almost always stored in one byte instead of the present > > usual two. > > So, if I get you correctly, you're advocating the creation of a Type::CharTyID > in the TypeID enumeration that is always written as a single byte? Note that > right now all ASCII values ( <128 ) will be written as a single byte for

At 02:05 PM 8/20/2004, you wrote: >Robert Mykland wrote: >>Dear Chris and Reid: > >Hi Robert. > >>Some other random ideas I've had as I've been sifting through the new >>bytecode format. Please let me know what you think. >>1) ANSI C allows for char to default to unsigned char. This is I guess >>not how it normally is in GCC. If char defaulted

On Fri, 2004-08-20 at 17:55, Robert Mykland wrote: > At 05:09 PM 8/20/2004, Chris Lattner wrote: > > > >If you're interested in the plans, they are described in some detail here: > >http://nondot.org/sabre/LLVMNotes/TypeSystemChanges.txt > > > >Note that there is no concrete timeline for this to happen, it basically > >depends on when someone is ambitious

On Oct 8, 2007, at 12:47 PM, Duncan Sands wrote: > Hi Evan, thanks for replying. > >>> Now that I'm working on codegen support for arbitrary precision >>> integers (think i36 or i129), I've hit the problem of what >>> getTypeSize and friends should return for such integers (the >>> current implementations seem to me to be wrong). However it's

Hi Evan, thanks for replying. > > Now that I'm working on codegen support for arbitrary precision > > integers (think i36 or i129), I've hit the problem of what > > getTypeSize and friends should return for such integers (the > > current implementations seem to me to be wrong). However it's > > not clear to me how getTypeSize and friends are defined.

On Oct 7, 2007, at 11:23 AM, Duncan Sands wrote: > Now that I'm working on codegen support for arbitrary precision > integers (think i36 or i129), I've hit the problem of what > getTypeSize and friends should return for such integers (the > current implementations seem to me to be wrong). However it's > not clear to me how getTypeSize and friends are defined. > >

Now that I'm working on codegen support for arbitrary precision integers (think i36 or i129), I've hit the problem of what getTypeSize and friends should return for such integers (the current implementations seem to me to be wrong). However it's not clear to me how getTypeSize and friends are defined. There seem to be several possible meanings for the size of a type (only talking

Dear Chris and Reid: Some other random ideas I've had as I've been sifting through the new bytecode format. Please let me know what you think. 1) ANSI C allows for char to default to unsigned char. This is I guess not how it normally is in GCC. If char defaulted to unsigned char several things would be possible. Single char constants that are defined would be almost always stored

On Thu, 2005-21-04 at 09:31 -0400, Vyacheslav Akhmechet wrote: > At this point I cannot know the type of 'i' at compile time. At > runtime 'i' is a structure that contains a type and a function > pointer. What I can't figure out is how to cast my llvm function > pointer to an appropriate function type. I cannot know until runtime > what the type will be.

I was investigating an error diagnostic in the following test example: typedef signed char char16 __attribute__((ext_vector_type(16))); void test( char16 srcA, char16 srcB, char16 *dst) { *dst = ( srcA == srcB ); } which produces the message: mismatch.c:5:10: error: assigning to 'char16' from incompatible type 'char __attribute__((ext_vector_type(16)))' *dst = (

[Reposted from llvm-bugs mailing list. Also has an updated, hopefully better, patch associated with it.] Hi, The following program causes the LLVM GCC4 front end to ICE: struct A { virtual ~A(); }; template <typename Ty> struct B : public A { ~B () { delete [] val; } private: Ty* val; }; template <typename Ty> struct C : public A { C (); ~C (); }; template

Hi Martin, On Oct 2, 2013, at 6:25 AM, Martin O'Riordan <Martin.ORiordan at movidius.com> wrote: > I was investigating an error diagnostic in the following test example: > > typedef signed char char16 __attribute__((ext_vector_type(16))); > > void test( char16 srcA, char16 srcB, char16 *dst) { > *dst = ( srcA == srcB ); > } > > which produces the

I was investigating an error diagnostic in the following test example: typedef signed char char16 __attribute__((ext_vector_type(16))); void test( char16 srcA, char16 srcB, char16 *dst) { *dst = ( srcA == srcB ); } which produces the message: mismatch.c:5:10: error: assigning to 'char16' from incompatible type 'char __attribute__((ext_vector_type(16)))' *dst = (

On Fri, 20 Aug 2004, Robert Mykland wrote: > >In any case, both signed and unsigned 8-bit constants can be written out > >in a single byte. Again, do you think it's worth special casing this > >though? Considering that we handle 8-bit strings specially already, there > >are not a ton of 8-bit constants with value >= 128. > > I'd rather that they not be

Hi, The lli interpreter crashed for the following case: ; ModuleID = 'x.c' target datalayout = "e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32" target triple = "i686-pc-linux-gnu" define i32 @main() { entry: %retval = alloca i32 ; <i32*> [#uses=2] %tmp = alloca i32 ;