> I think you should consider trying to fix bugs (Bugzilla has a broad choice
> of these things :-), maybe front-end bugs to start with, say the C and C++
> front-ends (relatively simple C++, not the fancy stuff), for example
> related to warnings and errors.
I filed http://gcc.gnu.org/PR22020 yes
Giovanni Bajo wrote:
> Also, remember to file papers for copyright assignment to the FSF, which is a
> prerequisite for accepting any patch.
Filing papers is a prerequisite for legally significant changes only:
http://www.gnu.org/prep/maintain/maintain.html#Legally-Significant
And, btw, it m
Lee Millward <[EMAIL PROTECTED]> wrote:
> I have spent the last few weeks reading the gcc-patches mailing list
> and the documentation available on GCC from the Wiki and various other
> documents I have found on the Internet to try and get a feel for how
> everything works. I also have the latest
Lee Millward wrote:
I'd like to get started with helping to develop GCC but am seeking
some advice from those of you who are regular contributors on the best
approach to adopt.
I have spent the last few weeks reading the gcc-patches mailing list
and the documentation available on GCC from the W
> I'd like to get started with helping to develop GCC but am seeking
> some advice from those of you who are regular contributors on the best
> approach to adopt.
I think you should consider trying to fix bugs (Bugzilla has a broad choice of
these things :-), maybe front-end bugs to start with, s
> Some of the work being carried out and posted on the gcc-patches
> mailing list makes those projects seem insignificant in comparision.
There's a wide range of ability in gcc developers, so there's a wide
range of projects to work on. They all use the same *process* so
starting with "trivial"
