search for: 8ll

...> > [Villmow, Micah] OpenCL C defines 'int' to be 32bits irrespective of > the > > host/device bitness. So this would follow the normal integer > promotion > > rules. > > I think you're misunderstanding the issue: the point is, is > "sizeof(int) + -8LL < 0" true or false? [Villmow, Micah] Yep, I don't see why this is any different than "4 + -8LL < 0". OpenCL C, and in turn SPIR, defines sizeof(int) == 4. While this might be a problem in C, this isn't an issue in OpenCL since there is no variance in the sizeof(int) ac...

...> > [Villmow, Micah] OpenCL C defines 'int' to be 32bits irrespective of > the > > host/device bitness. So this would follow the normal integer > promotion > > rules. > > I think you're misunderstanding the issue: the point is, is > "sizeof(int) + -8LL < 0" true or false? [Villmow, Micah] Yep, I don't see why this is any different than "4 + -8LL < 0". OpenCL C, and in turn SPIR, defines sizeof(int) == 4. While this might be a problem in C, this isn't an issue in OpenCL since there is no variance in the sizeof(int) ac...

...C defines 'int' to be 32bits irrespective of > > the > > > host/device bitness. So this would follow the normal integer > > promotion > > > rules. > > > > I think you're misunderstanding the issue: the point is, is > > "sizeof(int) + -8LL < 0" true or false? > [Villmow, Micah] Yep, I don't see why this is any different than "4 + -8LL > < 0". OpenCL C, and in turn SPIR, defines sizeof(int) == 4. While this > might be a problem in C, this isn't an issue in OpenCL since there is no > variance i...

...C defines 'int' to be 32bits irrespective of > > the > > > host/device bitness. So this would follow the normal integer > > promotion > > > rules. > > > > I think you're misunderstanding the issue: the point is, is > > "sizeof(int) + -8LL < 0" true or false?**** > > [Villmow, Micah] Yep, I don't see why this is any different than "4 + -8LL > < 0". OpenCL C, and in turn SPIR, defines sizeof(int) == 4. While this > might be a problem in C, this isn't an issue in OpenCL since there is no > v...

...its irrespective > of > >> the > >> > host/device bitness. So this would follow the normal integer > >> promotion > >> > rules. > >> > >> I think you're misunderstanding the issue: the point is, is > >> "sizeof(int) + -8LL < 0" true or false? > > > > [Villmow, Micah] Yep, I don't see why this is any different than "4 + > -8LL < > > 0". OpenCL C, and in turn SPIR, defines sizeof(int) == 4. While this > might > > be a problem in C, this isn't an issue in OpenC...

...;> >> the >> >> > host/device bitness. So this would follow the normal integer >> >> promotion >> >> > rules. >> >> >> >> I think you're misunderstanding the issue: the point is, is >> >> "sizeof(int) + -8LL < 0" true or false? >> > >> > [Villmow, Micah] Yep, I don't see why this is any different than "4 + >> -8LL < >> > 0". OpenCL C, and in turn SPIR, defines sizeof(int) == 4. While this >> might >> > be a problem in C, this isn...

...OpenCL C defines 'int' to be 32bits irrespective of >> the >> > host/device bitness. So this would follow the normal integer >> promotion >> > rules. >> >> I think you're misunderstanding the issue: the point is, is >> "sizeof(int) + -8LL < 0" true or false? > > [Villmow, Micah] Yep, I don't see why this is any different than "4 + -8LL < > 0". OpenCL C, and in turn SPIR, defines sizeof(int) == 4. While this might > be a problem in C, this isn't an issue in OpenCL since there is no variance &...

...ze_t is 64 bits wide. How is this handled? > > [Villmow, Micah] OpenCL C defines ‘int’ to be 32bits irrespective of the > host/device bitness. So this would follow the normal integer promotion > rules. I think you're misunderstanding the issue: the point is, is "sizeof(int) + -8LL < 0" true or false? -Eli

...enum E { a = sizeof(void*) // is this valid? }; Answer: we are discussing this and will provide an answer soon. ****comment 6: What is the rank of ‘size_t’? example: is "sizeof(int) + -8LL < 0" true or false? Answer: we are discussing this and will provide an answer soon. ****comment 7: Why can't we always make size_t 64 bits wide? If we ignore the issue of size_t inside structs, I don't see the pr...

...is this valid? }; Answer: we are discussing this and will provide an answer soon. [Guy Benyei] Same goes here - this source is not functionally portable. ****comment 6: What is the rank of ‘size_t’? example: is "sizeof(int) + -8LL < 0" true or false? Answer: we are discussing this and will provide an answer soon. [Guy Benyei] We discussed this case a lot, and IMO there are two possible solutions: we can either assign a rank to size_t, s.t. rank(long) < rank(ptrdiff_t) < rank(size_t) < ran...

From: metafoo at gmail.com [mailto:metafoo at gmail.com] On Behalf Of Richard Smith Sent: Wednesday, September 12, 2012 2:51 PM To: Villmow, Micah Cc: Ouriel, Boaz; cfe-dev at cs.uiuc.edu; llvmdev at cs.uiuc.edu Subject: Re: [LLVMdev] SPIR Portability Discussion On Wed, Sep 12, 2012 at 2:23 PM, Villmow, Micah <Micah.Villmow at amd.com<mailto:Micah.Villmow at amd.com>> wrote: From:

...ect it? The only reasonable way I can think of is banning sizeof(void*) and friends in integer constant expressions, which will work, but might make existing code non-SPIR-compatible. > ****comment 6: What is the rank of ‘size_t’? > example: is "sizeof(int) + -8LL < 0" true or false? > Answer: we are discussing this and will provide an answer soon. > > [Guy Benyei] We discussed this case a lot, and IMO there are two possible solutions: we can either assign a rank to size_t, s.t. rank(long) < rank(ptrdiff_t) < rank(si...

...a = sizeof(void*) // is this valid? }; Answer: sizeof(void*) is not a frontend compile time constant, so you get a SPIR frontend compile error. ****comment 6: What is the rank of 'size_t'? example: is "sizeof(int) + -8LL < 0" true or false? Answer: The rank of size_t is either uint for 32bit devices and ulong for 64bit devices (int < uint ( == size_t for 32bit) < long ( == size_t for 64bit) < ulong) This means that the only ambiguity is whe...