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
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
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
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
> 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
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
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
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
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
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
10 matches
Mail list logo