Contributing to GCC
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
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: function parameters
On Tue, 21 Nov 2023 at 02:31, André Albergaria Coelho via Gcc
wrote:
>
> Hello
Hello,
This mailing list is for discussing the development of GCC itself, not
for help with basic C programming. Please use the gcc-h...@gcc.gnu.org
list for this kind of thing, or a general C programming forum.
Thanks,
Jonathan
>
> #include
>
> void func(char *ptr) {
> printf("\n%i",sizeof(ptr));
> }
>
> int main(void) {
> char arr[10];
> printf("\n Sizeof arr %i",sizeof(arr));
> func(arr);
>
> return 0;
> }
>
> /* sizeof(arr) != sizeof(ptr), but they point to same thing. */
>
>
> So problem. On main, arr has size 10, while on func, arr has size 8. But
> they are equal.
>
>
> --
> André Albergaria Coelho
> andrealberga...@gmail.com
Re: Contributing to GCC
On Tue, 21 Nov 2023 at 10:58, Tobias Burnus 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: [PATCH 3/4] libbacktrace: work with aslr on windows
I'll guess it is not needed here, but otherwise defines the macros max and min, they then conflict e.g. with C++'s std::max/std::min. So I consider it best practice to always define it, before including . Am 20.11.2023 um 21:07 schrieb Eli Zaretskii: Date: Mon, 20 Nov 2023 20:57:38 +0100 Cc: gcc-patc...@gcc.gnu.org, gcc@gcc.gnu.org From: Björn Schäpers +#ifndef NOMINMAX +#define NOMINMAX +#endif Why is this part needed? Otherwise, LGTM, thanks. (But I'm don't have the approval rights, so please wait for Ian to chime in.)
Re: [PATCH 3/4] libbacktrace: work with aslr on windows
在 2023/11/22 03:35, Björn Schäpers 写道: I'll guess it is not needed here, but otherwise defines the macros max and min, they then conflict e.g. with C++'s std::max/std::min. So I consider it best practice to always define it, before including . The mingw-w64 header does not define them for C++ [1] and GCC defines `NOMINMAX` in 'os_defines.h', so either way it is not necessary. [1] https://github.com/mingw-w64/mingw-w64/blob/3ebb92804e3125d1be8f61bcd42f15a8db15ba1e/mingw-w64-headers/include/minmax.h#L9 -- Best regards, LIU Hao OpenPGP_signature.asc Description: OpenPGP digital signature
