Broken links on website

[Ryan Plant]

Just a quick heads-up , https://gcc.gnu.org/install/binaries.html currently
has two broken links. "MinGW" leads to a dead site covered in
domain-parking ads, and the "mingw-w64" one 404s. I believe the current
links for those projects are https://osdn.net/projects/mingw/ and
https://www.mingw-w64.org/ respectively.

Re: Development request

[Martin Jambor]

Hello Mohamed,

sorry for a late reply.  I was traveling and in various meetings over
the course of the last two weeks and could not pay as much attention to
email as I would have liked to.  It is always better to CC the GCC
mailing list so that others can step in, not just when I am not
available but also when they have other input.  Anyway...

On Thu, Sep 30 2021, Mohamed Atef wrote:
> Hello Mr Martin,
> Thank you for your reply.
> i am sorry for bothering you
> We talked to our professor and we are very happy to build the tool you
> suggested
> but there's something that we are worry about if we need help with anything
> related to the project (papers, resources, ...etc) will we find someone to
> support us
> The graduation project is a must to graduate and it's very serious to
> finish.

Understood.

> finally,
> can anyone of the expert developers mentor us i don't mean full mentorship
> i mean someone to contact once every month or every 2 weeks , someone to
> follow up with us and check our work
> if not that's not a problem but we will appreciate it

The preferred way of communication is email posted to the mailing list
(sometimes CCing the people you think are most likely to reply) and I am
quite confident that people will read it and reply to reasonable
questions and review patches, even RFC patches.

I think that the important OpenMP contributors could be persuaded to an
occasional - if perhaps not regular - call to discuss overall
architecture, milestones and even any hard-to-tackle problems, but you
need to ask them yourselves (hint: I CCed some).  In the end of the day,
email should be the main channel, though.

I assume that is not your case, but please note that we cannot teach you
basic C and similar fundamental stuff.  You will also be expected to
study relevant aspects of, for example, dynamic linking and autotools
yourselves if you do not know them already.  I am sorry I have to write
this, but there have been people who attempted GCC projects while not
knowing basic stuff and their failure lead to bitter disappointments on
all sides.  Nevertheless, a group of competent C programmers with
rudimentary knowledge of Linux and pthreads should be able to finish the
project in time.

I hope this mostly answers your question, please feel free to ask again
if I have omitted something.

Good luck with your project,

Martin


>>
>> On Sun, Sep 19 2021, Mohamed Atef via Gcc wrote:
>> > Hello there,
>> > We are 6 students from Egypt and now We are in our last year and We need
>> to
>> > build a project as a graduation project.
>> > And We are interested in the area of runtime systems, operating systems
>> and
>> > compilers.
>> > We are going to work 40-60 hrs a week
>> > Can We help in some tool you need as a graduation project given that We
>> > have a professor to mentor us.
>> > If not can you suggest some tool you need to build and We will work on
>> it.
>> > The project take one academic year
>> >
>>
>> GNU tools miss an implementation of OMPD, an interface for third-party
>> tools to examine and debug programs using OpenMP API for
>> multiprocessing.
>>
>> For complete formal description see chapter 5 (and other relevant bits)
>> in
>> https://www.openmp.org/wp-content/uploads/OpenMP-API-Specification-5-1.pdf
>>
>> The project would be a larger one and from the more difficult kind, but
>> 6 students interested in the areas you described should be well able to
>> complete it within a year and even enjoy it.  I believe most of the work
>> is needed within libgomp run-time library supporting OpenMP programs,
>> but everything in this area is very closely related to both core
>> operating system primitives, compilers and debuggers.
>>
>> Feel free to ask for more information on the gcc mailing list if you are
>> interested.
>>
>> Good luck with your project,
>>
>> Martin
>>

Re: Development request

[Jakub Jelinek via Gcc]

On Tue, Oct 12, 2021 at 01:09:10PM +0200, Martin Jambor wrote:
> The preferred way of communication is email posted to the mailing list
> (sometimes CCing the people you think are most likely to reply) and I am
> quite confident that people will read it and reply to reasonable
> questions and review patches, even RFC patches.
> 
> I think that the important OpenMP contributors could be persuaded to an
> occasional - if perhaps not regular - call to discuss overall
> architecture, milestones and even any hard-to-tackle problems, but you
> need to ask them yourselves (hint: I CCed some).  In the end of the day,
> email should be the main channel, though.

Note, we had already in the past a GSoC project for OMPD in 2020,
by Tony Sim.  It wasn't finished, so nothing has been committed, but
the student had GCC Copyright Assignment, so parts of what he has posted
to the gcc-patches mailing list could be used for the project, either
unmodified or modified (but I think changes from his private repository
can't be used unless he agrees with that), but even if nothing that has
been posted is used, it would be useful if you and your collegues read the
OMPD threads on gcc-patches.  Search in
https://gcc.gnu.org/pipermail/gcc-patches/2020-June/thread.html#start
https://gcc.gnu.org/pipermail/gcc-patches/2020-July/thread.html#start
for threads where y2s1982 participated, to e.g. see what we've been looking for.
One important part that was missing and is needed quite early is that it is
testable and consumable, so while some of the students should work on the
OMPD code in libgomp, somebody should also work on GDB support for OMPD
(and for that it would be useful to talk to people on the gdb mailing
list in sourceware.org and look for a mentor for that part of work there)
and somebody ideally should work on either a GDB plugin or just GDB python
scripts (and if needed some C code) and associated dejagnu infrastructure,
so that it is also possible to test the OMPD library side in the libgomp
testsuite.
You can e.g. look how other parts of GCC testsuite use GDB, we have e.g.
gcc/testsuite/gcc.dg/guality/* testsuite including
gcc/testsuite/gcc.dg/guality/guality.exp driver for that that uses
gcc/testsuite/lib/gcc-gdb-test.exp under the hood for running GDB on certain
test and querying the debugger about values of certain expressions on
certain lines, or e.g.
libstdc++-v3/testsuite/libstdc++-prettyprinters/*
with
libstdc++-v3/testsuite/libstdc++-prettyprinters/prettyprinters.exp
driver tests printing of libstdc++ types in the debugger.
Another option is writing some simple framework for the testing, but
one needs to provide the various callbacks OMPD needs and those would need
to use something like ptrace to talk to the inferior.

Also, please see https://gcc.gnu.org/contribute.html

Jakub

Re: Broken links on website

[Martin Liška]

On 10/12/21 10:12, Ryan Plant wrote:

Just a quick heads-up , https://gcc.gnu.org/install/binaries.html currently
has two broken links. "MinGW" leads to a dead site covered in
domain-parking ads, and the "mingw-w64" one 404s. I believe the current
links for those projects are https://osdn.net/projects/mingw/ and
https://www.mingw-w64.org/ respectively.



CCing Gerald.

Martin

Re: GSoC: Intention to apply to GSoC'22(GCC)

[Martin Jambor]

Hello,

sorry for a late reply.  I was traveling and in various meetings over
the course of the last two weeks and could not pay as much attention to
email as I would have liked to.  Nevertheless, we are delighted you
found contributing to GCC interesting.

On Sun, Sep 26 2021, mir imnan via Gcc wrote:
> Hello there,
> I want to contribute to GCC through next year's GSoC program. I'm a 2nd
> year engineering student, and I've been interested in compiler dev for
> quite some time now. Until now, I've implemented a high level PL(Zeta-lang
> ) and I'm now trying to write a C
> compiler in Ruby(rubyC ).

Indeed quite interesting.

> At this point, I can build the GCC from source and have read some internal
> docs. I want someone to help me to figure out the codebase and select a
> project idea that's appropriate for me (given my experience).

You have already reached the right place to ask questions about the
codebase.  Just email it to the gcc mailing list.  Alternatively, ask it
on the #gcc irc channel (https://gcc.gnu.org/wiki/GCConIRC) if you
prefer more real-time communication.

Regarding project ideas, that really depends on what you are interested
in.  GCC is a big project and you need to find the part that interests
you most.  If you like to work on the front-end (parsing) side of
things, I know that Fortran guys are always looking for someone to help
them out.  On the optimization and code-generation side of things,
potential projects are usually a bit bigger and more complex and so we
do not advertise them as much for GSoC, so I don't have a good proposal
right now, but we should be able to come up with something.  (Also, so
far I do not know the scope of GSoC 22 projects, I expect Google to
announce that on November 5th.)

In general, I expect all the projects on our GSoC wiki
(https://gcc.gnu.org/wiki/SummerOfCode) that were not successfully
tacked this year to be on the list next year again.

I'm looking forward to seeing you on the mailing list and/or IRC,

Martin

Re: Broken links on website

[David Edelsohn via Gcc]

The Binaries information on the website is generated from the Binaries
information in the GCC Install docs.  I updated the links in the docs.
Thanks for alerting us to the broken links.

Thanks, David

On Tue, Oct 12, 2021 at 4:14 AM Ryan Plant  wrote:
>
> Just a quick heads-up , https://gcc.gnu.org/install/binaries.html currently
> has two broken links. "MinGW" leads to a dead site covered in
> domain-parking ads, and the "mingw-w64" one 404s. I believe the current
> links for those projects are https://osdn.net/projects/mingw/ and
> https://www.mingw-w64.org/ respectively.

Question about symtab_node::order during LTO

[Erick Ochoa via Gcc]

Hi,

I have an LTO pass which stores information collected during "generate
function summary" in a map which is symtab_node* -> data*. I know that
the symtab_node*s are encoded by an lto encoder and can be decoded
back during the "read function summary". I also am aware that other
optimizations might be removing or adding cgraph_node*s to the program
and my pass uses the insertion and removal hooks to analyze or drop
these accordingly. However, I am confused about different function
versions. My current understanding is that different versions of the
same function share the same cgraph_node*. Is this correct?

If that's the case, that would mean that storing information on a map
where the key is the symtab_node* is probably not a good idea as a
specific version of the function might be dropped and in that case I
may be dropping information for all cases.

This brings me to the field "order" in symtab_node. Is this field
constant through the linking process and can it be used to
differentiate between different versions of the same function?

Thanks!

Seeking help for contributions and joining open-source community

[Vaibhav Malik via Gcc]

Hey!

I am an electrical engineering student. I came across the GNU octave a few
months back and I want to contribute to improving the existing open-source
projects and be part of the community.

I would appreciate it if someone could help me set up and guide me about
what should I learn to get started.

Could someone help me out?