Re: Offloading GSOC 2015

2015-03-20 Thread guray ozen
Hi all, I've started to prepare my gsoc proposal for gcc's openmp for gpus. However i'm little bit confused about which ideas, i mentioned last my mail, should i propose or which one of them is interesting for gcc. I'm willing to work on data clauses to enhance performance of shared memory. Or may

GCC 5 Status Report (2015-03-20)

2015-03-20 Thread Richard Biener
Status == The trunk is open for regression and documentation fixes only. We've come a long way towards the release criteria of zero P1 bugs. There are still a few remaining P1s though and we are targeting for a GCC 5 release candidate in the first week of April (given those P1 bugs are eithe

Re: Offloading GSOC 2015

2015-03-20 Thread Kirill Yukhin
Hello Güray, On 20 Mar 12:14, guray ozen wrote: > I've started to prepare my gsoc proposal for gcc's openmp for gpus. I think that here is wide range for exploration. As you know, OpenMP 4 contains vectorization pragmas (`pragma omp simd') which not perfectly suites for GPGPU. Another problem is

ARC length attribute patch

2015-03-20 Thread Claudiu Zissulescu
Hi Joern, I have a small patch for ARC backend that fixes the value of instruction length attribute when the instruction is predicated. Ok to apply? Thanks, Claudiu length.patch Description: length.patch

Re: ARC length attribute patch

2015-03-20 Thread Joern Wolfgang Rennecke
On 20/03/15 16:02, Claudiu Zissulescu wrote: Hi Joern, I have a small patch for ARC backend that fixes the value of instruction length attribute when the instruction is predicated. Ok to apply? Why would the arc_bdr_iscond test have any effect? arc_predicate_delay_insns should render the iss

Re: GCC 5 Status Report (2015-03-20)

2015-03-20 Thread Jan Hubicka
> Please also prioritize fixing P1s and avoid pushing in risky > fixes for P2s that might end up causing regressions. We are still > seeing way too many changes in the IPA area (hi Honza!). Hello :) GCC 5 is a busy release from IPA point of view indeed. Here is a quick summary what is still on m

future versions

2015-03-20 Thread Jack Howarth
What was the final decision concerning future versioning of FSF gcc post-5.0? In particular, I am confused about the designation of maintenance releases of 5.0. Will the next maintenance release be 5.1 or 5.0.1? I assume if it is 5.1, then after branching for release of 5.0, trunk will become 6

RFC: attaching functions to types

2015-03-20 Thread Shawn Landden
direct-declarator: ( type-qualifier[opt] type-specifier *[opt] identifier[opt] ) . function-definition call like so: type.foo(baz); typep->foo(baz); type automatically becomes first parameter, (when used as a function pointer) and as a pointer to if that was included in definition. if

Re: RFC: attaching functions to types

2015-03-20 Thread Andrew Pinski
On Fri, Mar 20, 2015 at 6:05 PM, Shawn Landden wrote: >direct-declarator: > ( type-qualifier[opt] type-specifier *[opt] identifier[opt] ) . > function-definition > > > call like so: > > > type.foo(baz); > typep->foo(baz); Wait you are re-inventing C with classes and C++. Thanks, Andrew

Re: future versions

2015-03-20 Thread Markus Trippelsdorf
On 2015.03.20 at 20:08 -0400, Jack Howarth wrote: > What was the final decision concerning future versioning of FSF > gcc post-5.0? In particular, I am confused about the designation of > maintenance releases of 5.0. Will the next maintenance release be 5.1 > or 5.0.1? I assume if it is 5.1, th