Re: git conversion in progress

[Martin Jambor]

Hi,

On Tue, Jan 14 2020, Andreas Schwab wrote:
> On Jan 14 2020, Georg-Johann Lay wrote:
>
>> git clone --reference original-gcc ...
>
> Don't use --reference.  It is too easy to lose work if you don't know
> what you are doing.

What are the risks, assuming I won't delete the referenced repo which
sits on the same partition of the same local disk as the new one?

I prefer it to worktree because I often just do have master checked out
in multiple directories and worktree would be unhappy about that... and
the risk of accidentally deleting the base worktree are IMHO the same as
the risk of deleting the referenced repo.

Anything that I am missing?  (In other words, do I know what I am doing? :-)

Thanks,

Martin

Re: git conversion in progress

[Martin Jambor]

Hi,

On Tue, Jan 14 2020, Andreas Schwab wrote:
> On Jan 14 2020, Martin Jambor wrote:
>
>> Hi,
>>
>> On Tue, Jan 14 2020, Andreas Schwab wrote:
>>> On Jan 14 2020, Georg-Johann Lay wrote:
>>>
>>>> git clone --reference original-gcc ...
>>>
>>> Don't use --reference.  It is too easy to lose work if you don't know
>>> what you are doing.
>>
>> What are the risks, assuming I won't delete the referenced repo which
>> sits on the same partition of the same local disk as the new one?
>
> The risk is if the original repository is gc'd (and nowadays git
> automatically runs git gc --auto from time to time) it may lose objects
> that are still needed by the referencing repository.  That doesn't
> happen with git worktree as the main repository knows about all
> references, including worktree local reflogs.

Aha, that makes sense.  In my intended setup, that *probably* would not
happen because the referenced repo would only hold stuff from the
upstream one but the danger sounds real enough for me to reconsider and
use worktrees and a number of branches pointing to the same commit as
master.

Thanks,

Martin

GCC GSoC 2020: Call for mentors and project ideas

[Martin Jambor]

Hello,

Google Summer of Code (aka GSoC) 2020 yesterday started accepting
Organization Applications.  I believe the last year was very successful
and so think that we want to take part again this year again.  I'll be
happy to volunteer to be the main Org Admin for GCC again (so let me
know if you think I shouldn't or that someone else should, but otherwise
I'll assume that I probably will). The deadline to apply is February
5th, so in the next three weeks we need to work on our project ideas and
have a list of willing mentors.

Therefore, first and foremost, I would like to ask all (moderately)
seasoned GCC contributors to consider mentoring a student this year and
ideally also come up with a project that they would like to lead.  I'm
collecting proposal on our wiki page
https://gcc.gnu.org/wiki/SummerOfCode - feel free to add yours to the
top list there.  Or, if you are unsure, post your offer and project idea
as a reply here to the mailing list.

Eventually each developed project should have a) a project
title/description b) more detailed description of the project (2-5
sentences) c) expected outcomes d) skills required/preferred and e)
possible mentors [1].

Project ideas that come without an offer to also mentor them are always
fun to discuss, by all means feel free to reply to this email with yours
and I will attempt to find a mentor, but please be aware that we can
only use the suggestion it if we actually find one.

Everybody in the GCC community is invited to go over
https://gcc.gnu.org/wiki/SummerOfCode and remove any outdated or
otherwise bad project suggestions and help improve viable ones which are
not yet viable.  I would especially want to ask GFortran and libstdc++
people to do so.

Finally, please continue helping (prospective) students figure stuff out
about GCC like you always do.  So far I think all of them enjoyed
working with us, even if many sometimes struggled with GCC's complexity.

More information together with GSoC 2020 time line is available at
https://summerofcode.withgoogle.com

Thank you, let's hope we attract some good young talent again this year.

Martin


[1] https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list

Re: C++ constructors and callgraph interaction ("__ct_comp " vs constructor function body)

[Martin Jambor]

Hi,

On Wed, Feb 05 2020, David Malcolm wrote:
> Answering my own question, calling ultimate_alias_target on the
> __ct_comp cgraph_node seems to find the "right" cgraph_node.
>
> Is that the right general-purpose answer here?
>

sounds like it.  If however you also want the function to
look through thunks you should use cgraph_node::function_symbol()
instead.  But thunks of course can modify the first parameter, return
value etc.

Martin

Re: GCC GSoC 2020: Call for mentors and project ideas

[Martin Jambor]

Hi David,

On Wed, Feb 12 2020, David Malcolm wrote:
> On Thu, 2020-02-06 at 20:58 -0500, David Malcolm wrote:
>> On Mon, 2020-01-27 at 16:30 +0100, Martin Liška wrote:
>> > On 1/15/20 11:45 PM, Martin Jambor wrote:
>> > > Therefore, first and foremost, I would like to ask all
>> > > (moderately)
>> > > seasoned GCC contributors to consider mentoring a student this
>> > > year
>> > > and
>> > > ideally also come up with a project that they would like to
>> > > lead.  I'm
>> > > collecting proposal on our wiki page
>> > 
>> > @David would you be interested in a analyzer topics? Seems to me
>> > ideal for newcomers to come up with a static analyzer check?
>> 
>> I'm not quite sure what the appropriate size of a project would be,
>> but
>> I'd be happy to mentor a student.  Some ideas I had for analyzer
>> topics:
>> 
>> * Generalize double-free checker to attribute-marking of
>> acquire/release API entrypoints so that the user can mark the
>> entrypoints and get a checker for that API "for free".
>> 
>> * Checking of the POSIX file-descriptor APIs (int rather than FILE
>> *),
>> or some other POSIX API that we're not yet checking.
>> 
>> * Maybe add plugin support, and write a plugin to add a project
>> specific-checker for a project of interest to the student (Linux
>> kernel?)
>> 
>> * C++ support (new/delete checking, exceptions, etc)
>> 
>> Thoughts?
>> Dave
>
> I've taken the liberty of adding the above idea to the list of
> "Selected Project Ideas for 2020" on
>   https://gcc.gnu.org/wiki/SummerOfCode
> with me as mentor.
>

Excellent! ...and sorry for not getting back to you earlier.

Thanks a lot,

Martin

Re: Make LTO Patch for Job Server Thread Detection Agnostic

[Martin Jambor]

Hi,

On Fri, Feb 28 2020, Nathan Sidwell wrote:
> On 2/27/20 12:04 PM, Paul Smith wrote:
>> On Thu, 2020-02-27 at 16:58 +, Jonathan Wakely wrote:
 That's a problem then as were assuming a user's build system for this
 to work. I mean for now its fine but in the future wouldn't it de a
 good ideal to not assume this?
>>>
>>> It works fine for everybody. There's just an optimisation for people
>>> with a GNU make jobserver available. I don't see a problem.
>>>
>>> If somebody wants to add an optimisation for their preferred build
>>> system they can propose a patch.
>> 
>> And/or they can suggest to other build systems that they also add support
>> for this service.
>> 
>> I'm not aware of any service like this which is supported by all build
>> tools, so it's not like we're choosing this over something else that's more
>> widely available.  Actually as far as I know other build tools don't
>> provide anything like it, portable or not.
>
> Recently Honza, me and others discussed LTO's interaction with build 
> systems, and that perhaps the module mapper could be generalized for 
> other purposes.  (Yes, still need to resurrect my Make PoC)

see also the "Create a general jobserver client/server library" library
suggested GSoC project at https://gcc.gnu.org/wiki/SummerOfCode.

Martin

Re: GSOC

[Martin Jambor]

Hello,

On Sun, Mar 15 2020, shivam tiwari via Gcc wrote:
> In Which Format I have to Send Gsoc Proposal On this Mail PDF or DOC Format

if you want to discuss your proposal on this mailing list, then plain
text in an email message is the best option.

Per GSoC rules (IIRC), the final application has to be in PDF.

Please make sure you read
https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply
and https://gcc.gnu.org/wiki/SummerOfCode#Application

Good luck,

Martin

Re: [GSoC] Extend the static analysis pass

[Martin Jambor]

Hi Nader,

On Tue, Mar 24 2020, Nader Al Awar wrote:
> Hello,
>
> I am a master's student at UT Austin and I am interested in working on
> extending the static analysis pass project as part of GSoC.
> Specifically, I'm interested in both adding C++ support for new/delete
> and adding plugin support.
>
> Most of my background is in software engineering and testing: building
> tools to find bugs and improving software reliability through testing,
> but I do have some experience with static analysis. Most of my
> programming experience is in C++ and C to a lesser extent. Also, I
> have always been interested in working on a compiler project, so this
> project seems like a good opportunity to combine my past experience
> with my other interests.
>
> I already worked through the “Before You Apply“ section

great!

> and I was
> wondering whether there are any tasks I need to do before I submit an
> official application.

We do not require students to do a small task before submitting
application.  Finding your way around the source so that you can write a
meaningful proposal is a task in itself.

I would however strongly encourage you to send a rough draft to this
mailing list first, at least a few days before the application deadline.
The community can usually help fix various errors and misconceptions and
especially help with planing the scope of the project.

If you have any specific questions, please feel free to ask as well.

Good luck!

Martin

Re: GSoC: Implementation of OMPD

[Martin Jambor]

Hi Tony,

sorry for a late reply, things are a bit crazy recently.

On Sat, Mar 07 2020, y2s1982 . wrote:
> Hello everyone,
>
> My name is Tony Sim. In anticipation to planning for my last summer within
> my degree program, I am considering to take part in the Google Summer of
> Codes.  In particular, I would like to work on implementing OMPD for GCC
> and related programs.
>
> I have studied CPU and GPU parallel programming in the span of two
> semesters, which included OpenMP as a significant part of the curriculum. I
> am quite fascinated by its possibilities and would love a chance to learn
> more while tackling a real-world challenge.
>
> I would appreciate any additional information on the project.  It looks
> very interesting. Really, it sounds like something I wish I had when I was
> taking the course.
>

The OMPD project idea might be the most ambitious from the whole lot.
Basically, the goal is to come up with a prototype implementation of
chapter 5 of OpenMP 5.0 Specification
(https://www.openmp.org/specifications/), so that OpenMP programs
compiled with GCC can be debugged in GDB using OpenMP terminology.

In order to start you need to understand how OpenMP programs are
internally structured (compile some a few basic ones with
-fdump-tree-optimized and then examine the generated dump) and
especially familiarize yourself with the libgomp library that provides
essential run-time support to OpenMP programs.  Libgomp is part of GCC
project, see https://gcc.gnu.org/git/?p=gcc.git;a=tree;f=libgomp.

The long-term goal is to implement that chapter 5 in libgomp, so that
internal structures of libgomp and the run program can be exposed with
this interface.  Of course, that would be too big a project for one
summer, so the immediate goal would be to come up with an implementation
of a subset that would behave well in a given set of contexts... and
either make it consumable by GDB or at the very least demonstrate that
it can be done.  Still a lot of work.

If you have any further questions, please feel free to ask.

Good luck with your GSoC!

Martin

Request to deprecate offloading to HSAIL in GCC

[Martin Jambor]

Hello,

HSAIL - the intermediate language bit of HSA - has not been much of a
success.  I don't know about anybody using it, planning to use it or
being interested in any way, except possibly me.  There really isn't any
finalizer targeting GPUs (or APUs), the one we use to test HSAIL
generation is a proprietary executable hacked into an old HSA run-time
in a way that makes me afraid to touch the computers set up this way.

The HSAIL code generation is fortunately mostly a rather separate bit of
code which does not really cause much trouble.  That is, except the
OpenMP bits which is how we feed the HSA back-end and which were
unfortunately badly designed (mostly by me) and very likely will soon
pose big problems during implementation of new OpenMP features.  They
have to go away.

Right at the beginning of the next stage 1, I will set aside a few days
to try and change the OpenMP bits of HSA offloading to something similar
to what we use for NVPTX.  But I will not hide that I plan to do it
mostly so that I learn something new, a few days is probably not enough,
and generally speaking, I do not think that any big effort invested into
HSAIL is now worth it.

Therefore it is only fair to warn the community and any possible hidden
users or would-be users that it is very likely that I will propose
removal of HSAIL offloading in the course of GCC 11 development cycle
and I would like to formally deprecate it.

So how is it done, by proposing a patch to changes.html?

Note that this deprecation does not include the BRIG front-end.  That
does not cause any real problems that I am aware of and I think that at
least at this point we can and should keep it.

Thanks,

Martin

Re: Not usable email content encoding

[Martin Jambor]

Hi,

On Fri, Apr 24 2020, Segher Boessenkool wrote:
> Hi!
>
> On Fri, Apr 24, 2020 at 05:48:38PM +0200, Thomas Koenig wrote:
>> >Of course, better would be to remove ChangeLogs entirely (including not
>> >putting anything like them into a commit message), because they are
>> >largely not useful and are just make-work.
>> 
>> I disagree. I find them quite useful.
>
> For what?  And, can that be provided some other way?

I often have a look at them when reviewing a patch.  It is great when
they clearly indicate whether a change is some form of restructuring or
a functional change and broadly speaking what it is.  Then I just know
what to look for.

I also find writing them useful as it forces me to go through every
patch one last time before submitting it :-) If you spend some time
configuring your text editor and git, the boilerplate stuff can be
generated automatically.

I do not think this can be provided in any other way that would not
resemble a ChangeLog.  I do support the effort to put them into commit
messages only though (and then perhaps generate the files from that).

Martin

Re: where i should insert the finalize function for c++？

[Martin Jambor]

Hi,

On Sun, Apr 26 2020, 易会战 via Gcc wrote:
> I am working a instrumentation tool based on gcc. I insert some
> intrumentation code into each function, including destructor
> functions. A finalize function will free memory resources after all
> work done. But I cannot find proper loacation calling my finalizing
> function since the destructor functions will called finally after the
> program exit.

IIUC you need to execute your "finalize function" from a "static
destructor" - nothing to do with C++ destructors, these are just
functions executed before the program exits.

Look for places in the code which call cgraph_build_static_cdtor with
'D' as the first parameter.

Good luck,

Martin

Re: Not usable email content encoding

[Martin Jambor]

Hi,

On Fri, May 01 2020, Jeff Law wrote:
> On Fri, 2020-04-24 at 22:01 +0200, Martin Jambor wrote:
>> Hi,
>> 
>> On Fri, Apr 24 2020, Segher Boessenkool wrote:
>> > Hi!
>> > 
>> > On Fri, Apr 24, 2020 at 05:48:38PM +0200, Thomas Koenig wrote:
>> > > > Of course, better would be to remove ChangeLogs entirely (including not
>> > > > putting anything like them into a commit message), because they are
>> > > > largely not useful and are just make-work.
>> > > 
>> > > I disagree. I find them quite useful.
>> > 
>> > For what?  And, can that be provided some other way?
>> 
>> I often have a look at them when reviewing a patch.  It is great when
>> they clearly indicate whether a change is some form of restructuring or
>> a functional change and broadly speaking what it is.  Then I just know
>> what to look for.
>> 
>> I also find writing them useful as it forces me to go through every
>> patch one last time before submitting it :-) If you spend some time
>> configuring your text editor and git, the boilerplate stuff can be
>> generated automatically.
> Agreed on all the points above.  I can't count how many patches I've
> written through the years, then got to the ChangeLog step and realized
> that further work was needed.

I can relate to that :-)

>
>> 
>> I do not think this can be provided in any other way that would not
>> resemble a ChangeLog.  I do support the effort to put them into commit
>> messages only though (and then perhaps generate the files from that).
> That's where I lean as well.  I could also live with the ChangeLog being
> generated by a commit hook

Please note that this would change the commit hash from what the author
had on their computer, which would be a bit unfortunate.  But generating
them along with the "Daily bump" seems like a nice alternative.

Thanks,

Martin


> and the like.  Ultimately it's the manual steps in
> applying patches that I want to eliminate from our workflows and the ChangeLog
> file consistently results in the need for manual intervention.
>
> jeff

Welcome GCC GSoC 2020 participants

[Martin Jambor]

Hello,

I am pleased to announce that three students will be working on GCC or
GCC-related Google Summer of Code (GSoC) projects in 2020:

 - Giuliano Belinassi will be working on "Automatic Detection of
   Parallel Compilation Viability."  This project will be mentored by
   Richard Biener and Jan Hubička.

 - John Ravi will work on "General Jobserver Client/Server Library" and
   be mentored by Martin Liška and Nathan Sidwell.

 - Tony Sim has embarked on " Implementing the OMPD interface" in
   libgomp, his project will be mentored by Jakub Jelínek and myself.

I'd like to congratulate all of them for putting together very solid
proposals and wish them best of luck with their projects.

All accepted students which do not already have one must request a
copyright assignment[1] as soon as possible.  Giuliano has it from last
year but I suspect that John and Tony do not.  Please email the
following information to ass...@gnu.org and they will send you the
assignment form for your past and future changes.  Use your full legal
name (in ASCII characters) as the subject line of the message.  The "the
program or package" is of course GCC.

--
REQUEST: SEND FORM FOR PAST AND FUTURE CHANGES

[What is the name of the program or package you're contributing to?]

[Did you copy any files or text written by someone else in these changes?
Even if that material is free software, we need to know about it.]

[Do you have an employer who might have a basis to claim to own
your changes?  Do you attend a school which might make such a claim?]

[For the copyright registration, what country are you a citizen of?]

[What year were you born?]

[Please write your email address here.]

[Please write your postal address here.]

[Which files have you changed so far, and which new files have you written
so far?]
--

Please report back to me when you have completed the process and also if
you encounter any issues and/or unreasonably long delays.

The GSoC program has now entered its "community bonding period" which
lasts until June 1st.  During this time you should get in touch with
your mentors unless you have already done so and probably start looking
a bit more at GCC in general.  Because GCC targets many computer
platforms, you may also find it very useful to get an account on the
compile farm[2] so that you can test your code on a variety of
architectures.  Last but not least, feel free to raise any question you
might have on an appropriate mailing list[3] or say hi to us on the gcc
development IRC channel [4].

If you have any concerns or questions regarding the organizational part
of GSoC 2020 or just don't know who else to reach out to, feel free to
contact me throughout the duration of the program.

Once more, congratulations and good luck!

Martin

[1] https://gcc.gnu.org/contribute.html#legal
[2] https://gcc.gnu.org/wiki/CompileFarm
[3] https://gcc.gnu.org/lists.html
[4] https://gcc.gnu.org/wiki/GCConIRC

Re: Welcome GCC GSoC 2020 participants

[Martin Jambor]

Hello Tony,

On Wed, May 20 2020, y2s1982 . wrote:
> Hello Martin,
> On Mon, May 18, 2020 at 11:32 AM Martin Jambor  wrote:
>
>> Hello Tony,
>>
>> sorry for not getting back to you last week.  Time seems to fly even
>> faster now that I'm forced to work from home :-/  Furthermore, both me
>> and Jakub have been preparing for a big OpenMP meeting that takes place
>> this week.
>
> Wow, is that meeting something I may attend? It sounds like an amazing
> learning opportunity.

Unfortunately no, it is a meeting of representatives of "members of the
OpenMP Architecture Review Board" and is not opened to public.

>> On Tue, May 12 2020, y2s1982 . wrote:
>> > This is Tony Sim. I am excited to report that I have been getting some
>> > documentation out of the way in the past few weeks.
>> > - I have submitted a signed application to ass...@gnu.org. I had a corr-
>> > -espondence with Craig and have submitted a signed document last
>> Thursday.
[...]
>
> I got a reply from Craig yesterday with the form that has both signatures.
> It seems that part is now complete.
>

Great, It is good to know this has been sorted out.

[...]

> Oh, that makes sense: private keys shouldn't be shared. I do have a public
> key, so I will share it when given the opportunity. I will reach out to the
> Compile Farm later this week to inquire more on the progress of the
> application.

Good.  Compile farm will only get handy once it gets to testing stuff
anyway (assuming you have a reasonable computer to work on).

[...]

>>
>> About "how do I contribute" question you asked on IRC: I think it's
>> going to take a little while before we get to that but once you have the
>> FSF copyright assignment and something to contribute, we'll get you an
>> account allowing you to commit after approval directly to the upstream
>> repo - after approval means once your patch has been officially approved
>> by the respective maintainer on the gcc-patches mailing list.
>>
>> At this point, I'd suggest that you simply clone our git repo and start
>> experimenting.  Patch-via-email is likely to be the most used way of
>> discussing code.  At some point we'll probably need a branch, that can
>> initially sit either on gcc git server or anywhere else, really.  There
>> is a mirror both at gitlab (https://gitlab.com/x86-gcc/gcc) or github
>> (https://github.com/gcc-mirror/gcc) and many other git hosting services,
>> for example.  Whatever fits your philosophical or practical preferences.
>
> If it is all the same, and since I am familiar with working on github, may
> I work on github?  I took the liberty of creating the fork of gcc-mirror to
> my account. I would like to create a major develop branch within the fork,
> and create minor develop branches from that branch. I would also like to
> plan out my tasks using their Issue tracking system. The minor develop
> branch code would be reviewed via PR by any interested parties,
> particularly Jakub, after which it would be squash-merged to the major
> develop branch of the fork.  We can discuss further on the interval for the
> patch-via-email process to merge the code to upstream, which I assume would
> happen when the code reaches certain maturity, or at least at the end of
> this project.

If that is how you like to work, I guess we can try it out.  Just please
keep in mind that:

1) We are used to reviewing patches in our email clients and prefer it
   to reviews in web-based tools.  I have quite a lot of customizations
   in place that I am used to and so prefer it to
   one-method-fits-everyone web tools.

2) Do not spend too much time thinking about how to organize the
   project.  The time is better spent actually thinking about the
   project itself, particularly because I expect this one to entail a
   lot of experimenting with an occasional dead end.

> I also would like to know how often I should pull from upstream to
> keep the fork up to date.

I personally pull every Monday, sometimes every other Monday if I feel I
am particularly short of time.  As long as it does not cause any painful
merging issues, I'd suggest similar cadence.  If there are issues,
falling behind a few weeks is OK if it helps you focus, I think.

[...]

>>
>> I know that this delayed response might suggest otherwise, but email
>> will be the main communication method for the project.  I believe Jakub
>> strongly prefers email too, perhaps even more than I do.
>
> I am comfortable with email. The community has been very generous on IRC
> front, too, so I guess I will use both methods.
>
>> More often than not it will be a good idea to CC the gcc mailing list on
>> any

Re: GSoC: OMPD conversation

[Martin Jambor]

Hi,

On Sun, May 31 2020, y2s1982 . wrote:
> Hello team,
>
> I just wanted to give an update to my current progress. I spent most of the
> time looking over OMPD documentation again and studying LLVM's approach to
> it.
>

thanks a lot, sorry about replying this late again, unfortunately I
missed your email on Monday and only noticed it yesterday.

[...]

>>
>> 1) We are used to reviewing patches in our email clients and prefer it
>>to reviews in web-based tools.  I have quite a lot of customizations
>>in place that I am used to and so prefer it to
>>one-method-fits-everyone web tools.
>>
> I understand. This kind of information is exactly what I wanted to know so
> I can adjust my work process to fit the community needs. My I follow the
> above process of making PR but also create a patch using 'git diff' command
> and share that with the mailing list?

yeah, sure, although I think people usually use git format-patch.

>
>>
>> 2) Do not spend too much time thinking about how to organize the
>>project.  The time is better spent actually thinking about the
>>project itself, particularly because I expect this one to entail a
>>lot of experimenting with an occasional dead end.
>>
> I understand. I just thought this discussion belonged to me getting to know
> how to work with the community and therefore fit the community bonding
> period theme. I am very excited to get to actually work, too.
>
>>
>> >> Having said that, if you'd like to do a hangouts video call to say hello
>> >> to each other and perhaps to discuss some issues with setting up your
>> >> work, I personally am definitely happy to do that too.  As a regular
>> >> communication tool, I did not find videoconferencing to be very useful
>> >> in the past (but I guess I can be persuaded to try again).
>> >
>> > Hmm. In my last coop that ended during pandemic, we used the video
>> > conferencing tool to do daily stand-ups so the team can keep tabs on how
>> > different parts of the project is going and give suggestions as needed. A
>> > little off-topic, but how often would you like to discuss my progress of
>> > the project?
>>
>> So... ideally the stream of emails discussing the overall approach,
>> followed by a stream of patches and reviews would make it completely
>> unnecessary to ask you for some kind of regular status reports.
>> Nevertheless, if some task takes you more than a 4-5 work-days in which
>> you don't get back to us, please send us a quick summary of what you
>> have been working on.  This arrangement of course means that you need to
>> reach out to us if you believe you are stuck, so please do.
>>
>> But let me reiterate that I am willing to try a videoconference or two
>> if you think it would be useful at any point.
>>
> Would it be nice to have a face-to-face conversation perhaps in the first
> week of June? Perhaps open to any interested community member to discuss
> the beginnings of the OMPD?

OK, so me not noticing the email made that impossible, I'm afraid.  But
let's try the 2nd week.  Feel free to offer a suitable time.  I plan to
ping Jakub on IRC tomorrow and see if/when he'd be willing to attend.

>>
>> No, GCC, the compiler, reads C and then goes through various stages of
>> intermediate representations of the C code, one of which is gimple,
>> optimizes it and produces an assembly.
>>
>> If that C file contains OpenMP directives (and you compile with
>> -fopenmp) many of those are converted in one way or another into calls
>> into the "GNU offloading and multi-processing (run-time) library:"
>> libgomp.  It used to be just GNU OpenMP library but now it is also the
>> run-time library for OpenACC.
>>
>> For example, #pragma omp parallel is compiled in a way that the body of
>> the construct is outlined into a special artificial function and the
>> construct itself is compiled into a call to a function GOMP_parallel,
>> with a reference to the function with the body passed in one of the
>> parameters.  In gimple optimized dump, the function is called
>> __builtin_GOMP_parallel which I admit is slightly confusing, but it is
>> the same thing - and the concept should be well visible in the dump.
>>
>> GOMP_parallel is a function in libgomp.  Grep-ing for it in the libgomp
>> subdirectory finds it in parallel.c.  From the dump you should have good
>> idea what it receives in its parameters.  Reading a large chunk of
>> libgomp source code starting there - and perhaps at other such entry
>> points - is probably a good idea.
>>
>
> I think I will study the libgomp library first week of June. I will keep
> the above in mind as I look over the code. Now that I have more
> understanding of OMPD, I aim to find relevant functions that I could use
> for OMPD.
>
>
>> > I skimmed through the documentation to familiarize with the interface. I
>> > would have to read more on it as I go through the development.
>> > I also looked at the clang project. I could see how some of the document
>> > was used to creat

Re: Push to my private branches is disallowed

[Martin Jambor]

Hi,

On Mon, Jun 15 2020, Segher Boessenkool wrote:
> Hi!
>
[...]
> What.
>
> Of course it is not a fast-forward.  I rebase the branches I publish,
> what is the point of publishing them otherwise?  This is so that people
> can see the stuff that will make its way into master *later*.
>
> The number of new commits is nonsense (it is just 13), and the number of
> emails that triggers should be 0.
>
> Please fix?  Or, what else is wrong?

while I tend to agree that sending emails about commits to user branches
is not a good idea, I also believe that you should (almost?) never
rebase a public branch.  Certainly not if you expect anyone else to
fetch it or - god forbid - base some of their commits on it, as opposed
to just reading it through the web interface.  I'd suggest appending a
date to the namer of the branch and thus always publish a new branch,
making it clear that its history is different.

Martin

Re: RFC noipa sizeof function for record relayout at link time

[Martin Jambor]

Hi,

On Mon, Jun 29 2020, Erick Ochoa wrote:
> == How do we get what we want? ==
>
> Ideally what we want is to:
>

[...]

> * Disable constant propagation and other optimizations:
>* possibly __attribute__((noipa))

[...]

> == What's the WORST CASE performance of having an unknown sizeof? ==
>
> I was concerned that the values generated by sizeof might be used by 
> constant propagation and other optimizations might depend on this value. 
> So, in order to have an idea of the impact of this transformation might 
> have on code, I manually changed all sizeof statements on MCF for an 
> equivalent function __lto_sizeof_T() where T identifies the type. I made 
> all these functions static and used the attribute noipa. There was no 
> measurable performance degradation when compared with an untransformed 
> run of MCF. Of course, this is only a data point and the performance 
> might depend on the application/workload/architecture... but it is good 
> to have a data point!

Note that attribute noipa also disables inlining.

>
> == What are some known unknowns? ==
>
>
> * Does noipa work for variables?
>* I think attribute noipa works for functions but I am not sure if it 
> works for variables.

No, but there are not too many IPA analyses/optimizations working on
global variables.  And making the attributes work for them should not be
hard.

> * After changing the definition of struct can we re-run all link time 
> optimizations?
>* I would not like to sacrifice performance. Because I might have 
> hindered constant propagation all optimizations which depend on it might 
> suffer. Therefore, I was wondering if after changing the fields I can 
> delete the noipa attribtue and re-run all link time optimizations 
> somehow? (However, the experiment tells us that this might not be a 
> worry. Perhaps there might be other benchmarks which are more affected 
> by this transformation.)

That would need quite a surgery in the pass manager, and it would
require re-running all body analyses at the link phase, something we're
trying to avoid.

If you need to disable IPA-CP (and IPA-SRA) changing a particular
parameter (e.g. because an earlier IPA pass has changed it beyond
recognition), ipa_param_adjustments::get_surviving_params should place
false in the corresponding vector element.

If you need to disable propagation of a specific value in a specific
call, you need to prevent creation of the associated jump function.

But of course, if the call gets inlined the propagation will happen
anyway, so if you are afraid that propagation of any value anywhere can
possibly be based on an offsetof or sizeof which you are changing, then
I don't think your problems are limited just to IPA (link time
optimization) propagation.

I'd do what Richi has suggested and enter some conservative mode if
sizeof and especially offsetof were used on a type (you might still be
able to handle memset from offset zero until the end of the structure as
a special case?).

Martin

Re: RFC noipa sizeof function for record relayout at link time

[Martin Jambor]

Hi,

On Mon, Jun 29 2020, Erick Ochoa wrote:
> On 29.06.20 06:05, Martin Jambor wrote:
>> Hi,
>> 
>> On Mon, Jun 29 2020, Erick Ochoa wrote:
>>> == How do we get what we want? ==
>>>
>>> Ideally what we want is to:
>>>
>> 
>> [...]
>> 
>>> * Disable constant propagation and other optimizations:
>>> * possibly __attribute__((noipa))
>> 
>> [...]
>> 
>>> == What's the WORST CASE performance of having an unknown sizeof? ==
>>>
>>> I was concerned that the values generated by sizeof might be used by
>>> constant propagation and other optimizations might depend on this value.
>>> So, in order to have an idea of the impact of this transformation might
>>> have on code, I manually changed all sizeof statements on MCF for an
>>> equivalent function __lto_sizeof_T() where T identifies the type. I made
>>> all these functions static and used the attribute noipa. There was no
>>> measurable performance degradation when compared with an untransformed
>>> run of MCF. Of course, this is only a data point and the performance
>>> might depend on the application/workload/architecture... but it is good
>>> to have a data point!
>> 
>> Note that attribute noipa also disables inlining.
>
> This is good! We want to basically make the values returned by these 
> functions as opaque as possible. At least as a worst case analysis for 
> how bad removing the sizeof parse time substitution all the way until 
> runtime would be.
>
>> 
>>>
>>> == What are some known unknowns? ==
>>>
>>>
>>> * Does noipa work for variables?
>>> * I think attribute noipa works for functions but I am not sure if it
>>> works for variables.
>> 
>> No, but there are not too many IPA analyses/optimizations working on
>> global variables.  And making the attributes work for them should not be
>> hard.
>> 
>>> * After changing the definition of struct can we re-run all link time
>>> optimizations?
>>> * I would not like to sacrifice performance. Because I might have
>>> hindered constant propagation all optimizations which depend on it might
>>> suffer. Therefore, I was wondering if after changing the fields I can
>>> delete the noipa attribtue and re-run all link time optimizations
>>> somehow? (However, the experiment tells us that this might not be a
>>> worry. Perhaps there might be other benchmarks which are more affected
>>> by this transformation.)
>> 
>> That would need quite a surgery in the pass manager, and it would
>> require re-running all body analyses at the link phase, something we're
>> trying to avoid.
>
> I understand. We might skip this since the experiment showed that there 
> was no performance degradation. But again... only one data point != 
> generalization.
>
>> 
>> If you need to disable IPA-CP (and IPA-SRA) changing a particular
>> parameter (e.g. because an earlier IPA pass has changed it beyond
>> recognition), ipa_param_adjustments::get_surviving_params should place
>> false in the corresponding vector element.
>
> Awesome! Thanks! I have been looking for something like this for a 
> little while.
>
>> 
>> If you need to disable propagation of a specific value in a specific
>> call, you need to prevent creation of the associated jump function.
>> 
>> But of course, if the call gets inlined the propagation will happen
>> anyway, so if you are afraid that propagation of any value anywhere can
>> possibly be based on an offsetof or sizeof which you are changing, then
>> I don't think your problems are limited just to IPA (link time
>> optimization) propagation.
>
> Sorry, I have some problem understanding this. You mentioned that noipa 
> disables inlining (which is good). Here you state that "if the call gets 
> inlined" then the value will be propagated.
>
> Are you saying that this mini benchmark experiment was flawed and that 
> we should also look at how to disable non-ipa passes?

My point was simply that if you just do not want inter-procedural
propagations to happen, than you cannot just somehow disable/limit
IPA-CP but also inlining, because that can convert them to plain old
intra-procedural propagation.  And disabling inlining is going to have
huge performance implications.  So I'd try to avoid such need as much as
possible.

Martin

Re: An problematic interaction between a call created by gimple_build_call and inlining

[Martin Jambor]

Hi,

On Wed, Jul 01 2020, Gary Oblock via Gcc wrote:
> Thank you Richard.
>
> I feel a bit dumb because I'm well aware of the GCC philosophy to have
> any new code produced update the state.  Of course I didn't know the
> commands to do this for the call graph (which I really appreciate you giving.)
>
> However, the real reason I'm sending a reply is this. Are there any surprising
> cases in IPA where GCC violates its philosophy and actually regenerates the
> information?

if by "the information" you specifically mean call graph edges then no.
(Regular) IPA optimizations are designed to also work when doing link
time optimization (LTO) which means that unless they specifically load
the (gimple) bodies of some selected functions, the bodies are not
available to them.  They only operate on the call graph and information
they collected when generating summaries.  Because gimple body is not
available, call graph edges cannot be regenerated from it.

In fact, when a call is redirected to a different/specialized function,
at IPA time it is only recored in the call graph by redirecting the
corresponding edge and the call statement is modified only at the end of
IPA phase (in LTRANS in LTO-speak).  This is necessary even when not
using LTO because until specialized nodes get their own body, they share
it with the node from which they were cloned.  That means that several
call graph edges, which do not share caller and may not even share the
callee, refer to the same gimple statement - so the decl in the
statement is actually meaningless and the edge encodes the important
information.

Martin

Re: An problematic interaction between a call created by gimple_build_call and inlining

[Martin Jambor]

Hi,

On Thu, Jul 02 2020, Gary Oblock wrote:
> Martin,
>
> What about immediate dominators?

I'm afraid I don't understand your question, what about them?

Dominators are re-computed after inlining and after clones are
materialized (when they get their own body)... I believe.

We do not store information which call graph edges dominate other call
graph edges in the callers body.  Having that information might be
useful at IPA stage.

But yeah, please be more specific what your question is.

Martin

>
> ________
> From: Martin Jambor 
> Sent: Wednesday, July 1, 2020 3:40 PM
> To: Gary Oblock ; Richard Biener 
> 
> Cc: gcc@gcc.gnu.org 
> Subject: Re: An problematic interaction between a call created by 
> gimple_build_call and inlining
>
> [EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please 
> be mindful of safe email handling and proprietary information protection 
> practices.]
>
>
> Hi,
>
> On Wed, Jul 01 2020, Gary Oblock via Gcc wrote:
>> Thank you Richard.
>>
>> I feel a bit dumb because I'm well aware of the GCC philosophy to have
>> any new code produced update the state.  Of course I didn't know the
>> commands to do this for the call graph (which I really appreciate you 
>> giving.)
>>
>> However, the real reason I'm sending a reply is this. Are there any 
>> surprising
>> cases in IPA where GCC violates its philosophy and actually regenerates the
>> information?
>
> if by "the information" you specifically mean call graph edges then no.
> (Regular) IPA optimizations are designed to also work when doing link
> time optimization (LTO) which means that unless they specifically load
> the (gimple) bodies of some selected functions, the bodies are not
> available to them.  They only operate on the call graph and information
> they collected when generating summaries.  Because gimple body is not
> available, call graph edges cannot be regenerated from it.
>
> In fact, when a call is redirected to a different/specialized function,
> at IPA time it is only recored in the call graph by redirecting the
> corresponding edge and the call statement is modified only at the end of
> IPA phase (in LTRANS in LTO-speak).  This is necessary even when not
> using LTO because until specialized nodes get their own body, they share
> it with the node from which they were cloned.  That means that several
> call graph edges, which do not share caller and may not even share the
> callee, refer to the same gimple statement - so the decl in the
> statement is actually meaningless and the edge encodes the important
> information.
>
> Martin

Re: SRA argument after materialization

[Martin Jambor]

Hi,

On Fri, Jul 10 2020, Erick Ochoa wrote:
> Hello,
>
> is there a way to determine just how an argument is affected by SRA 
> after SRA has occured? 
>
> How would I be able to determine the effects of ISRA on the struct argument?

For the changes performed by IPA-SRA (but also to spot arguments removed
as constant or unused by IPA-CP), look into the corresponding
cgraph_node->clone.param_adjustments.

(Assuming you want to do it programmatically, if you're just debugging
stuff, the IPA-SRA dump is probably the place to look at.)

Martin

Re: Crash at gimple_code(gimple* )

[Martin Jambor]

Hi,

On Wed, Jul 15 2020, Shuai Wang via Gcc wrote:
> Hello,
>
> I am using the following code to iterate different gimple statements:
>
> ...
>  gimple* stmt = gsi_stmt(gsi);
> if (gimple_assign_load_p(stmt)) {
>  tree rhs = gimple_assign_rhs1 (stmt);
>  if (!rhs) return;
>   gimple* def_stmt = SSA_NAME_DEF_STMT(rhs);

The RHS of a gimple load can never be an SSA_NAME (just look at the
source of gimple_assign_load_p), so you cannot use SSA_NAME_DEF_STMT
with it.  It's usually a VAR_DECL (or PARM_DECL) or MEM_REF which
however can be buried within arbitrarily complex "handled_component"
(see handled_component_p), i.e. ARRAY_REFs, COMPONENT_REFs and the like.

>   if (!def_stmt) return;
>
>  switch (gimple_code (def_stmt)) {
>  
>  }
> }
>
> While the above code works smoothly for most of the cases, to my surprise,
> the following statement (pointed by gsi) would cause a crash at
> gimple_code(def_stmt):
>
> stderr.9_1 = stderr;

the RHS is a VAR_DECL here.

Martin

Re: Question about function body and function specialization

[Martin Jambor]

Hi,

On Tue, Jul 14 2020, Erick Ochoa wrote:
> On 14/07/2020 12:37, Erick Ochoa wrote:
>> Hello,
>> 
>> I have a function foo defined on a source file. Sometimes, a function 
>> pointer pointing to foo is passed as a parameter to other functions 
>> where foo is called indirectly. This indirect call is specialized during 
>> link time. Still at link time, I analyze the function call the following 

Does "at link time" mean that all of the below happens as part of the
execute method of an IPA pass?  Statements and call graph do diverge for
a while at that stage (perhaps watching
https://youtu.be/LBn-0jYKLb8?t=2604 from time 26:04 until about 50:20
might help a little).

>> way:
>> 
>>    // s is the gimple statement which corresponds to the indirect call
>>    tree fn = gimple_call_fndecl(s);
>>    // for this particular call the assertions are true
>>    gcc_assert(fn)

That can't be.  If s was an indirect call, gimple_call_fndecl(s) would
return NULL (because gimple_call_fn(gs) would be an SSA_NAME).  Perhaps
early inlining already converted it to a direct one?

>>    cgraph_node *node = cgraph_node::get(fn)
>>    gcc_assert(node)
>> 
>> I have analyzed the body of this function previously by using the 
>> FOR_EACH_FUNCTION_WITH_GIMPLE_BODY macro. However, I do not know if 
>> there's a way to link the cnode_graph (or function decl) analyzed in the 
>> macro with the one obtained at the call site. What would be the best way 
>> to say something like:
>> 
>>    tree fn = gimple_call_fndecl(s);
>>    // for this particular call the assertions are true
>>    gcc_assert(fn)
>>    cgraph_node *node = cgraph_node::get(fn)
>>    gcc_assert(node)
>>    bool i_want_this_to_be_true = saw_fn_in_loop_before(node, fn);

At IPA time, the best way is always to look at the call graph edges,
something like:

   cgraph_edge *cs = caller_cgraph_node->get_edge (s);
   examine (e->callee);

Note that if the call is truly an indirect one cs->callee will be NULL
(and cs->indirect_unknown_callee will be set).  Things can also get
quite a bit more complicated if cs->speculative is set, then there is
both an indirect and guessed direct edge for a single call.

>> 
>> I don't think that using storing the for loop and checking in 
>> saw_fn_in_loop_before is the way to go because I believe cnode->decl 
>> pointers can be different. Is this correct? In other words
>> 
>> 
>> FOR_EACH_FUNCTION_WITH_GIMPLE_BODY(cnode)
>> {
>>    a_std_set.insert(cnode->decl)
>> }
>> 
>> // later
>> 
>> bool
>> saw_fn_in_loop_before(cnode_graph *cn, tree fn)
>> {
>>    return a_std_set.find(fn) != a_std_set.end();
>> }
>> 
>> Should not work. Something I found interesting is that for the fndecl 
>> obtained through the callsite gimple_has_body_p returns false. Even 
>> though I saw a fndecl which corresponds to the same function in the 
>> FOR_EACH_FUNCTION_WITH_GIMPLE_BODY.

I can only guess but it seems that something has created specialized
clone for all contexts and you happen to be looking at the gimple bodies
after clone materialization but before edge redirection... but I am only
guessing.

>
> Actually, another interesting hint is that the original foo function 
> takes two parameters. The function I am seeing inside the 
> FOR_EACH_FUNCTION_WITH_GIMPLE_BODY is a specialized function of foo with 
> only 1 parameter. However, the indirect function call is a version of 
> foo which has not been specialized (i.e. it takes the original two 
> parameters).
>
> I guess my questions would be:
>
> * Does FOR_EACH_FUNCTION_WITH_GIMPLE_BODY only iterates across functions 
> which are reachable for main across the call graph?

No.  But functions which are known not to be reachable are of course
removed from the call graph and from the entire compilation too.

> * Is the the underlying mechanism for FOR_EACH_FUNCTION_WITH_GIMPLE_BODY 
> not updated after ipa-prop discovers targets of indirect functions?

I am not sure I understand the question but I guess that no.  The
mechanism is simple, just look it up.

> * Or is it just that the new callsite does not have a gimple body for 
> its function? (This seems implausible since the new direct callsite 
> should refer to the original function implementation.) How can I access 
> this function's body?
>

In the IPA scheme of things, call-sites are updated last, even when the
function where they are keeps its body from the start until the end.  It
seems to me that you really want to be looking at the call graph edges
instead.

Generally speaking, at IPA time you want to work only with the call
graph and the data you collected in summary building stage and look at
actual function bodies only as the last resort.

Martin

Re: Crash at gimple_code(gimple* )

[Martin Jambor]

Hi,

On Wed, Jul 15 2020, Shuai Wang wrote:
> Hello!
>
> Thank you very much. I use the following statement to check and I confirm
> that it's not SSA_NAME:
>
> if (TREE_CODE(operand) != SSA_NAME) return;
>
> But considering the following code snippet:
>
> _313 = _312 + 2147450880;
> _314 = (signed char *) _313;
> _315 = **_314*; // _314 is NOT a SSA_NAME
>
> I was using the SSA_NAME_DEF_STMT here and there but right now since it
> does not work, how can I backwardly track the dependency of the above code
> snippet? Basically given _314, I would like to backwardly collect _313,
> _312, ..., until constructing the entire data dependency of _314...? Thanks
> a lot!

_314 almost certainly is an SSA_NAME, *_314 is not (note that star), it
is a MEM_REF (as far as I can tell from your email).
TREE_OPERAND (gimple_assign_rhs1 (stmt)) will give you the _314 SSA_NAME
on which you can use SSA_NAME_DEF_STMT.

When in doubt, debug_tree (callable also from within gdb) is your friend.

Martin


> On Wed, Jul 15, 2020 at 6:49 PM Martin Jambor  wrote:
>
>> Hi,
>>
>> On Wed, Jul 15 2020, Shuai Wang via Gcc wrote:
>> > Hello,
>> >
>> > I am using the following code to iterate different gimple statements:
>> >
>> > ...
>> >  gimple* stmt = gsi_stmt(gsi);
>> > if (gimple_assign_load_p(stmt)) {
>> >  tree rhs = gimple_assign_rhs1 (stmt);
>> >  if (!rhs) return;
>> >   gimple* def_stmt = SSA_NAME_DEF_STMT(rhs);
>>
>> The RHS of a gimple load can never be an SSA_NAME (just look at the
>> source of gimple_assign_load_p), so you cannot use SSA_NAME_DEF_STMT
>> with it.  It's usually a VAR_DECL (or PARM_DECL) or MEM_REF which
>> however can be buried within arbitrarily complex "handled_component"
>> (see handled_component_p), i.e. ARRAY_REFs, COMPONENT_REFs and the like.
>>
>> >   if (!def_stmt) return;
>> >
>> >  switch (gimple_code (def_stmt)) {
>> >  
>> >  }
>> > }
>> >
>> > While the above code works smoothly for most of the cases, to my
>> surprise,
>> > the following statement (pointed by gsi) would cause a crash at
>> > gimple_code(def_stmt):
>> >
>> > stderr.9_1 = stderr;
>>
>> the RHS is a VAR_DECL here.
>>
>> Martin
>>

Re: Question about function body and function specialization

[Martin Jambor]

Hi,

On Wed, Jul 15 2020, Erick Ochoa wrote:
> Hi,
>
> I narrowed down that ipa-inline is marking these indirect functions as 
> unreachable (these functions have been specialized and therefore should 
> now be direct functions). Therefore, symtab_remove_unreachable_nodes is 
> called on them. Running the following (immediately after materialization):
>
> tree fndecl = gimple_call_fndecl(s)
> cgraph_node *from_fndecl = cgraph_node::get(fndecl);
> cgraph_node *from_symtable = NULL;
> bool found = false;
> FOR_EACH_FUNCTION_WITH_GIMPLE_BODY(from_symtable)
> {
>found |= from_fndecl == from_symtable;
> }
>
> will result in found always being false.
>
> Is it the desired behaviour that functions which addresses are taken to 
> be marked as unreachable (and therefore being unregistered from the 
> symbol table)?

The individual references are tracked in the symbol table.  When we know
that we converted a former reference into a direct use, the associated
reference is removed.  When the last one is removed, the function is no
longer considered as address taken and is indeed a candidate for
removal.

Martin

>
>
> On 14.07.20 04:19, Erick Ochoa wrote:
>> Actually, another interesting hint is that the original foo function 
>> takes two parameters. The function I am seeing inside the 
>> FOR_EACH_FUNCTION_WITH_GIMPLE_BODY is a specialized function of foo with 
>> only 1 parameter. However, the indirect function call is a version of 
>> foo which has not been specialized (i.e. it takes the original two 
>> parameters).
>> 
>> I guess my questions would be:
>> 
>> * Does FOR_EACH_FUNCTION_WITH_GIMPLE_BODY only iterates across functions 
>> which are reachable for main across the call graph?
>> * Is the the underlying mechanism for FOR_EACH_FUNCTION_WITH_GIMPLE_BODY 
>> not updated after ipa-prop discovers targets of indirect functions?
>> * Or is it just that the new callsite does not have a gimple body for 
>> its function? (This seems implausible since the new direct callsite 
>> should refer to the original function implementation.) How can I access 
>> this function's body?
>> 
>> Thanks.
>> 
>> 
>> On 14/07/2020 12:37, Erick Ochoa wrote:
>>> Hello,
>>>
>>> I have a function foo defined on a source file. Sometimes, a function 
>>> pointer pointing to foo is passed as a parameter to other functions 
>>> where foo is called indirectly. This indirect call is specialized 
>>> during link time. Still at link time, I analyze the function call the 
>>> following way:
>>>
>>>    // s is the gimple statement which corresponds to the indirect call
>>>    tree fn = gimple_call_fndecl(s);
>>>    // for this particular call the assertions are true
>>>    gcc_assert(fn)
>>>    cgraph_node *node = cgraph_node::get(fn)
>>>    gcc_assert(node)
>>>
>>> I have analyzed the body of this function previously by using the 
>>> FOR_EACH_FUNCTION_WITH_GIMPLE_BODY macro. However, I do not know if 
>>> there's a way to link the cnode_graph (or function decl) analyzed in 
>>> the macro with the one obtained at the call site. What would be the 
>>> best way to say something like:
>>>
>>>    tree fn = gimple_call_fndecl(s);
>>>    // for this particular call the assertions are true
>>>    gcc_assert(fn)
>>>    cgraph_node *node = cgraph_node::get(fn)
>>>    gcc_assert(node)
>>>    bool i_want_this_to_be_true = saw_fn_in_loop_before(node, fn);
>>>
>>> I don't think that using storing the for loop and checking in 
>>> saw_fn_in_loop_before is the way to go because I believe cnode->decl 
>>> pointers can be different. Is this correct? In other words
>>>
>>>
>>> FOR_EACH_FUNCTION_WITH_GIMPLE_BODY(cnode)
>>> {
>>>    a_std_set.insert(cnode->decl)
>>> }
>>>
>>> // later
>>>
>>> bool
>>> saw_fn_in_loop_before(cnode_graph *cn, tree fn)
>>> {
>>>    return a_std_set.find(fn) != a_std_set.end();
>>> }
>>>
>>> Should not work. Something I found interesting is that for the fndecl 
>>> obtained through the callsite gimple_has_body_p returns false. Even 
>>> though I saw a fndecl which corresponds to the same function in the 
>>> FOR_EACH_FUNCTION_WITH_GIMPLE_BODY.
>>>
>>> Thanks! Any hints are appreciated!

Re: Re: Question about function body and function specialization

[Martin Jambor]

Hi,

On Wed, Jul 15 2020, Erick Ochoa wrote:
> On 15.07.20 05:03, Martin Jambor wrote:

[...]

>> At IPA time, the best way is always to look at the call graph edges,
>> something like:
>> 
>> cgraph_edge *cs = caller_cgraph_node->get_edge (s);
>> examine (e->callee);
>> 
>> Note that if the call is truly an indirect one cs->callee will be NULL
>> (and cs->indirect_unknown_callee will be set).  Things can also get
>> quite a bit more complicated if cs->speculative is set, then there is
>> both an indirect and guessed direct edge for a single call.
>
> Thanks! I did read a bunch of source code and I was wondering why all 
> the constant propagation and specialization happens by navigating the 
> call graph edges and not the gimple code.

It is designed that way in order to save memory.  When LTOing huge
applications, you do not want to load bodies of all functions into
memory at once, that way you might not be able to build Firefox,
Chromium and others even with very many gigabytes of RAM.

> I initially thought that 
> gimple_call_set_fndecl was not called because I couldn't find anything 
> except call graph edges. However, this was not the case.

The redirection is bound to eventually happen in
cgraph_edge::redirect_call_stmt_to_callee - but as you can see, it may be
a complicated process and may need to rebuild the call statement instead
of just setting the fndecl.

[...]

>> 
>> I can only guess but it seems that something has created specialized
>> clone for all contexts and you happen to be looking at the gimple bodies
>> after clone materialization but before edge redirection... but I am only
>> guessing.
>
> I think this is close to the truth. So... the function I am interested 
> in finding has indeed been specialized for "all contexts", but I think 
> this "all contexts" did not take into account the function pointers.

IPA-CP can specialize for "all known contexts" too, leaving the original
function behind for indirect calls and calls from outside of the current
compilation unit (or dll), in that case it does include code duplication
in its cost estimate.

>
> During ipa-cp I looked at the code where the function call has been 
> changed from an indirect call to a direct call and I was able to find 
> that callee->has_gimple_body_p() returns true and that it was also found 
> in FOR_EACH_FUNCTION_WITH_GIMPLE_BODY loop.
>
> I also did this during ipa-sra and the same was true.
>
> But for the pass just after materialization it was false.
>
> As mentioned in a sibling post, I found out that during the inlining 
> phase, the function is "reclaimed". I'm not 100% sure yet, but I think 
> the indirect functions are not inlined. I used -fdump-ipa-inline and in 
> my pass (after materialization) I used cnode->dump_name() to find its 
> dump name... I then looked for its dump_name and only found the following:
>
> IPA function summary for $dump_name inlinable
>
> $dump_name ($name) @0x40002a1936d8
>Type: function
>Body removed by symtab_remove_unreachable_nodes
>Visibility: prevailing_def_ironly
>Address is taken.
>References:
>Referring:
>Read from file: $file
>Availability: not_available
>Profile id: 1677473182
>Unit id: 2
>Function flags: count:17343 (adjusted) first_run:3 hot
>Called by:
>Calls:

It looks quite unreachable, no Callers, no Referring nodes - that's
where the address references which I wrote in another email are stored
in the symbol table.

Martin

Re: Question about clones after materialization

[Martin Jambor]

On Mon, Jul 20 2020, Erick Ochoa wrote:
> Hi,
>
> is there a way to find out that a function is a clone of another 
> function after materialization? I believe that `clone_of_p` only works 
> before materialization. I tried and no clones were detected.

there is former_clone_of - but as recently as PR 93621 we discussed
needing to extend that concept.  It's uses were usually added as an
afterthought and often turned out to be problematic, so be careful :-)

Martin

Re: Silly question about pass numbers

[Martin Jambor]

Hi,

On Tue, Aug 11 2020, Gary Oblock via Gcc wrote:
> For these two dump files:
>
> exe.ltrans0.ltrans.074i.cp
>
> and
>
> exe.ltrans0.ltrans.087i.structure-reorg
>
> doesn't the ".074i." mean that this dump was created
> before the ".087i." dump?
>
> If so then why does the ".074i." show GIMPLE that was
> created in the structure-reorg pass?

Honza will correct me if I am wrong but this is basically an unfortunate
effect of allowing "simple" "late" IPA passes while simultaneously
trying to achieve memory locality - i.e. after IPA we'd like to process
one function at a time and only access that function in memory, as much
as possible.  Therefore, transformation phases of proper IPA passes are
run just before the late normal intra-procedural on the same function.

But late_ipa_passes are run before that, so that they have a chance to
do their thing.  Because they cannot do WPA, they are really considered
second class citizens (that is at least my impression) and because they
wreck havoc to memory locality, we'd like to have as few of them as
possible - at least turned on by default.

Consider this another incentive to eventually upgrade your passes to
full IPA ones.

Martin

Re: Why am I seeing free.2 instead of free in exe.ltrans0.ltrans.s??

[Martin Jambor]

Hi,

On Tue, Aug 11 2020, Gary Oblock via Gcc wrote:
> Note, I'm getting close to getting my part of the structure reorganization
> optimization minimally functional (my question about value range propagation 
> remains open since I re-enabled a couple of optimizations to bypass it.) 
> Therefore this is actually important for me to resolve.
>
> I obviously generated calls to the standard library function "free."
> Also, similar calls to malloc didn't have that ".2" appended on them.
> I'd normally handle a problem like this with a Google search but
> "free.2" gets turned into "free to" and I get an insane number of
> junk search results.
>
> This is obviously an easy question to answer for those that
> have seen something similar in the past.

This looks like the name has been privatized for LTRANS compilation (see
promote_symbol and privatize_symbol_name in lto/lto-partition.c).  Does
the decl you call have DECL_EXTERN and DECL_PUBLIC set?  Are all of the
relevant flags of the associated call graph node set as you'd expect?

Martin

Re: Where did my function go?

[Martin Jambor]

Hi,

On Tue, Oct 20 2020, Richard Biener wrote:
> On Mon, Oct 19, 2020 at 7:52 PM Gary Oblock  wrote:
>>
>> Richard,
>>
>> I guess that will work for me. However, since it
>> was decided to remove an identical function,
>> why weren't the calls to it adjusted to reflect it?
>> If the call wasn't transformed that means it will
>> be mapped at some later time. Is that mapping
>> available to look at? Because using that would
>> also be a potential solution (assuming call
>> graph information exists for the deleted function.)
>
> I'm not sure how the transitional cgraph looks like
> during WPA analysis (which is what we're talking about?),
> but definitely the IL is unmodified in that state.
>
> Maybe Martin has an idea.
>

Exactly, the cgraph_edges is where the correct call information is
stored until the inlining transformation phase calls
cgraph_edge::redirect_call_stmt_to_callee is called on it - inlining is
a special pass in this regard that performs this IPA-infrastructure
function in addition to actual inlining.

In cgraph means the callee itself but also information in
e->callee->clone.param_adjustments which might be interesting for any
struct-reorg-like optimizations (...and in future possibly in other
transformation summaries).

The late IPA passes are in very unfortunate spot here since they run
before the real-IPA transformation phases but after unreachable node
removals and after clone materializations and so can see some but not
all of the changes performed by real IPA passes.  The reason for that is
good cache locality when late IPA passes are either not run at all or
only look at small portion of the compilation unit.  In such case IPA
transformations of a function are followed by all the late passes
working on the same function.

Late IPA passes are unfortunately second class citizens and I would
strongly recommend not to use them since they do not fit into our
otherwise robust IPA framework very well.  We could probably provide a
mechanism that would allow late IPA passes to run all normal IPA
transformations on a function so they could clearly see what they are
looking at, but extensive use would slow compilation down so its use
would be frowned upon at the very least.

Martin

Re: Where did my function go?

[Martin Jambor]

Hi,

On Tue, Oct 20 2020, Jan Hubicka wrote:
>> On Tue, Oct 20, 2020 at 1:02 PM Martin Jambor  wrote:
>> >
>> > Hi,
>> >
>> > On Tue, Oct 20 2020, Richard Biener wrote:
>> > > On Mon, Oct 19, 2020 at 7:52 PM Gary Oblock  
>> > > wrote:
>> > >>
>> > >> Richard,
>> > >>
>> > >> I guess that will work for me. However, since it
>> > >> was decided to remove an identical function,
>> > >> why weren't the calls to it adjusted to reflect it?
>> > >> If the call wasn't transformed that means it will
>> > >> be mapped at some later time. Is that mapping
>> > >> available to look at? Because using that would
>> > >> also be a potential solution (assuming call
>> > >> graph information exists for the deleted function.)
>> > >
>> > > I'm not sure how the transitional cgraph looks like
>> > > during WPA analysis (which is what we're talking about?),
>> > > but definitely the IL is unmodified in that state.
>> > >
>> > > Maybe Martin has an idea.
>> > >
>> >
>> > Exactly, the cgraph_edges is where the correct call information is
>> > stored until the inlining transformation phase calls
>> > cgraph_edge::redirect_call_stmt_to_callee is called on it - inlining is
>> > a special pass in this regard that performs this IPA-infrastructure
>> > function in addition to actual inlining.
>> >
>> > In cgraph means the callee itself but also information in
>> > e->callee->clone.param_adjustments which might be interesting for any
>> > struct-reorg-like optimizations (...and in future possibly in other
>> > transformation summaries).
>> >
>> > The late IPA passes are in very unfortunate spot here since they run
>> > before the real-IPA transformation phases but after unreachable node
>> > removals and after clone materializations and so can see some but not
>> > all of the changes performed by real IPA passes.  The reason for that is
>> > good cache locality when late IPA passes are either not run at all or
>> > only look at small portion of the compilation unit.  In such case IPA
>> > transformations of a function are followed by all the late passes
>> > working on the same function.
>> >
>> > Late IPA passes are unfortunately second class citizens and I would
>> > strongly recommend not to use them since they do not fit into our
>> > otherwise robust IPA framework very well.  We could probably provide a
>> > mechanism that would allow late IPA passes to run all normal IPA
>> > transformations on a function so they could clearly see what they are
>> > looking at, but extensive use would slow compilation down so its use
>> > would be frowned upon at the very least.
>> 
>> So IPA PTA does get_body () on the nodes it wants to analyze and I
>> thought that triggers any pending IPA transforms?
>
> Yes, it does (and get_untransormed_body does not)
>

Oh, sorry, I forgot that the function does this in conjunction to
streaming the function in.  So, we actually have the mechanism but it
has the described issues.

Martin

Re: gsi_remove on a call

[Martin Jambor]

On Tue, Oct 27 2020, Gary Oblock via Gcc wrote:
> I'm running into grief in verify_node in cgraph.c
> when I use gsi_remove on a call statement.
>
> Specifically it's a free statement which I've replaced
> with other free statements as part of my structure
> reorg optimizations. Note, in other working code
> I do this with malloc and it doesn't seem to be a problem.
>
> Where it happens it's trying to look at the call graph edges.
> Is there a way to remove the edge in question or mark it
> to be ignored?

Have you tried using cgraph_edge::set_call_stmt to update the edge?

> I see that line below about built in unreachable
> and wonder if I'm supposed to set the decl to that but I
> don't see others doing it so...

The comment you quoted explains why __builtin_unreachable is special.

Martin

>
> Here's the code in cgraph (e->call_stmt is the free in question:)
>
>  if (gimple_has_body_p (e->caller->decl)
>  && !e->caller->inlined_to
>  && !e->speculative
>  /* Optimized out calls are redirected to __builtin_unreachable.  */
>  && (e->count.nonzero_p ()
>  || ! e->callee->decl
>  || !fndecl_built_in_p (e->callee->decl, BUILT_IN_UNREACHABLE))
>  && count == ENTRY_BLOCK_PTR_FOR_FN(DECL_STRUCT_FUNCTION  (decl))->count
> && (!e->count.ipa_p ()
>  && e->count.differs_from_p (gimple_bb (e->call_stmt)->count)))
>{
>   :
>
> Thanks,
>
> Gary
>
>
>
>
>
>
> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is 
> for the sole use of the intended recipient(s) and contains information that 
> is confidential and proprietary to Ampere Computing or its subsidiaries. It 
> is to be used solely for the purpose of furthering the parties' business 
> relationship. Any unauthorized review, copying, or distribution of this email 
> (or any attachments thereto) is strictly prohibited. If you are not the 
> intended recipient, please contact the sender immediately and permanently 
> delete the original and any copies of this email and any attachments thereto.

Re: Need Guidance for GSOC 2021

[Martin Jambor]

Hello Abhay,

On Wed, Dec 16 2020, Abhay Singh via Gcc wrote:
> Hi Sir/Mam,
>
> My name is Abhay Singh, second year undergraduate student from Lovely
> Professional University, enrolled in Bachelors of Technology, Computer
> Science.  I am using GCC Compilers from the starting edge of mu
> engineering programme, and I experience a lot of updates, and I also
> want to be a part of your organisation through a project contribution.

> I have a great enthusiast regarding open source and contributing to
> the projects. And when I go through the introduction part of one of
> your projects from 2020, named as GNU Compiler Collection, it excites
> me a lot.  So I wanted to contribute to your projects so that I can
> add some of my knowledge as a contribution to your project.
>
> Please guide me for the further process.
>

I am very pleased to hear about your interest.  Although our GCC wiki
has not been updated for the 2021 yet (I will do it early in January)
but it is the correct place to start:
https://gcc.gnu.org/wiki/SummerOfCode

At the moment the most important section is "Before you apply" which
will has links to the first steps you should probably make to gain the
very initial insight into GCC and ability to build, examine and test it.

Afterwards, look at the list of selected projects.  At the moment I am
reasonably confident that project "Bypass assembler when generating LTO
object files," some extension of the static analysis pass and all
Fortran projects will still be on our list of ideas in 2021, try to find
the place in the compiler where you'd work, look around and start
questions on this list in order to write up your proposal.

Good luck,

Martin

Re: GSoC 2021 project help

[Martin Jambor]

Hi Adharsh,

I will be the GSoC organizer for GCC the next year (unless someone else
wants to be).

On Sun, Dec 20 2020, Adharsh Kamath via Gcc wrote:
> Hi everyone
> I came across the list of project ideas that were selected for GSoC 2020
> and I'm interested in contributing to the project regarding the 
> *Implementation
> of OMPD in GCC, libgomp, and GDB. *

> Is this project going to be considered for GSoC 2021 as well?

On one hand, I am very pleased that you are interested in a GCC GSoC
program, on the other, I am worried about the project you picked because
it is very difficult.  We had a student attempting it last year, which
unfortunately failed, and in the process it became painfully clear just
how tough it was for a newcomer.

Moreover, Google has shrunk the duration of GSoC this year, making it
even more difficult to attempt such a big endeavor, and so I was not
planning to keep it in the list of proposed projects for 2021.

Having said that, if you managed to bring about some real progress with
OMPD, it would have a big impact and would indeed be very welcome, so at
least I am not dead set against considering it.  But you'll have to
convince us you really understand what you are attempting.

Do you have some rudimentary knowledge of OpenMP?  Have you looked at
the OMPD part of the standard?  Do you feel you understand what its
goals are?

> I was able to build GCC from source, as specified in the *Before you apply*
> section.

This project would not deal so much with the compiler but mainly with
the run-time OpenMP library libgomp, in the libgomp subdirectory of the
GCC git repository.  At some point you'll have to familiarize yourself
with it, so it might be a good way to start.

You can compile some simple OpenMP program with options
-fopenmp -fdump-tree-optimized
and the generated dump file should show you what the compiler did to the
OpenMP directives and what are the entry points to the run-time library
(for the pragmas used in the program).

> How can I get started with this project? Can I contact the mentor who is
> mentioned in the above project's description regarding this?

I believe you can, in fact I have CCed him on this email already.
Jakub, what are your thoughts?  Can you think of some preliminary work
for Adharsh so that he can get a taste of what he is up to, and so that
we know whether he has a good chance of completing the project?  (And
IMHO completing really means writing something substantial and useful.
The entire OMPD is simply too large, I'm afraid).

Adharsh, I do not want to discourage you.  If you still think you can
succeed after looking into the problem, please do apply, I would love
someone to help with OMPD.  But at the same time I feel I have to
caution you that the project you have picked is a hard one.

Good luck,

Martin

Re: Google GSOC Idea

[Martin Jambor]

Hi,

On Sun, Dec 27 2020, Alper G. via Gcc wrote:
> Hello, I am waiting for your suggestions and evaluations about an idea that
> I am thinking about applying to this year's event of google gsoc. In short,
> I can say about myself that I am an engineering student and worked on
> compilers as well as several different fields. Nowadays, we see that
> scripting languages such as javascript / typescript are more than just a
> client-side language in the browser. In order to develop applications on
> desktop and mobile devices, there are alternatives such as electron that
> contain chromium and nodejs, have multi-disk-size requirements and cannot
> be packaged statically before runtime, such as react-native. In order to
> overcome such problems, it is necessary to create the ahead-of-time
> compilation, which we are familiar with such as c / c ++, according to this
> syntax and standards, and to call the graphics libraries and system calls
> directly from within js. Therefore, I want to create a subset of gcc that
> can be statically compiled and contains the ecmascript standards required
> to run common js frameworks native. What are your comments on this
> idea?

I'm afraid I don't understand it at all.  Making GCC "run common js
frameworks" makes very little sense to me.  Are you proposing some kind
of JavaScript Front-end (which is not a JIT)?

> What can we say about the acceptability for gsoc?

Well, unfortunately I can say only that I do not understand it.  If it
is the JavaScript Front-end, the project would too big for a GSoC, by
orders of magnitude, even if severely reduced in scope.

Martin

GCC GSoC 2021: Call for project ideas and mentors

[Martin Jambor]

Hello,

there have already been some inquiries from prospective students and so
I would like to start preparing for the next year of Google Summer of
Code now.  I'll be happy to volunteer to be the main Org Admin for GCC
again - so let me know if you think I shouldn't or that someone else
should, but otherwise I'll assume that I will.

First and foremost, I would like to ask all (moderately) seasoned GCC
contributors to consider mentoring a student this year and ideally also
come up with a project that they would like to lead.  I'm collecting
proposal on our wiki page https://gcc.gnu.org/wiki/SummerOfCode - feel
free to add yours to the top list there.  Or, if you are unsure, post
your offer and project idea as a reply here to the mailing list.


 The following si different this year(!): ==

Google has decided to cut the size of the projects by half, this year
the projects are supposed to take "175 hours over 10-week coding
period."  There will be only two evaluations.

While this offers much more flexibility to both mentors and students, I
am afraid It is not exactly good news for big and complex projects like
GCC because finding smaller projects is more difficult.  Also, students
will have to start their project prepared to begin working straight away
as they cannot be expected to use any of these hours to learn their way
around.  The coding period has also been shortened but is still
relatively long (June 7 - August 16).

See [1] for more on changes in the program this year.




Eventually, each listed project idea should have a) a project
title/description b) more detailed description of the project (2-5
sentences) c) expected outcomes d) skills required/preferred and e)
possible mentors [2].

Project ideas that come without an offer to also mentor them are always
fun to discuss, by all means feel free to reply to this email with yours
and I will attempt to find a mentor, but please be aware that we can
only use the suggestion it if we actually find one.

Everybody in the GCC community is invited to go over
https://gcc.gnu.org/wiki/SummerOfCode and remove any outdated or
otherwise bad project suggestions and help improve viable ones which are
not yet viable.  I would especially want to ask libstdc++ people to do
so, and GFortran folk to check that their suggestions from last year are
still good.

Finally, please continue helping (prospective) students figure stuff out
about GCC like you always do.  So far I think all of them enjoyed
working with us, even if many sometimes struggled with GCC's complexity.

More information together with GSoC 2021 time line is available at
https://summerofcode.withgoogle.com

Thank you, let's hope we attract some young talent again this year.

Martin


[1] 
https://opensource.googleblog.com/2020/10/google-summer-of-code-2021-is-bringing.html
[2] https://google.github.io/gsocguides/mentor/defining-a-project-ideas-list

Re: Google GSOC Idea (JS/TS FE)

[Martin Jambor]

Hi,

On Tue, Jan 05 2021, Alper G. wrote:
> We have a pre-implementation trial, although it is not very extensive.
> We intend to develop this during gsoc and take it forward in a planned
> manner.

I know very little about JavaScript / TypeScript and so am not in a good
position to evaluate it, but this sounds interesting.  Is this
"pre-implementation" effort of yours available somewhere so that we can
have a look?

A GSoC project is supposed to be a work of one individual, which this
year should take about 175 hours.  Some specific steps towards an
implementation could probably fit the bill even if the whole FE would
obviously be way too big.  Different members of your group would need to
work on different things (as a part of their GSoC).

We would probably also like to see at least some hazy path to eventually
finish and upstream the effort, so knowing the plans beyond this years
GSoC would also be helpful.

Last but not least, we cannot really predict how many slots we'll get
from Google and how many students apply, so we cannot promise to accept
all projects we like.

However, I am intrigued.

Martin


>
> David Edelsohn , 5 Oca 2021 Sal, 22:45 tarihinde şunu
> yazdı:
>
>> Are you trying to propose a JavaScript / TypeScript front-end and
>> associated runtime for GCC?
>>
>> I don't believe that anyone would object to that.  It probably is much
>> too ambitious for a GSoC project.  You could propose a subset as a
>> GSoC project.
>>
>> It's unclear if you already have a preliminary implementation and want
>> to incrementally continue it, like a Hackathon, as part of GSoC.
>>
>> Thanks, David
>>
>> On Tue, Jan 5, 2021 at 2:34 PM Alper G. via Gcc  wrote:
>> >
>> > I wanted to talk about a gcc front-end with the syntax js / ts, which is
>> > ahead-of-time. The standard library will also contain basic functions
>> that
>> > will enable the use of several basic frameworks that can be used in
>> > standard output. It was an e-mail that I could not fully explain because
>> I
>> > tried to correct the text a few times, I'm sorry :) We are a group of
>> > several people who have already worked on compiler design and we thought
>> of
>> > applying this idea under the name gcc.
>> >
>> > Martin Jambor , 4 Oca 2021 Pzt, 17:37 tarihinde şunu
>> yazdı:
>> >
>> > > Hi,
>> > >
>> > > On Sun, Dec 27 2020, Alper G. via Gcc wrote:
>> > > > Hello, I am waiting for your suggestions and evaluations about an
>> idea
>> > > that
>> > > > I am thinking about applying to this year's event of google gsoc. In
>> > > short,
>> > > > I can say about myself that I am an engineering student and worked on
>> > > > compilers as well as several different fields. Nowadays, we see that
>> > > > scripting languages such as javascript / typescript are more than
>> just a
>> > > > client-side language in the browser. In order to develop
>> applications on
>> > > > desktop and mobile devices, there are alternatives such as electron
>> that
>> > > > contain chromium and nodejs, have multi-disk-size requirements and
>> cannot
>> > > > be packaged statically before runtime, such as react-native. In
>> order to
>> > > > overcome such problems, it is necessary to create the ahead-of-time
>> > > > compilation, which we are familiar with such as c / c ++, according
>> to
>> > > this
>> > > > syntax and standards, and to call the graphics libraries and system
>> calls
>> > > > directly from within js. Therefore, I want to create a subset of gcc
>> that
>> > > > can be statically compiled and contains the ecmascript standards
>> required
>> > > > to run common js frameworks native. What are your comments on this
>> > > > idea?
>> > >
>> > > I'm afraid I don't understand it at all.  Making GCC "run common js
>> > > frameworks" makes very little sense to me.  Are you proposing some kind
>> > > of JavaScript Front-end (which is not a JIT)?
>> > >
>> > > > What can we say about the acceptability for gsoc?
>> > >
>> > > Well, unfortunately I can say only that I do not understand it.  If it
>> > > is the JavaScript Front-end, the project would too big for a GSoC, by
>> > > orders of magnitude, even if severely reduced in scope.
>> > >
>> > > Martin
>> > >
>>

Re: GSoC

[Martin Jambor]

Hello,

On Sun, Feb 07 2021, Ravi Kumar via Gcc wrote:
> Hello Sir,
> I am Ravi Kumar. I am currently a 2nd year undergraduate(B.Tech) student. I 
> want to participate in GSoC 2021 and want to work under the mentorship of 
> GCC.
> WHY ME?
> Because:
> 1.I have a proper knowledge and experience in C and C++ Language.
> 2. I have learnt to use git and GitHub.
> 3. I also have a theoretical knowledge of compilers and compiler organization.
> 4. I am ready to give 4-5 hours daily to the project.
> 5.I am familiar with GCC source code.
>
> Since I am a new contributor and I have a little knowledge regarding this so 
> I am facing lot of difficulties. But I am a good learner and I want to 
> explore more in contribution and project completion under a mentor. Since I 
> have the required skills for the project ideas that you have provided, I 
> would love to work for it. 
> Here is the project that I am opting:
> Extend the static analysis pass
>

we are delighted that you decided to apply for GSoC and that you have
chosen GCC as the organization.  If you think you need any help
selecting a particular static analyzer project or improving your
application proposal, feel free to email the mailing list again.

Thanks,

Martin

Re: GSoC age limit

[Martin Jambor]

Hi,

On Wed, Feb 10 2021, oilab kowaski via Gcc wrote:
> Hi! I am very interested in parsers and compilers. I would be very happy to
> participating in the development of GNU Rust compiler by applying to the
> Google Summer of Code. But I am 17 years old and I do not satisfy the
> requirements of the GSoC. What would you suggest me to do?

I am afraid that means that there is no way for you to be paid this
year, at least not by Google.

That does not mean you cannot pursue your interest in parsers and
compilers with us though.  Look at the gcc-rust repo (currently on
github), contact the authors and see if you can contribute to the effort
informally.  I am sure they will appreciate any help.

I am also sure that there will be work to be done on the Rust-gcc front
end for years to come, so if you become a contributor this year, you
will be in a prime position to become our GSoC student next year.

I understand that the financial renumeration is an important incentive
to participate in GSoC but I am afraid we cannot offer any more help,
Google will not change their rules for us.

Martin

Re: Extending static analysis GSoC

[Martin Jambor]

Hi,

I am CCing the GCC mailing list again because you are much more likely
to get advice from the people on the list than just from me.

On Wed, Feb 10 2021, Ravi Kumar wrote:
> First of all thanks for the reply. I have few questions:
> 1.How can I improve my proposal?

First and foremost, we need you to demonstrate that you have the skills
necessary to work on the project and that you have a somewhat good idea
what and how you want to accomplish.

> 2.How much I have to contribute before the application period( minimum no.
> of pull request merged)?

We do not have any such hard requirement but candidates who can
demonstrate that they can make some (even very basic) thing work are
much more likely to be accepted.  On the other hand, in the past we have
accepted students who only got something working in the summer.

> 3.Should I have some extra skill other than project requirements?

The unusual requirement for extending the static analyzer in GCC - in
the sense that it is not needed for our other project - is understanding
some basic theory of static analysis in general.

> 4.How can I know in depth about the static analyzer project(C++ support).

I suppose the main source is the source code of the static analysis pass
and various blog posts and presentations that David Malcolm, its author,
has published over the last year or so.  They should not be hard to
Google for.

Please note that you also should choose what extension of the static
analysis pass you'd like to work on.  The page
https://gcc.gnu.org/wiki/SummerOfCode lists four suggestions, you are of
course welcome to come up with your own.

>
> Till now I grabbed very few knowledge of the project. I am trying hard to
> get something out of it but I find it very difficult. I need someone's help
> who can make me understand the project completely.

I completely understand it is very hard, but there is no alternative to
sitting down, reading the source code and playing and experimenting with
it.  The analyzer lives in the gcc/analyzer subdirectory in the GCC
sources and the entry point, as far as I understand it (i.e. not very
much) is run_checkers() in gcc/analyzer/engine.cc.

You are very welcome to ask questions - even beginner's questions
but specific questions - on the mailing list and/or on our IRC channel.
Everyone is busy of course, but we try to answer such questions as much
as possible.

Good luck,

Martin

Re: Performing inter-procedural dataflow analysis

[Martin Jambor]

Hi,

On Thu, Feb 18 2021, Shuai Wang via Gcc wrote:
> Hello,
>
> I am doing interprocedural dataflow analysis and countered the following
> issue. Suppose I have an GIMPLE IR code as follows, which is after the
> "simdclone" pass while before my own SIMPLE IPA pass:
>
>
> foo (int a, int b)
> {
>   int c;
>   int d;
>   int D.2425;
>   int _5;
>
>:
> *  c_4 = a_2(D) + b_3(D);  *
> *  _5 = c_4;*
>   
>
> As you can see, while propagating certain dataflow facts among local
> variables are smooth (e.g., from c_4 --> c_4 --> _5), I can hardly somehow
> "link" function parameter "a" (or "b") with its first local usage "a_2(D)"
> or "b_3(D)".

are you perhaps looking for function ssa_default_def (defined in tree-dfa.c)?

>
> So my question is, when traversing the GIMPLE statements and encounter SSA
> variables like "a_2(D)" or "b_3(D)", how do I know they originate from
> parameter "a" and "b"?

You check that SSA_NAME_IS_DEFAULT_DEF is true (and that their
SSA_NAME_VAR is the PARM_DECL you are after).

Martin

Re: Request for contribution to your project

[Martin Jambor]

Dear Divyanshu,

On Wed, Mar 10 2021, divyanshu jamloki via Gcc wrote:
> sir,
> I have  plan about your site i have sent it but no one reply yet , i have
> been contribution to your project  since  Mon, 25 Jan 2021 at 19:26  now i
> would like to send you my gsoc proposal pdf where i have explained my ideas
> related to run time error and road map to solve it please help me as i
> don't know where to send my  proposal pdf,

I suggest that you to send your ideas to this mailing list in a simple
email, if at all possible.

If you insist on presenting them to us before application in a PDF, I am
afraid you'll have to upload it somewhere and send us a link to this
mailing list(services such as Google Drive or Dropbox provide that
service, I believe).

The final project proposal then must be in a pdf form, and you would
upload it to directly to the GSoC web site when you apply.

Good luck,

Martin

Re: GSoC

[Martin Jambor]

Hello Isitha,

On Fri, Mar 19 2021, Isitha Subasinghe via Gcc wrote:
> To whom it may concern,
>
> I am a student interested in participating in GSoC this year. After having
> a look at some of the available PL projects, gccrs caught my attention. I
> love Rust and have an interest in exploring more about type theory and
> automatic garbage collection.
>
> My background is that I am a Masters's student at the University of
> Melbourne in Australia, I have undertaken a graduate-level compiler class
> where we implemented a stack-based compiler in Haskell.
>
> I am quite interested in working on the static analysis project but wanted
> feedback to iron out and address my proposal before I submit it.
>
> I am quite confident in my C/C++ skills but somewhat unsure about the level
> of knowledge of static analysis that I would need. Unfortunately, I am yet
> to take any classes in this particular subfield but I am absolutely happy
> to learn on my own time and have purchased the book Principles of Program
> Analysis to assist with this matter.
>
> Also, I did want to notify you that I would be available for less than the
> entire coding duration of GSoC due to university commitments.
> Unfortunately, my exams overlap with GSoC, and it is hard to compromise on
> University studies since I am hoping to do a PhD in PL after the completion
> of my master's. I would be absolutely happy to make up this time at the end
> of the year where I have a 3-month break.

Google Summer of code coding period is 10 week long and takes place
between June 7 and August 23.  Students are expected to work total 175
hours over these 10 weeks, so on average 18 hours a week, but it can be
more during some weeks and fewer (even zero) during others, as long as
the hours add up.  There is however one evaluation taking place between
July 12-16, so some part of work must be done and evaluated before then.

Unfortunately, the GSoC rules require that all evaluated work is
submitted before the deadline on August 16, no work done later can be
considered.

I hope the flexibility to distribute work will allow you to participate
but unfortunately we are not in a position to make an exception for
anybody, we have to adhere to GSoC rules too.

Martin

Re: GSoC 2021

[Martin Jambor]

Hello,

On Sat, Mar 20 2021, Mahmoud Shawky via Gcc wrote:
> Hello there
> I have chosen the project that i want to develop , and i don't know what is
> the next step ,

we are delighted that you found contributing to GCC interesting.  The
next step usually is to discuss your project here on the mailing list.
Often the community can help students come up with better scoped and
focused proposals.  So I would suggest you briefly introduce your
intended project here on the mailing list.

> is it okay to communicate with the project mentor in
> linkedin or how can i communicate with him .

That depends on the particular mentor, I cannot speak on behalf of all
of them.  But I think most would prefer a discussion over email, and
ideally on the gcc@gcc.gnu.org mailing list.

Good luck,

Martin

Re: GSOC

[Martin Jambor]

Hello,

On Sat, Mar 20 2021, Manish Sahani via Gcc wrote:
> Hey,
>
> I'm a  student at Delhi Technological University, and interested in
> contributing to the *Make cp-demangle non-recursive* and *Fortran improved
> argument compile-time checking*.

we are very happy to hear you are interested in two topics, especially
since they are quite different.  It is going to be difficult, but unless
you want to submit two GCC GSoC proposals, you will have to choose one.

> Before reaching out here In the past week
> I have gone through most of the introduction wiki on building and testing,
> some wikis on the structure of gcc, have played around with configure
> script (explored various options), build the code multiple times, and ran
> test cases.

Great, thanks for taking the effort before reaching out to us.  What
next now depends on your particular choice of project.  The C++
demangler is part of libiberty (subdirectory), is fairly self-contained
and you can just go and read the source and (assuming the stated goal is
fairly clear to you), start planning on how you would go about carrying
out the task.  Ask here if you have any questions.

I cannot really help you with the Fortran project idea too, much, I
would suggest you request help and guidance on the fort...@gcc.gnu.org
mailing list (but thanks for announcing your intention here anyway, I am
not subscribed to the fortran list myself).

>
> My previous intern at adobe included some work to analyze the MSVC manglers
> and so I'm very interested in the cp-demangle project and I also want to
> work on the improvement of compile-time argument. So, If somebody can
> redirect me to the starting point that would be very helpful.
>
> Also, while compiling without bootstrapping. I ran into an error (screenshot
> of the error

I cannot access that URL any more and as Jonathan pointed out, there is
really no need to send a screenshot when cut and pasted error would do.
If the error is not an internal compiler error, requesting help on
avoiding it indeed is more appropriate on the gcc-h...@gcc.gnu.org
mailing list.

Apologies for referring you to two different mailing lists, but you see,
the world of GCC big!

Good luck, please do not hesitate to ask for any help if you struggle
with any particular problem.

Martin

Re: Remove RMS from the GCC Steering Committee

[Martin Jambor]

Hi,

On Fri, Mar 26 2021, Nathan Sidwell wrote:
>
> Dear members of the GCC Steering Committee (SC),  I ask you to remove Richard 
> Stallman (RMS) from the SC, or, should you chose not to do so, make a clear 
> statement as to why he remains.
>

I wholeheartedly agree with Nathan.

In a few weeks I will have to ask selected GSoC students to sign away
their copyright to FSF and it will be very hard for me to make that
request - and doubly so if any of the students is female.  It is true
that RMS has not directly interacted with us for a long time and so
removing him from the committee may amount only to a gesture, but it
would be a powerful and very helpful gesture in this regard.  And IMHO
not just in this regard.

Thank you,

Martin

Re: Remove RMS from the GCC Steering Committee

[Martin Jambor]

Dear Giacomo,

On Tue, Mar 30 2021, Giacomo Tesio wrote:
> Hi Nathan and hello everybody,
>
> On Fri, 26 Mar 2021 16:02:30 -0400 Nathan Sidwell wrote:
>
>> The USA is not the world and the SC is not the US government.  For
>> those in the USA, the (inapplicable) first amendment provides 5
>> rights, including showing an unwelcome guest the door. [...]
>>
>> If we fail to do so, it will continue to be harder and harder to
>> attract new talent to GCC development.
>
> I do not know if I qualify to speak here because I'm Italian and
> I ported GCC 9.2.0 to Jehanne (a Plan 9 fork, see
> http://jehanne.io/2021/01/06/gcc_on_jehanne.html), but due to the
> pandemic I wasn't able to align it with the new developments and
> contribute the port upstream. Also, I have no idea if you would be
> interested in running GCC on a Plan 9 fork and thus accept my
> contribution.
>
>
> Yet, after a careful read of this thread I realized that I might
> be considered the kind of "new talent" Nathan is talking about.
>
> So here is my perspective on this topic, "in the hope it helps but
> without any warranty". :-D
>
>
> I do not share many of Stallman's opinions (we are VERY different), but
> when I write free software and contribute to a free software community,
> what I want is long term assurances about one and only one topic: that
> the software will stay free as in freedom, as a common good for the
> whole humanity.
>
> As of today, GPLv3 is the legal tool that best suit this goal.
> I don't think it's perfect in this regards, but that's another story.

Nobody suggested that GCC would be relicensed and certainly not to a
non-free license.  If you decide to contribute your port upstream, it
will be safe with us, regardless of who will or will not be on the
steering committee or running the FSF.  Just read the copyright
assignment text that you have singed or would need to sign to contribute
and look for FSF obligations as the license holder there.

> As an Italian I'm having a hard time trying to follow your reasoning
> about Stallman being a problem to attract new talents.

I do not believe that being European or Italian has anything to do with
it. I am European, I understand and agree with everything Nathan wrote
and apparently I am not the only one.

The ability to see and stand up to consistent wrongdoing is universal
and every human of every nationality posses it.  Unfortunately, all
people are also able to close their eyes and ears and ignore mistreatment
when they are not the victims and when their friend or their favorite
public figure is the perpetrator.  There is absolutely nothing American
or European about either.

Sincerely,

Martin

Re: Remove RMS from the GCC Steering Committee

[Martin Jambor]

Dear Giacomo,

On Tue, Mar 30 2021, Giacomo Tesio wrote:
> On Tue, 30 Mar 2021 18:50:52 +0200 Martin Jambor wrote:
>
>> Unfortunately, all people are also able to close their eyes and ears
>> and ignore mistreatment when they are not the victims and when their
>> friend or their favorite public figure is the perpetrator.
>
> Martin, what you imply here, is an insult I do not deserve.

I am sorry.  I wanted to underline that the questions discussed here are
not cultural or somehow defined geographically.

> I do NOT ignore injustice or mistreatments whenever I see them and I
> fight them strongly through nonviolence. ALWAYS. 

Always?  OK, then you are clearly a much better person than I am.

> But in Italy we have a legal principle called "Presumption of innocence".

Nevertheless, I am convinced that all the many accusations are clear,
consistent and most of them are beyond any doubt (a lot of it is on
RMS's own blog).  They easily clear the bar for legitimate reasons why
he should not be an official representative of GCC.

I do not understand people which keep doubting the "evidence" or
describe it as hearsay, the only explanation I can think of is that they
simply do not wish to not accept the facts.  If you are certain that
this is not your case (no "proof" or explanation necessary) then please
accept my apologies.

Martin

Re: GSoC 2021 (incremental LTO)

[Martin Jambor]

Hi Dmitry,

we are delighted you found contributing to GCC interesting.

On Mon, Mar 29 2021, Dmitry Torilov via Gcc wrote:
> Greetings,
>
> I saw a task on your site for GSoC called < Optimization (LTO) linking>>. I am very interested in it, and I would
> like to know if it is possible to do it this summer. I have experience
> in C/C++ development as well as experience in related fields. I know how
> to compile GCC, and I have a top-level understanding of how LTO works.
> Unfortunately, I've never written compilers yet, but I've had experience
> in developing a LISP interpreter, and I've also watched a lot of
> conference talks about compilers. I am sending a link to my CV. I hope
> that you will be interested in it. Can I ask you to tell me about the
> further screening process for GSoC?

there is no formal screening process and GCC does not impose any
additional formal requirements on top of those of the GSoC program,
except that we want students to announce their intention to apply so
that we can help them write a good proposal and in the process learn
about the project they apply for.

I have CCed Honza who would be the primary mentor for this project.
>From what I know about the project, I can suggest (apart from the
suggestions at https://gcc.gnu.org/wiki/SummerOfCode) the following.
Compile some small but non-trivial program with options -flto
-save-temps and -v (in addition to one you would normally use).  The
*ltrans* files the compiler will produce are the partitions, which are
currently all always compiled, even when a partition from an earlier
build would do.

The project should probably start with the driver (gcc/gcc.c) or perhaps
lto-wrapper (gcc/lto-wrapper.c) stashing the *ltrans[0-9]*.o caching the
files somewhere and then using the information about what is cached to
prevent unnecessary compilation of a partition which is identical to one
that has been compiled at some point in the past.  So at this point I
would suggest to study how exactly the driver, the lto-plugin
(lto-plugin/lto-plugin.c), lto-wrapper and lto1 (gcc/lto/*.c) interact
and where it would make sense to cache the partitions and retrieve them
from the cache.

Please do not hesitate to ask here on the mailing list if you struggle
with reading the code, if you want to find out if your understanding is
correct or need any help with any specific aspect of the project
proposal.

Good luck,

Martin

Re: Question about reading LTO function summaries

[Martin Jambor]

Hi,

On Fri, Mar 26 2021, Erick Ochoa via Gcc wrote:
> I already have some experience developing SIMPLE_IPA_PASSes, but I am
> looking to understand IPA_PASSes better. I have made a hello world ipa
> pass that stores "hello world $FUNCTION_NAME" in the function
> summaries; however, I am having trouble reading this information back.
> Can someone help me understand how to use these interfaces correctly?
>
> At the moment, it **seems** to be writing information correctly.
> (I.e., it doesn't segfault when attempting to write data.) However, in
> my read summary function (ipa_hello_world_read_summary (void)) the
> function `lto_get_summary_section_data (file_data,
> LTO_section_ipa_hello_world, &len);` always returns NULL and
> `file_data_vec` is of size 1. This means that at run time, there is
> only one call to `lto_get_summary_section_data` and it returns NULL.

I looked at the code you posted and compared it with streaming in
ipa-sra.c and did not spot any difference that could result in this
behavior.

I guess you have checked that the functions are called from proper
hooks?  (I.e. from write_summary and read_summary or
write_optimization_summary and read_optimization_summary, depending on
what you are trying to do, and not some mixture of these combinations?)

You can try and send the whole patch (hopefully a hello world pass would
not be too large) and I can have a look.

Martin

Re: Question about reading LTO function summaries

[Martin Jambor]

Hi,

On Tue, Apr 06 2021, Erick Ochoa wrote:
>> On Fri, Mar 26 2021, Erick Ochoa via Gcc wrote:
>> > I already have some experience developing SIMPLE_IPA_PASSes, but I am
>> > looking to understand IPA_PASSes better. I have made a hello world ipa
>> > pass that stores "hello world $FUNCTION_NAME" in the function
>> > summaries; however, I am having trouble reading this information back.
>> > Can someone help me understand how to use these interfaces correctly?
>> >
>> > At the moment, it **seems** to be writing information correctly.
>> > (I.e., it doesn't segfault when attempting to write data.) However, in
>> > my read summary function (ipa_hello_world_read_summary (void)) the
>> > function `lto_get_summary_section_data (file_data,
>> > LTO_section_ipa_hello_world, &len);` always returns NULL and
>> > `file_data_vec` is of size 1. This means that at run time, there is
>> > only one call to `lto_get_summary_section_data` and it returns NULL.
>>
>> I looked at the code you posted and compared it with streaming in
>> ipa-sra.c and did not spot any difference that could result in this
>> behavior.
>>
>> You can try and send the whole patch (hopefully a hello world pass would
>> not be too large) and I can have a look.
>
> thanks for taking some time to help me. I think I accidentally deleted
> the original hello world pass, but I have re-made it and I still have
> the same problem. I copy paste the patch at the bottom.

First, please either send patches as attachments or use an email client
which does not corrupt the patch format.  What you sent had some spaces
removed and long lines clipped, which meant I had to manually fix it to
try it.  Doable for patch this small but if it was even a tiny bit
bigger, I would have to ask you to resend it.

Second, your problem seems to be that you are missing an entry in
lto_section_name in lto-section-in.c that would correspond to the one
you added to lto_section_type.

You also forgot to copy calls to lto_free_section_data and
lto_data_in_delete which means that subsequent attempts to stream stuff
in them then ICE.

The streaming API, especially the code setting it all up, is fairly
horrible, which is a known issue.  New IPA passes are however added only
seldom, which means the incentive to clean it up is fairly low,
unfortunately.

Martin

Re: removing toxic emailers

[Martin Jambor]

Hi Nathan,

On Wed, Apr 14 2021, Nathan Sidwell wrote:
> Do we have a policy about removing list subscribers that send abusive or 
> other toxic emails?  do we have a code of conduct?  Searching the wiki 
> or website finds nothing.  The mission statement mentions nothing.

I think that (most?) people have already figured out that messages from
unfamiliar senders on certain topics have to be ignored.  It is much
easier than any moderation, which would be ugly work (someone would have
to read the often horrible stuff).

I think that you only "associate" with trolls if you feed them.  I have
recently made that mistake on this list once and will not repeat it.

Martin


P.S.: For what it is worth, I would love us to disassociate from FSF as
much as possible for reasons that I swear have nothing to do with
politics of US or any other country.

Re: C++ coding style inconsistencies

[Martin Jambor]

Hi,

On Thu, Jun 25, 2015 at 07:28:45PM +0100, Richard Sandiford wrote:
> Sorry in advance for inviting a bikeshed discussion
>, but while making
> the hashing changes that I just committed, I noticed that the C++ification
> has been done in a variety of different styles.  I ended up having to follow
> the "do what the surrounding code does" principle that some code bases have,
> but to me that's always seemed like an admission of failure.  One of the
> strengths of the GCC code base was always that it was written in a very
> consistent style.  Regardless of what you think of that style (I personally
> like it, but I know others don't at all), it was always easy to work on
> a new area of the compiler without having to learn how the surrounding code
> preferred to format things.  It would be a shame if we lost that in the
> rush to make everything "more C++".

Agreed.

> 
> The three main inconsistencies I saw were:
> 
> (1) Should inline member functions be implemented inside the class or outside
> the class?  If inside, should they be formatted like this:

https://gcc.gnu.org/codingconventions.html has a big section on C++
(note that there is also a similar document on wiki which IIRC often
contradicts this one).  Unfortunately, in this case, it gives two
sightly contradicting guidelines.  On one hand, section
https://gcc.gnu.org/codingconventions.html#Cxx_Inlining says

  "Constructors and destructors, even those with empty bodies, are
  often much larger than programmers expect. Prefer non-inline
  versions unless you have evidence that the inline version is smaller
  or has a significant performance impact. "

on the other, https://gcc.gnu.org/codingconventions.html#Member_Form
explicitely states:

  "Define all members outside the class definition. That is, there are
  no function bodies or member initializers inside the class
  definition. "

Since the former seems to be specific to constructors and destructors,
it probably overrides the latter.  So in my book, you can have inline
constructors and destructors if they are extremely small, such as
empty, but nothing else should be inline.

> 
>void
>foo (args...)
>{
>  ...;
>}
> 
> or like this:
> 
>void
>foo (args...)
>  {
>...;
>  }
> 
> (both have been used).
> 
> The coding standard is pretty clear about this one:
> 
> Define all members outside the class definition. That is, there
> are no function bodies or member initializers inside the class
> definition.
> 
> But in-class definitions have become very common.  Do we want
> to revisit this?  Or do we just need more awareness of what the
> rule is supposed to be?
> 
> [Personally I like the rule.  The danger with in-class definitions
> is that it becomes very hard to see the interface at a glance.
> It obviously makes things more verbose though.]
> 
> (2) Is there supposed to be a space before a template parameter list?
> I.e. is it:
> 

Examples in that document have them but I could not quickly find any
rules enforcing this.  I personally do not like them, but will comply
to whichever case prevails.

>foo
> 
> or:
> 
>foo 
> 
> ?  Both are widely used.
> 
> The current coding conventions don't say explicitly, but all the
> examples use the second style.  It's also more in keeping with
> convention for function parameters.  On the other hand, it could
> be argued that the space in:
> 
>foo ::thing
> 
> makes the binding confusing and looks silly compared to:
> 
>foo::thing
> 
> But there again, the second one might look like two unrelated
> blobs at first glance.
> 
> (3) Do we allow non-const references to be passed and returned by
> non-operator functions?  Some review comments have pushed back
> on that, but some uses have crept in.

I think it was just me pushing back and I am still a bit unhappy about
them, but other people voicing opinions though they were perfectly
fine.

I believe the main reason for using them is that if you pass a pointer
to a vector to a function, the function then has to access the
elements with (*vec_arg)[i] which is super-ugly but there you go.  But
perhaps this is fixable with some template operator overload?  (Of
course, if someone then had an array of vectors, accessing the
individual elements would be pain).  Anyway, with a reference you are
fine.

> 
> [IMO non-const references are too easy to misread as normal
> parameters.]

Yes, IMHO too.

Thanks,

Martin

Re: C++ coding style inconsistencies

[Martin Jambor]

Hi,

On Thu, Jun 25, 2015 at 04:59:51PM -0400, David Malcolm wrote:
> On Thu, 2015-06-25 at 19:28 +0100, Richard Sandiford wrote:
> > Sorry in advance for inviting a bikeshed discussion, but while making
> > the hashing changes that I just committed, I noticed that the C++ification
> > has been done in a variety of different styles.  I ended up having to follow
> > the "do what the surrounding code does" principle that some code bases have,
> > but to me that's always seemed like an admission of failure.  One of the
> > strengths of the GCC code base was always that it was written in a very
> > consistent style.  Regardless of what you think of that style (I personally
> > like it, but I know others don't at all), it was always easy to work on
> > a new area of the compiler without having to learn how the surrounding code
> > preferred to format things.  It would be a shame if we lost that in the
> > rush to make everything "more C++".
> 
> [...snip...]
> 
> If we're bike-shedding (sorry, I'm waiting for a bootstrap), do we have
> a coding standard around the layout of member initialization in
> constructors?

Yes, https://gcc.gnu.org/codingconventions.html#Member_Form

> 
> i.e. should it be:
> 
> foo::foo (int x, int y) :
>   m_x (x),
>   m_y (y)
> {
> }
> 
> vs
> 
> foo::foo (int x, int y)
>   : m_x (x),
> m_y (y)
> {
> }

according to the document, the semicolon should be on the first column
if all initializers do not fit on one line with the definition.  Emacs
gnu-style indentation does not do that and produces your second case
above, which, according to some simple grepping, is also greatly
prevails in the codebase now.  So perhaps we should change the rule?

> 
> (how much indentation?)
> 
> https://gcc.gnu.org/wiki/CppConventions

I'd be wary of citing and using this document, IIRC it sometimes
contradicts the official one and was meant as a basis for discussion
when we were discussing whether to switch to gcc in the first place.

Martin

> has an example suggesting the
> latter, but puts both on the same line and then puts the empty body on
> one line, and doesn't have the space between the name and the
> open-paren, like this:
> 
> foo::foo(int x, int y)
>   : m_x(x), m_y(y)
> { }
> 
> though actually, it's inline in the class decl, akin to:
> 
> class foo {
>   foo(int x, int y)
> : m_x(x), m_y(y)
>   { }
> 
> 
> vs the one-liner for this simple case:
> 
> foo::foo (int x, int y) : m_x (x), m_y (y) {}
> 
> 
> fwiw GNU indent turns this into:
> 
> foo::foo (int x, int y):
> m_x (x),
> m_y (y)
> {
> }
> 
> which I think is ugly (I suspect this is a case of "indent" not handling
> C++).
> 
> fwiw I don't have a preference between either of the top two styles, and
> Emacs seems to cope with both.  I like having the option of doing it all
> on one line where it's simple enough.
> 
> Dave
> 

Can shrink-wrapping ever move prologue past an ASM statement?

[Martin Jambor]

Hi,

I've been asked to look into the item one of
http://permalink.gmane.org/gmane.linux.kernel/1990397 and found out
that at least shrink-wrapping happily moves prologue past an asm
statement which can be bad if the asm statement contains a call
instruction.

Am I right concluding that this is a bug?  Looking into the manual and
at requires_stack_frame_p() in shrink-wrap.c, I do not see any obvious
way of marking the asm statement as requiring the stack frame (but I
will not mind being proven wrong).  Do we want to create one, such as
only disallowing moving prologue past volatile asm statements?  Any
other ideas?

Thanks,

Martin


This is an x86_64 testcase, compare output of gcc -O2 -S and
gcc -S -O2 -fno-shrink-wrap


enum machine_mode
{
  FAKE_0,
  FAKE_1,
  FAKE_2,
  FAKE_3,
  FAKE_4,
  FAKE_5,
  NUM_MACHINE_MODES,
};

typedef int *rtx;
typedef long unsigned int size_t;
extern unsigned char mode_size[NUM_MACHINE_MODES];

extern rtx c_readstr (const char *, enum machine_mode);
extern rtx convert_to_mode (enum machine_mode, rtx, int);
extern rtx expand_mult (enum machine_mode, rtx, rtx, rtx, int);
extern rtx force_reg (enum machine_mode, rtx);
extern unsigned char mode_size_inline (enum machine_mode);
extern void *memset (void *__s, int __c, size_t __n);

rtx
builtin_memset_gen_str (void *data, long offset __attribute__ ((__unused__)),
enum machine_mode mode)
{
  rtx target, coeff;
  size_t size;
  char *p;
  asm volatile ("#" : : :);

  size = ((unsigned short) (__builtin_constant_p (mode)
? mode_size_inline (mode) : mode_size[mode]));
  if (size == 1)
return (rtx) data;

  p = ((char *) __builtin_alloca(sizeof (char) * (size)));
  memset (p, 1, size);
  coeff = c_readstr (p, mode);

  target = convert_to_mode (mode, (rtx) data, 1);
  target = expand_mult (mode, target, coeff, (rtx) 0, 1);
  return force_reg (mode, target);
}

Re: Can shrink-wrapping ever move prologue past an ASM statement?

[Martin Jambor]

Hi,

On Tue, Jul 07, 2015 at 01:44:15PM -0500, Segher Boessenkool wrote:
> On Tue, Jul 07, 2015 at 07:53:49PM +0200, Martin Jambor wrote:
> > I've been asked to look into the item one of
> > http://permalink.gmane.org/gmane.linux.kernel/1990397 and found out
> > that at least shrink-wrapping happily moves prologue past an asm
> > statement which can be bad if the asm statement contains a call
> > instruction.
> > 
> > Am I right concluding that this is a bug?  Looking into the manual and
> > at requires_stack_frame_p() in shrink-wrap.c, I do not see any obvious
> > way of marking the asm statement as requiring the stack frame (but I
> > will not mind being proven wrong).  Do we want to create one, such as
> > only disallowing moving prologue past volatile asm statements?  Any
> > other ideas?
> 
> For architectures like PowerPC where all calls clobber some register,
> you can write e.g.
> 
>   asm("bl func" : : : "lr");
> 
> and all is well (better than saving/restoring LR manually, too).
> 
> 
> For other archs, e.g. x86-64, you can do
> 
>   register void *sp asm("%sp");
>   asm volatile("call func" : "+r"(sp));
> 

Thanks, this is very clever and apparently what is going to be used:

https://lkml.org/lkml/2015/7/7/1071

> and the result seems to be optimal as well.
> 
> 
> Some special clobber, maybe "stack" (like "memory", which won't work)
> could be nicer?  What should the *exact* semantics of that be?
> 

Well, I only have had a quick look at where things "go wrong" and have
not spent much time thinking about all the things that coud break by
moving an asm statement before stack frame setup so I don't know.  I'm
CCing Josh who has been bitten by this, perhaps he can share some
insight.

Nevertheless, given that this was discovered only now, it might not be
a common problem but of course it may become one if we improve
shrink-wrapping further.  Using a register variable seems like a
workaround, so having a "stack" input operand is probably worth some
further thought.

Martin

Re: Can shrink-wrapping ever move prologue past an ASM statement?

[Martin Jambor]

On Tue, Jul 07, 2015 at 02:25:34PM -0600, Jeff Law wrote:
> On 07/07/2015 11:53 AM, Martin Jambor wrote:
> >Hi,
> >
> >I've been asked to look into the item one of
> >http://permalink.gmane.org/gmane.linux.kernel/1990397 and found out
> >that at least shrink-wrapping happily moves prologue past an asm
> >statement which can be bad if the asm statement contains a call
> >instruction.
> >
> >Am I right concluding that this is a bug?  Looking into the manual and
> >at requires_stack_frame_p() in shrink-wrap.c, I do not see any obvious
> >way of marking the asm statement as requiring the stack frame (but I
> >will not mind being proven wrong).  Do we want to create one, such as
> >only disallowing moving prologue past volatile asm statements?  Any
> >other ideas?
> Shouldn't this be driven by dataflow?

Sure, the correct way of handling this internally would be to put the
stack pointer register into the use set of the asm statement.  Please
disregard my mention of volatile asms, if that is what you are
referring to, that indeed does not seem wise.  But see the other part
of this thread about a possible "stack" input operand.

Thanks,

Martin

Cauldron Accelerator BoF call for agenda proposals

[Martin Jambor]

Hello,

because Thomas Schwinge unfortunately cannot attend the Cauldron this
year, I have volunteered to take care of organizing an Accelerator BoF
at the event (at the moment conveniently scheduled for Sunday 10am).

This email is not only an invitation to participate but also a call
for agenda items.  Although it will certainly be possible to propose a
topic for discussion on the spot, giving me a heads-up beforehand
might help me to organize them better.  And this call is also meant to
give a chance to propose a topic to those who will not be coming to
Prague.

Therefore, if you already know what we should discuss at the BoF, let
me know.  If think you need a little bit of inspiration, you can look
at an old agenda proposal at
http://thread.gmane.org/gmane.comp.gcc.devel/131560

My proposed topics will be about reconciling "offloading via LTO" and
"HSA offloading" and about issues regarding OpenMP constructs
expansion for GPGPUs.

I'm looking forward to meeting many of you in Prague,

Martin

Re: Moving to git

[Martin Jambor]

Hi,

On Thu, Aug 20, 2015 at 03:31:52PM -0400, David Malcolm wrote:
> On Thu, 2015-08-20 at 13:57 -0400, Jason Merrill wrote:
> > I hear that at Cauldron people were generally supportive of switching 
> > over to git as the primary GCC repository, and talked about me being 
> > involved in that transition.  Does anyone have more information about 
> > this discussion?
> > 
> > Our current workflow translates over to a git master pretty easily: 
> > basically, in the current git-svn workflow, replace git svn rebase and 
> > git svn dcommit with git pull --rebase and git push.
> > 
> > It should be pretty straightforward to use the existing git mirror as 
> > the master repository; the main adjustment I'd want to make is rewriting 
> > the various subdirectory branches to be properly represented in git. 
> > This is straightforward, but we'll want to stop SVN commits to 
> > subdirectory branches shortly before the changeover.
> > 
> > It would be good to have a more explicit policy on branch/tag creation, 
> > rebasing, and deletion in the git world where branches are lighter 
> > weight and so more transient.
> 
> If we're going to migrate to git (I hope so), can we also please
> *slightly* revise the policy on commit messages, to add meaningful
> titles to commits?
> 

I second this, looking at history with git shortlog or in tig
(something I do every now and then) would then be much more
convenient.

And yes, we can actually start doing that now and people using git
mirror would benefit immediately.

Thanks for bringing this up,

Martin

Re: Moving to git

[Martin Jambor]

Hi,

On Thu, Aug 20, 2015 at 05:32:26PM -0500, Segher Boessenkool wrote:
> On Thu, Aug 20, 2015 at 03:31:52PM -0400, David Malcolm wrote:
> > If we're going to migrate to git (I hope so), can we also please
> > *slightly* revise the policy on commit messages, to add meaningful
> > titles to commits?
> > 
> > Currently:
> > https://www.gnu.org/software/gcc/svnwrite.html#checkin says:
> > 
> > "The log message for that checkin should be the complete ChangeLog entry
> > for the change."
> > 
> > and the subsection "Commit the changes to the central repository" below
> > https://www.gnu.org/software/gcc/svnwrite.html#example
> > has an example showing this.
> > 
> > 
> > In the git world, the first line of the commit message has special
> > meaning, being treated as the "title" of the commit.
> 
> It would be nice if we could use a real commit message, not just a short
> title line; for example, people who prepare their patches in git already
> have that, and use it with format-patch as you say.  And many bonus points
> if we don't have to repeat the changelog in the commit message (it's in
> the commit already, the bugzilla hook could just pull it from out there).
> 

I suppose it would be too much to try to enforce patch email as the
commit message.  Patches get changed during discussions in the mailing
lists and it would be then quite unclear how to make these combined
emails and commit messages useful for both purposes and yet not
awkward and superfluous.

But let me re-iterate that I do wholeheartedly support the idea of a
patch title (which should be the same as the subject of the
corresponding mail to the list).

> Or we could have another discussion about if we want to have changelogs
> at all...
> 

Much less important but: I like them.  They force everybody to go
through their patches before submitting them, and giving them a chance
to spot simple bugs and spurious whitespace changes.
 In fact, I think that auto-generating changelogs
should be banned ;-)  Also, when gcc sources leave
any kind of version control system, changelogs are a useful way of
identifying what they might be.

In any way, that is a separate issue,

Martin

Re: IPA/cgraph: propagating node frequencies to offloaded functions

[Martin Jambor]

Hi,

On Fri, Feb 12, 2016 at 05:40:58PM +0100, Thomas Schwinge wrote:
> Hi!
> 
> As I'm touching areas of GCC here, that I have no noteworthy experience
> with (IPA optimizations, cgraph), I'm asking for your help.  Thanks!
> 
> This is primarily to implement a better "avoid offloading" policy for
> un-parallelized OpenACC kernels constructs with nvptx offloading,
> ,
> but I imagine that potentially also any non-nvptx offloading can benefit
> from this, by better parameterization of GCC's optimization passes.
> 
> For this consideration, simplified, "offloading" means that:
> 
> int main()
> {
>   [block 1]
>   #pragma omp target
> {
>   [block 2]
> }
>   [block 3]
> }
> 
> ... is re-written into something like:
> 
> void main_offloaded()
> {
>   [block 2]
> }
> 
> int main()
> {
>   [block 1]
>   GOMP_target(&main_offloaded);
>   [block 3]
> }
> 
> ..., and the code of main_offloaded is then not run on the CPU but is in
> GOMP_target launched to execute on an offloading device (not actually
> important for this consideration).
> 
> GOMP_target, described by gcc/omp-builtins.def:BUILT_IN_GOMP_TARGET, is
> implemented externally to the compiler (in libgomp), but we "control" its
> implementation, and so we're free to have the compiler make certain
> assumptions about its behavior.
> 
> (I guess) due to it being passed to the intermediary GOMP_target call,
> the address of main_offloaded "escapes".  But, as we know how/what for
> GOMP_target is using it, we should be able to (teach the compiler to)
> handle it like a "static" function -- I hope.
> 
> For reference, I'm assuming the example above should look/work a bit like
> the following example:
> 
> static __attribute__((noinline)) int fun_s(int x)
> {
>   return x + 1;
> }
> 
> int main()
> {
>   return fun_s(10);
> }
> 
> ..., where I do observe that, for example, main's
> NODE_FREQUENCY_EXECUTED_ONCE is propagated to fun_s.  (For main
> initialized in gcc/predict.c:compute_function_frequency, and the
> propagation to fun_s then happens in
> gcc/ipa-profile.c:ipa_propagate_frequency.)  See
> test.c.067i.profile_estimate: "Node foo_s promoted to executed once".
> However, this node frequency propagation does not currently happen for
> main_offloaded.  Looking into this for a bit, I think I have identified
> two issues.
> 
> IPA/cgraph does not consider main_offloaded to be "local" (as in struct
> cgraph_local_info; handled/set in
> gcc/ipa-visibility.c:cgraph_node::local_p), so does not even attempt to
> do such optimizations.  (But, per my comment above, we should actually be
> able to treat main_offloaded at least similar to a "static" function.)

for cgraph/IPA purposes, a cgraph_node is local if we have under
control all its potential call-sites.  So in general case, an address
escaped function cannot be local, regardless of its static-ness.

> 
> If I hack gcc/ipa-visibility.c:cgraph_node::local_p to forcefully mark
> main_offloaded as "local", the node frequency propagation still doesn't
> work correctly, because no callers (cgraph_edge) have been registered for
> the respective cgraph_node, so gcc/ipa-profile.c:ipa_propagate_frequency
> doesn't have the data available that it needs in order to set the
> ipa_propagate_frequency_data, which later will be used to set the node
> frequency.

If you only care about ipa-profile propagation, then I would suggest
hacking just ipa-profile.c so that whenever it sees a cgraph_edge
going to gomp_target (and perhaps also gomp_parallel, gomp_task etc.),
it knows it has to propagate something to the corresponding parameter
of that function (the parameter value can easily be extracted from
ipa-prop/ipa-cp jump functions because it is always going to be
constant).  That way, you do not need to make any changes to symtab
core.

If, on the other hand, you want all of IPA, such as IPA-CP (and
associated inlining heuristics), work seamlessly across gomp_ calls,
you probably want to invent some new kind of special call graph edge
for such invocations.  This would would be a bigger task because a
large portion of code dealing with cgraph_edge would need to be made
aware of the new kind.  I am not sure it would be worth it.

> 
> As it already has some support for gomp_parallel and gomp_task (which I
> understand to have similar semantics in that regard, comparing to
> gomp_target), maybe extending gcc/cgraphbuild.c will help with the latter
> issue?

The special support for gomp_parallel and gomp_task in cgraphbuild.c
only makes sure we extract references correctly from the special omp
statements so that we don't remove them as unreachable (it seems that
gomp_target should be handled there as well, really).  I don' think
that can help frequency propagation in any way.  Are the frequencies
to gomp_parall

Re: omp-low.c split

[Martin Jambor]

Hi,

On Mon, Nov 14, 2016 at 09:45:49AM -0800, Cesar Philippidis wrote:
> What's the plan to split omp-low.c into multiple files? Right now,
> omp-low.c contains code to lower and expand OpenMP and OpenACC. At least
> for the OpenACC transforms, we made an effort to keep the changes in
> omp-low.c target-independent. Is goal to break omp-low.c into separate
> lowering, expansion and target/offloading-specific files?

at this point my plan is to split the file into:
- a file with lowering-specific stuff,
- a file with expansion-specific stuff,
- a file with HSA gridification stuff,
- a file with other stuff (various helpers, things like
  make_gimple_omp_edges called from other passes), and
- header files for all of the above.

A file with non-gridification target/offloading-specific stuff might
also be a good idea, I will keep it in mind.  In any way, I do expect
discussion after I post the first patch and will incorporate feedback.

> 
> Is there a timeline for it? The major pending OpenACC changes involve
> the tile clause and routines. Most of the routine changes happen in the
> FEs, we do preform some error handling in omp-low.c.

The timeline is basically this stage3, the earlier the better, but not
before all patches submitted against omp-low.c in stage1 are in (or
retracted, or dealt with somehow in general).

Martin

Re: [RFC] noipa attribute (was Re: How to avoid constant propagation into functions?)

[Martin Jambor]

Hi,

On Fri, Dec 16, 2016 at 02:31:48PM +0100, Jakub Jelinek wrote:
> Suggestions how to test that IPA-SRA and IPA-PTA aren't happening?
> Anything else we need to cover?
> 

I would use some test from gcc/testsuite/gcc.dg/ipa/ipa-sra-*.c, add
the attribute and negate the scan-dump test.

Martin

Re: IPA: Devirtualization versus placement new

[Martin Jambor]

Hi,


On Fri, Apr 25, 2014 at 11:22:22AM +0100, Andrew Haley wrote:
> Summary: Devirtualization uses type information to determine if a
> virtual method is reachable from a call site.  If type information
> indicates that it is not, devirt marks the site as unreachable.  I
> think this is wrong, and it breaks some programs.  At least, it should
> not do this if the user specifies -fno-strict-aliasing.
> 
> Consider this class:
> 
> class Container {
>   void *buffer[5];
> public:
>   EmbeddedObject *obj() { return (EmbeddedObject*)buffer; }
>   Container() { new (buffer) EmbeddedObject(); }
> };
> 
> Placement new is used to embed an object in a buffer inside another
> object.  Its address can be retrieved.  This usage of placement new is
> common, and it even appears as the canonical use of placement new in
> the in the C++ FAQ at
> http://www.parashift.com/c++-faq/placement-new.html.  (I am aware that
> this is not strictly legal.  For one thing, the memory at buffer may
> not be suitably aligned.  Please bear with me.)
> 
> The embedded object is an instance of:
> 
> class EmbeddedObject {
> public:
>   virtual int val() { return 2; }
> };
> 
> And it is called like this:
> 
> extern Container o;
> int main() {
> 
>   cout << o.obj()->val() << endl;
> }
> 
> The devirtualization pass looks into the call to val() and the type of
> o, decides that there is no type inside o that is compatible with
> EmbeddedObject, and inserts a call to __builtin_unreachanble().  As a
> result, instead of printing 2, the program does nothing.
> 
> I'm not sure what this transformation is supposed to achieve.  It does
> nothing for strictly compliant code

It can be and often is useful.  Very often such calls are in a branch
that is guarded by a type check and performs a down-cast.
Devirtualization can figure out the branch is unreachable when it
knows that the call in it would be illegal.  (And yes, placement new
has been considered, see PR 45734, especially comment #4.)

In this case, however, I believe that ipa-devirt should not mark its
result as final if the offset with outer_type leads to a
non-artificial field, certainly not if such a field is a POD,
regardless of any compiler option.  I believe you should open a PR for
this.

Martin


> and it silently breaks non-
> compliant code like this.  GCC users would be better off if it were
> not done.  At least an error message could be printed instead of silently
> failing to generate code.
> 
> IMO, this transformation should not be performed when
> -fno-strict-aliasing is used.
> 
> `-fstrict-aliasing'
>  Allow the compiler to assume the strictest aliasing rules
>  applicable to the language being compiled.  For C (and C++), this
>  activates optimizations based on the type of expressions.
> 
> I have appended a suggested patch to this message.
> 
> Andrew.
> 
> 
> Index: gcc/ipa-devirt.c
> ===
> --- gcc/ipa-devirt.c  (revision 209656)
> +++ gcc/ipa-devirt.c  (working copy)
> @@ -1362,8 +1362,9 @@
> 
> /* Only type inconsistent programs can have otr_type that is
>not part of outer type.  */
> -   if (!contains_type_p (TREE_TYPE (base),
> - context->offset + offset2, *otr_type))
> +   if (flag_strict_aliasing
> +   && !contains_type_p (TREE_TYPE (base),
> +context->offset + offset2, 
> *otr_type))
>   {
> /* Use OTR_TOKEN = INT_MAX as a marker of probably type 
> inconsistent
>code sequences; we arrange the calls to be 
> builtin_unreachable
> @@ -1441,7 +1442,8 @@
> gcc_assert (!POINTER_TYPE_P (context->outer_type));
> /* Only type inconsistent programs can have otr_type that is
>not part of outer type.  */
> -   if (!contains_type_p (context->outer_type, context->offset,
> +   if (flag_strict_aliasing
> +   && !contains_type_p (context->outer_type, context->offset,
>   *otr_type))
>   {
> /* Use OTR_TOKEN = INT_MAX as a marker of probably type 
> inconsistent
> 

Re: What would it take to always force indirect inlining?

[Martin Jambor]

Hi,

On Thu, Jul 17, 2014 at 12:26:43PM -0500, Daniel Santos wrote:
> I've recently discovered that a function marked always_inline but
> called by pointer won't always be inlined. What would it take to
> assure that this either always happens or generates an error?

Generally, that is the case.  Direct non-inlined calls of
always_inline functions thus indicate that the destination become
known only after inlining in the optimization pipeline.  Without more
context, especially without knowing how exactly you call my_quicksort
function, it is impossible to say why.  If you cannot povide us with
the source code (I would be interested if you can), you can try
compiling with -fdump-tree-all -fdump-ipa-all-details and go through
the generated dump files to find out at what point it becomes known.
ipa-cp and ipa-inline dumps also contain information about what
inlining context of your function.

Martin

> Unfortunately, it's breaking (well, failing to properly optimize)
> some code where I need the optimizer to see what's in the inline
> function (which is a constant at compile time) so it can optimize it
> into a REP MOVSx loop on x86 or similar on other archs. I kinda
> designed the function so that it would work that way, but it ends up
> making a function call and then can't optimize any further.
> 
> 
> 
> static __always_inline void my_copy(const struct qsort_def *def,
> void *dest, const void *src) {
> const struct size_type __aligned(ALIGN_SIZE) *s = src;
> struct size_type __aligned(ALIGN_SIZE) *d = dest;
> //fprintf(stderr, "copy: d=%p, s=%p\n", d, s);
> *d = *s;
> 0020  mov(%rdx),%rax
> 0023  mov%rax,(%rsi)
> 0026  retq
> 
> ...
> 
> static __always_inline __flatten void
> _quicksort_ror(const struct qsort_def *def, void *left, void *right,
> void *tmp, size_t tmp_size) {
> const size_t size = def->size;
> char *r = right;
> char *l = left;
> const ssize_t dist = (r - l) / (ssize_t)def->size; /* left
> to right offset */
> 03c1  sub %rbx,%rdx
> 03c4  test %rdx,%rdx
> 03c7  lea 0x7(%rdx),%r12
> 03cb  cmovns %rdx,%r12
> 
> if (size <= tmp_size) {
> ssize_t i;
> char *left_minus_one = l - size;
> 
> def->copy(def, tmp, r);
> 03cf  mov %r13,%rdx
> static __always_inline __flatten void
> _quicksort_ror(const struct qsort_def *def, void *left, void *right,
> void *tmp, size_t tmp_size) {
> const size_t size = def->size;
> char *r = right;
> char *l = left;
> const ssize_t dist = (r - l) / (ssize_t)def->size; /* left
> to right offset */
> 03d2  sar $0x3,%r12
> 
> if (size <= tmp_size) {
> ssize_t i;
> char *left_minus_one = l - size;
> 
> def->copy(def, tmp, r);
> 03d6  callq 0020
> 
> /* rep movs-friendly loop */
> for (i = dist; i; --i) {
> 03db  test %r12,%r12
> 03de  je 041d
> 
> 03e0  lea 0x0(,%r12,8),%rdx
> 03e8  lea (%rbx,%rdx,1),%r14
> 03ec  add %rdx,%r15
> 03ef  xchg   %ax,%ax
> 03f1  data32 data32 data32
> data32 data32 nopw %cs:0x0(%rax,%rax,1)
> def->copy(def, &l[i * size],
> &left_minus_one[i * size]);
> 0400  mov %r15,%rdx
> 0403  mov %r14,%rsi
> 0406  mov $0x0,%edi
> 407: R_X86_64_32.rodata+0x20
> 040b  callq 0020
> 
> 0410  sub $0x8,%r14
> 0414  sub $0x8,%r15
> ssize_t i;
> char *left_minus_one = l - size;
> 
> def->copy(def, tmp, r);
> /* rep movs-friendly loop */
> for (i = dist; i; --i) {
> 0418  dec%r12
> 041b  jne 0400
> 
> def->copy(def, &l[i * size],
> &left_minus_one[i * size]);
> }
> 
> def->copy(def, left, tmp);
> 041d  mov -0x450(%rbp),%rdx
> 0424  mov %rbx,%rsi
> 0427  mov $0x0,%edi
> 428: R_X86_64_32.rodata+0x20
> 042c  callq 0020
> 
> 0431  jmpq 0378
> 
> 
> 
> 
> If the optimizer had the body of my_copy above, it should be able to
> use two pointers (one for l and another for left_minus_one) and a
> single index as long as size is either 1, 2, 4 or 8.  All and all, I
> need to refine my strategy, but if I can solve this little part, it
> will help greatly.
> 
> Thanks,
> Daniel

Re: What would it take to always force indirect inlining?

[Martin Jambor]

Hi,

On Fri, Jul 18, 2014 at 03:31:23PM -0500, Daniel Santos wrote:
> 
> On 07/18/2014 04:55 AM, Martin Jambor wrote:
> >Hi,
> >
> >On Thu, Jul 17, 2014 at 12:26:43PM -0500, Daniel Santos wrote:
> >>I've recently discovered that a function marked always_inline but
> >>called by pointer won't always be inlined. What would it take to
> >>assure that this either always happens or generates an error?
> >Generally, that is the case.  Direct non-inlined calls of
> >always_inline functions thus indicate that the destination become
> >known only after inlining in the optimization pipeline.  Without more
> >context, especially without knowing how exactly you call my_quicksort
> >function, it is impossible to say why.  If you cannot povide us with
> >the source code (I would be interested if you can), you can try
> >compiling with -fdump-tree-all -fdump-ipa-all-details and go through
> >the generated dump files to find out at what point it becomes known.
> >ipa-cp and ipa-inline dumps also contain information about what
> >inlining context of your function.
> >
> >Martin
> 
> Hello. I've given it a new home:
> https://github.com/daniel-santos/cmeta. I'm using cmake for the
> first time and I'm not sure that I like it. For now, you have to
> *manually* specify your CFLAGS. This is what I'm using:
> 
> CFLAGS="-std=gnu11 -march=native -g3 -pipe -Wall -Wextra
> -Wcast-align -Wno-unused-parameter -O2 -DNDEBUG"
> 
> My -march=native is a Phenom 9850 and I did this on gcc 4.8.3. I
> have 4.9.0 installed, but I haven't examined that one just yet, but
> I will shortly. Also please note that this is currently not the
> worlds prettiest code! (sorry, I guess I'm vain)
> 

I have had a look and it indeed seems to reveal that we miss an
important opportunity for indirect inlining and will work to fix it,
hopefully in the next major version of gcc.  Meanwhile, if you want to
continue your experiments with current releases, you can replace your
ror function pointer with a macro (or its expansion, this is just an
illustration) like in the patch below and I believe it will just work,
at least on 4.9 (I have tried myself with trunk only).

If you want to continue discuss this path more, please take it off the
gcc development mailing list (you can also ask at gcc-help but I am
not subscribed there).

Thank you for the testcase,

Martin

Ada bootstrap failure

[Martin Jambor]

Hi Arnaud and Robert,

I have not been able to bootstrap pristine gcc trunk this morning
(rev. 213544) with Ada enabled.  I have set up a bisecting script
which has pointed to revision 213541 as the first failing one (if you
use git mirror, it is git commit
54d549ff02e4549ff12977a2c3e71e163cda066a).  The commit message is:

Author: charlet 
Date:   Mon Aug 4 08:12:01 2014 +

2014-08-04  Robert Dewar  

* exp_ch4.adb: Minor reformatting.
* exp_attr.adb: Minor reformatting.

unfortunately, I have not been able to quickly locate the
corresponding email in the gcc-patches mailing list so I'm reporting
the issue this way.

All the reported errors look like the following two:

exp_ch4.adb:6502:07: "Check_Float_Op_Overflow" is undefined (more references 
follow)
exp_ch4.adb:6852:19: (style) misplaced "then"

Thanks,

Martin

Re: cgraph_node::verify - quite strong condition that was met by IPA-ICF

[Martin Jambor]

Hi,

On Fri, Sep 26, 2014 at 10:34:16AM +0200, Richard Biener wrote:
>

...

> 
> Btw, isn't cgraph edge redirection a "transform" step?  Thus why is
> it performed at WPA time at all?  Shouldn't it be performed at LTRANS
> time the same time we materialize clones and inline?
> 

No, not really, changing the callee of an edge is how at WPA stage we
record the decision to redirect the given call to a different target
(an ipa-cp clone or now a semantic equivalent).  The gimple statement
change (which is the real "transform" here I suppose) is done at
LTRANS but is verified like it was an ipa-cp redirection and fails.

Martin

Re: Comparing tree types

[Martin Jambor]

Hi,

On Mon, Nov 03, 2014 at 03:12:10AM +0530, Vini Kanvar wrote:
> I am trying to compare the tree declarations of the lhs and the rhs of
> the assignment statement in the following program.
> 
> struct node {
> struct node * next;
> };
> struct node ** obj1, obj2;
> obj1 = &obj2.next;// lhs is obj1, rhs is obj2.next

RHS should be &obj2.next, note the &.  I suppose that is why you are
getting a non-pointer type when inspecting TREE_TYPE (obj2.next_tree),
because according to the dumps below, you are missing an ADDR_EXPR
somewhere.

Please note that when comparing types, you should probably use a
designated function to do that.  If you work at GIMPLE level, such
functions are types_compatible_p or useless_type_conversion_p, I do
not remember now what they are at GENERIC stage.

> 
> ---
> Let us call the following tree declaration of the lhs as "obj1_tree".
> -
>   type  type 
> unsigned SI
> size 
> unit size 
> align 32 symtab 0 alias set -1 canonical type 0x405cc000
> pointer_to_this >
> unsigned SI
> size 
> unit size 
> align 32 symtab 0 alias set -1 canonical type 0x405c5ea0>
> used unsigned SI file structstruct2.c line 8 col 17
> size  bitsizetype> constant 32>
> unit size  sizetype> constant 4>
> align 32 context  chain  0x405cc1e0 obj2>>
> 
> -
> Let us call the following tree declaration of the rhs as
> "obj2.next_tree"
> -
>   type  type  size 
> unit size 
> align 32 symtab 0 alias set -1 canonical type 0x405c5f60
> fields  context  0x40526804 D.2319>
> pointer_to_this  chain  0x40526870 node>>
> unsigned SI
> size 
> unit size 
> align 32 symtab 0 alias set -1 canonical type 0x405cc000
> pointer_to_this >
> used unsigned nonlocal SI file structstruct2.c line 3 col 16
> size  bitsizetype> constant 32>
> unit size  sizetype> constant 4>
> align 32 offset_align 128
> offset  sizetype> constant 0>
> bit offset  bitsizetype> constant 0> context  chain
> >
> -
> 
> Please note from the above tree declarations that 
> Type1 = TREE_TYPE (TREE_TYPE (obj1_tree)) = 0x405c5f00
> Type2 = TREE_TYPE (obj2.next_tree) = 0x405cc000
> Type3 = TYPE_POINTER_TO (TREE_TYPE (TREE_TYPE (obj2.next_tree))) =
> 0x405c5f00
> 
> I was expecting Type1 and Type2 to be equal because obj1=&obj2.next.
> However, in this case, we see that Type1 and Type3 are equal. Please
> explain this.
> 
> Also, what is the meaning of "pointer_to_this" in the tree declarations?

I have not double checked but I suppose that is a simple mechanism of
caching so that we do not re-create the same type multiple times.

HTH

Martin

Re: Legal paperwork for GCC contributions

[Martin Jambor]

On Sun, Nov 23, 2014 at 06:48:53PM -0500, Lawrence Velázquez wrote:
> Hi,
> 
> I recently contributed some fixes against GCC trunk, gcc-4_9-branch, and
> gcc-4_8-branch for which I need the requisite legal paperwork.
> 
> However, I'd like to backport these particular fixes to the MacPorts
> Project's ports of Apple GCC 4.2 and LLVM-GCC 4.2, which are licensed
> under "version 2, or (at your option) any later version" of the GPL. We
> would like the software provided by these ports to remain
> GPLv2-licensed.
> 
> Given this, what would be the best way for me to handle copyright?

If you are the only author of the stuff you want to backport, I
believe you do not need to ask any permission from anyone.  Donating
your own work to a FSF project does not prevent you from contributing
it to a different project, even under a different license (IIUC, for
example the go front-end works this way too).  Of course, you must not
include anybody else's substantial piece in the backport.

Martin

Building an x86_64-linux-gnux32 (x32) gcc wiki page

[Martin Jambor]

Hi,

I have spent quite some time trying to build an x32 gcc to debug a PR
this week before I finally found the configure switch that made
everything work.  In order to share this possibly valuable knowledge,
I have created a wiki mini-page detailing how I managed to get it
finally working:

https://gcc.gnu.org/wiki/SettingUpX32GCC

I've linked it from the "Tutorials, HOWTOs" section of the
GettingStarted page because I did not find a better place.  Of course,
feel free to correct any mistakes I might have made.

Martin

Re: gcc wiki project

[Martin Jambor]

Hi,

On Mon, Mar 23, 2015 at 06:14:30PM -0500, David Kunsman wrote:
> Hello, I was just reading through the current projects wiki page and I
> noticed how out of date pretty much all of them are.  So I was
> planning on doing "spring cleaning" by going down the list tracking
> down what has been and what needs to be down and updating all the
> wikis.  Do you think this is something that is worthwhile to work on?

Yes, I think that even just moving hopelessly outdated stuff to some
"Archive" section, looking at what is left and then perhaps
re-organizing the sections on the main page (and perhaps a few similar
ones) would be great, if you have the time and energy to do it.

I do not know how much history is kept in the wiki when moving pages
around, so you might want to announce your big re-organization
intentions here before actually doing them.

Thanks,

Martin

Re: gcc wiki project

[Martin Jambor]

On Tue, Mar 24, 2015 at 12:20:46PM +, Jonathan Wakely wrote:
> > On Mon, Mar 23, 2015 at 06:14:30PM -0500, David Kunsman wrote:
> >> Hello, I was just reading through the current projects wiki page and I
> >> noticed how out of date pretty much all of them are.  So I was
> >> planning on doing "spring cleaning" by going down the list tracking
> >> down what has been and what needs to be down and updating all the
> >> wikis.  Do you think this is something that is worthwhile to work on?
> 
> Yes, I think that would be very useful.
> 
> On 24 March 2015 at 12:16, Martin Jambor wrote:
> > Yes, I think that even just moving hopelessly outdated stuff to some
> > "Archive" section,
> 
> I don't see any need to move pages (that would break old links).

You're right, by section I meant the page sections where links to
outdated contents are.  I do not know why I thought for a moment that
changing the URL would happen too.

> Just add a header to old pages saying they are outdated, and stop
> linking to them from other pages that imply they are current.  There
> could be a single ArchivedProjects page, or just sub-section of
> another page, that links to the old projects, but no need to move the
> old project pages themselves.

This is exactly what I actually had in mind.

Martin

Do we have any plans to un-flatten our header files?

[Martin Jambor]

Hi,

because I really dislike the hassle our (almost) flattened header
files cause quite often, I have made a very simple experiment to find
out how the header files really depend on each other.  Some results,
together with a dozen of short paragraphs of relevant text are here:

http://labs.suse.cz/mjambor/150417-headers_in_gcc/headers_in_gcc.html

Short summary: I wrote a script removing an include at a time and
parsing errors and recording such discovered "dependencies."  The page
has text-file reports showing what needs to be included before what,
in which files and because of which error messages.  I have also
plotted a few graphs from these "dependencies."  The pictures look
interesting, I am not sure if they are in any way useful, but have
a look and judge for yourself. 

Regardless of whether or not this experiment had any value.  Do we
plan to do un-flattening of header files in the course of the next
release or two?  The pain the flat header files is real and enduring
it for much longer or indefinitely seems unhealthy to me.

Thanks,

Martin

Re: About GSOC.

[Martin Jambor]

Hi Joseph,

this seems related to your proposal GSoC proposal in the beginning
of this year.  Do you have any comments about Tejas's idea?  Do you
think this would be a good (part of) a GSoC project next year?

Thanks a lot,

Martin


On Sat, Oct 13 2018, Tejas Joshi wrote:
> Hello.
> I reached asking about GCC GSoC project about adding and
> folding functions
> like roundeven. I could not apply for the idea this year but
> interested in the peoject and
> really hoping it would be carry forwarded. Since I've been studying
> source code and about the project, I think working on this from now
> would give me some heads up and hands on with the source code.
>
> I did study .
> It does tell that roundeven rounds its argument to nearest integral
> ties to even (least significant bit 0) returning integral value
> provided that the resulting value is exact.
> So, for the start, I'd be implementing this functionality for roundeven.
> As ita said in earlier mails that, similar functions like
> real_ceil are implemented
> in real.c and are used in fold-const-call.c.
> Roundeven might be implemented in similar way. Is it built-in
> (internal) function means not to be exposed to end-user?
> Studying some functions like real_ceil, there are call checks
> (flag_errno_math) so I believe similar would be needed for roundeven.
>
> In real.c where real_ceil is implemented, there are function calls
> (and implementations) like do_fix_trunc which also then call functions
> like decimal_do_dix_trunc (maybe the main functionality of
> do_fix_trunc?, other are just checks, like NaN or qNaN). I did not
> understand these functions really and what do they do. Also I did not
> understand the structure of REAL_VALUE_TYPE (r->cl and etc?)
>
> Also when does the real.c and fold-const-call.c comes in picture in
> the flow of GCC (Is it for GIMPLE level instruction selection (gimple
> stmnt to corresponding rtl instruction))?
> Thanks.
>
> Regards,
> -Tejas

Re: Parallelize the compilation using Threads

[Martin Jambor]

Hi Giuliano,

On Thu, Nov 15 2018, Richard Biener wrote:
> You may want to search the mailing list archives since we had a
> student application (later revoked) for the task with some discussion.

Specifically, the whole thread beginning with
https://gcc.gnu.org/ml/gcc/2018-03/msg00179.html

Martin

Re: [GSOC] variations in testsuite results

[Martin Jambor]

Hi Siddhartha,

On Tue, Nov 27 2018, Siddhartha Sen wrote:
> I am Siddhartha Sen,currently pursuing my B.Tech degree in Information
> Science and Engineering,2nd year. I have taken a keen interest in your
> projects and have some ideas of my own as well. I am really interested in
> working with you in G-SOC 2019.

We are delighted.

> I am proficient in C and C++ and am eager
> to work on brushing my skills in whichever field required. I have already
> checked out the GCC trunk source-code and am being able to build GCC from
> it.I have run the testsuite and saved the results.

Great, those are all the essential first steps, it seems like you are
ready to work on your first patch.

> However, upon building
> it and saving it again, the results don't match. I apologise for my lack of
> knowledge but any help on your part would be great.

How did you compare the test results and which tests behaved
differently?  How did you configure GCC?  Was it on an x86_64?

Unfortunately, this sometimes happens.  As far as I can tell, the libgo
testsuite is very flaky and I basically ignore its results.  In the
past, I believe that also some guality tests sometimes passed and
sometimes did not, but I have not heard such reports recently.  These
tests however also depend on the GDB (version) you have installed on
your system.

Martin

Re: LTO Test Case Help

[Martin Jambor]

Hi,

On Wed, Dec 05 2018, Michael Ploujnikov wrote:
> Hi,
>
> I'm trying to write a testcase to reproduce duplicate clone symbols
> such as in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88297 I
> started with a testcase that is known to have constprop clones and
> split it into two object files:

so as we discussed on IRC, the testcase as you posted it to the mailing
list re-defined functions in a way that would not link, with or without
LTO.

When I fixed that, I had to make the following changes in order to
trigger IPA-CP cloning:  1. I had to put the calls in main into a loop,
otherwise everything is cold and we would not clone.  2. I had to make
different foos and bars actually semantically different, otherwise
IPA-ICF unified them, as it should.

The result reproduces the bug.  The two files are below.

Martin


 1.c 

volatile int g;

void __attribute__ ((noipa))
use (int v)
{
  g = v;
}

static int __attribute__ ((noinline))
foo (int arg)
{
  return 7 * arg;
}

static int __attribute__ ((noinline))
bar (int arg)
{
  return arg * arg;
}

extern int __attribute__ ((noinline))
entry2 (void);

int  __attribute__ ((noipa))
get_opaque_number (void)
{
  return 1;
}

int main (void)
{
  int i;
  for (i = 0; i < get_opaque_number (); i++)
{
  use (bar (3));
  use (bar (4));
  use (foo (5));
  use (foo (6));

  entry2 ();
}
  return 0;
}

 2.c 

extern void __attribute__ ((noipa))
use (int v);


static int __attribute__ ((noinline))
foo (int arg)
{
  return 8 * arg;
}

static int __attribute__ ((noinline))
bar (int arg)
{
  return arg * arg + 3;
}

int __attribute__ ((noinline))
entry2 (void)
{
  use (bar (3));
  use (bar (4));
  use (foo (5));
  use (foo (6));
  return 0;
}

Re: [GSOC] variations in testsuite results

[Martin Jambor]

Hello Siddhartha,

first and foremost, I'd like to apologize for replying so late.  I have
accidently marked your messages as only needing attention when the new
GSoC year is about to start.

On Sat, Dec 01 2018, Siddhartha Sen wrote:
> Hi Martin,
>
> Firstly,I use an x86_64(Ubuntu 18.04) since you asked,although I am not
> sure whether that was a big factor or not. Anyways, I checked out the
> source code. I checked on the internet to find that a few missing libraries
> were required to compile gcc. Initially I was going to install them by hand
> but then I realised it woud be a long process, considering I had to get
> each one of those as well as check each of their versions,etc.

On Ubuntu and other Debian-based distributions it should be enough to
just install libgmp-dev, libmpfr-dev and libmpc-dev through apt or
aptitude.

> So I used
> the script that has been bundled with the source about which,to be
> honest,

That works too.

> I was unaware of until very recently. Then, I initially unset everything
> and then enabled 'langages' and 'gold' and disabled 'libquadmath'(the quad
> math library),werror' and 'bootstrap'.

Being able to bootstrap the compiler is essential so that you can test
your changes (they have to pass bootstrap).  For development, you
definitely want to have bootstrap disabled.

> (A quick question:Did I also need to
> disable the support for quadmath as well?).

I personally don't care about it and it gets automatically enabled.

> I thought of using the default
> ld linker instead of the gold linker, but then I read somewhere gold linker
> worked faster for c++ projects.

Unless you have specific need for one or the other, I don't think it
matters which one you choose (it might make a difference in LTO projects
but because of bugs of one or the other rather than anything else).

> Finally I compiled it(which took a bit longer than it should have)

That is most certainly because of enable bootstrap.

> and installed it for usage.I was actually
> experimenting a bit and went a bit further and added it as an environment
> variable through the export command. And that was all.

Good, it looks like you are all set up.  I'm not sure I understand the
bit about the environment variable though.

>  Please let me know what you thought and tell me what to do next.

I'm not sure I understand this question well either.  But I'd suggest
looking at https://gcc.gnu.org/wiki/GettingStarted and especially at
https://gcc.gnu.org/wiki/DebuggingGCC and
https://gcc.gnu.org/onlinedocs/gcc/Developer-Options.html.  Compile a
simple but non-trivial program with -O3 -S -fdump-tree-all
-fdump-ipa-all -fdump-rtl-all and look through the generated files.
Look at the the source code, especially in the `gcc` subdirectory and
try to set a breakpoint somewhere and hit it.  Then look around in gdb.

And then it is really up to you what you want to focus on, it depends on
what attracts you most, what you are most interested in.  As far as GSoC
is concerned, we are in the process of finalizing an "official" list of
project ideas for this year at https://gcc.gnu.org/wiki/GettingStarted
but it will not be finished for at least a few more days, possibly even
a week.

If you have any further specific questions, please feel free to ask,
I'll make my best to be more diligent with replying.

Martin


> Thank You.
>
> On Wed, Nov 28, 2018 at 10:46 PM Martin Jambor  wrote:
>
>> Hi Siddhartha,
>>
>> On Tue, Nov 27 2018, Siddhartha Sen wrote:
>> > I am Siddhartha Sen,currently pursuing my B.Tech degree in Information
>> > Science and Engineering,2nd year. I have taken a keen interest in your
>> > projects and have some ideas of my own as well. I am really interested in
>> > working with you in G-SOC 2019.
>>
>> We are delighted.
>>
>> > I am proficient in C and C++ and am eager
>> > to work on brushing my skills in whichever field required. I have already
>> > checked out the GCC trunk source-code and am being able to build GCC from
>> > it.I have run the testsuite and saved the results.
>>
>> Great, those are all the essential first steps, it seems like you are
>> ready to work on your first patch.
>>
>> > However, upon building
>> > it and saving it again, the results don't match. I apologise for my lack
>> of
>> > knowledge but any help on your part would be great.
>>
>> How did you compare the test results and which tests behaved
>> differently?  How did you configure GCC?  Was it on an x86_64?
>>
>> Unfortunately, this sometimes happens.  As far as I can tell, the libgo
>> testsuite is very flaky and I basically ignore its results.  In the
>> past, I believe that also some guality tests sometimes passed and
>> sometimes did not, but I have not heard such reports recently.  These
>> tests however also depend on the GDB (version) you have installed on
>> your system.
>>
>> Martin
>>

Re: Regarding GSOC Projects

[Martin Jambor]

Hello Aadrit,

On Sun, Jan 20 2019, Aadrit Aggarwal wrote:
> Greetings for the day!!
> I'm an undergraduate in my 2nd year at Punjab Engineering College,
> Chandigarh. I'm pursuing CSE.
> This mail is regarding GSOC Projects.
>
> *It's my first time, that I'd be participating in an open source event, and
> apparently first time in GSOC.*
>
> I was going through your idea list,  and I'm keen to contribute to some of
> the projects. As I have expertise in C, C++ Language, Algorithm Analysis
> etc, I'd like to work on projects   involving these technologies.

We are delighted you found contributing to GCC interesting.  On the
other hand, I am worried that you also need at least some rudimentary
theoretical background in the area of compilers in order to apply.

Nevertheless, you can definitely try yourself and see how difficult it
will be.  Please look again at the "Before you apply" section of the
idea page https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply and
make sure you are able to build, install and test GCC and then have it
generate dumps and step through some function during compilation.

Afterwards, if you still find contributing to GCC interesting, look at
a suggested idea, try to identify the portion of GCC source which is
involved and email us back to the mailing list, describing which idea
you liked best and what your thoughts about it are.

Good luck,

Martin

Re: Google Summer Of Code

[Martin Jambor]

Hello Vikramsingh,

On Mon, Jan 21 2019, Vikramsingh Kushwaha wrote:
> Respected sir/madam
> I, Vikramsingh Kushwaha, currently studying in B.Tech 3rd year computer
> engineering in MIT Pune, India. I am very much interested to contribute in
> the open source projects. But i am new to this so I needed some guidance.
> Even i wanted to participate in Google Dummer Of Code, so i wanted your
> organisation to be my mentor.
> Kindly, be my mentor, i am ready for any challenge or task, test whatever
> you want to take. I shall be sharing my github and codechef profile. I am
> an average coder but a dedicated hard worker.

We are delighted you found contributing to GCC interesting.  On the
other hand, I am worried that you also need at least some rudimentary
theoretical background in the area of compilers in order to apply.

Nevertheless, you can definitely try yourself and see how difficult it
will be.  Please look again at the "Before you apply" section of the
idea page https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply and
make sure you are able to build, install and test GCC and then have it
generate dumps and step through some function during compilation.

Afterwards, if you still find contributing to GCC interesting, look at
a suggested idea, try to identify the portion of GCC source which is
involved and email us back to the mailing list, describing which idea
you liked best and what your thoughts about it are.

Good luck,

Martin

GCC and GSoC 2019

[Martin Jambor]

Hi,

today I have filed an application on behalf of the GCC project to be a
mentoring organization in the year 2019 of Google Summer of Code.  I'd
like to have the following requests and announcements:

1. First and foremost, I would like to ask all (moderately) seasoned GCC
   contributors to consider mentoring a student this year and ideally
   also come up with a project that they would like to lead.  I'm
   collecting proposal on our wiki page
   https://gcc.gnu.org/wiki/SummerOfCode - feel free to add yours to the
   top list there.  Or, if you are unsure, post your offer and project
   idea as a reply here, of course.

2. I would like to thank a lot to those who have already confirmed that
   they are willing to mentor a GSoC project.

3. Project ideas that come without an offer to also mentor them are
   always fun to discuss, by all means feel free to reply to this email
   with yours, but please be aware that we can only make use the
   suggestion it if we find a mentor.  I might mention them on the wiki,
   but only less prominently.

4. All knowledgeable GCC folk are invited to go over
   https://gcc.gnu.org/wiki/SummerOfCode and simply remove any outdated
   or otherwise really bad project suggestions.  I would especially want
   to ask GFortran and to a lesser extent C++ people to do so.

5. Please continue helping (prospective) students figure stuff out about
   GCC like you always do.

6. I intend to be the main "org admin" for GCC organization, I have
   asked Prathamesh Kulkarni and Honza Hubička to be my co-admins,
   because we must have at least two.  If anybody else would like to join
   us, let me know.

More information together with GSoC 2019 time line is available at
https://summerofcode.withgoogle.com

Thank you, let's hope we attract some good young talent this year.

Martin

GCC GSoC project idea to make C/C++ not promote memory_order_consume to memory_order_acquire

[Martin Jambor]

Hi,

I have received the following idea for a Google Summer of Code project,
see the quotation from Paul McKenney below (I do not know myself where
exactly it is from).  I consider memory consistency models a very tough
topic and so am doubly reluctant to just post it to wiki without having
a mentor for it.  On the other hand, with the right mentors it
definitely can be quite a remarkable project with a big potential.

Paul, this may come as a surprise for you, but would you be willing to
(co-)mentor such a project if there is a student brave enough to
undertake it?

C++ front-end guys, would you please consider co-mentoring this project
if Paul was willing to do so?

Anybody else interested in getting involved?

Any other suggestions/comments?

Thank you very much in advance,

Martin


 Start of forwarded message 

Hi Martin,

I don't think I have a mentor for this yet though I wonder if Paul McKenney
could be persuaded for this from the memory model side and someone familiar
with the C++ frontend on the GCC side ?


--

One could argue that compilers in fact implement the C and C++
memory_order_consume facility.  However, all known compilers do so by
promoting it to memory_order_acquire, which on weakly ordered systems
can result in unnecessary memory-barrier instructions on your fastpaths,
which might not be what you want.  The reason for the promotion to
memory_order_acquire is the difficutlies faced by compiler writers when
attempting to trace dependencies at the C/C++ source-code level.  In fact,
there is a proposal to temporarily deprecate memory_order_consume [1].

So what is to be done?  One proposal [2] restricts dependency chains
to cases where it is difficult for the compiler to break them, and
further requires that pointer variables carrying dependencies be marked.
(This proposal also includes prototype wording for the C++ standard,
a number of litmus tests, and some discussion.)  Such marking might not
go down well with the Linux kernel community, which has been carrying
dependencies in unmarked variables for more than 15 years, so there is
further informal proposal asking C and C++ implementations to provide a
command-line option forcing the compiler to treat any pointer variable
as if it had been marked.  (Why informal?  Because command-line options
are outside of the scope of the standard.)

There is a prototype implementation that obtains the functionality of
memory_order_consume without actually using memory_order_consume, which
is briefly described in a recent C++ working paper [3].  However, the
committee was not all that happy with this approach, preferring marking
of a single pointer variable to maintaining a separate variable to carry
the dependency.

It would therefore be quite desirable to have an implementation that
allowed pointers to be marked as carrying dependencies, that avoided
the specified dependency-breaking optimizations on such pointers, and
that provided a command-line switch that caused the compiler to treat
all pointers as if they were to marked [2].


[1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0371r0.html
[2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0190r4.pdf
[3] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0750r1.html

---

Ramana
 End of forwarded message 

Gfortran GSoC (Was: Re: [patch, libgfortran RFC] Installation script for OpenCoarrays to enable multi-image gfortran)

[Martin Jambor]

Hello,

On Fri, Jan 27 2017, Damian Rouson wrote:
> I wonder if developing an OpenCoarrays rpm package would be a good
> task as part of a Google Summer of Code (SoC) project.  February 9 is
> the application deadline for organizations seeking to host an SoC

No, February 6, 2019, 21:00 Central European Standard Time is the
deadline, i.e. in less than 22 hours.  GCC has already applied, I am the
primary Org admin.

> student and I’m interested in applying to host a student.  If anyone
> can suggest other good projects related to gfortran and OpenCoarrays,
> please let me know.  Several students have expressed interest.  I’m
> especially interested in anything that increases the support for the
> Fortran standards.

As far as GFortran GSoC projects are concerned, have a look at Fortran
section at
https://gcc.gnu.org/wiki/SummerOfCode#Language_front-ends_and_run-time_libraries

If any of the ideas is especially appealing to gfortran developers and
it is likely you will find a mentor for it, please feel free to move (or
copy?) it up to the "Selected project ideas" section at the top of the
page and definitely please tell the interested students to apply (but
let me again point out that we need mentors for each project too).

Thanks a lot,

Martin

Re: GCC GSoC project idea to make C/C++ not promote memory_order_consume to memory_order_acquire

[Martin Jambor]

Hi Jason and Andrew,

On Mon, Feb 04 2019, Jason Merrill wrote:
> On Mon, Feb 4, 2019 at 6:06 AM Martin Jambor  wrote:
>>
>> I have received the following idea for a Google Summer of Code project,
>> see the quotation from Paul McKenney below (I do not know myself where
>> exactly it is from).  I consider memory consistency models a very tough
>> topic and so am doubly reluctant to just post it to wiki without having
>> a mentor for it.  On the other hand, with the right mentors it
>> definitely can be quite a remarkable project with a big potential.
>>
>> Paul, this may come as a surprise for you, but would you be willing to
>> (co-)mentor such a project if there is a student brave enough to
>> undertake it?
>>
>> C++ front-end guys, would you please consider co-mentoring this project
>> if Paul was willing to do so?
>
> I wouldn't expect this project to touch the C++ front-end at all; any
> compiler work would all be in the middle/back-end.  There's some
> previous discussion of these issues at
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59448
>
> So I'd suggest pinging Andrew Macleod.

All right then, I was wondering what the FE specific parts would be too
but did not have a reason to doubt it.

Andrew, the word has it that Paul McKenney has expressed interest to
co-mentor this Google Summer of Code project, would you be willing to
join him?  The proposal is still copied below for your convenience.

Thanks,

Martin


>
> Jason
>
>> Anybody else interested in getting involved?
>>
>> Any other suggestions/comments?
>>
>> Thank you very much in advance,
>>
>> Martin
>>
>>
>>  Start of forwarded message 
>>
>> Hi Martin,
>>
>> I don't think I have a mentor for this yet though I wonder if Paul McKenney
>> could be persuaded for this from the memory model side and someone familiar
>> with the C++ frontend on the GCC side ?
>>
>> 
>> --
>>
>> One could argue that compilers in fact implement the C and C++
>> memory_order_consume facility.  However, all known compilers do so by
>> promoting it to memory_order_acquire, which on weakly ordered systems
>> can result in unnecessary memory-barrier instructions on your fastpaths,
>> which might not be what you want.  The reason for the promotion to
>> memory_order_acquire is the difficutlies faced by compiler writers when
>> attempting to trace dependencies at the C/C++ source-code level.  In fact,
>> there is a proposal to temporarily deprecate memory_order_consume [1].
>>
>> So what is to be done?  One proposal [2] restricts dependency chains
>> to cases where it is difficult for the compiler to break them, and
>> further requires that pointer variables carrying dependencies be marked.
>> (This proposal also includes prototype wording for the C++ standard,
>> a number of litmus tests, and some discussion.)  Such marking might not
>> go down well with the Linux kernel community, which has been carrying
>> dependencies in unmarked variables for more than 15 years, so there is
>> further informal proposal asking C and C++ implementations to provide a
>> command-line option forcing the compiler to treat any pointer variable
>> as if it had been marked.  (Why informal?  Because command-line options
>> are outside of the scope of the standard.)
>>
>> There is a prototype implementation that obtains the functionality of
>> memory_order_consume without actually using memory_order_consume, which
>> is briefly described in a recent C++ working paper [3].  However, the
>> committee was not all that happy with this approach, preferring marking
>> of a single pointer variable to maintaining a separate variable to carry
>> the dependency.
>>
>> It would therefore be quite desirable to have an implementation that
>> allowed pointers to be marked as carrying dependencies, that avoided
>> the specified dependency-breaking optimizations on such pointers, and
>> that provided a command-line switch that caused the compiler to treat
>> all pointers as if they were to marked [2].
>>
>>
>> [1] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0371r0.html
>> [2] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2017/p0190r4.pdf
>> [3] http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0750r1.html
>>
>> ---
>>
>> Ramana
>>  End of forwarded message 

Re: question about inlining long call sequence

[Martin Jambor]

On Tue, Feb 12 2019, Bin.Cheng wrote:
> Hi,
> When reading inlining code in GCC, I wonder if we have size heuristics
> to limit inlining long call sequence?  For example, for call sequence
> A -> B -> C -> D -> ... -> X -> Y -> Z
> if each function call grows size by a very small amount, inlining Z
> all the way up to the outermost function could result in a big
> function which may hurt icache.  Is this case handled in inliner? if
> yes, which code handles this?  Thanks in advance.
>
> BTW, I am using GCC 6, not sure if trunk has different behavior.

I believe it is done in caller_growth_limits() in ipa-inline.c in both
trunk and GCC 6.  The following comment in the function might shed a bit
more light on the behavior regarding big functions:

  /* Look for function e->caller is inlined to.  While doing
 so work out the largest function body on the way.  As
 described above, we want to base our function growth
 limits based on that.  Not on the self size of the
 outer function, not on the self size of inline code
 we immediately inline to.  This is the most relaxed
 interpretation of the rule "do not grow large functions
 too much in order to prevent compiler from exploding".  */

HTH

Martin

Re: GSoC 2019

[Martin Jambor]

Hello Parashuram,

On Tue, Feb 12 2019, Shourya IIT B wrote:
> Respected Sir,
>
>I am Parashuram Shourya from India. Currently, I am doing my
> Master’s in Geoinformatics from Centre of Studies in Resources
> Engineering(CSRE),
> Indian Institute of Technology Bombay(IITB). I have a Bachelor's degree in
> Computer Science and Engineering.
>
> Currently, I am learning Machine Learning and High-Performance Computing. I
> have vast programming experience in C, C++, Python
>
>   I would love to contribute to GNU Compiler Collection in the upcoming
> Google Summer of Code 2019. I would be very grateful to get any directions
> to start with so that I can pursue and participate in GSoC 2019 with your
> organization.

we are delighted you found contributing to GCC interesting.  Please look
again at the "Before you apply" section of our GSoC wiki page at
https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply and make sure you
are able to build, install and test GCC and then have it generate dumps
and step through some function during compilation.

Afterwards, if you still find contributing to GCC appealing, look at
a suggested idea, try to identify the portion of GCC source which is
involved and email us back to the mailing list, describing which idea
you liked best and what your thoughts about it are.

Good luck,

Martin

Re: [GSoC 2019] [extending Csmith for fuzzing OpenMp extensions]

[Martin Jambor]

Hello Sameeran,

On Sun, Feb 10 2019, sameeran joshi wrote:
> Hi,I am an undergraduate student currently in final year of computer
> science and engineering degree course from Pune University, India. I
> and Shubham have been working on Last year's GSoC project idea :
>
> Implement a fuzzer leveraging GCC extensions. Fuzzers like csmith are
> fairly good at finding compiler bugs. But they only generate standard
> C, but no extensions. GCC has many extensions, which are not covered.
> It would be good to extend a fuzzer like csmith to fuzz extensions
> like OpenMP, attributes, vector extensions, etc. Then run the fuzzer
> and report compiler bugs.
>
> since June 2018 under the guidance of mentor Andi Kleen.
> I worked on generating GCC C language extensions here is the link
> (coverage reports,implemented extension's list,bugs found,test cases,
> and usage are in README file on github)
> github Link:   https://github.com/Sameeranjoshi/csmith/tree/gcc-extensions
>
> We choose this as our university project as well, and are still
> fuzzing the extensions on compiler farm.
>
> Based on the previous work I would like to propose the following idea
> for GSoC 2019:
> Extending Csmith for OpenMP extensions.
>
> I would implement following constructs of OpenMP
>
> 1.PARALLEL CONSTRUCT
> 2.WORKSHARING CONSTRUCTS -
>   2.1 sections
>   2.2 single
>   2.3 loop constructs
>   2.4 master construct
> 3.TEAMS CONSTRUCT
> 4.TASKING CONSTRUCT -
>   4.1 task
>   4.2 taskloop
>   4.3 taskloop simd
>   4.4 taskyield
> 5.SYNCHRONIZATION CONSTRUCTS -
>   5.1 critical
>   5.2 atomic
>   5.3 barrier
>   5.4 taskwait
>   5.5 taskgroup
> 6.DATA SHARING ATTRIBUTES -
>   6.1 private
>   6.2 public
>   6.3 firstprivate
>   6.4 lastprivate
> Also, I would like to work on the target constrains if time permits.
> The main challenge what I think would be to ensure that there aren't
> any data races and data conflicts so that the parallelized program is
> not undefined.
>
> Usage for the GCC community :
> 1. It might have slight large increments in code coverage and trigger
> a lot of unique code .
>
> I have watched
>A "Hands-on" Introduction to OpenMP | Tim Mattson, Intel all 4 
> parts
>https://www.youtube.com/watch?v=pRtTIW9-Nr0
>
> I have started reading the specification of latest 5.0 standard.
> Please suggest if this could be an interesting idea for upcoming GSoC ?
>

Indeed it is, you clearly have it thought out very well.  I have noted
it down and am looking forward to your project submission (assuming
Google approves us as a participating organization, of course).

Meanwhile, if you have any technical questions, regarding the GCC
extensions you listed above, feel free to ask here on the list.

Good luck diving into the OpenMP spec and thank you,

Martin

Re: GCC GSOC 2019

[Martin Jambor]

Hello Shubham,

On Sun, Feb 10 2019, Shubham Narlawar wrote:
> Hi,
>
> I am Shubham Narlawar. Currently, I am a Computer Engineering undergrad
> student at Pune University, India. I am interested in contributing to GCC
> for GSOC 2019.
>
> We have done a project from GCC GSOC 2018 idea list which is implementing
> Csmith fuzzer leveraging GCC C Extensions under the guidance of Andi Kleen.
>
> Csmith is a C fuzzer which generates standard C code but no extensions. We
> implemented few of GCC C extensions in Csmith (which now we call it as
> "Extended Csmith"). Extended Csmith is now able to fuzz extensions along
> with standard C code.
>
> Following GCC C Extensions are implemented in Csmith currently -
> 1. Labels as Values (Computed Goto)
> 2. Local Labels
> 3. Typeof
> 4. __int128 - Signed and unsigned integer of size 128 bits.
> 5. Cast to Union
> 6. Label attributes - hot cold
> 7. Variable attributes - a) aligned
> b) unused
> c) section
> 8. Binary constants
> 9. Statement Expression
>
> 10. Transactional memory relaxed - tm_relaxed (not a GCC C extension)
>
> Note - Different Combinations of these extensions can be used while
> generating random C code using extended csmith.
>
> Here is the github link of the project.
> https://github.com/Sameeranjoshi/csmith/tree/gcc-extensions
>
> Currently, We are running extended csmith on gcc10 of GCC Compile Farm
> Project and found following bugs -
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89135
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89153
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87118
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89223
>
> We expect to find more bugs in GCC as the gcc compiler is being stress
> tested now.
>
> Code coverage - Csmith vs Extended Csmith
>
>  Csmith i.e. [without gcc extn ]
>   line - 35.2
>   function - 43.2
>   branch - 25.7
>
>   Extended Csmith [with gcc extn]
>   line - 35.7
>   function - 43.9
>   branch - 26.1
>
>   %gain
>   line - 0.5%
>   function - 0.7%
>   branch - 0.4%
>
> For GSOC 2019, I am proposing below project idea -
>
> Implementation of following extensions in the Csmith -
> 1. Function attributes - aligned, alloc_align, always_inline, hot, cold,
> deprecated, nothrow, used, etc
> 2. Vector extensions
> 3. Transactional Memory extensions
> 4. Type attributes
> and remaining GCC C extensions.
>
> Benefits to GCC -
> 1. Increased code coverage.
> 2. There is a possibility of finding more bugs after adding the above
> extensions.
>

Thank you very much for sending us your project idea.  I have noted
it down and am looking forward to your project submission (assuming
Google approves us as a participating organization, of course).

Meanwhile, if you have any technical questions, regarding the GCC
extensions you listed above, feel free to ask here on the list.

Thank you,

Martin

Re: [GSOC] Simple things to play with (Was: variations in testsuite results)

[Martin Jambor]

Hi Siddhartha,

On Sat, Feb 02 2019, Siddhartha Sen wrote:
> Hey Marting,
> I have disabled the boottrap and am able to bootstrap
> the compiler on my own. I have done as you said and have experimented a bit
> with gdb as well. I was facing trivial problems but nothing that the
> internet did not have answers for. I have done most of the things on the
> list - I have built,compiled,debugged as well as tested variations in gcc.
> However, I am unable to understand the project ideas here
> https://gcc.gnu.org/wiki/GettingStarted. Could you suggest something
> trivial before I look into these in order to get a proper understanding?
> Like any microproject or miniproject would be alright.
> Thanks

I apologize for my late reply again.  One reason is that my TODO list
kind of exploded last week but another is that it is difficult to think
of an easy project in GCC.  Easy things usually get immediately done,
starting to contribute to GCC is unfortunately usually a bit hard.  On
the other hand, it is better to ask such questions on the mailing list
(CCed) in the future, it can well happen someone else will be able to
help you (faster).

In any event, I guess it now mostly comes down to selecting a specific
part of GCC you want to look into.  At this point I'd recommend looking
at the "Bypass assembler when generating LTO object files" project idea
from our wiki page (the likely mentor, Honza, is also in CC).  What you
want to do as the first step is to compile some simple (almost
hello-world-like), program with options "-flto -save-temps -v" and
examine the compiler output (especially the command lines invoking the
various steps of LTO compilation, some of which you will want to re-run
within gdb) and the various file it keeps around, especially the *.s
ones that are not called ltrans-something, which you'd eventually want
to eliminate.

Most of the data writing/reading is done in the libiberty library so
look at that, along with code in gcc/lto/*.[ch] which invokes it.  IIUC,
the project basically means implementing direct output of ELF-format
field, from libiberty instead of the assembler one, so look into ELF
format too.  And perhaps Honza can suggest some further exploratory
steps for you too.

Good luck,

Martin


>
> On Mon, Jan 28, 2019 at 11:03 PM Martin Jambor  wrote:
>
>> Hello Siddhartha,
>>
>> first and foremost, I'd like to apologize for replying so late.  I have
>> accidently marked your messages as only needing attention when the new
>> GSoC year is about to start.
>>
>> On Sat, Dec 01 2018, Siddhartha Sen wrote:
>> > Hi Martin,
>> >
>> > Firstly,I use an x86_64(Ubuntu 18.04) since you asked,although I am not
>> > sure whether that was a big factor or not. Anyways, I checked out the
>> > source code. I checked on the internet to find that a few missing
>> libraries
>> > were required to compile gcc. Initially I was going to install them by
>> hand
>> > but then I realised it woud be a long process, considering I had to get
>> > each one of those as well as check each of their versions,etc.
>>
>> On Ubuntu and other Debian-based distributions it should be enough to
>> just install libgmp-dev, libmpfr-dev and libmpc-dev through apt or
>> aptitude.
>>
>> > So I used
>> > the script that has been bundled with the source about which,to be
>> > honest,
>>
>> That works too.
>>
>> > I was unaware of until very recently. Then, I initially unset everything
>> > and then enabled 'langages' and 'gold' and disabled 'libquadmath'(the
>> quad
>> > math library),werror' and 'bootstrap'.
>>
>> Being able to bootstrap the compiler is essential so that you can test
>> your changes (they have to pass bootstrap).  For development, you
>> definitely want to have bootstrap disabled.
>>
>> > (A quick question:Did I also need to
>> > disable the support for quadmath as well?).
>>
>> I personally don't care about it and it gets automatically enabled.
>>
>> > I thought of using the default
>> > ld linker instead of the gold linker, but then I read somewhere gold
>> linker
>> > worked faster for c++ projects.
>>
>> Unless you have specific need for one or the other, I don't think it
>> matters which one you choose (it might make a difference in LTO projects
>> but because of bugs of one or the other rather than anything else).
>>
>> > Finally I compiled it(which took a bit longer than it should have)
>>
>> That is most certainly because of enable bootstrap.
>>
>> > and installed it 

Re: [GSoC 2019] No application template?

[Martin Jambor]

Hi,

On Sun, Mar 24 2019, 김규래 wrote:
> Hello,
> I was trying to write my application for GSoC 2019 but couldn't find an 
> application form for GCC.
> Some other organizations seem to have GSoC application forms/templates.
> The gcc GSoC wiki page doesn't mention any.
> Is the application format free? or did I miss it somewhere?

No, you did not miss anything, we do not have any specific application
format to follow.  In the OpenMP tread you sounded like you knew what
to do and why anyway.  But to at last give an example, last year this
was an application that would have been accepted if the applicant did
not retract it:
https://docs.google.com/document/d/1YkKYI3J-pKFfHLdxljWVoJ89l2oVGibxslIW3ikluz8/edit
(at least at the moment it i still available).

> If it is free, is there anything I should include else than what is mentioned 
> in [1, 2]
>  

Generally speaking, it is probably a good idea to accompany the proposed
project description with a brief motivation, an expected time-line (we
understand it is likely to change) and a brief introduction of your
technical background, skills and/or accomplishments.  The project
description is the most important part however (and each project is
perhaps best explained differently), we'll mostly judge your abilities
from your interactions with us, on mailing lists and IRC, rather than
from a CV.

If you share the proposal with us on this list some three or four work
days before submitting it, we are likely to have a look at it and
comment if we'd like something changed.

Good luck,

Martin


> Ray Kim
>  
> [1] https://www.drupal.org/node/59037
> [2] http://of-code.blogspot.com/2007/08/soc-experience-introduction.html

Re: GSoC

[Martin Jambor]

Hello Martin,

On Sun, Mar 10 2019, Martin Emil wrote:
> Hello ,
> I am Martin Emil last year computer engineering student from Egypt .
> I came through your project in GSoC  and i am very interested about it and
> want to work on it.
> I have strong knowledge in C,C++,Java and python programming
> languages.

Given the project you are interested in, do you have background in
parallel programming?  OpenMP in particular?  I am also worried that you
need at least some rudimentary theoretical background in the area of
compilers in order to apply too.

> I am interested in *Implementation of OMPD
> 
> in  GCC idea  , and i want to know more about it .*

We are happy to answer any specific question but this one is quite a bit
too broad.  Apart from what is covered by the spec you have linked, what
would you like to know?

Thanks,

Martin

Re: GSOC 19 Add new math.h and complex.h functions as built-ins

[Martin Jambor]

Hi Thilakar,

On Fri, Mar 22 2019, GSOC19TR I wrote:
> Dear Sir,
> I like to work on the project *Adding new math.h and complex.h functions as
> built-ins**.

we are already in fairly advanced stage of putting together a proposal
for the same project with Tejas Joshi.  You can of course try to submit
a better one but it will be difficult.  Or you just have about time to
switch and attempt a different project idea.

> *With an year's experience in the field, I believe that I am
> the type of person you are seeking. I am interested in working on real time
> projects and contribute to the opensource community.

You do understand GCC has litle to do with real-time, right?

> I am conscientious in my personal and professional life. I take pride in
> myself and my work, and derive considerable satisfaction from doing an
> assignment well. I cope well with high-stress situations and can manage a
> variety of projects simultaneously.
> It would be helpful if I get to know some tips on applying successful
> project proposal. I wanted to give my best in the project. I would also
> like to know some suggestions on preparations that I would do before 
> committing
> into the project like prescribed textbook or some important list of topics
> to be revised.

We are delighted you found contributing to GCC interesting.  On the
other hand, I am worried that you need to already have at least some
rudimentary theoretical background in the area of compilers in order to
apply, asking for a textbook now is definitely too late.  The best
textbook that I can think of right now is "Building an Optimizing
Compiler" by Bob Morgan.  If you read and understand it, you will be
very well equipped for a GSoC with us... next year.

Nevertheless, you can definitely try yourself and see how difficult it
will be.  Please look again at the "Before you apply" section of the
idea page https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply and
make sure you are able to build, install and test GCC and then have it
generate dumps and step through some function during compilation.

Afterwards, if you still find contributing to GCC interesting, look at a
suggested idea, try to identify the portion of GCC source which is
involved and email us back to the mailing list, describing which idea
you liked best and what your thoughts about it are.  If you insist on
optimizing new math.h functions, dig into the source and find where the
existing ones are processed, step through them in gdb.  But again, I'd
recommend reconsidering applying for a GCC project and if so, look at
other ideas.

In any event, good luck,

Martin

Re: GSoC

[Martin Jambor]

Hello Youssuf,

On Sat, Mar 23 2019, youssef Elmasry wrote:
> What kind of experience i should have in c/c++ before applying?

I am afraid that not only you need a very solid command of C and have to
be comfortable navigating C++ mazes but that you also need at least some
rudimentary theoretical background in the area of compilers in order to
apply.

>  Is it possible to learn what’s missing before the deadline?

No, unfortunately I don't think that is realistic.

I do not mean to be discouraging though, we are delighted you found
contributing to GCC interesting.  If your interest in C, C++ and
compilers in particular persists, I'm sure we will be only very happy to
consider you another year.

Good luck,

Martin

Re: Regarding GSOC

[Martin Jambor]

Hi Aniket,

On Mon, Mar 25 2019, Aniket Agarwalla wrote:
> Hello Sir,
>
> I am interested in working with you in your shortlisted projects on Gsoc
> 2019 namely
> "Add new math.h and complex.h functions as built-ins".

we are already in fairly advanced stage of putting together a proposal
for the same project with Tejas Joshi.  You can of course try to submit
a better one but it will be difficult.  Or you just have about time to
switch and attempt a different project idea.

> I would like to add that I have a good mathematical background and have
> been doing competitive programming for years now.So I think I can work hard
> on this project and complete the project as per the organization
> requirements. I also wanted to know what more I can do or submit a proposal
> to get a chance to work with your organization.

Please look again at the "Before you apply" section of our GSoC wiki
page at https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply and make
sure you are able to build, install and test GCC and then have it
generate dumps and step through some function during compilation.

Then find bits of GCC that are relevant to your selected project and
continue exploring like above.  If you have any specific questions, feel
free to ask again here on the mailing list.

Good luck,

Martin

Re: Gsoc

[Martin Jambor]

Hello Darshan,

On Tue, Mar 26 2019, FuN traveller wrote:
> Hello ,
> I am Darshan jadhao, computer engineering student at Lovely Professional
> University Jalandhar,
> I would like to work with GNU on the project *Make C/C++ not automatically
> promote memory_order_consume to memory_order_acquire*.
> Email: darshan18jadha...@gmail.com

You posted the email twice, so I assume you are expecting an answer.
Your intention has been noted, I assume that you have also completed all
steps described in the "Before you apply" section of our GSoC wiki page
at https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply

If you have any specific question, please do not hesitate to ask on this
list.

Good luck,

Martin

Re: [GSoC 2019]: Interested in "Make C/C++ not automatically promote memory_order_consume to memory_order_acquire"

[Martin Jambor]

Hello Akshatg,

On Tue, Mar 12 2019, Akshatg wrote:
> Hello all,
>
> I'm a 2nd year Master's student at IIT Bombay. I have taken advance 
> compiler related courses in the past semesters. I'm interested to work 
> on the project "Make C/C++ not automatically promote 
> memory_order_consume to memory_order_acquire" this summer. I have read 
> the documents shared.

We are glad that you find contributing to GCC interesting, I have
already talked with Paul about you and the project a little.

>
> Kindly, let me know what I can do next to make my proposal stronger?
>

If you have not done so yet, please look at the "Before you apply"
section of the idea page
https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply and make sure you
are able to build, install and test GCC and then have it generate dumps
and step through some function during compilation.  In your case, you
will most likely want to start at how built-in functions representing
atomic operations are defined in sync-builtins.def and used throughout
the compiler.  Grep is your friend.  Feel free to ask here on the list
if there is anything specific you don't understand or would like to
know.

Good luck,

Martin

Re: GSoC

[Martin Jambor]

Hello Matias,

On Thu, Mar 14 2019, Matias Barrientos wrote:
> Hello,
>
> I am Matías Barrientos, I am in my third year studying computing
> engineering at the Pontifical University of Valparaiso.
>
> I am very interested in contributing at GCC this year in GSoC. I have
> followed the steps of the link
> (https://gcc.gnu.org/wiki/SummerOfCode), so I was able to do bootstrap
> and installation of GCC in my computer.

Wonderful, we are delighted you found contributing to GCC interesting
and happy to hear that you have got past the first steps.

>
> On the other hand, I have been studying GCC’s codes, optimization
> flags to be more specific. In that time I could realize that the
> warnings have their dependence among them, but that is not the case of
> optimization. This is how I have had the idea of implementing
> dependence among optimization flags by modifying the .opt files.
>
> It would be as follow:
>
> 1. Embed the attribute EnabledBy o LangEnabledBy to create the dependence.
> 2. Implement the dependency of the optimization flag (“-O”) to
> detect the different levels.

Unfortunately, this project idea apparently has not quite caught much
attention.  I myself struggle with understanding what is supposed to be
dependent on what and don't think that simply mapping dependencies from
optimization levels to individual warning options is a project that
should span three months.  You'd need to substantially extend the scope
somehow or perhaps look for another idea, our wiki still has a few that
nobody took up.

If I misunderstood something, please feel free to correct me and/or ask
anything specific that you'd like to know about GCC.

Thanks,

Martin

Re: [GSoC]

[Martin Jambor]

Hi Avinash,

On Thu, Mar 28 2019, Avinash Tiwary wrote:
> Hi,
> I am Avinash Tiwary, fourth year engineering graduate from BIT Mesra. I
> will like to contribute on "Add new math.h and complex.h functions as
> built-ins". Please guide me.

we are delighted you found contributing to GCC interesting.  Please look
again at the "Before you apply" section of our GSoC wiki page at
https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply and make sure you
are able to build, install and test GCC and then have it generate dumps
and step through some function during compilation.

Afterwards, if you still find contributing to GCC appealing, look at
a suggested idea, try to identify the portion of GCC source which is
involved and email us back to the mailing list, describing which idea
you liked best and what your thoughts about it are.

Good luck,

Martin