GCN back-end branch

[Martin Jambor]

Hello,

after working on GCN back-end in private branch, we would like to make
it public and invite the community to have a look, comment, review or
even contribute.  Therefore we have just pushed the current state of
the back-end to the git branch gcn (see
https://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/gcn or
fetch it as any other git branch).

We have decided not to have ChangeLog.gcn files but if you wish to
contribute, please make standard changelog entries part of commit
messages.  Additionally, the basic git collaboration rules should
apply, most notably make sure you do not do non-fast-forward pushes to
the branch, start your commit messages with one-line brief summaries
and so forth.  Any patches against the branch should be sent to
gcc-patches, and while I think that full-blown reviews are not
necessary at this stage, please coordinate with me and Honza before
you commit anything.  I will be making regular merges from trunk.

At this point, the back-end can compile small kernels open-coded in C
with target-specific attributes, built-ins and address spaces to make
use of the various special characteristics of the architecture.
Eventually, it should of course provide for high-level programming
models, most notably OpenMP, but the list of steps we need to take
before we get there is very long.

The changelog of the branch initial commit is below.  Apart from a new
machine description, it also contains a few modifications to the
compiler proper, most of which are needed to increase the limit on
size of scalar types and the number of arguments of an instruction
(which are actually not strictly necessary now but we have bumped into
them during development).  We plan to commit generally useful generic
changes early in stage1.

So far we have tested output of the branch only on AMD APUs, we have
not tested on discrete GPUs yet.  To run the kernels, you need quite a
few more pieces in your software stack in addition to our branch and
the hardware.  Most notably, you currently need:

  1) an AMDGPU-LLVM-based assembler,
  2) the amdphdrs utility from
https://github.com/RadeonOpenCompute/LLVM-AMDGPU-Assembler-Extra, and
  3,4,5) ROCK kernel, ROCT thunk interface library and ROCR run time
library, which you can get from
https://github.com/RadeonOpenCompute (or currently from

http://download.opensuse.org/repositories/home:/jamborm:/roc-1.3/openSUSE_Tumbleweed
if you use openSUSE Tumbleweed, so far I have packaged only
version 1.3 but so far it was sufficient).

The work-flow is that you configure the branch with
--target=amdgcn-unknown-amdhsa, use it to compile the kernel into
assembly, which you then feed to llvm-mc amdgcn assembler, we then use
amdphdrs tool to convert the resultant object file to an AMD HSA "code
object" which the ROCR run time can then load and execute.  Honza and
I hope to come up with an article demonstrating what can already be
done with the branch soon, but that is clearly out of scope of this
already too long announcement.  We plan to write a wiki page with some
examples and more detailed descriptions of some basic problems with
modeling GCN in GCC.

Thus, let me conclude saying that I'm looking forward to taking on
many challenges this architecture will present for GCC and I would
like to invite everyone interested to help tackling them,

Martin



2017-03-10  Jan Hubicka  <j...@suse.cz>
        Martin Jambor  <mjam...@suse.cz>

* config.sub: Added amdgcn cases.

gcc/
* common/config/gcn/gcn-common.c: New file.
* config/gcn/constraints.md: Likewise.
* config/gcn/gcn-builtins.def: Likewise.
* config/gcn/gcn-c.c: Likewise.
* config/gcn/gcn-hsa.h: Likewise.
* config/gcn/gcn-modes.def: Likewise.
* config/gcn/gcn-protos.h: Likewise.
* config/gcn/gcn-valu.md: Likewise.
* config/gcn/gcn.c: Likewise.
* config/gcn/gcn.h: Likewise.
* config/gcn/gcn.md: Likewise.
* config/gcn/gcn.opt: Likewise.
* config/gcn/predicates.md: Likewise.
* config/gcn/t-gcn-elf: Likewise.
* ira.c (ira_init_register_move_cost): Also check that
contains_reg_of_mode.
* combine.c (gen_lowpart_or_truncate): Return clobber if there is
not a integer mode if the same size as x.
(gen_lowpart_for_combine): Fail if there is no integer mode of the
same size.
* config.gcc: Added amdgcn cases.
* emit-rtl.c (get_mem_align_offset): Return zero for overaligned
memory.
* explow.c (memory_address_addr_space): Call memory_address_addr_space
if a representation by a single register is invalid.
* expr.c (expand_expr_real_1): disable converting operand to fields or
BLK mode.
* ira-costs.c (setup_allocno_class_and_costs): Do not assert that
cost_classes_ptr->hard_regno_index is non-negative.
* lra-constraints.c (process_alt_o

Re: dejagnu version update?

[Martin Jambor]

Hi,

On Wed, Sep 16, 2015 at 01:25:18PM -0400, Trevor Saunders wrote:
> On Wed, Sep 16, 2015 at 10:36:47AM -0600, Jeff Law wrote:
> >

...

> > I'd rather just move to 1.5 and get on with things.  If some systems don't
> > have a new enough version, I'm comfortable telling developers on those
> > platforms that they need to update.  It's not like every *user* needs
> > dejagnu, it's just for the testing side of things.
> 
> yeah, it seems like a poor idea to slow down progress we make for all
> users to benefit a few people who want to develope on rather old
> machines.
> 

Could we at least make sure that machines in the FSF compile farm have
a new enough dejagnu before move to requiring at least 1.5?

I understand that may be a tall order, given that some machines
(e.g. gcc117) do not have dejagnu at all and this was reported some
time ago :-(

Martin

Re: Help with getting started with adding IPA-related attribute

[Martin Jambor]

Hi,

On Sat, Apr 29, 2017 at 06:28:31AM -0500, Daniel Santos wrote:
> Brievity is not my forte, so let me start with the questions.  Can somebody
> please point me to the pass and/or function where gcc
> 
> 1.) decides rather or not to inline a function,

There are two inlining passes.  Early-inliner that works in
topological order and inlines (almost) only when the result is
expected to be smaller than uninlined code.  Then there is a full IPA
inlining pass, which can take advantage of LTO and heuristics that
allows code to grow.

To understand both, you really need to read most of ipa-inline*.[ch]
files.  The exact places where the decisions are made are:
  - early_inline_small_functions() and want_early_inline_function_p()
in ipa-inline.c for early inlining, and
  - the IPA inliner has a few phases and sub-phases itself, see the
helper functions in ipa_inline() and especially in
inline_small_functions().  Alternatively, you want to check out
all functions which call inline_call().

> 2.) decides rather or not to make a .constprop version of a
> function,

Check out the places that call create_specialized_node() in ipa-cp.c,
namely templated decide_about_value() and the end of
decide_whether_version_node(), which however just checks the flag
do_clone_for_all_contexts set earlier in estimate_local_effects().

> 3.) a good pass (when all constant propagation is done) to search for fn
> parameters and variables (marked with an attribute) that were not
> constproped away, and finally

The attributes must be accepted by the front-end.  For example in C
and C++ this is done in gcc/c-family/c-attribs.c.  Afterwards any pass
or any code in the compiler can use lookup_attribute on the
PARM_DECL tree representing the parameter.

> 4.) what mechanism should I use for that search?  (iterate through the tree
> to find them and then see if they have rtl?  I haven't worked in this area
> yet.

No, I do not think you want to operate on the RTL level (though I have
only very briefly skimmed through the rest of your email).  Use the
gimple/tree representation as I wrote above.  Look at for example
ipa_populate_param_decls() in ipa-prop.c to see how to iterate over
all PARM_DECLs of a function.


Hope this helps,

Martin

Re: RFC: Improving GCC8 default option settings

[Martin Jambor]

Hi,

On Thu, Sep 14, 2017 at 11:55:21AM +0200, Richard Biener wrote:
> On Wed, Sep 13, 2017 at 5:08 PM, Allan Sandfeld Jensen
>  wrote:
> > On Mittwoch, 13. September 2017 15:46:09 CEST Jakub Jelinek wrote:
> >> On Wed, Sep 13, 2017 at 03:41:19PM +0200, Richard Biener wrote:
> >> > On its own -O3 doesn't add much (some loop opts and slightly more
> >> > aggressive inlining/unrolling), so whatever it does we
> >> > should consider doing at -O2 eventually.
> >>
> >> Well, -O3 adds vectorization, which we don't enable at -O2 by default.
> >>
> > Would it be possible to enable basic block vectorization on -O2? I assume 
> > that
> > doesn't increase binary size since it doesn't unroll loops.
> 
> Somebody needs to provide benchmarking looking at the compile-time cost
> vs. the runtime benefit and the code size effect.  There's also room to tune
> aggressiveness of BB vectorization as it currently allows for cases where
> the scalar computation is not fully replaced by vector code.
> 

A good candidate too look at might be 525.x264_r from the SPEC2017 CPU
suite.  With just -O2, GCC is about 70% slower than LLVM (which I
think must be doing some vectorization at -O2).  When I give -O2
-ftree-vectorize to gcc, the difference drops to 20%, so vectorization
is not the whole story either.  There is no real difference in
run-time of executables generated with both compilers at -Ofast.

(But no, I'm not volunteering to analyze it further in foreseeable
future.)

Martin

Re: pass manager question

[Martin Jambor]

Hi,

On Mon, Oct 02, 2017 at 01:27:05PM -0600, Sandra Loosemore wrote:
> Is there an idiom for target-specific back end code to ask the pass manager
> if a particular pass (e.g., "split1") has already run?

(I might be wrong but) I don't think there is.  But it might be a
useful thing to have generally, it would allow us for example to merge
early SRA and "late" SRA which differ in behavior only because the
first one must not touch aggregates that pass_stdarg will operate on.

And I guess the infrastructure to do that could be as simple as adding
a flag (or a counter) to class opt_pass that the pass manager would
set (or increment) when running the pass.

Martin

> 
> I have some nios2 addressing mode improvement patches in the works that
> depend on deferring splitting of some complex address forms until after cse
> and fwprop, instead of during expand.  Once "split1" has run,
> TARGET_LEGITIMATE_ADDRESS_P shouldn't consider those address forms valid any
> more.  For now I've solved this problem by adding a target-specific pass
> immediately after "split1" that does nothing but set a flag, but that seems
> kind of hacky.  If I can get at the information from the pass manager's
> public interface, that seems like a better solution, but I've gotten rather
> lost in that code.  :-(
> 
> I suppose another alternative is adding a split1_completed variable akin to
> reload_completed, but I'm hesitant to touch target-independent code for
> things that aren't generally useful.
> 
> Any suggestions/recommendations?
> 
> -Sandra
> 

Re: I want to dump something when I compile the program. How should I do ?

[Martin Jambor]

Hi,

On Thu, May 17 2018, 冠人 王 via gcc wrote:
> My work is to modify the gcc source code so as to customize the warning 
> message, when the programmer writing the program violating some rules. 
> When the violation occurs, I want to reveal some message such as "guanjen375 
> warning: the rule ### is violated" on the window.
> How should I do ? Should I modify some file in the gcc source code so that I 
> can print my own message?
> Besides, I want to realize how GCC code executed, so I want to insert some 
> code into GCC source code to check waht happens when those code
> be executed. I try to use "printf" but failed, the message I print
> reveals when I make(after configure), but not reveals at compile time

For this purpose, use fprintf to write your debug message to stderr.

Martin
 
> If you do not really understand what do I say, let me show an example:
> $gcc -Wunused test.c
> test.c:5:6: warning: unused variable ‘a’ [-Wunused-variable]  int a;      ^
> becomes
> $gcc -Wunused test.c
> HI,DAVIDtest.c:5:6: warning: unused variable ‘a’ [-Wunused-variable]  int a;  
>     ^

Re: I want to know the information about the function arguments

[Martin Jambor]

Hi,

On Wed, Jun 06 2018, 冠人 王 via gcc wrote:
> When I modify the gcc source code, sometimes I do not know what parameters 
> does the function call.
> For example, 
> bool warn_if_unused_value(const tree exp,location_t locus){    function 
> declaration ...
> }
> I want to know what "exp" and "locus" are by using fprintf such as
> fprintf(stderr,"%s\n%s\n",exp,locus) --> I know it does not work since exp 
> and locus is not strings
> How should I do to know the content of variable "exp" and "locus" ?

For trees, look for example at:

- debug_tree (tree);
- print_node (FILE *, const char *, tree, int);
- print_node_brief (FILE *, const char *, const_tree, int);

For location_t, I *think* you need to expand it yourself first.  Look at
how it is being done for example in tree-dump.c.

Generally speaking, for any given type, try searching for functions with
"debug" or "dump" in their names that dump any particular type.

HTH

Martin

Re: How to get GCC on par with ICC?

[Martin Jambor]

Hi Steve,

On Fri, Jun 08 2018, Steve Ellcey wrote:
> On Thu, 2018-06-07 at 12:01 +0200, Richard Biener wrote:
>> 
>> When we do our own comparisons of GCC vs. ICC on benchmarks
>> like SPEC CPU 2006/2017 ICC doesn't have a big lead over GCC
>> (in fact it even trails in some benchmarks) unless you get to
>> "SPEC tricks" like data structure re-organization optimizations that
>> probably never apply in practice on real-world code (and people
>> should fix such things at the source level being pointed at them
>> via actually profiling their codes).
>
> Richard,
>
> I was wondering if you have any more details about these comparisions
> you have done that you can share?  Compiler versions, options used,
> hardware, etc  Also, were there any tests that stood out in terms of
> icc outperforming GCC?

Mostly AMD Ryzen, GCC 8 vs ICC 18.  We were comparing a few combinations
of options.  When we compared ICC's and our -Ofast (with or without
native GCC march/mtune and a set ICC options that hopefully generate
best code on for Ryzen), we found out that without LTO/IPO, GCC is
actually slightly ahead of ICC on integer benchmarks (both SPEC 2006 and
2017).

Floating-point results were a more mixed bag (mostly because ICC
performed surprisingly poorly without IPO on a few) but at least on SPEC
2017, they were clearly better... with a caveat, see below my comment
about wrf.

With LTO/IPO, ICC can perform a few memory-reorg tricks that push them
quite a bit ahead of us but I'm not convinced they can perform these
transformations on much source code that happens not to be a well known
benchmark.  So I'd recommend always looking at non-IPO numbers too.

>
> I did a compare of SPEC 2017 rate using GCC 8.* (pre release) and
> a recent ICC (2018.0.128?) on my desktop (Xeon CPU E5-1650 v4).
> I used '-xHost -O3' for icc and '-march=native -mtune=native -O3'
> for gcc.

Please try with -Ofast too.  The main reason is that -O3 does not imply
-ffast-math and the performance gain from it is often very big (and I
suspect the 525.x264_r difference is because of that).  Alternatively,
if your own workloads require high-precision floating-point math, you
have to force ICC to use it to get a fair comparison.  -Ofast also turns
on -fno-protect-parens and -fstack-arrays that also help a few
benchmarks a lot but note that you may need to set large stack ulimit
for them not to crash (but ICC does the same thing, as far as we know).

>
> The int rate numbers (running 1 copy only) were not too bad, GCC was
> only about 2% slower and only 525.x264_r seemed way slower with GCC.
> The fp rate numbers (again only 1 copy) showed a larger difference, 
> around 20%.  521.wrf_r was more than twice as slow when compiled with
> GCC instead of ICC and 503.bwaves_r and 510.parest_r also showed
> significant slowdowns when compiled with GCC vs. ICC.
>

Keep in mind that when discussing FP benchmarks, the used math library
can be (almost) as important as the compiler.  In the case of 481.wrf,
we found that the GCC 8 + glibc 2.26 (so the "out-of-the box" GNU)
performance is about 70% of ICC's.  When we just linked against AMD's
libm, we got to 83%. When we instructed GCC to generate calls to Intel's
SVML library and linked against it, we got to 91%.  Using both SVML and
AMD's libm, we achieved 93%.

That means that there likely still is 7% to be gained from more clever
optimizations in GCC but the real problem is in GNU libm.  And 481.wrf
is perhaps the most extreme example but definitely not the only one.

Martin

Re: Gcc Plugin Api

[Martin Jambor]

Hi,

On Fri, Jun 15 2018, Shubham Narlawar wrote:
> Hello all, I have been figuring out to work on some project. So while
> searching I found GCC Plugin API project quite interesting.
> So, please can I get some more information and links about gcc Plugin API
> project.
> Can anyone help me please.

If you are referring to the Google Summer of Code project idea we have
on the wiki, the idea of the project is to create a nice semi-stable
and, above all, well-defined API for GCC plugins.  Currently, we just
export tons of internal functions in a semi-random fashion and plugins
use them directly.  The idea is to allow most, and eventually all,
plugins to do their work via an API that 1) would be easy to use for
people who know basics concepts of compilers but not about GCC
internals, 2) would allow almost any introspection (for extra
domain-specific warnings and analysis) and 3) also limited IL
modification to facilitate the most common instrumentation tasks.

Ideally, some existing plugins would be converted to the new API.  Over
the time, restrictions in point 3 above would be gradually alleviated
until the API is good for almost everyone.

At least that is my idea of the project,

Martin

Re: [GSOC] LTO dump tool project

[Martin Jambor]

Hi,

On Sun, Jun 17 2018, Hrishikesh Kulkarni wrote:
> Hi,
>
> I am trying to isolate the dump tool into real lto-dump tool. I have
> started with the copy of lto.c into lto-dump.c and done the
> changes to Make-lang.in and config-lang.in suggested by Martin (patch
> attached). However when I try to build, I get the following error:
>
> In file included from ../../gcc/gcc/lto/lto-dump.c:24:0:
>
> ../../gcc/gcc/coretypes.h:397:24: fatal error: insn-modes.h: No such
>
> file or directory
>
> compilation terminated.
>
>
> I am unable to find the missing dependencies and would be grateful for
> suggestions on how to resolve the issue.

insn-modes.h is one of header files which are generated at build time,
you will find it in the gcc subdirectory of your build directory (as
opposed to the source directory).

Martin

Google Summer of Code 2018: Call for mentors and ideas

[Martin Jambor]

Hi,

following a discussion at IRC about an upcoming deadline to register GCC
as an independent organization for Google Summer of Code 2018 (GSoC), I
have volunteered to serve as the org-admin for GCC if:

  - there is not another volunteer (so step up if you are!),

  - the community does not object (so let me and/or the steering
committee know if you think I am not the right person!), and

  - we have at least 4 good project ideas together(!) with willing
mentors by next Monday January 22 (the deadline is on Tuesday).  I
will be very happy if we have more.

There are project ideas on our GSoC wiki page
(https://gcc.gnu.org/wiki/SummerOfCode) but those are not associated
with a willing mentor and it is basically an idea dump, it is often not
clear how up to date the proposals are and often they are just a bit too
terse.

Therefore I would like to ask all seasoned GCC contributors who would
like to mentor a GSoC student to send a reply to this thread with their
idea for a project.  If you have an idea but you do not want to be a
mentor then I will consider it only if it is really interesting, really
specific (e.g. improving -O2 -g *somehow* is not specific) and I would
have to be reasonably confident I'd find a good mentor for it.  So far I
have the following ideas from the IRC discussion:

1) Jakub is willing to mentor (with someone from GDB but I reckon that
   we will find someone) a project implementing OMPD.

2) Martin Liška is willing to mentor either:
   2a) -fsanitize=type (He provided URL https://reviews.llvm.org/D32197
   but it gives me a 404 error) or its prototype, or
   2b) bash code completion like:
   http://blog.llvm.org/2017/09/clang-bash-better-auto-completion-is.html
   but frankly I am afraid it is too small to be a GSoC project, or
   2c) textual representation of LTO stream a.k.a. lto-dump tool

3?) Joseph Myers brought up idea to do "built-in functions for TS 18661
floating-point functions - which has the feature that there are a
lot of similar built-in functions for C99/C11 functions to serve as
a guide for how to implement things)" ...Joseph, would you be
willing to mentor it?

Please send me your idea for a project you'd like to mentor.  Also feel
free to comment on other proposals including those above.  I intend to
put successful project ideas from this thread into a prominent position
on the wiki page.  Remember, I want at least four plausible ones with
willing mentors until Monday, January 22nd 23:59 CET.

All sorts of information are available from the GSoC web page at
https://summerofcode.withgoogle.com/, for example guides for mentors are
at
https://developers.google.com/open-source/gsoc/resources/guide#mentor_manual

Thanks,

Martin

Re: Google Summer of Code 2018: Call for mentors and ideas

[Martin Jambor]

Hi,

On Thu, Jan 18 2018, Martin Liška wrote:
> On 01/17/2018 06:54 PM, Martin Jambor wrote:
>
...
>> 
>> 2) Martin Liška is willing to mentor either:
>>2a) -fsanitize=type (He provided URL https://reviews.llvm.org/D32197
>>but it gives me a 404 error) or its prototype, or
>>2b) bash code completion like:
>>http://blog.llvm.org/2017/09/clang-bash-better-auto-completion-is.html
>>but frankly I am afraid it is too small to be a GSoC project, or
>>2c) textual representation of LTO stream a.k.a. lto-dump tool
>
> If there's an interest, I can specify in more detail these topics.

First, we'll need (just) enough info to make the idea attractive for
students.  Then they will need to write a project proposal with
milestones and stuff
(https://google.github.io/gsocguides/student/writing-a-proposal).  I am
not sure how involved we will be at that point, but perhaps it is a good
idea to think about milestones anyway.

> Note that
> David Malcolm is also interested in 2b) and he's willing to be co-mentor.
> The topic 2b) can be enlarged to an overhaul of option handling, with possible
> rewritten of current AWK scripts.

I am still a bit sceptical about the b option.  IIRC there was an
objection on the IRC that rewriting AWK scripts would require extensive
testing in a wide variety of often obscure environments.  That may make
it ill-suited for GSoC.  But well... I am not strictly against it, but
we may need to set the expectations accordingly ...which may not make it
attractive neither for students not for Google.

Martin

Re: Google Summer of Code 2018: Call for mentors and ideas

[Martin Jambor]

Hi Joseph,

On Wed, Jan 17 2018, Joseph Myers wrote:
> On Wed, 17 Jan 2018, Martin Jambor wrote:
>
>> 3?) Joseph Myers brought up idea to do "built-in functions for TS 18661
>> floating-point functions - which has the feature that there are a
>> lot of similar built-in functions for C99/C11 functions to serve as
>> a guide for how to implement things)" ...Joseph, would you be
>> willing to mentor it?
>
> Yes, provided at least one other mentor is available as well as I may not 
> be around all the time during the GSoC period, including one of the 
> evaluation periods.

Thank you (but please think who that other mentor could be :-)

>
> (The outline I put on the wiki page is:
>
>   GCC supports built-in functions for math.h and complex.h functions in 
>   the C99/C11 standards (both folding calls for constant arguments, and 
>   expanding inline when the processor supports appropriate functionality). 
>   More such functions have been added in ISO/IEC TS 18661, supporting 
>   features of IEEE 754-2008. It would be useful to have built-in functions 
>   for those, both folding for constant arguments, and expanding inline 
>   where appropriate (e.g. for roundeven and the functions rounding result 
>   to narrower type, on some processors; roundeven can be inlined on x86 
>   for SSE4.1 and later, and the narrowing functions on IA64 and POWER8, 
>   for example). Existing built-in functions would provide a guide for how 
>   to do this.
>
> This project has the feature that there are lots of smaller subprojects 
> each of which would be a useful enhancement to GCC, so a student could 
> start off with e.g. roundeven built-in functions, closely following how 
> existing code handles round / floor / ceil / trunc, before going on to 
> more complicated functions such as the narrowing ones or the fromfp 
> functions - with scope for functions from TS 18661-3 and TS 18661-4 if 
> they run out of useful functions from TS 18661-1.  If a student were 
> interested I could provide more detailed lists of possible subprojects.)

That is a very nice feature indeed,

Martin

Re: Google Summer of Code 2018: Call for mentors and ideas

[Martin Jambor]

On Fri, Jan 19 2018, Martin Jambor wrote:
> Hi,
>
> On Thu, Jan 18 2018, Martin Liška wrote:
>> On 01/17/2018 06:54 PM, Martin Jambor wrote:
>>
> ...
>>> 
>>> 2) Martin Liška is willing to mentor either:
>>>2a) -fsanitize=type (He provided URL https://reviews.llvm.org/D32197
>>>but it gives me a 404 error) or its prototype, or
>>>2b) bash code completion like:
>>>
>>> http://blog.llvm.org/2017/09/clang-bash-better-auto-completion-is.html
>>>but frankly I am afraid it is too small to be a GSoC project, or
>>>2c) textual representation of LTO stream a.k.a. lto-dump tool
>>
>> If there's an interest, I can specify in more detail these topics.
>
> First, we'll need (just) enough info to make the idea attractive for
> students.  Then they will need to write a project proposal with
> milestones and stuff
> (https://google.github.io/gsocguides/student/writing-a-proposal).  I am
> not sure how involved we will be at that point, but perhaps it is a good
> idea to think about milestones anyway.
>
>> Note that
>> David Malcolm is also interested in 2b) and he's willing to be co-mentor.
>> The topic 2b) can be enlarged to an overhaul of option handling, with 
>> possible
>> rewritten of current AWK scripts.
>
> I am still a bit sceptical about the b option.  IIRC there was an
> objection on the IRC that rewriting AWK scripts would require extensive
> testing in a wide variety of often obscure environments.  That may make
> it ill-suited for GSoC.  But well... I am not strictly against it, but
> we may need to set the expectations accordingly ...which may not make it
> attractive neither for students not for Google.
>

Ah no, I confused myself.  That was Joseph's issue with the idea of
replacing libiberty with gnulib.  The problem with this one was getting
a consensus to move away from AWK to python which would introduce a new
dependency of the gcc project.  Someone experienced (and determined)
from the community would have to drive that decision, we may not expect
a newcomer, let a alone a student, to do it.

Sorry for the confusion,

Martin

Re: Google Summer of Code 2018: Call for mentors and ideas

[Martin Jambor]

Hi Joel,

On Wed, Jan 17 2018, Joel Sherrill wrote:
> On 1/17/2018 11:54 AM, Martin Jambor wrote:
>> Hi,
>> 
>> following a discussion at IRC about an upcoming deadline to register GCC
>> as an independent organization for Google Summer of Code 2018 (GSoC), I
>> have volunteered to serve as the org-admin for GCC if:
>> 
>>- there is not another volunteer (so step up if you are!),
>> 
>>- the community does not object (so let me and/or the steering
>>  committee know if you think I am not the right person!), and
>> 
>>- we have at least 4 good project ideas together(!) with willing
>>  mentors by next Monday January 22 (the deadline is on Tuesday).  I
>>  will be very happy if we have more.
>> 
>> There are project ideas on our GSoC wiki page
>> (https://gcc.gnu.org/wiki/SummerOfCode) but those are not associated
>> with a willing mentor and it is basically an idea dump, it is often not
>> clear how up to date the proposals are and often they are just a bit too
>> terse.
>
> I will put a plug for a GCC related project on the RTEMS wish list that
> is on our GSoC Open Projects list. It is part of a broader project.
> We need someone who understands gcov for. We would consider you a
> co-mentor but I think the support would be light. I think it would
> be better described as a subject matter expert helping on an issue.
>
> We have a tool that aggregates the output of simulator trace logs
> and generates coverage reports directly. It can also generate
> gcov output but there are some anomalies when gcov generates reports
> from our input that don't match the truth of the traces.
>
> We just need someone who can explain what is wrong so it can be fixed.

I see.  However, since this would be an RTEMs project from Google's
point of view, I would suggest that you then email your questions (or
requests for co-mentorship) to the gcc mailing list independently
(i.e. without my involvement) and CC the maintainers and people who have
touched the corresponding files a lot recently.  (Unless you think I
specifically can be of help somehow, of course).

Thanks,

Martin


>
>> 
>> Therefore I would like to ask all seasoned GCC contributors who would
>> like to mentor a GSoC student to send a reply to this thread with their
>> idea for a project.  If you have an idea but you do not want to be a
>> mentor then I will consider it only if it is really interesting, really
>> specific (e.g. improving -O2 -g *somehow* is not specific) and I would
>> have to be reasonably confident I'd find a good mentor for it.  So far I
>> have the following ideas from the IRC discussion:
>> 
>> 1) Jakub is willing to mentor (with someone from GDB but I reckon that
>> we will find someone) a project implementing OMPD.
>> 
>> 2) Martin Liška is willing to mentor either:
>> 2a) -fsanitize=type (He provided URL https://reviews.llvm.org/D32197
>> but it gives me a 404 error) or its prototype, or
>> 2b) bash code completion like:
>> 
>> http://blog.llvm.org/2017/09/clang-bash-better-auto-completion-is.html
>> but frankly I am afraid it is too small to be a GSoC project, or
>> 2c) textual representation of LTO stream a.k.a. lto-dump tool
>> 
>> 3?) Joseph Myers brought up idea to do "built-in functions for TS 18661
>>  floating-point functions - which has the feature that there are a
>>  lot of similar built-in functions for C99/C11 functions to serve as
>>  a guide for how to implement things)" ...Joseph, would you be
>>  willing to mentor it?
>> 
>> Please send me your idea for a project you'd like to mentor.  Also feel
>> free to comment on other proposals including those above.  I intend to
>> put successful project ideas from this thread into a prominent position
>> on the wiki page.  Remember, I want at least four plausible ones with
>> willing mentors until Monday, January 22nd 23:59 CET.
>> 
>> All sorts of information are available from the GSoC web page at
>> https://summerofcode.withgoogle.com/, for example guides for mentors are
>> at
>> https://developers.google.com/open-source/gsoc/resources/guide#mentor_manual
>> 
>> Thanks,
>> 
>> Martin
>> 

Re: Google Summer of Code 2018: Call for mentors and ideas

[Martin Jambor]

Hi,

On Thu, Jan 18 2018, Joseph Myers wrote:
> On Thu, 18 Jan 2018, Eric Gallager wrote:
>
>> Would it make sense to recycle old GSoC projects that never got
>> completed?

in principle that is definitely possible, but...

>>I'm wondering about the "replace libiberty with gnulib" one
>
> I'd like to see that finished, but I'm not convinced it makes a good GSoC 
> project, given how it involves tricky portability and build system issues 
> and the need to test for lots of different configurations including 
> Canadian crosses.  It would really need someone particularly interested in 
> that area, and a build machinery maintainer actively involved.
>

...Joseph's concern sounds very valid to me.

Martin

Re: Google Summer of Code 2018: Call for mentors and ideas

[Martin Jambor]

Hi Andi,

On Thu, Jan 18 2018, Andi Kleen wrote:
> Martin Jambor <mjam...@suse.cz> writes:
>>
>> Therefore I would like to ask all seasoned GCC contributors who would
>> like to mentor a GSoC student to send a reply to this thread with their
>> idea for a project.  If you have an idea but you do not want to be a
>> mentor then I will consider it only if it is really interesting, really
>> specific (e.g. improving -O2 -g *somehow* is not specific) and I would
>> have to be reasonably confident I'd find a good mentor for it.  So far I
>> have the following ideas from the IRC discussion:
>
> Here's an idea:
>
> 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.
>
> I'm not a seasoned gcc contributor, but would be willing to mentor
> such a project.
>

Thanks a lot, project noted, it is an interesting idea.  You are
definitely seasoned enough as far as I am concerned.

Martin

Re: Status of m32c target?

[Martin Jambor]

Hi,

On Fri, Jan 19 2018, Sandra Loosemore wrote:
> On 01/19/2018 10:14 AM, Jeff Law wrote:
>
>> cc0 needs to die.  That doesn't mean that any particular target needs to
>> be dropped -- it just  means that someone has to step forward to do the
>> conversion.
>
> Unifying two parallel threads:  might this be a good project for GSoC?

I have no idea how big the task would be but it seems it could be quite
difficult.  Therefore we would need an experienced and extraordinarily
willing to help mentor.

Martin

Re: Google Summer of Code 2018: Call for mentors and ideas

[Martin Jambor]

Hi,

On Wed, Jan 17 2018, Martin Jambor wrote:
> Hi,
>
> following a discussion at IRC about an upcoming deadline to register GCC
> as an independent organization for Google Summer of Code 2018 (GSoC), I
> have volunteered to serve as the org-admin for GCC if:
>
>   - there is not another volunteer (so step up if you are!),
>
>   - the community does not object (so let me and/or the steering
> committee know if you think I am not the right person!), and
>
>   - we have at least 4 good project ideas together(!) with willing
> mentors by next Monday January 22 (the deadline is on Tuesday).  I
> will be very happy if we have more.
>

I consider the above conditions fulfilled and have started applying.

Unfortunately, Google requires there are at least two org-admins for an
organization.  We need to an additional admin by 6pm CET, which is in a
little over 6 hours.  So, who would like to do this with me?  (We can
have up to five :-).

Since I have started this thread, I expect to do most of the
org-admining, so any additional admin should not have that much work
with it.  But they apparently want a back-up as they want a reply to any
inquiry they might have within 36 hours.

My apologies for finding out this late but I did go through various
documents about the program and the requirement was not listed there, it
only popped up half-way through the application.

Martin

Re: Google Summer of Code 2018: Call for mentors and ideas

[Martin Jambor]

Hi,

I am happy to announce that we were selected as a Google Summer of Code
2018 mentor organization.

At this point I am being asked to "invite mentors," so I will soon
invite all the people who have expressed interest in the January email
thread (or on IRC).

If anybody has an additional idea for a GSoC project, please share it
with us here and perhaps also add it to the Wiki page.

If anybody else thinks of being a mentor this year, please write me an
email, the sooner the better.  I suspect that a google account is
mandatory, though.

Any other ideas/comments/suggestions are also welcome.

Martin

Re: Google Summer of Code 2018: Call for mentors and ideas

[Martin Jambor]

Hi,

On Wed, Feb 14 2018, Janus Weil wrote:
> Hi Martin,
>
>> I am happy to announce that we were selected as a Google Summer of Code
>> 2018 mentor organization.
>
> good to hear!
>
>
>> At this point I am being asked to "invite mentors," so I will soon
>> invite all the people who have expressed interest in the January email
>> thread (or on IRC).
>>
>> If anybody has an additional idea for a GSoC project, please share it
>> with us here and perhaps also add it to the Wiki page.
>>
>> If anybody else thinks of being a mentor this year, please write me an
>> email, the sooner the better.
>
> I'd be happy to (co-)mentor any Fortran-related project, should one come up.

I have invited you to be a mentor.  If there is a fortran project or two
that you would especially like to see to be picked up this year, please
move it to the "Selected project ideas" on the GSoC wiki page.

Thank you,

Martin

Re: Google Summer of Code 2018: Call for mentors and ideas

[Martin Jambor]

Hi Christopher,

On Thu, Feb 15 2018, Janus Weil wrote:
> Hi Christopher,
>
> 2018-02-15 11:52 GMT+01:00 Christopher Dimech :
>> I am the administrator of GNU Behistun, a package designed
>> to image the internal constituents of the subsurface using seismic waves.
>> It is written in Fortran and uses gfortran. I am not sure how well you
>> think it fits in your GSoC project. Does related work under your proposal
>> have to focus on development of the gcc compiler itself, or would it also
>> allow work on peripheral associations.
>
> I don't quite think this is appropriate for GCC as a mentoring org. It
> might fit better under the "GNU" umbrella, which also seems to be a
> mentoring org in this year's GSoC and lists all kinds of GNU projects:
>
> https://www.gnu.org/software/soc-projects/ideas-2018.html

I completely agree with Janus.  I believe GNU project will accommodate
your needs better.

Thanks,

Martin

Re: GSoC

[Martin Jambor]

Hi Thejazeto,

I apologize for replying this late, I've been traveling and did not
manage to write to you earlier as a consequence.

On Wed, Feb 21 2018, Thejazeto Lhousa wrote:
> Hello,
>
> I went through the GSoC 2018 idealist and found 'Improving GCC
> Developer Documentation' to be interesting and feasible for me.
> But I am confused because I remember reading somewhere that
> documentation will not be accepted as a valid project for GSoC.
> Can anyone shed some light?

You are right, the rules do not allow documentation-only projects, thank
you very much for pointing this out. As Thomas pointed out, I have
corrected the wiki.

Moreover, I think that writing good internal documentation is actually a
fairly difficult task that is not really suitable for newcomers, because
it often takes quite some knowledge to understand all important caveats.

Nevertheless, if you are really interested in compilers in general and
GCC in particular, please not feel put off by this.  Check out and build
GCC (as described at https://gcc.gnu.org/install/) and experiment with
it a little, you may find it is not actually as hard as it seems.  Feel
free to ask for help here on the mailing list or on our IRC when you get
stuck, we are a friendly bunch that want to help beginners, even though
we are often busy.

If the scope of GCC still intimidates you (but we all struggle with it
sometimes, trust me), consider reaching out to Andi Kleen and discuss
his fuzzer project idea with him (he may tell you what to check out and
experiment with to get the feeling about the task at hand).

Thanks again for notifying us about the documentation and I hope that
you will eventually find a project you will enjoy,

Martin

Re: GSOC 2018 - Textual LTO dump tool project

[Martin Jambor]

Hello Hrishikesh,

I apologize for replying to you this late, this has been a busy week
and now I am traveling.

On Mon, Feb 19 2018, Hrishikesh Kulkarni wrote:
> Hi,
>
> I am Hrishikesh Kulkarni currently studying as an undergrad student in
> Computer Engineering at Pune University, India. I find compilers quite
> interesting as a subject,  and would like to apply to GSoC to gain some
> understanding of how real-world compilers work. So far, I have managed to
> build gcc and perform some simple tweaks to the codebase. In particular, I
> would like to apply to the Textual LTO dump tool project.
>

I must say I am impressed by the research you have already done.
Nevertheless, please note that Ray Kim has also expressed interest in
the project.  Martin Liska will be the mentor, so I will let him drive
the selection process.  On the other hand, Ray also liked another
project, so maybe he will pick that and everyone will be happy.

> As far as I understand, the motivation for LTO framework was to enable
> cross file interprocedural optimizations, and for this purpose an ipa pass
> is divided into following three stages:
>
>1.
>
>LGEN: The pass does a local analysis of the function and generates a
>“summary”, ie, the information relevant to the pass and writes it to LTO
>object file.

A pass might do that, but the output of the whole stage is not just the
pass summaries, it also writes the function IL (the function gimple
statements, above all) to the object file.

>2.
>
>WPA: The LTO object files are given as input to the linker, which then
>invokes the lto1 frontend to perform global ipa analysis over the
>call-graph and write optimized summaries to LTO object files
>(partitioning). The global ipa analysis is done over summary and not the
>actual function bodies.

Well... note that partitioning actually means dividing the whole
compiled program/library into chunks that are then compiled
independently in the LTRANS stage.  But you are basically right that WPA
does also do whole-program analysis based on summaries and then writes
its decisions to optimization summaries, yes.

>3.

>
>LTRANS: The partitions are read back, and the function bodies are
>reconstructed from summary and are then compiled to produce real object
>files.

Function bodies and the summaries are distinct things.  The body
consists of gimple statements and all the associated stuff (such as
types, so a lot of stuff), whereas when we refer to summaries, we mean
small chunks of data that interprocedural optimizations such as inlining
or IPA-CP scurry away because they cannot feasibly work on bodies of the
entire program.

But apart from this terminology issue, you are basically correct, at the
LTRANS stage, IPA passes apply transformations to the bodies according
to the optimization summary generated by the WPA phase.  And then, all
normal, intra-procedural passes and code generation runs.

>
>
> If I understand correctly, the motivation for textual LTO dump tool is to
> easily analyze contents of LTO object file, similar to readelf or objdump ?

That is how I understand it too, but Martin may have some further uses
in mind.

>
> Assume that LTO object file contains in pureconst section: 0b0110 (0b for
> binary prefix) corresponding to values of fs->pure_const_state and
> fs->state_previously_known.
>
> If I understand correctly, the output of dump tool should then be:
>
> pure_const pass:
>
> pure_const_state = IPA_PURE (enum value of pure_const_state_e corresponding
> to 0b01)
>
> state_previously_known = IPA_NEITHER (enum value of pure_const_state_e
> corresponding to 0b10)
>
> Is this the expected output of the dump tool ?

I think the tool would have to a bit more than just dumping summaries of
IPA passes.  I tend to think that the task should also include dumping
gimple bodies (but we already do that in GCC and so it should be mostly
easy) and also of types (that are merged as one of the first steps of
WPA and interesting things happen when mergingit does something
"interesting").  And perhaps quite a bit more.  Martin?

>
> I am reasonably familiar working with C, C++ and python. My prior
> experience includes opportunities to work in areas of NLP. Some of my
> accomplishments in the area include presenting project VicharDhara- A
> thought Mapper that was selected among top five ideas in Accenture
> Innovation Challenge among 7000 nationwide entries. My paper on this topic
> won the best paper award in IEEE Conference ICCUBEA-2017. My previous work
> was focused on simple parsers, student psychology, thought process
> detection for team selection.

Interesting, congratulations.

>
> In the interim, I have been through a few docs on GCC and LTO [1][2][3] and
> am trying to write a toy ipa pass to better understand LTO/IPA
> infrastructure. 

Great, I believe that's exactly what my advice would be

> I would be grateful for feedback on the textual LTO dump
> tool.

I hope that Martin 

Re: RTL compression in GCC

[Martin Jambor]

Hello Alfonso,

On Sat, Aug 18 2018, ALFONSO LUIS CASTANO MARIN wrote:
> Dear Martin,
>
> I am interested in contributing to GCC to speed-up the compiler and I
> thought that the issues related with RTL are very interesting. I wonder if
> still there has not been done any job in RTL compression and if you could
> point me to someone how could give me some hints about how to contribute in
> this.

I suggest you discuss any GCC development ideas on the mailing list
gcc@gcc.gnu.org

As far as RTL compression is concerned, I do not remember it being
discussed or proposed before.  From what I can tell, we are not usually
looking at RTL memory footprint when dealing with excessive memory
consumption, one reason is likely that there is only one function in the
RTL representation at a time, as opposed to the whole compilation unit
in GIMPLE.  Others will surely correct me if I am wrong, however, and
may even suggest other areas where compilation speed could be improved.

Thanks,

Martin

Re: Google Summer of Code 2018: Call for mentors and ideas

[Martin Jambor]

Hi,

On Tue, Jan 23 2018, Prathamesh Kulkarni wrote:
> On 23 January 2018 at 16:26, Martin Jambor <mjam...@suse.cz> wrote:
>> Hi,
>>
>> On Wed, Jan 17 2018, Martin Jambor wrote:
>>> Hi,
>>>
>>> following a discussion at IRC about an upcoming deadline to register GCC
>>> as an independent organization for Google Summer of Code 2018 (GSoC), I
>>> have volunteered to serve as the org-admin for GCC if:
>>>
>>>   - there is not another volunteer (so step up if you are!),
>>>
>>>   - the community does not object (so let me and/or the steering
>>> committee know if you think I am not the right person!), and
>>>
>>>   - we have at least 4 good project ideas together(!) with willing
>>> mentors by next Monday January 22 (the deadline is on Tuesday).  I
>>> will be very happy if we have more.
>>>
>>
>> I consider the above conditions fulfilled and have started applying.
>>
>> Unfortunately, Google requires there are at least two org-admins for an
>> organization.  We need to an additional admin by 6pm CET, which is in a
>> little over 6 hours.  So, who would like to do this with me?  (We can
>> have up to five :-).
> If it's OK, I can volunteer to be backup admin.
>

I was happy to accept both this offer from Prathamesh and another one
from Honza and put down both as a co-org-admins and submitted our
application.  We'll be notified before February 12th whether we were
accepted.

I'll update the wiki with the new ideas tomorrow.

Thanks,

Martin

Re: Regarding Google summer of code.

[Martin Jambor]

Hello Chaitanya,

On Fri, Mar 02 2018, Sai Chaitanya wrote:
> Hello,
> I am Chaitanya.while checking the organisation for GSOC I am very
> confused,sir I have skills in C,C++, Java and little bit of python,till now
> I didn't take part in any big projects.
> Please guide me which organisation and which project suitable for me.
>

you have reached out to developers of GNU Compiler Collection (GCC).  I
am afraid that we are unable to help you with picking the most suitable
GSoC mentor organization, for many reasons.  If you are thinking of
applying to do a GSoC project with us, look at our dedicated wiki page
https://gcc.gnu.org/wiki/SummerOfCode

If you are still interested after reading through it, I suggest that you
check out our sources (https://gcc.gnu.org/svn.html,
https://gcc.gnu.org/wiki/GitMirror), build the compiler (look at steps
referenced from https://gcc.gnu.org/install/), look around the code a
bit and then come back to us with specific questions (and ideally at
least an idea for the project).

Good luck,

Martin

Re: Further for GSoC.

[Martin Jambor]

Hello, Tejas,

On Fri, Mar 02 2018, Joseph Myers wrote:
> On Fri, 2 Mar 2018, Tejas Joshi wrote:
>
>> I have some university level experience of working and programming assembly
>> language under Intel 80386DX architecture. I think it may help for
>> implementing supports for other architectures. Just for start, you
>> mentioned roundeven function as a guide for start. Where can I find these
>> (e.g. real.c) .c files for detailed study of these functions so that I can
>> have broader scenario? I have GCC 7.2.0 installed and could not find it in
>> library nor in libc/.
>
> You need to check out the GCC source code from version control and find 
> the files and functions referenced in there (locating pieces of GCC code 
> using find, grep, etc. on the GCC source tree is something you'll need to 
> do a lot), and make sure you can build GCC, run the testsuite, save 
> results from a testsuite run, build and run the testsuite and compare the 
> results of the two runs (this is something that would need doing very many 
> times in the course of any project working on GCC).
>

You might have figured this out already but just in case something is
not clear:

  1. How to check out our sources using svn and git is described at
https://gcc.gnu.org/svn.html and https://gcc.gnu.org/wiki/GitMirror
respectively, and

  2. perhaps more importantly, how to configure, build and test GCC is
described in steps linked from https://gcc.gnu.org/install/ (look
for --disable-bootstrap, among other things).

If you have any specific question regarding any of these steps, feel
free to ask on the mailing list or the IRC.

Good luck,

Martin

Re: GCC GSOC Participation

[Martin Jambor]

Hello Prateek,

On Sat, Mar 03 2018, Prateek Kalra wrote:
> Hello GCC Community,
> My name is Prateek Kalra.I am pursuing integrated dual
> degree(B.tech+M.tech) in Computer Science Software Engineering,from Gautam
> Buddha University,Greater Noida.I am currently in 8th semester of the
> programme.
> I have experience in competitive programming with C++.Here's my linkedin
> profile:
> https://www.linkedin.com/in/prateek-kalra-6a40bab3/.
> I am interested in GSOC project "Implement a fuzzer leveraging GCC
> extensions".
> I had opted compiler design as one of the course subjects in the previous
> semester and was able to secure an 'A' grade at the end of the semester.
> I have theoretical knowledge of fuzz testing and csmith,that how the random
> C programs are generated to check the compiler bugs and I am very keen to
> work under this project.
> I request you to guide me to progress through the process.I would really
> appreciate if you could mentor me with the further research of this project
> idea.

I would suggest that you start with reading through Andi's email to
another student who expressed interest in that project which you can
find at: https://gcc.gnu.org/ml/gcc/2018-02/msg00216.html

Andi, do you have any further suggestions what Prateek should check-out,
perhaps build, examine and experiment with in order to come up with a
nice proposal?  Do you personally prefer starting with any particular
existing fuzzer, for example?

Good luck,

Martin

Re: Queries on GSoC project on OMPD interface

[Martin Jambor]

Hello Siyuan,

On Mon, Mar 12 2018, LIU SIYUAN wrote:
> Dear all,
>
> Hi, my name is Siyuan and this is my first time using the GCC mailing list!

Welcome!

>
> I’m a senior CS student from Nanyang Technological University, Singapore who 
> is interested in the GSOC project related to OMPD.
>
> I personally have experience in C/C++ (development and performance 
> optimization). I have also taken compiler course and implemented a 
> mini-compiler (https://github.com/koallen/mini-go).
>
> I participated in student cluster competitions so I also have experience in 
> parallel computing (OpenMP, CUDA, MPI, etc.). And that’s why I’m particularly 
> interested in the OMPD project.
>
> Could you give me further information if I’m intending to apply for GSoC for 
> this project?

We can, but what kind of information are you looking for?

First and foremost, please get GCC sources and make sure you can build
GCC from them and then run the testsuite.  If you need it, the following
links should help you:

  - How to check out our sources using svn and git is described at
https://gcc.gnu.org/svn.html and https://gcc.gnu.org/wiki/GitMirror
respectively.

  - Steps linked from https://gcc.gnu.org/install/ show you how to
configure, build and test GCC is described in (look for
--disable-bootstrap, among other things).

  - You may also want to look at https://gcc.gnu.org/wiki/InstallingGCC
and https://gcc.gnu.org/wiki/GettingStarted wiki pages.

For the OMPD task, you will primarily want to look at the OMP run-time
that is in the libgomp subdirectory (and on the libgomp.exp part of the
testsuite).  You will probably also want to have a look at how to build
GDB.

The OMPD itself is described in the latest TR of the upcoming version of
the OpenMP standard:
http://www.openmp.org/wp-content/uploads/openmp-TR6.pdf

I assume that once you familiarize with the standard and look at how the
OpenMP run-time is organized (at least roughly), you will want to reach
out to Jakub (CCed) to figure out how to structure your work.

Good luck!

Martin

Re: GSoC (Making C++ concepts conform to the current standard)

[Martin Jambor]

Hello Maria,

On Wed, Mar 14 2018, Maria Kalikas wrote:
> Hello anyone this concerns,
>
> My name is Maria Kalikas and I am a senior majoring in Computer Science at
> The University of Akron.
>
> My familiarity and continuous reading of the C++ Standard has encouraged me
> to extend the previously developed support for concepts in GCC. I want to
> modify the implementation to conform with the current specification in the
> C++ Standard. I am curious to know if this would be a good project to
> propose for Google Summer of Code and am interested in finding a mentor.

I personally do not know what the status of C++ concept implementation
is, how much it differs from the current standard is or whether making
it more up to date would make a good GSoC project.  Jason, Nathan, what
do you think?  (And if so, would you be willing to be a mentor?  Can you
think of someone else?)

Martin

>
>  I took a Compiler Design course in Spring 2017 where I designed a compiler
> for a C-like programming language. My implementation is written in C++.
> Since completing the course, I became familiar with Clang and LLVM and am
> currently completing a capstone project where I am creating a virtual
> machine to implement the C++ abstract machine using LLVM instructions and
> rewriting the conversions, expressions and declarations specified in the
> C++ Standard as three address code instructions.
>
> I look forward to any responses and feedback.
>
> Thank you,
>
> Maria Kalikas

Re: GSoC (Improvements to GCC on Windows)

[Martin Jambor]

Hello,

On Tue, Mar 13 2018, Ko Phyo wrote:
> Hello
>
> I want to apply the project "Improvements to GCC on Windows" of GCC
> foundation. As a student, I have some theorectical knowledges about C/C++
> and compiler technologies. And I am sure that the Windows platform has
> steps that are little behind than other open source platforms in pure C/C++
> technology. So I decided to work on GSoC 2018 with your "Windows
> Improvement program". Please let me know if I am selected as a mentored
> student in yours great project. I will be waiting for your kind reply.

Well, please note that you still need to apply formally through the GSoC
website to stand a chance to be selected, that does not happen here.
We want students to contact us prior to applying so that their proposals
and goals make sense.

As far as improving GCC on Windows is concerned, we may find it
challenging to find you a mentor (I am CCing Jonathan Yong, the cygwin
and mingw-w64 maintainer, maybe he has an idea what could be done in
this area as a GSoC project and who might mentor it?).

Meanwhile, make sure you can build GCC from sources on Windows (I admit
I would not know how to do it myself!) and run the testsuite.

Good luck,

Martin

Re: GSoC

[Martin Jambor]

Hello Gurav,

On Thu, Mar 15 2018, Gaurav Ahuja wrote:
> I had a query, while choosing project for GSoC. Actually I'm
> contributing to GCC for the first time, and I am not sure about what
> is expected of me.
>
> So, can you please explain me about , what GCC organisation expects me
> to do, like detect bugs, or add a new feature ,etc.?

I am not sure I understand your question.  GCC as an GSoC organization
does not give prospective students any tasks they need to complete
before applying.  However, it is a good idea to at least check out,
build and test the compiler suite before you apply for a project with
us.  See the information at

   https://gcc.gnu.org/wiki/SummerOfCode#Before_you_apply

and generally speaking the entire wiki page on GSoC for what to do.

Martin

Re: about the gsoc

[Martin Jambor]

Hello Jagmeet, 

On Wed, Mar 07 2018, Jagmeet Singh wrote:
> Any one for help me
>
> I want to ask question about the ideas
>
> reply please

please ask your question directly to this mailing list
(gcc@gcc.gnu.org).

Martin

Re: eliminate dead stores across functions

[Martin Jambor]

Hi Bin,

On Tue, Mar 06 2018, Bin Cheng wrote:
> On Tue, Mar 6, 2018 at 2:28 PM, Richard Biener
>>
>> Do you think the situation happens often enough to make this worthwhile?
> There is one probably more useful case.  Program may use global flags
> controlling
> how it does (heavy) computation.  Such flags are only set couple of
> times in execution
> time.  It would be useful if we can (IPA) propagate flags into computation 
> heavy
> functions by versioning (if necessary).  For example:
>
> int flag = 1;
> void foo ()
> {
>   //heavy computation wrto to flag
> }
> void main()
> {
>   flag = 2;
>   foo();
>   flag = 1;
>   foo();
> }
>

So basically IPA-CP done on (not-addressable) static global variables.
Do you happen to know some real code which would benefit?  I'd like to
experiment with it but would like to have a real thing to look at, as
opposed to artificial test cases.

Thanks,

Martin

Re: GSOC

[Martin Jambor]

Hello Prashant,

On Thu, Mar 08 2018, prashant kumar wrote:
> Hello sir my self *Prashant kumar *second year B.TECH student and i am
> interesting in *"GCC plugin Api" *project .i have a good hand in c,c++
> languages .Can u tell me what the further process i have to do and what
> kind of thing i have to do

first and foremost, please discuss any GSoC idea or topic, use the
gcc@gcc.gnu.org mailing list (CCed), this way other people may also
participate in the discussion which will eventually help you as well.
Moreover, in your particular case, you sent me your message while I was
on vacation and so it took quite some time before I got to replying.
Other members of the GCC community might have done that meanwhile.

The aim of the gcc API project would be to start building a real GCC API
for plugins, so that simple but already useful plugins (operating on
GIMPLE level) could be written that use only this API (as opposed to the
current state where they can - actually they have to - use any normal
public symbol there is in GCC.  I do not think it is reasonable to
attempt make the API really entirely compiler agnostic but whenever
practical, the interface should be built on top of generic compiler
constructs (e.g. statements and operands as opposed to gimple and
trees), for many reasons.

In the first half of the project one would aim to build various dumping
plugins... that would simply dump CFG, statements and perhaps also some
information about types queried through the new interface.  In the
second half, you should try to rewrite some existing simple plugins
using this API (such as https://pagure.io/funcp-encrypt that is
described at
https://developers.redhat.com/blog/2017/03/17/diagnosing-function-pointer-security-flaws-with-a-gcc-plugin/
or perhaps the structleak_plugin.c kernel GCC plugin or
https://rwmj.wordpress.com/2016/02/24/playing-with-gcc-plugins/ though I
have not had a very close look any of those).

If you are interested, make sure you can check out the GCC trunk source
code, can build GCC from it.  The following links should help you:

 - How to check out our sources using svn and git is described at
   https://gcc.gnu.org/svn.html and https://gcc.gnu.org/wiki/GitMirror
   respectively.

 - Steps linked from https://gcc.gnu.org/install/ show you how to
   configure, build and test GCC is described in (look for
   --disable-bootstrap, among other things).

 - Also make sure you also look at https://gcc.gnu.org/wiki/InstallingGCC and
   https://gcc.gnu.org/wiki/GettingStarted wiki pages.

And while you are at it, try also to look at the source.  But you have
gone through all of the above and still find a little bit intimidating
or difficult to see where to start looking, do not despair.  That is
something the mentors and the community at large are willing to help
you with.

Regarding plugins, I'd suggest reading one ore more tutorials on their
current implementation
(e.g. http://thinkingeek.com/2015/08/16/a-simple-plugin-for-gcc-part-1/)
and then look at some real plugins to get the sense of what would need
to be APIzied.

Good luck,

Martin

GSoC 2018: Hrishikesh Kulkarni has been selected to work on LTO dumping tool

[Martin Jambor]

Hello,

I am pleased to announce that Hrishikesh Kulkarni will be working on
"Textual Representation of LTO Object Files (Textual LTO dump tool
project)" as his Google Summer of Code 2018 project.  I believe I write
on behalf of everybody in the GCC community when I congratulate him and
wish him success in the upcoming work.  Hrishikesh's mentors are Martin
Liška and Jan Hubička, but the plan is to have most of the conversation
about the project on the mailing list and so I would like to encourage
everyone to help him out here if they can.

According to the schedule of GSoC, we have entered "Community Bonding
period" which lasts until May 14th (when the first out of three "coding"
periods begin).  Hrishikesh, Martin and Honza will take over from me in
suggesting what technical things you should study/play with, but I'd
like to request that you make sure you get an FSF copyright assignment
quickly (see https://gcc.gnu.org/contribute.html#legal).  David, I
assume that Hrishikesh does not have the assignment yet, can you please
send him the necessary forms?  Hrishikesh, please fill them is when you
get and send them to FSF.  If at any moment it will appear that the
process got stuck, please let me know sooner rather than later.

On a general note, GCC was given two student slots which we requested
after receiving two high-quality student proposals.  Unfortunately,
Sebastiaan has withdrawn from GSoC 2018 before selection was announced
and so we "only" have one student this year.

I'm looking forward to the new tool,

Martin

Re: Google Summer of Code 2018: Call for mentors and ideas

[Martin Jambor]

Hi,

I was wondering how much I should announce publicly about GSoC proposals
since students are not supposed to know in advance that we want any
particular one before they are officially accepted or not by google, but
I hope I will not overstep any line by saying the following:

(I am willing to invite any GCC contributer among the mentors, then you
can look at the proposals at the GSoC "dashboard" website.  You need
gmail account for that, however.)


On Thu, Mar 29 2018, Joseph Myers wrote:
> Now the student application deadline has, I understand, passed, how do we 
> go about collectively deciding which are the best proposals to request 
> slots for?

GCC has received 11 proposals for projects, but 7 of them were clearly
unsuitable (two were completely blank, one was a link to a live google
document with the string "WIP" in it, one contained only a short CV of
the applicants, one was three lines suggesting we use a "linked list"
and "hash tags" for memory management, there was also a proposal for
driver able to compile C and python in different sections of a single
file, and one proposal was just spam or an elaborate report on some past
java project, I cannot tell) and 2 were inferior to the point that I
also decided they should not be considered.  None of these two was
discussed on the mailing list and both were basically copied text from
an (outdated) wiki page.

The remaining two are strong candidates, both proposals were discussed
at length here on the mailing list and so I asked for two student slots.
My plan forward is basically to sincerely hope that we get two.  If we
get only one (IIRC we will know on April 10th), I will bring this
question up here (but let's just toss a coin in that case).

Generally speaking, I am somewhat disappointed that one or two topics
that were also discussed on the mailing list did not eventually turn up
among the proposals.  I should have probably pinged one student and
perhaps also two gcc developers a bit in order to make them come up with
something.  It also did not help that I was traveling to an important
meeting in the US last week (and I had much less time for email than I
thought I would).  Nevertheless, it is mostly students' responsibility
to come up with good projects and there is only so much we can do about
it.  However, if the community decides I should be the admin also next
year, I believe I will be able to organize it slightly better.

Martin

Re: GSOC proposal

[Martin Jambor]

Hello Ismael,

On Wed, Mar 21 2018, Ismael El Houas Ghouddana wrote:
> Dear Mr./Mrs,
>
> First of all, I really appreciate your time and attention. I am Ismael El
> Houas an aerospace engineer student with knowledge of Google Cloud Platform
> and I want to express my interest in working on your project.

I am sorry to reply only now, mainly because of traveling, I was not
reading my email in the second half of last week.  

>
> Secondly, I want to ask if I am still at a time to apply to this project,
> unfortunately, I was not aware of GSOC until yesterday. In the case, I am
> still able to apply for it, I will make the proposal as soon as possible.

Strictly speaking, the deadline is tomorrow, as decided by the GSoC
organizers.  If you have been working on a proposal despite not hearing
from us, we would sill like to see it and encourage you to submit it
before the deadline.  If you haven't, it is really getting rather late,
unless you have a very clear idea of what you want to do (in that case
we should still try!).

My apologies again for missing you message, I hope GSoC works out for
you one way or another.

Martin

RE: Google Summer of Code 2018: Call for mentors and ideas

[Martin Jambor]

Hi Sebastian,

On Tue, Apr 03 2018, Sebastian Peryt wrote:
> Hi Martin,
>
> Frankly speaking I believe that students who discussed topics on mailing list 
> might 
> eventually just decide that they were too challenging for them and also 
> competition 
> appeared too difficult. As far as I remember student can only pick few 
> organizations and 
> maybe they just decided to pick some other projects where they expected 
> higher chance 
> of success. After all, as you wrote, it is students work to come up with good 
> projects.
>
> Nevertheless, I'd suggest keeping discussions regarding GSoC projects, that 
> took place in 
> mailing list in wiki (as a summary or direct links) for future reference if 
> someone would 
> like to better understand how some elements work in GCC or would like to 
> continue those works. 
> Without any external link I'm afraid it might get lost in the mailing list 
> soon.

I have pointers to the most important threads in my notes.  I will
put them onto the wiki when I'll reorganize it after this GSoC year or
before the next one starts.  Hopefully by that time we will have two
successful projects.

>
> From my personal point of view I think you did a great work with handling all 
> communication 
> regarding GSoC participation and I believe you are a perfect candidate for 
> admin role next year.

Thanks a lot,

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: 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]

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

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: [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

[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 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: 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 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: 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 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]

[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

Re: GCC GSOC 2019

[Martin Jambor]

Hello Shubham,

On Fri, Mar 29 2019, Shubham Narlawar wrote:
> Hi, here is my proposal for the above idea. Please review and suggest
> necessary changes.
>
> https://docs.google.com/document/d/11MNhuuD7dbwAfSW6ZgFrAys9My1Lw1PuMVcAqeNGr7A/edit?usp=sharing

I have had a quick look and the proposal seems very nice.

How did you select the attributes you want to implement in csmith?  It
is for example a little strange that you decided to include "pure" but
not "const."  If you handle visibility, you might as well consider
throwing in externally_visible too, I guess.  As a stretch goal, the
alias function attribute might be useful to exercise nasty paths in GCC
IPA optimizations.

I assume Andi Kleen has seen this proposal and if he is fine with it, so
am I. 

Thanks,

Martin

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

[Martin Jambor]

Hello Joshi,

On Mon, Apr 01 2019, sameeran joshi wrote:
> HI,
> Discussing the project with Andi, I have drafted a proposal, please
> review and suggest
> necessary changes.
> If some OpenMP experts from GCC have some ideas or changes please suggest.
>
> https://docs.google.com/document/d/1axElw-I5pTwcjI4iMle5NhLeRCcshIjH5ZHm3GGwsZU/edit?usp=sharing

I will leave most of the evaluation on Andi (and assume he likes the
proposal, by the way).  However, I have read the proposal, I like it and
I consider it very useful but also possibly quite ambitious.  But we can
adjust expectations as we go forward.

Please consider fixing some of the formatting in the document,
especially of the code snippets, sometimes they are a bit difficult to
read without any indentation.  That may be also the reason why I don't
quite understand what is the relationship of omp tasks and loops or
uninitialized local arrays.

But apart from that it is nice, thanks for applying,

Martin

Re: GSoC OMPD

[Martin Jambor]

Hello Bryan,

On Wed, Apr 03 2019, Bryan Carroll wrote:
> Hi,
>
> I know my first email is vague. I wanted to throw it out there since
> the April 9th deadline is coming up.

I was hoping Jakub Jelinek, who would be the mentor, would chime in
earlier.  But unfortunately he has probably not been online in the past
few days.  (And I admit I struggle a little bit to answer all GSoC email
in a timely manner this week too).

> So far, I've built gcc several
> times. I downloaded the gcc source code. Also I compiled a program
> with the -fdump options and looked through the files.

Good.

> I've been using
> gcc for a few years now for projects.. If you think that OMPD will too
> much for a first time GCC developer, I'm willing to try for a
> different project.

More on OMPD below.  If you have not worked with OpenMP internals
before, OMPD is probably going to be a steep uphill struggle, even
drafting the proposal given how much time is left.  I believe the
"Bypass assembler when generating LTO object files" is much easier for a
complete newcomer (and so far other students showed little interest in
it).  You can try reaching out to Honza Hubicka (CCed) for further
guidelines (but remember to read the info on wiki including the linked
old patch).

>
> On Mon, Apr 1, 2019 at 2:05 PM Bryan Carroll  wrote:
>>
>> Hi,
>>
>> My name is Bryan Carroll and I'm a M.S. student in the Applied
>> Mathematics and Computer Science program at University of Central
>> Oklahoma. I'm interested in the OpenMP and GDB debugger project.
>>
>> A little bit about myself: I've been programming for about 6 years,
>> the majority of those years in C++ or C. Last year I started learning
>> about parallelization. I taught myself MPI and recently started
>> learning OpenMP. I have some experience with compiling - I'm taking a
>> Progamming Languages class right now.  The final project is an
>> assembler.
>>
>> I know how to debug programs. However, I don't really know much about
>> how debuggers work. I also don't really know about how OpenMP works
>> underneath the directives. I very much want to learn about these
>> topics. I'm very much willing to learn and think I could be of help to
>> this project.
>>
>> What I'd like to know and discuss: What other pre-requisites are there
>> other than those listed on the GNU GSoC page?

First and foremost, you'd need to read through and reasonably understand
the OMPD specification, which is in Chapter 5 of

https://www.openmp.org/wp-content/uploads/OpenMP-API-Specification-5.0.pdf

Then you would need to have some knowledge of how GCC handles OpenMP
programs (compile a simple one with -fdump-tree-all and look at the
dumps) and especially how the run-times work.  The run-time is in
subdirectory libgomp of the GCC source repository, you can start by
finding an entry point that interests you (that you can find for example
in the aforementioned dumps) and then just keep reading.  But there is a
fair amount to read.

I must say I myself do not know what GDB background would be necessary.
But probably just following the spec would be more than enough for a
GSoC projet.

>>Also what would the goals and timeline look like?

For this, especially the timeline, we probably need Jakub's input.  The
goal would be to implement a substantial portion of the spec, but I
cannot quickly provide any guidance about how time consuming different
parts are likely to be.

Good luck,

Martin

Re: GSoC

[Martin Jambor]

Hello Muhammad,

On Thu, Apr 04 2019, Muhammad Shehzad wrote:
> Hello GCC Community,
>
> For GSoC I Would love to work on "*Add new math.h and complex.h functions
> as built-ins*" project from given project ideas.

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 if you act really quicly, you
just have about time to switch and attempt a different project idea.

> I wanted to know which
> mailing list should I subscribe to?

This one.  And look at https://gcc.gnu.org/lists.html to find if perhaps
to some more.

>
> I also wanted to know If I have my own idea, I want to present, what steps
> should I follow?

Send it to this (gcc@gcc.gnu.org) mailing list (and remember to put GSoC
somewhere into the subject).

In any case, remember to read "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.

Good luck,

Martin Jambor

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

[Martin Jambor]

Hi,

On Wed, Apr 03 2019, sameeran joshi wrote:
> On 4/3/19, Martin Jambor  wrote:
>> Hello Joshi,
>>
>> On Mon, Apr 01 2019, sameeran joshi wrote:
>>> HI,
>>> Discussing the project with Andi, I have drafted a proposal, please
>>> review and suggest
>>> necessary changes.
>>> If some OpenMP experts from GCC have some ideas or changes please
>>> suggest.
>>>
>>> https://docs.google.com/document/d/1axElw-I5pTwcjI4iMle5NhLeRCcshIjH5ZHm3GGwsZU/edit?usp=sharing
>>
>> I will leave most of the evaluation on Andi (and assume he likes the
>> proposal, by the way).  However, I have read the proposal, I like it and
>> I consider it very useful but also possibly quite ambitious.  But we can
>> adjust expectations as we go forward.
>>
>> Please consider fixing some of the formatting in the document,
>> especially of the code snippets, sometimes they are a bit difficult to
>
> Thanks for pointing it, I have indented them.

Great, it indeed is now much better.

>
>> read without any indentation.  That may be also the reason why I don't
>> quite understand what is the relationship of omp tasks and loops or
>> uninitialized local arrays.
>
> I have removed the location to insert for OMP tasks at 'uninitialized
> local array initialization'.
> Only kept it for as it was getting more complex.
>
> 1. while loops
> 2. nested for loops

OK.

>
> If you could suggest which constructs do you feel more ambitious?, so

The one thing I am quite intrigued by is how exactly you will detect
data races, but I assume a conservative but useful approach will not be
too difficult to devise.

> I could work on it to modify them.

Don't worry about the remark too much.  The proposal looks solid.

Martin

Re: [GSoC] TySan

[Martin Jambor]

Hello,

On Wed, Apr 03 2019, Youssef Mohamed wrote:
> Hi,
>
> I hope you are healthy and all well
3>
> I was applying to GCC GSoC and I want to implement TySan in GCC

we are very happy to hear that you find contributing to GCC
interesting.  Unfortunately, I am quite confident that I will not be
able to find you a mentor for a TypeSanitizer project this year.

Please consider looking into other projects.

I'm sorry I don't have better news.

Martin


>
> I am very fluent with C (although i prefer lisp/scheme , but i used C way
> much more)
> I am good at C++  , Python and Java
> bash scripting and I know fair enough about GCC (using it ,about internals
> ;actually GCC internals are really the hugest so i would be lying if i said
> i know all of it, but i know fair enough)
>
> just btw i wanted to know if it was okay t read how TySan was implemented
> in LLVM (would there be any legal problem ?!)
>
> Thanks in advance for your time
> Looking forward to do something great with you
> My Best Wishes

Re: Google Summer of Code

[Martin Jambor]

Hi Supriya.

On Thu, Apr 04 2019, Supriya Palli wrote:
> Hello,
>
> My name is Supriya Palli and I am a first-year Computer Science B.S.
> student at Florida State University. I currently finishing up a C++ course
> in Object Oriented Programming and am looking for ways to continue my
> learning in C++ and other technologies over the summer. I noticed that some
> of the projects you have listed for Google Summer of Code include C++ as a
> skill, but I am not sure I would meet the other skill requirements. Are
> there any specific projects you would recommend for beginners? Or any
> projects I could contribute to outside of the Google Summer of Code program?
>

we are delighted you found contributing to GCC interesting.  On the
other hand, I am afraid you not only need fairly solid knowledge of
C/C++ to do that but also at least some rudimentary theoretical
background in the area of compilers.

Couple of days back another student asked for a textbook and I
recommended "Building an Optimizing Compiler" by Bob Morgan.  If you
read and understand it - or some other solid textbook on compilers - you
will be very well equipped for a GSoC with us... but not this year I am
afraid.

Good luck,

Martin Jambor

Re: GSOC

[Martin Jambor]

Hello,

On Sun, Apr 07 2019, ashwina kumar wrote:
> Hi ,
>
> While working I just figured out that -Wconversion is buggy. Please see the
> below code- -
>
> $ cat b.c
> #include 
>
> void main (void)
> {
> //contains build errors
> uint16_t x = 1;
> uint16_t y = 2;
> y += x;  /* contains error */
>
> }
>
> $ gcc b.c -Wconversion
> b.c: In function ‘main’:
> b.c:22:7: warning: conversion to ‘uint16_t {aka short unsigned int}’
> from ‘int’ may alter its value [-Wconversion]
>   y += x;  /* contains error */
>
> Please help me to know as an GSOC student can I work on this for this year
> to make -Wconversion more robust.

Unfortunately I am not quite sure what you think is a problem.  The
option -Werror warns "for implicit conversions that may alter a value."
In this case, the C language mandates that the addition is performed in
full integer type, which is then stored to a shorter type, which is a
conversion which may alter the value.  Thus the warning.

In this particular example the values are known constants and so one
could argue that the result of addition is known at compile not to
exceed the uint16_t range.  However, the infrastructure that would have
to be added to the C/C++ front-ends to perform such value tracking would
not be justified with this simple use-case - especially given that the
warning should be perfectly silence-able with an explicit conversion.

Therefore, we are very unlikely to accept such GSoC proposal, sorry.

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 for usage.I was actually
>> > experimenting a bit and went a 

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 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: 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

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 

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 

Re: dg-extract-results broken since rev 268511, was Re: Status of 9.0.1 20190415 [trunk revision 270358] on x86_64-w64-mingw32

[Martin Jambor]

Hi,

On Tue, Apr 16 2019, Jakub Jelinek wrote:
> On Tue, Apr 16, 2019 at 02:49:13PM +0200, Christophe Lyon wrote:
>> > I executed the dg-extract-results.sh manually in the gcc/testsuite
>> > directory after a complete testsuite run which didn't give the correct
>> > results. Rev. 240429 gives the expected results, where rev 268511 fails.
>> > I'm on windows using msys2 with bash 4.4.23.
>> >
>> > I'm bootsrapping at the moment but that's really slow on windows. When
>> > the testsuite run is finished I try to assemble a reproducer. This will
>> > take a while.
>> >
>> 
>> OK, thanks! Do you mean the problem happens on Windows only?
>
> It is not on Windows only, I e.g. see the same problem on Linux too,
> unfortunately only when doing package builds.
>
> E.g.
> https://kojipkgs.fedoraproject.org//work/tasks/3883/34193883/build.log
> In the ===TESTING=== section where it emits result of contrib/test_summary
> the results look reasonable (though, the ordering looks random-ish even
> when it is always LC_ALL=C, so if there are multiple FAILs, diffing them
> from one build to another has -FAIL and +FAIL lines for the same tests),
> but if you uudecode the file (with more recent uudecode one needs to extract
> the begin ... end part manually, what a progress :( ) in the tarball any
> *.log files changed with dg-extract-results.py contain just Running lines
> and no further details.  Others like libgomp.log are complete, but those are
> not merged.  I get those almost empty *.log files even after
> rm -f contrib/dg-extract-results.py
> (which should force the *.sh version).
>
> I can't reproduce this on my Fedora 29 x86_64-linux bootstrap box though,
> the *.log files are complete there.
>

My experience might be completely unrelated, but I was getting empty
*.sum files (the big merged ones) - and I believe also empty .log files
but I am not longer sure - on a big Linux machine where a lot people
build stuff and the reason was that I was hitting some maximum cgroup
PID number limit that SUSE systemd invented for me/us in:

   /sys/fs/cgroup/pids/user.slice/user-$UID.slice/pids.max

After setting that to "max" the problems never again materialized.  In
any event, it is worth checking whether some system limits do not
prevent spawning new processes, I believe there were messages about it
extractable from logs (or rather journalctl).

Martin

Re: About GSOC.

[Martin Jambor]

On Thu, May 30 2019, Segher Boessenkool wrote:
> On Thu, May 30, 2019 at 07:08:45PM +0200, Martin Jambor wrote:
>> Interesting, I was also puzzled for a moment.  But notice that:
>> 
>> int main ()
>> {
>> _Float128 x = 18446744073709551617.5f128;
>> _Float128 y = __builtin_roundf128 (x);
>> }
>> 
>> behaves as expected... the difference is of course the suffix pegged to
>> the literal constant (see
>> https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/Floating-Types.html).
>> 
>> I would also expect GCC to use a larger type if a constant does not fit
>> into a double, but apparently that does not happen.  I would have to
>> check but it is probably the right behavior according to the standard.
>
> 6.4.4.2/4: "An unsuffixed floating constant has type double."  I don't
> think your suggestion would be okay?

Sorry if I was not clear but I was definitely not suggesting that we
change this (or anything).  I wrote that I was also surprised but
believed that GCC was doing the correct thing.

Thanks for pointing out where exactly the standard says what has to be
done though.

Martin

Re: [GSoC'19, libgomp work stealing] baseline benchmark results

[Martin Jambor]

Hi,

On Thu, May 30 2019, 김규래 wrote:
> ​Hi everyone,
> Just wanted to share some quick baseline benchmark results [3].
> I ran LU decomposition on a AMD Ryzen Threadripper 1950x 16C/32T system.
> LAPACK is currently plain loop parallel BLAS as far I believe.
> And the upstream version of PLASMA uses OpenMP tasks [1].
> The colored region is the 95% confidence interval.
> Task parallelism seems to scale pretty well on such a small scale benchmark.
> I hope work-stealing could improve this even more.
> An
>  
> Ray Kim
>  
> [1] YarKhan, Asim, et al. "Porting the PLASMA numerical library to the OpenMP 
> standard." International Journal of Parallel Programming 45.3 (2017): 612-633.
> [2] https://bitbucket.org/icl/plasma/src/default/
> [3] Link to benchmark plot: https://m.imgur.com/ysxs5ol

This last link leads to some sort of Error 404 page of imgur, or at
least that's how I understand it.  Maybe you have not copy'n'pasted the
whole address?

Thanks,

Martin

Committing patches and other conventions (Was: Re: About GSOC)

[Martin Jambor]

Hi,

On Mon, Jun 03 2019, Tejas Joshi wrote:
> Hello.
> I have already sent a patch for roundeven implementation but I do not
> know how do I commit my changes to GCC. Am I supposed to create a
> branch or anything etc?

You don't have to create a branch unless you think it would make ease
your own workflow.  Once a patch is ready to go and has been explicitely
approved by a corresponding maintainer, you will be expected to commit
it directly to svn (we'll ask for a svn write access for you when we get
to that point).  You'll find the list of maintainers in the MAINTAINERS
file of the gcc repository, I believe your patches will need approval
from a global reviewer, most probably Joseph.

Before that happens, the code must be of course considered correct but
also must adhere to some conventions, please see
https://gcc.gnu.org/codingconventions.html.  Your patches so far lacked
a ChangeLog and testcases.  Have a look at what other do when they post
patches to gcc-patches: https://gcc.gnu.org/ml/gcc-patches/2019-06/

ChangeLog has to have the given, fairly strict format, but should be
very brief.  When posting patches, you don't make it part of the patch
even though when committing, you are expected it to prepend the
corresponding ChangeLog file with your bit (see e.g. gcc/ChangeLog and
gcc/testsuite/ChangeLog).

You have always stated how you tested your patches but you are actually
supposed to add the testsuite and committed along with the functional
patch, so that other can then test they do not regress on the
functionality you have just added.

That is why everybody including you has to test their patches also by
doing:

make bootstrap
make -k check

(with a -j level appropriate for your computer) and then collect *.sum
files from unpatched and patched runs and compare them (see script in
contrib/compare_tests) to make sure they did not introduce any
regressions.

See section on "Testing patches" at https://gcc.gnu.org/contribute.html
for more details.

Please ask about these mechanisms and conventions if anything is not
clear.  I'll go and find the latest version of your roundeven patch and
see if I can help you a little (but I am likely to finish that only
tomorrow morning).

Thanks,

Martin

Re: About GSOC.

[Martin Jambor]

Hi,

On Thu, May 30 2019, Tejas Joshi wrote:
> Hello.
> I tried to check the values for significand words using _Float128
> using a test program with value larger than 64 bit.
> Test program :
>
> int main ()
> {
> _Float128 x = 18446744073709551617.5;   (i.e. 2^64 + 1.5 which is
> certainly longer than 64-bit)
> _Float128 y = __builtin_roundf128 (x);
> }

Interesting, I was also puzzled for a moment.  But notice that:

int main ()
{
_Float128 x = 18446744073709551617.5f128;
_Float128 y = __builtin_roundf128 (x);
}

behaves as expected... the difference is of course the suffix pegged to
the literal constant (see
https://gcc.gnu.org/onlinedocs/gcc-9.1.0/gcc/Floating-Types.html).

I would also expect GCC to use a larger type if a constant does not fit
into a double, but apparently that does not happen.  I would have to
check but it is probably the right behavior according to the standard.

>
> The lower words of significand (sig[1] and sig[0] for 64-bit system)
> are still being zero. I haven't included the roundevenf128 yet but
> inspecting this on real_round function.

I figured out what was going on when I realized that in your testcase,
sig[0] was equal to 0x8000 and so some precision has been
lost.  Then it was easy to guess that it was because it was represented
in a narrower type.

Hope this helps,

Martin

Re: Expanding roundeven (Was: Re: About GSOC.)

[Martin Jambor]

Hi,

On Fri, Jun 14 2019, Tejas Joshi wrote:
>> Of course the instruction is not present there, that is the next step in
>> your project :-)
>
> Yes, of course, but what I meant was that instructions for existing
> round/ceil functions and not roundeven. If inlining for these
> functions is available, how can I inspect such instructions getting
> inlined maybe in a *.s file?

Make sure you compile to a target that has the rounding instruction,
i.e. by using an appropriate -march or -mavx) and also specify
-ffast-math on the command line.  I have not double checked, but I
assume the latter is necessary (mainly) because it implies
-fno-math-errno and most of the math builtin expansion into instructions
is guarded by check for !flag_errno_math.

So e.g. my test input:

  double
  callplusone (double d)
  {
return __builtin_round (d) + 1;
  }

has vroundsd instruction in the output of:

  ~/gcc/trunk/inst/bin/gcc -O2 -S expand_example.c -mavx -ffast-math

>
> Also, I am trying to find appropriate places to introduce changes for
> roundeven to be inlined. Attached patch is what I have tried so far to
> find the places.

So far I only quickly glanced over it but it seems to be going in the
right direction.  I'll try to answer the rest of your questions as soon
as I can but I also have to look a bit into the machine descriptions
myself first.

Martin


> ix86_expand_roundeven have dummy code for the sake of time.
>
> In i386.md:
> 1. How should roundeven be defined at certain places where existing
> floor is defined as:
> (define_int_attr rounding_insn
> [(UNSPEC_FRNDINT_FLOOR "floor")
>
> 2. Also, can roundeven be handled like round_floor is handled by:
> (define_expand "2"
> but definitely with certain changes of flags, options and macros.
>
> Thanks,
> --Tejas

Re: Committing patches and other conventions (Was: Re: About GSOC)

[Martin Jambor]

Hi Tejas,

On Wed, Jun 12 2019, Tejas Joshi wrote:
> Hello.
> Is this the correct sequence for regression test:
> 1. Revert back all the changes I made and then configure, build along with
> make bootstrap
> make -k check
> collect the *.sum files
> 2. Apply the patch and do the configuration, build as above 1 and then
> collect the *.sum files and compare them.

Yes, exactly  (make sure to pass an appropriate -j parameter to make, of
course).

>
> How do I collect and inspect these *.sum files?

I collect *.sum files with a small script that internally simply does

  cp -vp `find . -name '*.sum' -print` $DEST_DIRECTORY

with different $DEST_DIR for pristine trunk and the patched version.

I admit I have my own script for comparing *.sum files but the usual way
is to use the compare_tests in the contrib directory, so for comparing
the old and new gcc.sum, you would do something like:

  ./src/contrib/compare_tests ../trunk/logs/gcc.sum logs/gcc.sum

with the directories matching your setup, of course.

Writing about scripts in contrib, you might also want to look at
check_GNU_style.sh and/or check_GNU_style.py.  They take a patch file as
they argument and check GNU style (things like two spaces after each
sentence, long lines, these tiny things where we still however try to be
consistent).  Of course, some of the errors given should be ignored,
in your case probably long lines in a *.def file.

Hope this helps,

Martin

Re: Expanding roundeven (Was: Re: About GSOC.)

[Martin Jambor]

Hi Tejas,

On Thu, Jun 13 2019, Tejas Joshi wrote:
> Hello.
> As further part of implementing roundeven is inlining, I was studying
> machine descriptions and I have a few questions.
>
> As suggested, builtin functions provided a strong model for
> implementing roundeven. Keeping that in mind, I tried to inspect how
> similar functions (round/ceil) would get inlined. As it is dependent
> on target machine, (mine is i7, so should be x86_64 ? I wonder why
> gcc/config/ does not have x86_64 or amd64 directory. Or is it i386
> itself as extended?),

Yes, the directory with x86_64 specific stuff is i386.

> should *.s file after compilation contain the
> specific instruction if supported? I was unable to see such kind of
> instruction on any -O level.
>

I am not sure I understand your question.  Yes, the intent is that when
the compiler cannot determine the argument of roundeven to be constant,
it should emit the instruction instead of a library call, if the target
architecture supports it.  (and if IIUC, the intent is to use the 0 mode
from table 4-8 in
https://software.intel.com/sites/default/files/managed/39/c5/325462-sdm-vol-1-2abcd-3abcd.pdf
in instructions that take a rounding a mode to implement roundeven).

Of course the instruction is not present there, that is the next step in
your project :-)

> Different pattern names are available for machine descriptions
> , also for
> round, ceil, etc. Will I have to add such pattern name for roundeven?
> (is it the same as optab defined in optabs.def?)

Yes.

Martin

Re: copyright assignment form

[Martin Jambor]

Hello,

On Sat, May 18 2019, David Čepelík wrote:
> Dear GCC devs,
>
> in accordance with [1] I'd like to ask you to provide me
> with the copyright assignment form (the "for all future
> changes" variant). I'll be submitting a larger patch soon.

I believe the right process is to 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.

--
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?]
--

I find the form quite a bit strange since it asks people about stuff
they already changed when without a copyright assignment they could not
have changed anything, but well...

Martin

Re: About GSOC.

[Martin Jambor]

Hello Tejas,

On Wed, May 08 2019, Tejas Joshi wrote:
> Hello.
> I can't figure out from the documentation how to add test cases in the
> testsuite and inspect the results. How can I do that? Although, Taking
> the mentioned conditions under consideration, I have made another
> patch, attached.

in addition to the things already pointed out by Joseph, I have the
following comments.  But as Joseph has already pointed out, you should
also test your patch on __float128 types, so please make sure your code
gets invoked and works for something like:

if (__builtin_roundevenf128 (0x1p64q+0.5) != (0x1p64q))
  link_error (__LINE__);


> diff --git a/gcc/builtins.def b/gcc/builtins.def
> index ef89729fd0c..e1d593a8765 100644
> --- a/gcc/builtins.def
> +++ b/gcc/builtins.def
> @@ -542,6 +542,9 @@ DEF_C99_BUILTIN(BUILT_IN_RINTL, "rintl", 
> BT_FN_LONGDOUBLE_LONGDOUBLE, AT
>  #define RINT_TYPE(F) BT_FN_##F##_##F
>  DEF_EXT_LIB_FLOATN_NX_BUILTINS (BUILT_IN_RINT, "rint", RINT_TYPE, 
> ATTR_CONST_NOTHROW_LEAF_LIST)
>  #undef RINT_TYPE
> +DEF_EXT_LIB_BUILTIN(BUILT_IN_ROUNDEVEN, "roundeven", 
> BT_FN_DOUBLE_DOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)
> +DEF_EXT_LIB_BUILTIN(BUILT_IN_ROUNDEVENF, "roundevenf", 
> BT_FN_FLOAT_FLOAT, ATTR_CONST_NOTHROW_LEAF_LIST)
> +DEF_EXT_LIB_BUILTIN(BUILT_IN_ROUNDEVENL, "roundevenl", 
> BT_FN_LONGDOUBLE_LONGDOUBLE, ATTR_CONST_NOTHROW_LEAF_LIST)

...and for the code to trigger for __builtin_roundevenf128 you have to
define this builtin function too.  The easiest way is to do it in the
same way it is done for BUILTIN_ROUND and many other functions, i.e. use
DEF_EXT_LIB_FLOATN_NX_BUILTINS.


> diff --git a/gcc/fold-const-call.c b/gcc/fold-const-call.c
> index 06a420601c0..7eafd91e9a2 100644
> --- a/gcc/fold-const-call.c
> +++ b/gcc/fold-const-call.c
> @@ -792,6 +792,14 @@ fold_const_call_ss (real_value *result, combined_fn fn,
>   }
>return false;
>  
> +case CFN_BUILT_IN_ROUNDEVEN:

If you look at other cases in this switch statement, they all use
CASE_CFN_* macros.  These the get expanded to all the type variants of
the builting function, so please do the same thing and replace the case
with

CASE_CFN_ROUNDEVEN:
CASE_CFN_ROUNDEVEN_FN:


> +  if (!REAL_VALUE_ISNAN (*arg) || !flag_errno_math)
> +  {

Make sure you set your editor to follow the GNU coding style.  The
horizontal position of the curly braces here is incorrect.  Insisting on
coding style details may sound like excessive nit-picking but in the
long run it makes the sources much more readable.

> +real_roundeven (result, format, arg);
> +return true;
> +  }
> +  return false;
> +
>  CASE_CFN_LOGB:
>return fold_const_logb (result, arg, format);
>  
> @@ -854,6 +862,9 @@ fold_const_call_ss (wide_int *result, combined_fn fn,
>return fold_const_conversion (result, real_round, arg,
>   precision, format);
>  
> +case CFN_BUILT_IN_ROUNDEVEN:

the comment about CASE_CFN_* macros applies here as well.

> +  return fold_const_conversion (result, real_roundeven, arg, precision, 
> format);
> +
>  CASE_CFN_IRINT:
>  CASE_CFN_LRINT:
>  CASE_CFN_LLRINT:
> diff --git a/gcc/fold-const.c b/gcc/fold-const.c
> index 59cedeafd71..30c409e95bf 100644
> --- a/gcc/fold-const.c
> +++ b/gcc/fold-const.c
> @@ -329,6 +329,7 @@ negate_mathfn_p (combined_fn fn)
>  CASE_CFN_LLROUND:
>  CASE_CFN_LROUND:
>  CASE_CFN_ROUND:
> +CASE_CFN_ROUNDEVEN:

and CASE_CFN_ROUNDEVEN_FN:

>  CASE_CFN_SIN:
>  CASE_CFN_SINH:
>  CASE_CFN_TAN:
> @@ -13060,6 +13061,8 @@ tree_call_nonnegative_warnv_p (tree type, combined_fn 
> fn, tree arg0, tree arg1,
>  CASE_CFN_RINT_FN:
>  CASE_CFN_ROUND:
>  CASE_CFN_ROUND_FN:
> +CASE_CFN_ROUNDEVEN:
> +CASE_CFN_ROUNDEVEN_FN:
>  CASE_CFN_SCALB:
>  CASE_CFN_SCALBLN:
>  CASE_CFN_SCALBN:
> @@ -13583,6 +13586,8 @@ integer_valued_real_call_p (combined_fn fn, tree 
> arg0, tree arg1, int depth)
>  CASE_CFN_RINT_FN:
>  CASE_CFN_ROUND:
>  CASE_CFN_ROUND_FN:
> +CASE_CFN_ROUNDEVEN:
> +CASE_CFN_ROUNDEVEN_FN:
>  CASE_CFN_TRUNC:
>  CASE_CFN_TRUNC_FN:
>return true;
> diff --git a/gcc/real.c b/gcc/real.c
> index f822ae82d61..045dc758048 100644
> --- a/gcc/real.c
> +++ b/gcc/real.c
> @@ -5010,6 +5010,53 @@ real_round (REAL_VALUE_TYPE *r, format_helper fmt,
>  real_convert (r, fmt, r);
>  }
>  
> +/* Return true if integer part of R is even, else return false. */

If the function is supposed to work only on integer values (encoded as
REAL_VALUE_TYPE) then please write that into the function comment.

> +
> +bool
> +is_even (REAL_VALUE_TYPE *r)
> +{
> +  unsigned int n = SIGNIFICAND_BITS - REAL_EXP (r);

Otherwise, if you really wanted to make it work on integer parts of any
real number, this is clearly wrong for any value smaller than 0.5
(i.e. when REAL_EXP (r) is negative).

> +
> +  unsigned long num = ((unsigned long)1 << (n % 

Re: GSoC'19 Thanks for acceptance

[Martin Jambor]

Hello Ray,

On Wed, May 08 2019, 김규래 wrote:
> Hi everyone,
> Thanks for accepting my proposal Implementing OpenMP Work Stealing
> Scheduling for GSoC 2019.  I'll do my best to accomplish the proposed
> goals.

Ii is a pleasure, we are looking forward to your contributions.

> Right now the semester hasn't ended so progress would be limited.
> However, I'll start working on the project as soon as the semester
> ends.

We are in the community bonding period right now so that should not be
any problem.  If your availability will be limited after May 28th,
please talk to Jakub so that he knows about it and you agree how to
handle/compensate for it.

> During the time being, any basic guidance related to contributing to
> GCC and the project would be much appreciated.

Please request a copyright assignment as described in
https://gcc.gnu.org/ml/gcc/2019-05/msg00067.html

Thank you,

Martin

GCC GSoC 2019 projects: announcement and a mandatory first step

[Martin Jambor]

[Sorry for a re-post, I forgot to write a subject and as a consequence
the email did not make it through to the mailing list]

Hello,

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

  - JeanHeyd Meneide will be working on improving libstdc++, focusing on
vector and related algorithms and data structures (see
https://gcc.gnu.org/ml/libstdc++/2019-02/msg4.html and the
ensuing thread for more details),

  - Tejas Joshi will be working on adding new builtins for math
functions introduced in IEC 18661 and thus exposing them to
optimizations,

  - Akshat Garg will be making sure that gcc/g++ do not automatically
promote memory_order_consume to memory_order_acquire,

  - Giuliano Belinassi will be parallelizing GCC with Threads, 

  - Khurai Kim will be working on implementing OpenMP Work Stealing
Scheduling scheduling options, and

  - Shubham Narlawar will be working on enabling generation of GCC
extensions by the CSmith fuzzer.

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

The GSoC program has now entered its "community bonding period" which
lasts until May 27th.  One of the most important things all accepted
students who are expected to contribute directly to GCC code base should
do in this time is to request a copyright assignment[1] as soon as you
can (i.e. everybody but Shubham who is however also invited to do so).

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.

--
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 or if you
encounter any issues and/or unreasonably long delays.

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.  Of course, you should get in
touch with your mentors unless you have already done so.  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 2019, 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: RFC on a new optimization

[Martin Jambor]

Hi,

On Tue, Jul 02 2019, Richard Biener wrote:
> On Mon, Jul 1, 2019 at 11:58 PM Gary Oblock  wrote:
>>
>> I've been looking at trying to optimize the performance of code for
>> programs that use functions like qsort where a function is passed the
>> name of a function and some constant parameter(s).
>>
>> The function qsort itself is an excellent example of what I'm trying to show
>> what I want to do, except for being in a library, so please ignore
>> that while I proceed assuming that that qsort is not in a library.  In
>> qsort the user passes in a size of the array elements and comparison
>> function name in addition to the location of the array to be sorted. I
>> noticed that for a given call site that the first two are always the
>> same so why not create a specialized version of qsort that eliminates
>> them and internally uses a constant value for the size parameter and
>> does a direct call instead of an indirect call. The later lets the
>> comparison function code be inlined.
>>
>> This seems to me to be a very useful optimization where heavy use is
>> made of this programming idiom. I saw a 30%+ overall improvement when
>> I specialized a function like this by hand in an application.
>>
>> My question is does anything inside gcc do something similar? I don't
>> want to reinvent the wheel and I want to do something that plays
>> nicely with the rest of gcc so it makes it into real world. Note, I
>> should mention that I'm an experienced compiler developed and I'm
>> planning on adding this optimization unless it's obvious from the
>> ensuing discussion that either it's a bad idea or that it's a matter
>> of simply tweaking gcc a bit to get this optimization to occur.
>
> GCC performs intraprocedural constant propagation (IPA-CP) and
> this should catch your case already.  The IPA-CP function cloning
> might have too constrained limits (on code bloat) to apply on a
> specific testcase but all functionality for the qsort case should
> be available.

At least in 505.mcf/605.mcf we do inline the comparator to the qsort
function - and in order to do that, IPA-CP actually creates two clones,
one for each of the two used comparators in the benchmark, see:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84149

I'll be happy to see any examples where it fails to do the right thing.

Martin

Re: How does one traverse all the global decls

[Martin Jambor]

Hi,

On Wed, Aug 21 2019, Gary Oblock wrote:
> I'm trying to do some analysis code for an optimization
> that involves my code looking at all the declarations and
> types there of during the link time optimizations.
>
> Note, doing this for the local variables seems to be trivial
> because of FOR_EACH_LOCAL_DECL and there are also
> obvious ways of getting at the type information once I have
> a decl. However,  I can't seem to find any similar way of
> getting at the global level decls.
>
> I'd appreciate your help on this.
>

Look at FOR_EACH_VARIABLE defined in cgraph.h (because symtab.h does not
exist) and it's various uses throughout the compiler.

Martin

Re: [PATCH] Builtin function roundeven folding implementation

[Martin Jambor]

Hi,

On Sun, Aug 25 2019, Tejas Joshi wrote:
> I have made the respective changes and fixed the indentations and it
> passes the testing.

Great, please send the patch (to me and to the mailing list too), so
that I can commit it.

Thanks,

Martin

Re: Expansion of narrowing math built-ins into power instructions

[Martin Jambor]

Hi,

On Sat, Aug 24 2019, Richard Sandiford wrote:
> Martin Jambor  writes:

...

>>
>> 2. direct_internal_fn_supported_p on which replacement_internal_fn
>>depends to expand built-ins as internal functions cannot handle
>>conversion optabs... and narrowing is a kind of conversion and the
>>optab is added as such with OPTAB_CD.
>>
>> Actually, the second statement is not entirely true because somehow it
>> can handle optab while_ult which is a conversion optab but a) the way it
>> is handled, if I can understand it at all, seems to be a big hack and
>> would be even worse if we decided to copy that for all narrowing math
>> functions
>
> Think "big hack" is a bit unfair.  The way that the internal function
> maps argument types to the optab modes, and the way it expands calls
> into rtl, depends on the "optab type" argument (the final argument to
> DEF_INTERNAL_OPTAB_FN).  This is relatively flexible in that it can use
> a single-mode "direct" optab or a dual-mode "conversion" optab, with the
> modes coming from whichever arguments are appropriate.  New optab types
> can be added as needed.

My apologies. I guess I should have been more careful with my choice of
words when perhaps I did not understand all aspects but when I saw:

#define direct_while_optab_supported_p convert_optab_supported_p

(and when I saw expand_while_optab_fn defined normally while all(?)
other were constructed in an elaborate macro), I thought that I did not
want to replicate the mechanism, not for a number of functions.

>
> FWIW, several other DEF_INTERNAL_OPTAB_FNs are conversion optabs too
> (e.g. IFN_LOAD_LANES, IFN_STORE_LANES, IFN_MASK_LOAD, etc.).
>
> But...
>
>> and b) it gets both modes from argument types whereas we need one from
>> the result type and so we would have to rewrite
>> replacement_internal_fn anyway.
>
> ...yeah, I agree this breaks the current model.  The reason IFN_WHILE_ULT
> doesn't rely on the return type is that if you have:
>
>   _2 = .WHILE_ULT (_0, _1) // returning a vector of 4 booleans
>   _3 = .WHILE_ULT (_0, _1) // returning a vector of 8 booleans
>
> then the calls look equivalent.  So instead we pass an extra argument
> indicating the required boolean vector "shape".
>
> The same "problem" could in principle apply to FADD if we ever needed
> to support double+double->_Float16 for example.

Right.  I hope not going through an internal function is acceptable.  If
not, we'll have to teach this builtin->internal_funcxtion->optab
mechanism about conversions.

Thanks,

Martin


>
>> Therefore, at least for now (GSoC deadline is kind of looming), I
>> decided that the best way forward would be to not rely on internal
>> functions but plug into expand_builtin() and I wrote the following,
>> lightly tested patch - which of course misses testcases and stuff - but
>> I'd be curious about any feedback now anyway.  When I proposed a very
>> similar approach for the roundeven x86_64 expansion, Uros actually then
>> opted for a solution based on internal functions, so I am curious
>> whether there are simple alternatives I do not see.
>>
>> Tejas, of course cases for other fadd variants should at least be added
>> to expand_builtin.
>>
>> Thanks,
>>
>> Martin
>>
>>
>> 2019-08-23  Tejas Joshi  
>>  Martin Jambor  
>>
>>  * builtins.c (expand_builtin_binary_conversion): New function.
>>(expand_builtin): Call it.
>>  * config/rs6000/rs6000.md (unspec): Add UNSPEC_ADD_NARROWING.
>>  (add_truncdfsf3): New define_insn.
>>  * optabs.def (fadd_optab): New.
>>

Re: Expansion of narrowing math built-ins into power instructions

[Martin Jambor]

Hello,

On Thu, Aug 22 2019, Segher Boessenkool wrote:
>> > Hi Tejas,
>> >
>> > [ Please do not top-post. ]
>
> On Thu, Aug 22, 2019 at 01:27:06PM +0530, Tejas Joshi wrote:
>> > What happens then?  "It does not work" is very very vague.  At least it
>> > seems the compiler does build now?
>> 
>> Oh, compiler builds but instruction is still "bl fadd". It should be
>> "fadds" right?
>
> Yes, but that means the problem is earlier, before it hits RTL perhaps.
>
> Compile with -dap, look at the expand dump (the lowest numbered one, 234
> or so), and see what it looked like in the final Gimple, and then in the
> RTL generated from that.  And then drill down.
>

Tejas sent me his patch and I looked at why it did not work.  I found
two reasons:

1. associated_internal_fn (in builtins.c) does not handle
   DEF_INTERNAL_OPTAB_FN kind of internal functions, and Tejas
   (sensibly, I'd say) used that macro to define the internal function.
   But when I worked around that by manually adding a case for it in the
   switch statement, I ran into an assert because...

2. direct_internal_fn_supported_p on which replacement_internal_fn
   depends to expand built-ins as internal functions cannot handle
   conversion optabs... and narrowing is a kind of conversion and the
   optab is added as such with OPTAB_CD.

Actually, the second statement is not entirely true because somehow it
can handle optab while_ult which is a conversion optab but a) the way it
is handled, if I can understand it at all, seems to be a big hack and
would be even worse if we decided to copy that for all narrowing math
functions and b) it gets both modes from argument types whereas we need
one from the result type and so we would have to rewrite
replacement_internal_fn anyway.

Therefore, at least for now (GSoC deadline is kind of looming), I
decided that the best way forward would be to not rely on internal
functions but plug into expand_builtin() and I wrote the following,
lightly tested patch - which of course misses testcases and stuff - but
I'd be curious about any feedback now anyway.  When I proposed a very
similar approach for the roundeven x86_64 expansion, Uros actually then
opted for a solution based on internal functions, so I am curious
whether there are simple alternatives I do not see.

Tejas, of course cases for other fadd variants should at least be added
to expand_builtin.

Thanks,

Martin


2019-08-23  Tejas Joshi  
Martin Jambor  

* builtins.c (expand_builtin_binary_conversion): New function.
  (expand_builtin): Call it.
* config/rs6000/rs6000.md (unspec): Add UNSPEC_ADD_NARROWING.
(add_truncdfsf3): New define_insn.
* optabs.def (fadd_optab): New.


---
 gcc/builtins.c  | 55 +
 gcc/config/rs6000/rs6000.md | 13 +
 gcc/internal-fn.def |  2 ++
 gcc/optabs.def  |  1 +
 4 files changed, 71 insertions(+)

diff --git a/gcc/builtins.c b/gcc/builtins.c
index 9a766e4ad63..a9bf5710834 100644
--- a/gcc/builtins.c
+++ b/gcc/builtins.c
@@ -2935,6 +2935,54 @@ expand_builtin_powi (tree exp, rtx target)
   return target;
 }
 
+/* Attempt to expand a builtin function call EXP which performs a binary
+   operation on its floating point arguments and then converts the result into
+   a different floating point format.  The operation in question is specified
+   in OP_OPTAB.  Return NULL if the attempt failed.  SUBTARGET may be used as
+   the target for computing the operand of EXP.  */
+
+static rtx
+expand_builtin_binary_conversion (tree exp, rtx target, rtx subtarget,
+ optab op_optab)
+{
+  if (TREE_CODE (TREE_TYPE (exp)) != REAL_TYPE
+  || !validate_arglist (exp, REAL_TYPE, REAL_TYPE, VOID_TYPE))
+return NULL_RTX;
+
+  tree arg0 = CALL_EXPR_ARG (exp, 0);
+  tree arg1 = CALL_EXPR_ARG (exp, 1);
+  gcc_assert (TYPE_MAIN_VARIANT (TREE_TYPE (arg0))
+ == TYPE_MAIN_VARIANT (TREE_TYPE (arg1)));
+  machine_mode arg_mode = TYPE_MODE (TREE_TYPE (arg1));
+  machine_mode res_mode = TYPE_MODE (TREE_TYPE (exp));
+
+  insn_code icode = convert_optab_handler (op_optab, res_mode, arg_mode);
+  if (icode == CODE_FOR_nothing)
+return NULL_RTX;
+
+  /* Wrap the computation of the arguments in a SAVE_EXPR, as we may
+ need to expand the argument again.  This way, we will not perform
+ side-effects more the once.  */
+  CALL_EXPR_ARG (exp, 0) = arg0 = builtin_save_expr (arg0);
+  CALL_EXPR_ARG (exp, 1) = arg1 = builtin_save_expr (arg1);
+
+  rtx op0 = expand_expr (arg0, subtarget, VOIDmode, EXPAND_NORMAL);
+  rtx op1 = expand_expr (arg1, subtarget, VOIDmode, EXPAND_NORMAL);
+
+  struct expand_operand ops[3];
+  create_output_operand ([0], target, res_mode);
+  create_input_operand ([1], op0, arg_mode);
+  create_input_operand ([2], op1, arg_mode);

Re: Deprecate -traditional-cpp?

[Martin Jambor]

Hi,

On Thu, Sep 05 2019, Nathan Sidwell wrote:
> Is it time to deprecate traditional preprocessing?  It's been  30 years 
> since C89.  Are (non-compiler) tools that use it still things?

xrdb runs .Xdefaults and I believe .Xresources files through the
pre-processor and I still use the latter to configure my desktop.

I cannot however find the string "traditional" in
https://gitlab.freedesktop.org/xorg/app/xrdb/blob/master/xrdb.c so
perhaps it does not use that option.

Martin

Expansion of narrowing math built-ins into power instructions

[Martin Jambor]

Hi Segher,

as you might know, Tejas is our Google Summer of Code student working on
adding built-in functions for some new math functions added in ISO/IEC
TS 18661.

His next step is to expand "functions rounding result to narrower type"
(so fadd, fsub and possibly fmul and fdiv described in
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2314.pdf) into ISA
instructions on targets that have such instructions.  And Joseph
suggested when he proposed this project that POWER8 (and I suppose also
9) is one of them.

Can you please confirm this and also perhaps point Tejas to the right
pieces of power machine description and target code to emulate to
implement expansion of these functions?  It would be very appreciated,
because even though me and Honza are official mentors of the project, we
are not very well versed in ppc target.

Thanks a lot,

Martin

Re: [GSoC-19] Implementing narrowing functions like fadd

[Martin Jambor]

Hi,

On Sat, Jul 27 2019, Tejas Joshi wrote:
> Hello.
>
>>> You'll need something different from CASE_MATHFN - these are a different
>>> kind of functions that need handling in a different way, because they are
>>> parametrized over certain *pairs* of types, rather than over a single
>>> type.
>> first phase, please just directly test for in the code for
>> CFN_BUILT_IN_FADD, CFN_BUILT_IN_FADDL, CFN_BUILT_IN_DADDL and process
>> those here to get a prototype working.  When you add support for more
>
> Thanks for the inputs. I have used CFN_BUILT_IN_FADD, etc in this
> following patch and function is getting folded.

good.  Please add comments to functions which miss them (real_fadd and
fold_const_fadd), for example I am not sure what the return values are
supposed to mean, and add a run-time testcase(s) and I'd say you are
done for now - after you implement fsub, fmul and fdiv(?) you might want
to re-structure some common bits to make the code prettier.

> My question is that how the addition and narrowing should be performed
> (is it ok to use do_add for addition?).

I don't see a reason why it would not be.

> As functions in real.c does
> not operate on any specific precision, just defining the return type
> as float would do the trick? Or do I need to make trailing
> out-of-precision bits zero? If yes, having functions like
> double_to_float would then be useful or such functions already exist
> to do the conversion?

I am not sure I understand your question, you have used real_convert in
real_fadd and it seems to be doing exactly that?  As you know I am not
too familiar with this area of gcc but reading the code suggests that
and a simple debugging session seems to confirm that (some unimportant
gdb output omitted):

--
$ ~/gcc/gsoc/inst/bin/gcc -Ofast -S fadd-fold.c -wrapper gdb,--args
GNU gdb (GDB; openSUSE Tumbleweed) 8.3
Copyright (C) 2019 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 

(gdb) b real_fadd
Breakpoint 1 at 0x108215b: file /home/mjambor/gcc/gsoc/src/gcc/real.c, line 
5100.
(gdb) r
Starting program: 
/home/mjambor/gcc/gsoc/inst/lib/gcc/x86_64-pc-linux-gnu/10.0.0/cc1 -quiet 
fadd-fold.c -quiet -dumpbase fadd-fold.c -mtune=generic -march=x86-64 -auxbase 
fadd-fold -Ofast -o fadd-fold.s

Breakpoint 1, real_fadd (r=0x7fffc580, fmt=..., x=0x77800060, 
y=0x77800080)
at /home/mjambor/gcc/gsoc/src/gcc/real.c:5100
5100  do_add (r, x, y, 0);
(gdb) n
5101  if (fmt)
(gdb) p *r
$1 = {cl = 1, decimal = 0, sign = 0, signalling = 0, canonical = 0, uexp = 5, 
sig = {0, 0, 
10549231767152649216}}
(gdb) p/x r->sig[2]
$2 = 0x92666400
(gdb) n
5102real_convert (r, fmt, r);
(gdb) 
5103  return false;
(gdb) p/x r->sig[2]
$3 = 0x9200
--

Thanks,

Martin

Re: Commit messages and the move to git

[Martin Jambor]

On Mon, Nov 04 2019, Richard Earnshaw (lists) wrote:
> Some tools, particularly gitk or git log --oneline, can use one-line 
> summaries from a commit's log message when listing commits.  It would be 
> nice if we could start adopting a style that is compatible with this, so 
> that in future commits are summarized in a useful way.

...

> The normal convention in git is that the one line summary is essentially 
> the subject line of the email message that describes the patch and is 
> then followed by a blank line before the body of the commit message.
>

I wholeheartedly agree.  Thanks to everyone already doing this and
everyone else, please just start, adding a summary line takes just
minimal effort.

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: 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: GIT conversion: question about tags & release branches

[Martin Jambor]

Hi,

On Thu, Jan 09 2020, Martin Liška wrote:
> Hi.
>
> I have question about release branches and release tags. For the current
> git mirror, we do have release tags living on release branches. Example:
>
> commit 64e1a4df1bc9dbf4cedb3a842c4eaff6b3425a66
> Author: jakub 
> Date:   Mon Aug 12 08:40:24 2019 +
>
>  * BASE-VER: Set to 9.2.1.
>  
>  
>  git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-9-branch@274276 
> 138bc75d-0d04-0410-961f-82ee72b054a4
>
> commit 3e7b85061947bdc7c7465743ba90734566860821 (tag: gcc-9_2_0-release) <- 
> THE TAG
> Author: jakub 
> Date:   Mon Aug 12 07:38:49 2019 +
>
>  Update ChangeLog and version files for release
>  
>  git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-9-branch@274274 
> 138bc75d-0d04-0410-961f-82ee72b054a4
>
> commit fc3f35e10b6ca627727d71c74fd5e76785226200
> Author: gccadmin 
> Date:   Mon Aug 12 00:16:21 2019 +
>
>  Daily bump.
>  
>  git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/branches/gcc-9-branch@274271 
> 138bc75d-0d04-0410-961f-82ee72b054a4
>
> while the reposurgeon git has:
>
> commit a9044428b313402507aa047a17e6ea10f63b2b8b
> Author: Jakub Jelinek 
> Date:   Mon Aug 12 10:40:24 2019 +0200
>
>  * BASE-VER: Set to 9.2.1.
>  
>  From-SVN: r274276
>
> commit d46878c3cce3be8f6c8878be8af326adecbb8ec6  <- THE TAG IS MISSING HERE
> Author: Jakub Jelinek 
> Date:   Mon Aug 12 09:38:49 2019 +0200
>
>  Update ChangeLog and version files for release
>  
>  From-SVN: r274274
>

I use the release tags every now and then so this caught my attention
but I do not understand what the problem is?

In the gcc-reposurgeon-7a conversion, there is a tag called
gcc_9_2_0_release:

mjambor@virgil:/space/mjambor/gcc/newconv/gcc-reposurgeon-7a.git$ git log -1 
gcc_9_2_0_release
commit 56bc3061f168c39a85117d4daefc2d5c0e4edb91 (tag: gcc_9_2_0_release)
Author: Jakub Jelinek 
Date:   Mon Aug 12 09:38:59 2019 +0200

Tagging source as tags/gcc_9_2_0_release

From-SVN: r274275

Even when I query the commit directly, it shows it is tagged:

mjambor@virgil:/space/mjambor/gcc/newconv/gcc-reposurgeon-7a.git$ git log -1 
56bc3061f168c39a85117d4daefc2d5c0e4edb91
commit 56bc3061f168c39a85117d4daefc2d5c0e4edb91 (tag: gcc_9_2_0_release)
Author: Jakub Jelinek 
Date:   Mon Aug 12 09:38:59 2019 +0200

Tagging source as tags/gcc_9_2_0_release

From-SVN: r274275


in gcc-reposurgeon-7b it is called releases/gcc-9.2.0

commit 56bc3061f168c39a85117d4daefc2d5c0e4edb91 (tag: releases/gcc-9.2.0)
Author: Jakub Jelinek 
Date:   Mon Aug 12 09:38:59 2019 +0200

Tagging source as tags/gcc_9_2_0_release

From-SVN: r274275

It seems that reposurgeon conversion has a commit representing the
revision r274275 whereas git mirror does not, but that does not seem to
be too bad?

> That's when I do git log parent/gcc-9-branch (git log origin/releases/gcc-9 
> respectively).
> And git log releases/gcc-9.2.0:
>
> commit 56bc3061f168c39a85117d4daefc2d5c0e4edb91 (tag: releases/gcc-9.2.0)  <- 
> THE TAG
> Author: Jakub Jelinek 
> Date:   Mon Aug 12 09:38:59 2019 +0200
>
>  Tagging source as tags/gcc_9_2_0_release
>  
>  From-SVN: r274275
>
> commit d46878c3cce3be8f6c8878be8af326adecbb8ec6
> Author: Jakub Jelinek 
> Date:   Mon Aug 12 09:38:49 2019 +0200
>
>  Update ChangeLog and version files for release
>  
>  From-SVN: r274274
>
> I see it useful to have the release tags on release branches.
> Thoughts?

Thinking about it, assuming the reposurgeon is the way to go, did we
decide whether it's going to be the a or b variant?  I like the tags in
the B version better, but it does not seem to have all the branches, I
mean:

mjambor@virgil:/space/mjambor/gcc/newconv/gcc-reposurgeon-7a.git$ git branch | 
wc -l
536

mjambor@virgil:/space/mjambor/gcc/newconv/gcc-reposurgeon-7b.git$ git branch | 
wc -l
38


I did clone both with --mirror.

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: 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