Hi, I've had a look over the patches and they Look Good To Me (assuming the plan is to get something definite committed within ForcedLangOpts and then refactoring later if there's a consensus). About the only thing that I noticed was that all other tests that use a static assert open-code it rather than putting it in a macro, but I'm not sure if that's for any reason or not.
Cheers, Dave -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Erik Schnetter Sent: 03 September 2013 21:04 To: Michele Scandale Cc: [email protected] Subject: Re: OpenCL C "long" should always have 64 bits On 2013-09-03, at 14:37 , Michele Scandale <[email protected]> wrote: > On 09/03/2013 07:53 PM, Tom Stellard wrote: >> On Tue, Sep 03, 2013 at 01:34:50PM -0400, Erik Schnetter wrote: >>> Yes, R600 defines a "good" address space map. >>> >>> My patch currently overrides the target-specific address space maps... >>> >>> Instead of doing so, I think the right approach is to define a default >>> address space map that already does the right thing for OpenCL and CUDA. >>> This makes sense since address spaces seem currently defined for OpenCL and >>> CUDA only, i.e. they won't be used by standard C/C++. The targets can then >>> override the default (which they already do). >>> >> >> Does the rest of this patch depend on resolving the mangling issues with >> address spaces? If not, can we split the address space map out into a >> separate patch and commit the rest of the changes? The OpenCL type >> changes are very useful, and I wouldn't want the address space mapping >> discussions to prevent them from being committed. > > I agree. The problems of type size is orthogonal from mangling and address > spaces. I know that it's all related and to have everything working we would > need a global solution, but still being orthogonal they should be solved in > different patches. > > This part related to type size is first step that fix a quite big lack in the > support of OpenCL. > > Then the mangling can be fixed (I'm still waiting for feedback to know if the > last proposed patch can be fine or not to be committed). > > The last part about address space information requires also modification in > the > middle end (I am working on this... soon a proposed patch for metadata > handling). Yes, these issues are unrelated. (However, I still have the address space parts in my source tree to be able to compile and test.) Here is an updated patch against the trunk (previous patch was against 3.3 release branch), with the address space handling removed. I also add two test cases. -erik -- 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/. -- IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you. ARM Limited, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2557590 ARM Holdings plc, Registered office 110 Fulbourn Road, Cambridge CB1 9NJ, Registered in England & Wales, Company No: 2548782 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
