Re: Ideas for Google Summer of Code

> I am a PhD student who has been working with CUDA for the GPU and also > gcc for Cell BE for about a year now. (By work I mean developing > applications). I am looking to bring GCC closer to being able to > support OpenCL as a Google Summer of Code. This is very interesting and I'm willing to h

Re: Minimum GMP/MPFR version bumps for GCC-4.5

Ralf Corsepius writes: > Pardon, there seems to be a misunderstanding. I only was surprised to see > FreeBSD shipping much newer versions of packages than most Linux distros > (even those who claim to be "(b)leading edge"). If you want to have the bleading edge you need to look at something like

Re: Ideas for Google Summer of Code

On Mon, 30 Mar 2009, Paolo Bonzini wrote: > 2) half-precision floats; I expect Sandra will be merging half-precision support for ARM to trunk fairly soon; see her announcement . This includes generic support for the IEEE half-precision

Re: Ideas for Google Summer of Code

Joseph S. Myers wrote: > On Mon, 30 Mar 2009, Paolo Bonzini wrote: > >> 2) half-precision floats; > > I expect Sandra will be merging half-precision support for ARM to trunk > fairly soon; see her announcement > . This includes > generi

Re: Linking libgfortran with libiberty

Jakub Jelinek wrote: > On Sun, Mar 29, 2009 at 01:00:50PM +0200, FX wrote: >> This mail is a request for some help from our local build machinery >> experts... We have a patch under testing for libgfortran to add >> runtime memleaks checking, and it uses libiberty's hash tables. So, we >> now

Re: Linking libgfortran with libiberty

+1. If libgfortran includes a custom allocator of any sort (does it?) instead of using malloc/free, it should use valgrind hooks like those we already have in GCC. libgfortran uses malloc/free. Regarding valgrind, it's not supported on all GCC targets, so it's not a valid alternative to o

Re: Linking libgfortran with libiberty

FX wrote: >> +1. If libgfortran includes a custom allocator of any sort (does it?) >> instead of using malloc/free, it should use valgrind hooks like those we >> already have in GCC. > > libgfortran uses malloc/free. > > Regarding valgrind, it's not supported on all GCC targets, so it's not a >

Re: Linking libgfortran with libiberty

> For Windows, I found > http://www.codeproject.com/KB/applications/visualleakdetector.aspx which > is free (LGPL); I don't know how good it is and it may be hard to > compile it to GCC, but doing that would be a better service than adding > a leak detector to libgfortran (Purify is proprietary an

Re: Ideas for Google Summer of Code

On Mon, Mar 30, 2009 at 01:09:56AM -0700, Paolo Bonzini wrote: > > I am a PhD student who has been working with CUDA for the GPU and also > > gcc for Cell BE for about a year now. (By work I mean developing > > applications). I am looking to bring GCC closer to being able to > > support OpenCL as

Re: Ideas for Google Summer of Code

Hi All, Thanks for the feedback. As far as the NVIDIA ISA details, I have the pdf that describes it. In the CUDA toolkit, available on NVIDIA's website there is a pdf named ptx_isa_1.3.pdf under the doc directory. (Get it from here http://www.nvidia.com/object/cuda_get.html). So we can do Intel

Re: Ideas for Google Summer of Code

On Mon, Mar 30, 2009 at 10:10:24AM -0700, phil++ wrote: > Hi All, > > Thanks for the feedback. As far as the NVIDIA ISA details, I have the > pdf that describes it. In the CUDA toolkit, available on NVIDIA's > website there is a pdf named ptx_isa_1.3.pdf under the doc directory. > (Get it from h

Re: Ideas for Google Summer of Code

> So we can do Intel, ATI and NVIDIA GPU backends. NVIDIA already has > an implementation of OpenCL working. > http://www.nvidia.com/object/cuda_opencl.html. Would there be any > sharing involved with them?? If you mean between backends, 1) do not underestimate the time needed to write a new GCC

Re: Ideas for Google Summer of Code

Joe Buck, You have to choose an operating system and then a table appears below it to download the CUDA toolkit. Phil On Mon, Mar 30, 2009 at 1:32 PM, Joe Buck wrote: > On Mon, Mar 30, 2009 at 10:10:24AM -0700, phil++ wrote: >> Hi All, >> >> Thanks for the feedback.  As far as the NVIDIA ISA

Use of __restrict__ in g++

I have two questions regarding the use on __restrict__ qualifiers for function arguments in C++: 1) How does it interact with volatile? Example, given: void foo(volatile int* __restrict__ p1, volatile int* __restrict__ p2) { *p1 = 3; if (*p1 == 5) ...

Re: Use of __restrict__ in g++

> "quick" == quick writes: quick> I have two questions regarding the use on __restrict__ quick> qualifiers for function arguments in C++: quick> 1) How does it interact with volatile? quick> Example, given: quick> void foo(volatile int* __restrict__ p1, volatile int* quick> __restri

Re: Getting variable attribute from rtx

Dobes writes: >>> See the SYMBOL_REF_FLAGS stuff in rtl.h and various examples in the >>> back-ends. >> Or, better, look for uses of lookup_attribute. >> > > OK, I've now got it working for globals and static locals by tagging the rtl > in "encode_section_info" and checking for that tag later.

Re: Getting variable attribute from rtx

Ian Lance Taylor-3 wrote: > > Dobes writes: > See the SYMBOL_REF_FLAGS stuff in rtl.h and various examples in the back-ends. >>> Or, better, look for uses of lookup_attribute. >>> >> >> OK, I've now got it working for globals and static locals by tagging the >> rtl >> in "encode_sec

Re: Ideas for Google Summer of Code

Paolo Bonzini writes: >Regarding the NVIDIA GPU backend, I think NVIDIA is not yet distributing >details about the instruction set unlike ATI, is it? In this case, I >think ATI would be a better match. I think a GPU backend would be well beyond the scope of a Summer of Code project. GPUs don't h

Re: Getting variable attribute from rtx

Dobes writes: > Could you clarify a little about how/where to use lookup_attribute? Use it wherever it is you need to know whether a symbol has your attribute (I don't know when you need the information). In RTL you can normally find the VAR_DECL using MEM_EXPR or REG_EXPR. Ian

Re: Ideas for Google Summer of Code

Joe Buck writes: >I'm having trouble finding that document, I don't see a link to it >on that page. Maybe I'm missing something obvious? Sticking "nvidia ptx" into Google turned up this document: http://www.nvidia.com/object/io_1195170102263.html It's an intermediate language, so isn't

Testing patch to make FDO profile data tolerate more source changes

Hello, I'm working on a patch which makes FDO profile data more robust to source changes. Before I sent the patch to the list for review, I was wondering how to write a test for this situation. In particular, what I would like to have is two source files which are similar but not the same. The

Re: Ideas for Google Summer of Code

Paolo, Thanks for the feedback, I am not very experienced in compilers so it is hard to judge how long a task will take... By sharing I meant sharing of code between NVIDIA and GCC. It probably won't happen I guess. Here is my proposal for an OpenCL runtime with a target runtime as well. If yo

Re: Ideas for Google Summer of Code

On Mon, Mar 30, 2009 at 01:36:14PM -0700, Ross Ridge wrote: > Joe Buck writes: > >I'm having trouble finding that document, I don't see a link to it > >on that page. Maybe I'm missing something obvious? > > Sticking "nvidia ptx" into Google turned up this document: > > http://www.nvidia.

Re: Testing patch to make FDO profile data tolerate more source changes

On Mon, 2009-03-30 at 13:53 -0700, Neil Vachharajani wrote: > Hello, > > I'm working on a patch which makes FDO profile data more robust to > source changes. Before I sent the patch to the list for review, I was > wondering how to write a test for this situation. In particular, what > I would li

Re: Ideas for Google Summer of Code

On Mon, 30 Mar 2009, Ross Ridge wrote: > >2) half-precision floats; > > Do you mean just conversion only support, like Sandra Loosemore's > proposed ARM patch, or full arithmetic support like any other scalar or > vector type? Arithmetic via converting to float, doing arithmetic on that and con

Re: Testing patch to make FDO profile data tolerate more source changes

On Mon, Mar 30, 2009 at 2:50 PM, Janis Johnson wrote: > On Mon, 2009-03-30 at 13:53 -0700, Neil Vachharajani wrote: >> Hello, >> >> I'm working on a patch which makes FDO profile data more robust to >> source changes.  Before I sent the patch to the list for review, I was >> wondering how to write

Re: Debuglocus

On Mar 21, 2009, Andrew MacLeod wrote: > I was planning to send this note next week, but I guess I should know > better than to put something on the wiki and think it won't be > noticed, even if it is in a crusty dark corner :-) :-) > I see on #gcc that my debuglocus document has been discovere

Re: New no-undefined-overflow branch

Hi Ho! On Fri, 2009-03-27 at 13:49 +0100, Paolo Bonzini wrote: > Eus wrote: > > Hi Ho! > > > > On Fri, 2009-03-06 at 15:29 +0100, Paolo Bonzini wrote: > >>> So while trapping variants can certainly be introduced it looks like > >>> this task may be more difficult. > >> I don't think you need to i

Re: Testing patch to make FDO profile data tolerate more source changes

Just to clarify is gcc.dg/tree-prof/wcoverage-mismatch.c an example of what you are talking about? If so, I really like this is approach. Thanks for the feedback! Neil On Mon, Mar 30, 2009 at 4:41 PM, Andrew Pinski wrote: > On Mon, Mar 30, 2009 at 2:50 PM, Janis Johnson wrote: >> On Mon, 2009-

Re: logical error with 16bit arithmatic operations

Thank you for your advice. Compared RICE (my processor name) RTL and MIPS RTL, I found the problem. Because of the subreg operations which I missed to add support in my RTL. I noticed the mips rtl code which will convert the QImode and HI mode to SImode operations. Like the following: (insn 28 26

Re: logical error with 16bit arithmatic operations

daniel tian writes: > But the question is how I make the gcc know to extend every smaller > mode to SImode. Now I check the MIPS port, maybe I can find some clue. Maybe PROMOTE_MODE. Ian

Re: logical error with 16bit arithmatic operations

Yes. You are right. I fixed the problem. I checked the macro in INTERNAL docment, and I copied the mips definition of PROMOTE_MODE: #define PROMOTE_MODE(MODE, UNSIGNEDP, TYPE) \ if (GET_MODE_CLASS (MODE) == MODE_INT \ && GET_MODE_SIZE (MODE) < UNITS_PER_WORD) \ {

Re: Testing patch to make FDO profile data tolerate more source changes

Neil Vachharajani wrote: > Just to clarify is gcc.dg/tree-prof/wcoverage-mismatch.c an example of > what you are talking about? If so, I really like this is approach. Yes, it's that one. Paolo