I agree: clang should define long to be 64 bits unconditionally. In fact, I thought they already did that for OpenCL.
In the short term, we need to work around this via #defines, typedefs, and stdint.h. This should be straightforward, but will have some warts. printf will need to be corrected anyway; C printf and OpenCL printf are slightly different anyway. I suggest to exclude these for the 0.8 release. This has been broken for some time, to the extent that supporting long on 32 bit platforms is almost a new features. -erik On 2013-07-30, at 17:28 , Pekka Jääskeläinen <[email protected]> wrote: > On 07/30/2013 11:40 PM, Chuck Zhao wrote: >> Just a quick thought, how about using "long long" type to replace "long" >> for OpenCL on 32b platform(s) only? >> >> I checked, on Ubuntu/ARM, long long is 8 byte. >> The apparent part that needs to fix is string format: %d vs. %lld, etc. >> Do people like this idea? >> >> This is not an elegant solution, but may work in the short term. >> Pekka's "slong" type didn't seem to make into pocl-0.8rc8 tree. > > The patch was not finished. If you want you might continue from that, > but it might have "diverged" too much to be of any help. I recall > there was some nasty problem with this approach, but cannot > remember what. > > The cleaner way would be to ask the Clang people what do they think > about fixing the OpenCL C basic type sizes in the frontend. It's > a language feature after all. I think I saw something related to > that added to Clang, but not all the types. > > http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20121119/068545.html > > This discussion thread died. > > Yet another approach would be to consider using the SPIR/SPIR64 > as the target for Clang to standardize the input to pocl. This > would fix the size of the types and might also fix the kernel > calling convention issues (e.g. structs split to multiple arguments > breaking the assumption of clSetKernelArg mapping to the actual > kernel args). https://bugs.launchpad.net/pocl/+bug/987905 > >> Can you post me to the place where configuration fails and disables >> support for int64_t and double? > > Sorry, it's too long since I worked on that patch to > remember. > > -- > --Pekka > > ------------------------------------------------------------------------------ > Get your SQL database under version control now! > Version control is standard for application code, but databases havent > caught up. So what steps can you take to put your SQL databases under > version control? Why should you start doing it? Read more to find out. > http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk > _______________________________________________ > pocl-devel mailing list > [email protected] > https://lists.sourceforge.net/lists/listinfo/pocl-devel -- Erik Schnetter <[email protected]> http://www.perimeterinstitute.ca/personal/eschnetter/ My email is as private as my paper mail. I therefore support encrypting and signing email messages. Get my PGP key from http://pgp.mit.edu/. ------------------------------------------------------------------------------ Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk _______________________________________________ pocl-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/pocl-devel
