Contributing to GCC

Contributing to GCC

[Hamish Baxter]

[-- Attachment #1: Type: text/plain, Size: 417 bytes --]

Dear GCC community.

I am a current Computer Science student who enjoys C programming with an
interest in learning compilers, and am looking to contribute to an
open source project.

I am not sure exactly where to start or how it works: perhaps testing /
technical documentation / bug fixes?  Is it possible to please have some
guidance or perhaps I can assist someone with their current project?

Kind regards,

Tom

Re: Contributing to GCC

[Tobias Burnus]

Hi Tom,

On 21.11.23 11:32, Hamish Baxter via Gcc wrote:
> I am a current Computer Science student who enjoys C programming with an
> interest in learning compilers, and am looking to contribute to an
> open source project.
>
> I am not sure exactly where to start or how it works: perhaps testing /
> technical documentation / bug fixes?  Is it possible to please have some
> guidance or perhaps I can assist someone with their current project?

I think the first question is at which part of the compiler you would
like to work on:

* The front end: C, C++, Fortran, Ada, Rust, Go, Modula2, ...

* Middle end such as diagnostic (e.g. analyzer), optimizations (loops,
IPA, pattern-based, ...)

* Backend: Code for a specific hardware

Additionally, there is:

* library related work (including C++'s STL) – usually related to
front-end work

and work on

* language extensions like OpenMP or OpenACC.

https://gcc.gnu.org/wiki/SummerOfCode give some idea – those are for
summer of code projects and outside of such a project, some other tasks
(smaller and more diverse) might make more sense, but at least it gives
an idea.

Some documentation on GCC internals and tutorials also exists, but I it
makes sense for you to decide rough area interests you most – as the
backend documentation is probably less useful if you want to work on the
FE or vice versa.

What I regard as good starting point is indeed bugfixing. When guiding
summer of code students, I always tried to find some small bug-fix
project to get started and have some simple but complete task (building
GCC; writing the patch; adding testcase; testing it; submitting the full
patch). While there might be some simple feature tasks, I usually found
it the easiest to to propose fixing an internal-compiler error (ICE) for
invalid code (ice-on-invalid-code) or adding accepts-invalid diagnostic
– those tend to be easier and there are more often lower-hanging fruits
as wrong-code bugs or reject-valid / ice-on-valid-code tend to get more
attention and are quicker fixed if easy. (*)

Tobias,

who mostly works on the OpenMP and on the Fortran FE.

(*) https://gcc.gnu.org/bugzilla/query.cgi - the hyphenated strings are
Bugzilla keywords. When beginning, it makes sense to ask for some
guidance as some bugs might turn out to be rather complex while others
sound complex but are simple. — One place to ask for some
code-development hints is besides the mailing list the IRC channel, cf.
top at https://gcc.gnu.org/wiki

-----------------
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht München, HRB 106955

Re: Contributing to GCC

[Jonathan Wakely]

On Tue, 21 Nov 2023 at 10:58, Tobias Burnus <tobias@codesourcery.com> wrote:
>
> Hi Tom,
>
> On 21.11.23 11:32, Hamish Baxter via Gcc wrote:
> > I am a current Computer Science student who enjoys C programming with an
> > interest in learning compilers, and am looking to contribute to an
> > open source project.
> >
> > I am not sure exactly where to start or how it works: perhaps testing /
> > technical documentation / bug fixes?  Is it possible to please have some
> > guidance or perhaps I can assist someone with their current project?
>
> I think the first question is at which part of the compiler you would
> like to work on:
>
> * The front end: C, C++, Fortran, Ada, Rust, Go, Modula2, ...
>
> * Middle end such as diagnostic (e.g. analyzer), optimizations (loops,
> IPA, pattern-based, ...)
>
> * Backend: Code for a specific hardware
>
> Additionally, there is:
>
> * library related work (including C++'s STL) – usually related to
> front-end work
>
> and work on
>
> * language extensions like OpenMP or OpenACC.
>
> https://gcc.gnu.org/wiki/SummerOfCode give some idea – those are for
> summer of code projects and outside of such a project, some other tasks
> (smaller and more diverse) might make more sense, but at least it gives
> an idea.
>
> Some documentation on GCC internals and tutorials also exists, but I it
> makes sense for you to decide rough area interests you most – as the
> backend documentation is probably less useful if you want to work on the
> FE or vice versa.
>
> What I regard as good starting point is indeed bugfixing. When guiding
> summer of code students, I always tried to find some small bug-fix
> project to get started and have some simple but complete task (building
> GCC; writing the patch; adding testcase; testing it; submitting the full
> patch). While there might be some simple feature tasks, I usually found
> it the easiest to to propose fixing an internal-compiler error (ICE) for
> invalid code (ice-on-invalid-code) or adding accepts-invalid diagnostic
> – those tend to be easier and there are more often lower-hanging fruits
> as wrong-code bugs or reject-valid / ice-on-valid-code tend to get more
> attention and are quicker fixed if easy. (*)


Another good place to start is the
https://gcc.gnu.org/wiki/GettingStarted wiki page (which the
SummerOfCode page also links to).

Re: contributing to gcc

[Jeff Law]

On 01/08/15 13:02, Zach Tomkoski wrote:
> I have been working on changes to extend the functionality of the
> GCC's built in code coverage tool gcov.  What steps would I need to go
> through to work on getting these additions to be added in to the
> upstream releases of GCC?
https://gcc.gnu.org/contribute.html

contributing to gcc

[Zach Tomkoski]

I have been working on changes to extend the functionality of the
GCC's built in code coverage tool gcov.  What steps would I need to go
through to work on getting these additions to be added in to the
upstream releases of GCC?


Thanks,
Zachary Tomkoski

Re: Contributing to GCC

[Jeff Law]

[-- Attachment #1: Type: text/plain, Size: 2728 bytes --]

On 10/17/14 01:12, Krzesimir Nowak wrote:
> Hello.
>
> My name is Krzesimir Nowak and I'd like to try my hand at contributing
> to gcc in my free time.
>
> To start learning a workflow I started with something easy - 42014. Is
> testcase for this fix necessary (it would be checking preprocessor
> output)? Is sending a patch created by "git format-patch" for review
> with git-send-email to gcc-patches acceptable (or even better - git
> patches with cover letter)?
A project you could tackle would be furthering David's work on improving 
the typesafety of RTX objects.

In simplest terms, until recently all RTL objects were of type "rtx". 
We've started work to try and utilize more concrete objects, for example 
"rtx_insn *" for objects which are part of the INSN chain.  There's 
numerous benefits of this work and I'm happy to walk you through them if 
you want more details.


So one easy project would be to search for objects of type "rtx" that 
should be converted to type "rtx_insn *".  Commonly these variables will 
be called "insn" or "jump_insn".

Often you'll just need to fix the type.  In fact, I'd initially focus 
strictly on those.  In cases where the object you want to convert is a 
return value or argument to another function which hasn't been converted 
yet, you can:

  1. Punt and return to it later after more infrastructure is in place.

  2. Use checked casts to convert between rtx_insn * and rtx.

  3. Convert the target function.


#1 is the easiest, and would be my recommendation when you're just 
getting started.   You can always come back after you're more familiar 
with the codebase and know how to utilize #2 or #3.

#2 is still quite useful.  First we get the stronger typechecking, but 
the checked casts are also useful markers for folks who are working on 
the underlying infrastructure a converting function arguments/return 
values in #3.

#3 is by far the most useful, but may require quite a bit more work as 
the function in question may be used in many places, by backends, etc 
and converting everything at once may be nontrivial.  Finding a good 
"stop point" for a particular batch of work can be hard.  Just look at 
David's patchkit that had 239 parts that got the ball rolling.


You might start by looking at the backend code generators since there'll 
be fewer cases where you need to change the return type or an argument 
type for functions which are used across multiple backends.

I just happened to be converting the HPPA backend because I'm going to 
poke at the code generator for other reasons.  But there's dozens of 
other backends you could look to convert.  I'm attaching the 
work-in-progress on the PA backend so you can see a concrete example.

Jeff

[-- Attachment #2: pa.rtx.patch --]
[-- Type: text/x-patch, Size: 6972 bytes --]

diff --git a/gcc/config/pa/pa-protos.h b/gcc/config/pa/pa-protos.h
index 80e1efe..0ba5055 100644
--- a/gcc/config/pa/pa-protos.h
+++ b/gcc/config/pa/pa-protos.h
@@ -48,7 +48,7 @@ extern const char *pa_output_mod_insn (int, rtx_insn *);
 extern const char *pa_singlemove_string (rtx *);
 extern void pa_output_addr_vec (rtx, rtx);
 extern void pa_output_addr_diff_vec (rtx, rtx);
-extern void pa_output_arg_descriptor (rtx);
+extern void pa_output_arg_descriptor (rtx_insn *);
 extern void pa_output_global_address (FILE *, rtx, int);
 extern void pa_print_operand (FILE *, rtx, int);
 extern void pa_encode_label (rtx);
diff --git a/gcc/config/pa/pa.c b/gcc/config/pa/pa.c
index 7072722..6e34d77 100644
--- a/gcc/config/pa/pa.c
+++ b/gcc/config/pa/pa.c
@@ -117,8 +117,8 @@ static int pa_can_combine_p (rtx_insn *, rtx_insn *, rtx_insn *, int, rtx,
 static bool forward_branch_p (rtx_insn *);
 static void compute_zdepwi_operands (unsigned HOST_WIDE_INT, unsigned *);
 static void compute_zdepdi_operands (unsigned HOST_WIDE_INT, unsigned *);
-static int compute_movmem_length (rtx);
-static int compute_clrmem_length (rtx);
+static int compute_movmem_length (rtx_insn *);
+static int compute_clrmem_length (rtx_insn *);
 static bool pa_assemble_integer (rtx, unsigned int, int);
 static void remove_useless_addtr_insns (int);
 static void store_reg (int, HOST_WIDE_INT, int);
@@ -156,8 +156,8 @@ static void hppa_va_start (tree, rtx);
 static tree hppa_gimplify_va_arg_expr (tree, tree, gimple_seq *, gimple_seq *);
 static bool pa_scalar_mode_supported_p (machine_mode);
 static bool pa_commutative_p (const_rtx x, int outer_code);
-static void copy_fp_args (rtx) ATTRIBUTE_UNUSED;
-static int length_fp_args (rtx) ATTRIBUTE_UNUSED;
+static void copy_fp_args (rtx_insn *) ATTRIBUTE_UNUSED;
+static int length_fp_args (rtx_insn *) ATTRIBUTE_UNUSED;
 static rtx hppa_legitimize_address (rtx, rtx, machine_mode);
 static inline void pa_file_start_level (void) ATTRIBUTE_UNUSED;
 static inline void pa_file_start_space (int) ATTRIBUTE_UNUSED;
@@ -775,7 +775,7 @@ legitimize_pic_address (rtx orig, machine_mode mode, rtx reg)
   /* Labels need special handling.  */
   if (pic_label_operand (orig, mode))
     {
-      rtx insn;
+      rtx_insn *insn;
 
       /* We do not want to go through the movXX expanders here since that
 	 would create recursion.
@@ -811,7 +811,8 @@ legitimize_pic_address (rtx orig, machine_mode mode, rtx reg)
     }
   if (GET_CODE (orig) == SYMBOL_REF)
     {
-      rtx insn, tmp_reg;
+      rtx_insn *insn;
+      rtx tmp_reg;
 
       gcc_assert (reg);
 
@@ -915,7 +916,8 @@ hppa_tls_call (rtx arg)
 static rtx
 legitimize_tls_address (rtx addr)
 {
-  rtx ret, insn, tmp, t1, t2, tp;
+  rtx ret, tmp, t1, t2, tp;
+  rtx_insn *insn;
 
   /* Currently, we can't handle anything but a SYMBOL_REF.  */
   if (GET_CODE (addr) != SYMBOL_REF)
@@ -2090,7 +2092,8 @@ pa_emit_move_sequence (rtx *operands, machine_mode mode, rtx scratch_reg)
       else if (GET_CODE (operand1) != CONST_INT
 	       || !pa_cint_ok_for_move (INTVAL (operand1)))
 	{
-	  rtx insn, temp;
+	  rtx temp;
+	  rtx_insn *insn;
 	  rtx op1 = operand1;
 	  HOST_WIDE_INT value = 0;
 	  HOST_WIDE_INT insv = 0;
@@ -2884,7 +2887,7 @@ pa_output_block_move (rtx *operands, int size_is_constant ATTRIBUTE_UNUSED)
    count insns rather than emit them.  */
 
 static int
-compute_movmem_length (rtx insn)
+compute_movmem_length (rtx_insn *insn)
 {
   rtx pat = PATTERN (insn);
   unsigned int align = INTVAL (XEXP (XVECEXP (pat, 0, 7), 0));
@@ -3026,7 +3029,7 @@ pa_output_block_clear (rtx *operands, int size_is_constant ATTRIBUTE_UNUSED)
    count insns rather than emit them.  */
 
 static int
-compute_clrmem_length (rtx insn)
+compute_clrmem_length (rtx_insn *insn)
 {
   rtx pat = PATTERN (insn);
   unsigned int align = INTVAL (XEXP (XVECEXP (pat, 0, 4), 0));
@@ -3515,7 +3518,8 @@ static int save_fregs;
 static void
 store_reg (int reg, HOST_WIDE_INT disp, int base)
 {
-  rtx insn, dest, src, basereg;
+  rtx dest, src, basereg;
+  rtx_insn *insn;
 
   src = gen_rtx_REG (word_mode, reg);
   basereg = gen_rtx_REG (Pmode, base);
@@ -3570,7 +3574,8 @@ store_reg (int reg, HOST_WIDE_INT disp, int base)
 static void
 store_reg_modify (int base, int reg, HOST_WIDE_INT mod)
 {
-  rtx insn, basereg, srcreg, delta;
+  rtx basereg, srcreg, delta;
+  rtx_insn *insn;
 
   gcc_assert (VAL_14_BITS_P (mod));
 
@@ -3600,7 +3605,7 @@ store_reg_modify (int base, int reg, HOST_WIDE_INT mod)
 static void
 set_reg_plus_d (int reg, int base, HOST_WIDE_INT disp, int note)
 {
-  rtx insn;
+  rtx_insn *insn;
 
   if (VAL_14_BITS_P (disp))
     {
@@ -3790,7 +3795,8 @@ pa_expand_prologue (void)
   HOST_WIDE_INT size = get_frame_size ();
   HOST_WIDE_INT offset;
   int i;
-  rtx insn, tmpreg;
+  rtx tmpreg;
+  rtx_insn *insn;
 
   gr_saved = 0;
   fr_saved = 0;
@@ -4035,7 +4041,8 @@ pa_expand_prologue (void)
 	  if (df_regs_ever_live_p (i)
 	      || (! TARGET_64BIT && df_regs_ever_live_p (i + 1)))
 	    {
-	      rtx addr, insn, reg;
+	      rtx addr, reg;
+	      rtx_insn *insn;
 	      addr = gen_rtx_MEM (DFmode,
 				  gen_rtx_POST_INC (word_mode, tmpreg));
 	      reg = gen_rtx_REG (DFmode, i);
@@ -4454,7 +4461,8 @@ hppa_profile_hook (int label_no)
      lcla2 and load_offset_label_address insn patterns.  */
   rtx reg = gen_reg_rtx (SImode);
   rtx_code_label *label_rtx = gen_label_rtx ();
-  rtx begin_label_rtx, call_insn;
+  rtx begin_label_rtx;
+  rtx_insn *call_insn;
   char begin_label_name[16];
 
   ASM_GENERATE_INTERNAL_LABEL (begin_label_name, FUNC_BEGIN_PROLOG_LABEL,
@@ -5826,7 +5834,7 @@ pa_output_mod_insn (int unsignedp, rtx_insn *insn)
 }
 
 void
-pa_output_arg_descriptor (rtx call_insn)
+pa_output_arg_descriptor (rtx_insn *call_insn)
 {
   const char *arg_regs[4];
   machine_mode arg_mode;
@@ -6334,7 +6342,7 @@ pa_scalar_mode_supported_p (machine_mode mode)
 static bool
 branch_to_delay_slot_p (rtx_insn *insn)
 {
-  rtx jump_insn;
+  rtx_insn *jump_insn;
 
   if (dbr_sequence_length ())
     return FALSE;
@@ -6368,7 +6376,7 @@ branch_to_delay_slot_p (rtx_insn *insn)
 static bool
 branch_needs_nop_p (rtx_insn *insn)
 {
-  rtx jump_insn;
+  rtx_insn *jump_insn;
 
   if (dbr_sequence_length ())
     return FALSE;
@@ -6396,7 +6404,7 @@ branch_needs_nop_p (rtx_insn *insn)
 static bool
 use_skip_p (rtx_insn *insn)
 {
-  rtx jump_insn = next_active_insn (JUMP_LABEL (insn));
+  rtx_insn *jump_insn = next_active_insn (JUMP_LABEL (insn));
 
   while (insn)
     {
@@ -7428,7 +7436,7 @@ pa_output_movb (rtx *operands, rtx_insn *insn, int which_alternative,
 
 /* Copy any FP arguments in INSN into integer registers.  */
 static void
-copy_fp_args (rtx insn)
+copy_fp_args (rtx_insn *insn)
 {
   rtx link;
   rtx xoperands[2];
@@ -7471,7 +7479,7 @@ copy_fp_args (rtx insn)
 
 /* Compute length of the FP argument copy sequence for INSN.  */
 static int
-length_fp_args (rtx insn)
+length_fp_args (rtx_insn *insn)
 {
   int length = 0;
   rtx link;

Re: Contributing to GCC

[Krzesimir Nowak]

2014-10-17 10:00 GMT+02:00 Marek Polacek <polacek@redhat.com>:
> On Fri, Oct 17, 2014 at 09:55:28AM +0200, Krzesimir Nowak wrote:
>> I was asking, because, in the beginning at least, somebody will have
>> to commit the patch to trunk for me. I don't know if svn understands
>> git patches.
>
> No worries about that, we'll just apply the patch manually.

Ok, thanks.

>
>         Marek

Re: Contributing to GCC

[Marek Polacek]

On Fri, Oct 17, 2014 at 09:55:28AM +0200, Krzesimir Nowak wrote:
> I was asking, because, in the beginning at least, somebody will have
> to commit the patch to trunk for me. I don't know if svn understands
> git patches.

No worries about that, we'll just apply the patch manually.

	Marek

Re: Contributing to GCC

[Krzesimir Nowak]

2014-10-17 9:31 GMT+02:00 Thomas Schwinge <thomas@codesourcery.com>:
> Hi!
>
> On Fri, 17 Oct 2014 09:12:07 +0200, Krzesimir Nowak <qdlacz@gmail.com> wrote:
>> My name is Krzesimir Nowak and I'd like to try my hand at contributing
>> to gcc in my free time.
>
> Great, and welcome!
>
>> To start learning a workflow I started with something easy - 42014.
>
> As this is one of the issues listed on
> <https://gcc.gnu.org/wiki/EasyHacks>, I assume you've already seen this,
> and other pages, such as <https://gcc.gnu.org/wiki/GettingStarted>.
>

Yes, exactly.

>> Is
>> testcase for this fix necessary (it would be checking preprocessor
>> output)?
>
> Yes.  Please see the previous discussion about one aspect of PR42014,
> <http://news.gmane.org/find-root.php?message_id=%3C1727363575.9580702.1368168907851.JavaMail.root%40redhat.com%3E>.
>

Ok, thanks.

>> Is sending a patch created by "git format-patch" for review
>> with git-send-email to gcc-patches acceptable (or even better - git
>> patches with cover letter)?
>
> A lot of contributors send in-line patches in their emails, but using
> "modern" tools, such as Git, is certainly fine, too.
>

I was asking, because, in the beginning at least, somebody will have
to commit the patch to trunk for me. I don't know if svn understands
git patches.

>
> Grüße,
>  Thomas

Re: Contributing to GCC

[Thomas Schwinge]

[-- Attachment #1: Type: text/plain, Size: 1065 bytes --]

Hi!

On Fri, 17 Oct 2014 09:12:07 +0200, Krzesimir Nowak <qdlacz@gmail.com> wrote:
> My name is Krzesimir Nowak and I'd like to try my hand at contributing
> to gcc in my free time.

Great, and welcome!

> To start learning a workflow I started with something easy - 42014.

As this is one of the issues listed on
<https://gcc.gnu.org/wiki/EasyHacks>, I assume you've already seen this,
and other pages, such as <https://gcc.gnu.org/wiki/GettingStarted>.

> Is
> testcase for this fix necessary (it would be checking preprocessor
> output)?

Yes.  Please see the previous discussion about one aspect of PR42014,
<http://news.gmane.org/find-root.php?message_id=%3C1727363575.9580702.1368168907851.JavaMail.root%40redhat.com%3E>.

> Is sending a patch created by "git format-patch" for review
> with git-send-email to gcc-patches acceptable (or even better - git
> patches with cover letter)?

A lot of contributors send in-line patches in their emails, but using
"modern" tools, such as Git, is certainly fine, too.


Grüße,
 Thomas

[-- Attachment #2: Type: application/pgp-signature, Size: 472 bytes --]

Contributing to GCC

[Krzesimir Nowak]

Hello.

My name is Krzesimir Nowak and I'd like to try my hand at contributing
to gcc in my free time.

To start learning a workflow I started with something easy - 42014. Is
testcase for this fix necessary (it would be checking preprocessor
output)? Is sending a patch created by "git format-patch" for review
with git-send-email to gcc-patches acceptable (or even better - git
patches with cover letter)?

Thanks.

Re: contributing to gcc

[Basile Starynkevitch]

On Mon, Jan 09, 2012 at 07:33:54PM -0500, Aayush Upadhyay wrote:

> I'm a sophomore in college, and I'm a solid C programmer. I'd like to work
> on an open source project, and the gcc compiler seems like a great one.

In addition to the other replies, you could also contribute to branches or
to GCC plugin (or to the GCC infrastructure). For example, you could (if you
wanted to) contribute to the MELT branch and plugin: http://gcc-melt.org/

Be however aware of one important point, specific to GCC and several other
GNU software: the copyright owner is the FSF, and you need some legal paper
to be done.  Read carefully http://gcc.gnu.org/contribute.html#legal

This implies practically that you get some legal paper signed by you and by
your university (and by the FSF). Getting that paper signed takes
burocractic time and effort: you'll need to convince people in suits (e.g.
your University Dean) to sign a legal paper. You can understand this process
as also being a screening procedure for your personal motivation :-) [I'm
half joking here]

Be sure that you won't be able to contribute to GCC (even to some
experimental branches) without having settled the legal questions, which
requires such documents to be processed.

So if you are serious about contributing to GCC (or any branches of it),
start working on these legal aspects today. They take a lot of time
(months) to be achieved. I'm serious, if you want to contribute to GCC,
worry about the legal aspects right now (this means getting a legal paper
signed to transfer copyright to FSF and to share responsability in case you
violated some copyright).

And welcome to the GCC community, if you want to be part of it.

Cheers.

-- 
Basile STARYNKEVITCH         http://starynkevitch.net/Basile/
email: basile<at>starynkevitch<dot>net mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mines, sont seulement les miennes} ***

Re: contributing to gcc

[Joe Buck]

On Mon, Jan 09, 2012 at 04:33:54PM -0800, Aayush Upadhyay wrote:

> I'm a sophomore in college, and I'm a solid C programmer. I'd like to
  work on an open source project, and the gcc compiler seems like a great
  one. However, I'm not sure if work is still done on the compiler itself,
  or just porting it to other systems? I'm interested in the former, but I
  don't know much about compilers. Would it be possible for me to make
  meaningful contributions, and if so, how should I start?

Quite a bit of work is being done on the compiler itself, with lots of
brainpower devoted to making it better and to implement the latest
language standards.

There is a great deal of information on gcc development on http://gcc.gnu.org/ .
As this is a core piece of infrastructure for GNU/Linux and lots of other
folks, standards are extremely high.  However, you could start out by
reading

http://gcc.gnu.org/contribute.html

and

http://gcc.gnu.org/projects/beginner.html

The latter lists some projects that non-experts could contribute to,
though it is wise to check for duplication and relevance before starting
any major efforts.

contributing to gcc

[Aayush Upadhyay]

Hey guys,

I'm a sophomore in college, and I'm a solid C programmer. I'd like to work on an open source project, and the gcc compiler seems like a great one. However, I'm not sure if work is still done on the compiler itself, or just porting it to other systems? I'm interested in the former, but I don't know much about compilers. Would it be possible for me to make meaningful contributions, and if so, how should I start?

Thanks,
Aayush

Re: Contributing to gcc

[Ian Lance Taylor]

José Manuel Marín Román <gyakoo@gmail.com> writes:

> I'm a spanish senior c++ development and I would like to contribute to
> gnu compiler in some way you consider neccesary.
>
> My expertise is on graphic and games technologies, such as 3d realtime
> engine programming, raytracing, artificial intelligence, and so
> on... and currently I'm working on low-level optimization using gcc
> intrinsics and extended assembler making use of simd instruction
> (intel's sse), in a vectorial library (like intel MKL's one).
>
> I really don't know how could I help you, I'm interested in any area.

Thanks for your interest.  See http://gcc.gnu.org/contribute.html .
There are many ideas at http://gcc.gnu.org/wiki/ under "Improving
GCC."

Ian

Contributing to gcc

[José Manuel Marín Román]

Hi again, I better resend the message from my personal mail account.

Hi all,

I'm a spanish senior c++ development and I would like to contribute to 
gnu compiler in some way you consider neccesary.

My expertise is on graphic and games technologies, such as 3d realtime 
engine programming, raytracing, artificial intelligence, and so on... 
and currently I'm working on low-level optimization using gcc intrinsics 
and extended assembler making use of simd instruction (intel's sse), in 
a vectorial library (like intel MKL's one).

I really don't know how could I help you, I'm interested in any area.

You can read a brief of my resume at http://www.linkedin.com/pub/3/895/123
My blogsite is http://gyakoo.blogspot.com

Thanks in advance.

--
Jose Manuel Marin (gyakoo)
gyakoo at gmail

Contributing to gcc

[José Manuel Marín Román]

Hi all,

I'm a spanish senior c++ development and I would like to contribute to 
gnu compiler in some way you consider neccesary.

My expertise is on graphic and games technologies, such as 3d realtime 
engine programming, raytracing, artificial intelligence, and so on... 
and currently I'm working on low-level optimization using gcc intrinsics 
and extended assembler making use of simd instruction (intel's sse), in 
a vectorial library (like intel MKL's one).

I really don't know how could I help you, I'm interested in any area.

You can read a brief of my resume at http://www.linkedin.com/pub/3/895/123
My blogsite is http://gyakoo.blogspot.com

Thanks in advance.

--
Jose Manuel Marin (gyakoo)
gyakoo at gmail

contributing to gcc

[Dmitry]

Dear Sir/Madam,

Sorry bothering you.
I have created a gcc port for msp430 series MCU.
This port is available at  http://mspgcc.sourceforge.net
I have got signed copyright form from GNU licensing office.

Is it possible to add this port to official gcc release/development tree?

Respectfully,
Dmitry Diky.



/********************************************************************
     ("`-''-/").___..--''"`-._     (\   Dimmy the Wild      UA1ACZ
      `6_ 6  )   `-.  (     ).`-.__.`)  Enterprise Information Sys 
      (_Y_.)'  ._   )  `._ `. ``-..-'   Nevsky prospekt,   20 / 44
    _..`--'_..-_/  /--'_.' ,'           Saint Petersburg,   Russia
   (il),-''  (li),'  ((!.-'             +7 (812)  3468202, 5585314
 ********************************************************************/