I was just looking to get into a project...and the incremental project caught my eye....wondering if it even practical due to the branch is over 6 years old...and merging everything with the current trunk would be a job. It seems like many of the projects on the wiki are out of date. Does anybody know a current project that needs major help? I would be more than happy to work on it.
On Fri, Sep 4, 2015 at 11:37 AM, David Kunsman <dmkuns...@gmail.com> wrote: > I was just looking to get into a project...and the incremental project > caught my eye....wondering if it even practical due to the branch is > over 6 years old...and merging everything with the current trunk would > be a job. It seems like many of the projects on the wiki are out of > date. Does anybody know a current project that needs major help? I > would be more than happy to work on it. > > On Fri, Sep 4, 2015 at 11:31 AM, Manuel López-Ibáñez > <lopeziba...@gmail.com> wrote: >> On 4 September 2015 at 17:44, Jeff Law <l...@redhat.com> wrote: >>> On 09/04/2015 09:40 AM, David Kunsman wrote: >>>> >>>> what do you think about the sub project in the wiki: >>>> >>>> Parallel Compilation: >>>> >>>> One approach is to make the front end multi-threaded. (I've pretty >>>> much abandoned this idea. There are too many mutable tree fields, >>>> making this a difficult project. Also, threads do not interact well >>>> with fork, which is currently needed by the code generation approach.) >>> >>> You should get in contact with David Malcolm as these issues are directly >>> related to his JIT work. >> >> See https://gcc.gnu.org/wiki/JIT >> >> If I remember correctly from past discussions, making the C/C++ FEs >> multi-threaded is not really desired. People already compile multiple >> files in parallel using 'make -j' and it is expected that many >> bottlenecks would require sequential execution anyway. Adding locks >> within the FEs may make them slower rather than faster. >> >> However, making the FEs thread-safer would be great for JIT and for >> converting them into reusable libraries (or if someone comes up with a >> feasible GCC server design). >> >>>> This will entail removing most global variables, marking some with >>>> __thread, and wrapping a few with locks. >>> >>> Yes, but that's work that is already in progress. Right now David's got a >>> big log and context switch in place, but we really want to drive down the >>> amount of stuff in that context switch. >> >> Removing global variables would already be a big help. For example, >> most flag_* global variables (example: flag_no_line_commands) can be >> encoded in struct gcc_options and could be removed. This would be a >> small project to start with, since one can do the conversion one at a >> time. >> >> Cheers, >> >> Manuel.
