Now a simple user

2013-09-13 Thread Gabriel Dos Reis
Hi, As you probably noticed, I relinquished my GCC maintainer privileges (including the Release Management bit which was still set.) It was a very difficult decision, but I'am taking on a new rĂ´le that is incompatible with my continuing being a GCC maintainer or contributor. I would like to emp

ilp32 far pointers

2013-09-13 Thread David McQuillan
Has there been an implementation or design of a way of representing 64 bit pointers with ilp32 on a 64 bit system? I know this sounds like it is rather pushing the boundary and one should just use the lp64 but I believe it could save effort in a number of circumstances. What I was thinking of i

Re: [RFC] Offloading Support in libgomp

2013-09-13 Thread Jakub Jelinek
On Fri, Sep 13, 2013 at 02:36:14PM +0200, Jakub Jelinek wrote: > FYI, I'm attaching a WIP patch with the splay tree stuff, debugging > target-1.c with OMP_DEFAULT_DEVICE=257 right now (with all tgtv related > stuff removed), but hitting some error regarding OMP_CLAUSE_MAP_POINTER > reallocation, su

Re: [RFC] Offloading Support in libgomp

2013-09-13 Thread Ilya Tocar
Hi, I'm working on dumping gimple for "omp pragma target" stuff into gnu.target_lto_ sections. I've tried to reuse current lto infrastructure as much as possible. Could you please take a look at attached patch? gomp_out.patch Description: Binary data

Re: [RFC] Offloading Support in libgomp

2013-09-13 Thread Jakub Jelinek
On Fri, Sep 13, 2013 at 05:11:09PM +0400, Michael V. Zolotukhin wrote: > > FYI, I'm attaching a WIP patch with the splay tree stuff. > Thanks, I'll take a look. By the way, isn't it better to move splay-tree > implementation to a separate file? As it is just a few routines, heavily modified from

Re: [RFC] Offloading Support in libgomp

2013-09-13 Thread Michael V. Zolotukhin
> But I doubt dirent.h is portable to all targets we support, so I believe it > needs another configure test, and perhaps we want to define some macro > whether we actually support offloading at all (HAVE_DLFCN_H would be one > precondition, HAVE_DIRENT_H (with opendir etc.) another one (for this t

Re: [RFC] Offloading Support in libgomp

2013-09-13 Thread Jakub Jelinek
On Fri, Sep 13, 2013 at 03:29:30PM +0400, Michael V. Zolotukhin wrote: > Here is the first patch for adding plugins support in libgomp - could you > please > take a look at it? > > I changed configure.ac to add dl-library, but I am not sure if I regenerated > all > related to configure files pro

Re: [RFC] Offloading Support in libgomp

2013-09-13 Thread Michael V. Zolotukhin
Hi Jakub, Here is the first patch for adding plugins support in libgomp - could you please take a look at it? I changed configure.ac to add dl-library, but I am not sure if I regenerated all related to configure files properly. I'd appreciate your help here, if I did it wrong. Any feedback is we

Re: [RFC] Offloading Support in libgomp

2013-09-13 Thread Michael V. Zolotukhin
Hi Nathan, > This is an interesting design. It appears similar to how we'd > envisioned implementing openacc support -- namely leverage the LTO > machinery to communicate from the host compiler to the device > compiler. Your design looks more detailed, which is good. Thanks, do you have a simila

Re: [RFC] Offloading Support in libgomp

2013-09-13 Thread Nathan Sidwell
On 09/13/13 10:34, Michael Zolotukhin wrote: Hi Jakub et al., We prepared a draft for design document for offloading support in GCC - could you please take a look? It is intended to give a common comprehension of what is going on in this part. This is an interesting design. It appears similar

Re: [RFC] Offloading Support in libgomp

2013-09-13 Thread Kirill Yukhin
Hello, Adding Richard who might want to take a look at LTO stuff. -- Thanks, K

Re: [RFC] Offloading Support in libgomp

2013-09-13 Thread Michael Zolotukhin
Hi Jakub et al., We prepared a draft for design document for offloading support in GCC - could you please take a look? It is intended to give a common comprehension of what is going on in this part. We might publish it to a GCC wiki, if it is ok. And later we could fill it with more details if n