Google Summer of Code

[Supriya Palli]

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?


*Thank You,*
*Supriya Palli*

gcc-7-20190404 is now available

[gccadmin]

Snapshot gcc-7-20190404 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/7-20190404/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 7 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-7-branch 
revision 270153

You'll find:

 gcc-7-20190404.tar.xzComplete GCC

  SHA256=d6db1e56f45caf48951907f6ae9755e37b4112c9b0df599e5ded6f2130ce3da9
  SHA1=6f2eec9c9d2a34c50f2866ef160770bb34a1085a

Diffs from 7-20190328 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-7
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: Putting an all-zero variable into BSS

[Thomas Koenig]

Hi Andreas,


Well, nothing is going to write to it (this is not accessible by
user code), so that should not be a problem.

Then don't make it read-only.


I tried this, and while it solves the executable size problem, it
causes an OpenMP regression (see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84487#c22 ),
so now I am out of ideas.

Oh well, I would have liked fixing this before 9.0, but it
seems that this may not be possible.

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

[Martin Sebor]

On 4/3/19 11:40 PM, Richard Biener wrote:

On April 3, 2019 7:59:47 PM GMT+02:00, Martin Sebor  wrote:

On 4/3/19 5:13 AM, Richard Biener wrote:

On Tue, Apr 2, 2019 at 6:20 PM Martin Sebor  wrote:


GCC tries to align a vector on its natural boundary, i.e., that
given by its size, up to MAX_OBJECT_ALIGNMENT.  Vectors that are
bigger than that are either silently [mis]aligned on that same
maximum boundary (PR 89798), silently truncated (and misaligned),
or cause an ICE (PR 89797).  Compiling the following:

 __attribute__ ((vector_size (N))) char v;

 _Static_assert (sizeof (v) == N, "size");
 _Static_assert (__alignof__ (v) == N, "alignment");

with N set to 1LLU << I shows these failures:

 I < 29   succeeds
 I < 31   fails alignment
 I < 32   ICE
 I >= 32  fails alignment and size

Attribute aligned doesn't seem to have any effect on types or
variables declared with attribute vector_size.  The alignment
set by the latter prevails.

This happens no matter what scope the vector is defined in (i.e.,
file or local).

I have some questions:

1) Is there some reason to align vectors on the same boundary
  as their size no matter how big it is?  I can't find such
  a requirement in the ABIs I looked at.  Or would it be more
  appropriate to align the big ones on the preferred boundary
  for the target?  For instance, does it make more sense to
  align a 64KB vector on a 64KB boundary than on, say,
  a 64-byte boundary (or some other boundary less than 64K?)


I don't think there's a good reason.  Instead I think that
BIGGEST_ALIGNMENT is what we should go for as upper limit,
anything bigger doesn't make sense (unless the user explicitely
requests it).


Sounds good.  Changing the alignment will impact object layout.


Do we really apply the alignment there? How do other compilers lay out here?


Unfortunately, yes.  The struct below is 2048 in size.

  struct S {
char c;
__attribute__ ((vector_size (1024))) char a;
  };

Clang and ICC do the same thing.  The biggest vector Clang allows
is 1024 bytes.  ICC tops out at 1<<21.  GCC ICEs for sizes over
1LLU << 32 but with my patch for bug 89797 it accepts any size
up to 1/2 the address space.

With types other than char the aligned attribute can be used in
conjunction with packed to reduce the size to just 1088:

  struct S {
char c;
__attribute__ ((aligned (64), packed, vector_size (1024))) int a;
  };

All three compilers require the packed attribute to reduce
the alignment.  Clang and GCC silently ignore the aligned
attribute without it but ICC issues warning #1366: a reduction
in alignment without the "packed" attribute is ignored.  That
would be a helpful enhancement to add to GCC.

I think ignoring the packed attribute for char vectors is a bug
so I opened PR 89968 for it.


How do you suggest to deal with it? (Presumably for GCC 10.)
Issuing an ABI warning and adding an option to override
the new setting come to mind as possible mitigating solutions.


We could reject these vector types in aggregates in favor of arrays. Of course 
that ship has sailed...


We could still issue a warning for vectors that are excessively
overaligned and suggest to use attributes aligned and packed to
reduce the alignment.

Martin

Re: Subversion repository is inaccessible.

[Jonathan Wakely]

On Thu, 4 Apr 2019 at 13:38, Taiki Akita wrote:
>
> Currently the subversion repository and the rsync server is inaccessible.
> Please check.
>
>
> $ svnsync sync file://`pwd`
> svnsync: E170013: Unable to connect to a repository at URL 
> 'svn://gcc.gnu.org/svn/gcc'
> svnsync: E210002: Network connection closed unexpectedly
>
>
> $ svn co svn://gcc.gnu.org/svn/gcc
> svn: E170013: Unable to connect to a repository at URL 
> 'svn://gcc.gnu.org/svn/gcc'
> svn: E210002: Network connection closed unexpectedly
>
>
> $ rsync ls rsync://gcc.gnu.org/
> rsync: safe_read failed to read 1 bytes [sender]: Connection reset by peer 
> (104)
> rsync error: error in rsync protocol data stream (code 12) at io.c(285) 
> [sender=3.1.2]

Thanks for letting us know. Anon svn was being throttled due to server
load. An IP address that was hammering the site has been blocked, and
service has been restored.

Re: GSoC OMPD

[Jeff Law]

On 4/4/19 6:24 AM, Martin Jambor wrote:
> 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).
Jakub is on PTO this week.  He'll be back in the office Monday.

jeff

GSOC Proposal on GENERIC level issues with threads

[nick]

Richard,

This is the link:
https://docs.google.com/document/d/1BKVeh62IpigsQYf_fJqkdu_js0EeGdKtXInkWZ-DtU0/edit

Seems that the function finalize_compilation_unit is a issue as it's the final
function before the GIMPLE level. It seems to have lots of issues related to
shared state if I'm understanding it correctly. In my proposal I'm assuming
that it's the final GENERIC pass and should be fixed, this is due to even
if the GIMPLE level is fixed we can only pass in shared state there which 
is still not a complete threaded pipeline through all three layers of 
GENERIC,GIMPLE and RTA. We would be bottle necked here and that seems to
be a issue after reading the code.


Let me know if this makes more sense to you as a proposal and feel free to
ask questions if something doesn't make sense,

Nick

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

[sameeran joshi]

On 4/4/19, Martin Jambor  wrote:
> 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,


There could be 2 approaches to it:

1. Not changing the current generation grammar :
How?

  //This is done after statement is generated and after fact analysis of
statement is done, inside Statement::make_random()
  //whenever statement is generated, can set flag to indicate a data race in it.

check_and set_data_race_in_statement(){
 1.retrieve write vars from current statement (Effect.h)
 2.loop through all write vars and check is_shared(write_var)
 if true
 its a data race
 set some flag to indicate
 }


This labels each statement with a flag to indicate data race in the
statement, now after generation of a particular block, looping through
the statements and checking whether they have a data race,
if YES:(possible solutions )
 1.Neglect the block for parallel region ( may not be
efficient as may neglect most of the blocks)

 2. May be apply some synchronization constructs to the block.
if NO race:
 good to go with the block to be parallel.

Andi suggested "that will be hard after the fact", But I found Csmith
doing some Fact analysis (DFA analysis) in it's code base.
Which I didn't explore during the previous project.

Will need some help to investigate about Fact Analysis (Fact*.h) which Csmith
 already implements, also they maintain the current generation context
 (CG_Context.h). As I think would solve most of the problems?


2. Decide before you generate the block that is parallel( a block
would be explicitly selected as a parallel block (based on
probability) ) and then avoid generating any data races. (Andi
suggested )


   So, how do you avoid them?
  e.g.
LHS OP EXPRESSION

Whenever a LHS variable is selected, care needs to be taken
it's not a shared variable.This avoids the data races during
generation itself.
But this approach restricts the generation grammar, so only
writes to  local variables from that block will be present in the
block . Will this work?

The above function could now become something like
Statement::check_and_avoid_data_races_in_statement()


---
> but I assume a conservative but useful approach will not be
> too difficult to devise.

I feel the most time consuming and challenging part would be adding
the first extension, i.e the ' #pragma omp parallel'  pragma.
Do you have more suggestions ?

>
>> I could work on it to modify them.
>
> Don't worry about the remark too much.  The proposal looks solid.
>
> Martin
>

Thanks,
Sameeran Joshi

Re: Show name of compiler options when linking

[David Malcolm]

On Thu, 2019-04-04 at 10:12 +, Jonathan Wakely wrote:
> On Thu, 4 Apr 2019 at 11:10, Jonathan Wakely wrote:
> > 
> > On Thu, 4 Apr 2019 at 10:56, Peter Olsson wrote:
> > > 
> > > Hello,
> > > 
> > > I often want to link to specific compiler options in your online
> > > docs
> > > but the problem is that the named anchors are placed after the
> > > name of
> > > the option so when the link is clicked it will only show the
> > > description.
> > > 
> > > Example:
> > >   https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-W
> > > shadow
> > >   Will show the description for -Wshadow but not the name
> > > -Wshadow itself.
> > > 
> > > I think it would be very useful to be able to link in such a way
> > > that
> > > the name of the option also becomes visible. If this somehow
> > > breaks
> > > backwards compatibility you could introduce new ones that refers
> > > to
> > > the name and let the old ones refer to the description like it is
> > > today.
> > 
> > Yes, it's annoying. The HTML is auto-generated by the makeinfo
> > program, so as far as I know we don't have much control over the
> > placement of those anchors.
> 
> Maybe it's because we have @opindex entries after the @item e.g.
> 
> @item -Wfatal-errors
> @opindex Wfatal-errors
> @opindex Wno-fatal-errors
> 
> But I don't know texinfo or makeinfo well enough to be sure, or if we
> can do it differently.

FWIW I started a discussion related to this on the help-texinfo list
here a couple of months ago:
  http://lists.gnu.org/archive/html/help-texinfo/2019-02/msg0.html

It may be that there's a way of fixing this from the GCC side (either
by changing our macros, or by changing our .texi source), but I'm not
expert enough at texinfo to figure that out.

Dave

Re: About GSOC.

[Tejas Joshi]

Hello.
Here is the proposal draft for the idea. Please review and suggest
changes or modifications.

https://docs.google.com/document/d/15DEXa5NZL6Q_X_zlME3NNJw2zVimFWzi16x7cgIDqL0/edit?usp=sharing

Thanks,
-Tejas

On Tue, 2 Apr 2019 at 01:23, Joseph Myers  wrote:
>
> On Sat, 30 Mar 2019, Tejas Joshi wrote:
>
> > Hello.
> > I have developed a fairly working patch for roundeven, attaching herewith.
> > The testcase function as follows :
> >
> > double f()
> > {
> >   double x = 4.5;
> >   double ret = __builtin_roundeven (x);
> >   return ret;
> > }
>
> Tests need to be added to the testsuite, covering a range of inputs and
> automatically verifying that the test is optimized correctly.
>
> "Round X to nearest even integer towards zero." is not correct.  The
> roundeven function does not round to an even integer.  It rounds to the
> nearest integer, whether even or odd - but, if two integers are equally
> close, the result is even (and for any input that is not halfway between
> two integers, it produces the same result as round (which rounds halfway
> cases away from zero) - so 2.501, 3 and 3.499 round to 3, but 2.5 rounds
> to 2 not 3, unlike round, and 3.5 rounds to 4, as with round).
>
> The function can't rely on arguments being in the range of HOST_WIDE_INT,
> so it needs to examine the REAL_VALUE_TYPE representation directly to
> determine whether it's half way between two integers and which way to
> round in that case.
>
> --
> Joseph S. Myers
> jos...@codesourcery.com

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

Subversion repository is inaccessible.

[Taiki Akita]

Currently the subversion repository and the rsync server is inaccessible.
Please check.


$ svnsync sync file://`pwd`
svnsync: E170013: Unable to connect to a repository at URL 
'svn://gcc.gnu.org/svn/gcc'
svnsync: E210002: Network connection closed unexpectedly


$ svn co svn://gcc.gnu.org/svn/gcc
svn: E170013: Unable to connect to a repository at URL 
'svn://gcc.gnu.org/svn/gcc'
svn: E210002: Network connection closed unexpectedly


$ rsync ls rsync://gcc.gnu.org/
rsync: safe_read failed to read 1 bytes [sender]: Connection reset by peer (104)
rsync error: error in rsync protocol data stream (code 12) at io.c(285) 
[sender=3.1.2]

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: GCC GSOC 2019

[Shubham Narlawar]

On Thu, Apr 4, 2019 at 2:13 PM Martin Liška  wrote:

> On 4/3/19 6:31 PM, Martin Jambor wrote:
> > 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
> >
>
> Hi.
>
> Just for the record, Martin Jambor asked me to co-mentor during time period
> when Andi will be on vacation (if I'm correct).
>

I have included your name as co-mentor in my proposal. Is it fine?


> I have couple of questions/ideas about the proposal:
>
> 1) I would not spend much time with nested functions, it's quite legacy
> C extension
>

Once Andi Kleen suggested that nested functions has lot of potential for
bugs.
I will not only just add nested functions but I plan to do integration
testing along with merging of previously implemented extensions in phase 3
of gsoc timeline


> 2) for functions, I would basically include add potential attribute:
>
> https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes
>
> see:
> gcc/c-family/c-attribs.c:242
> const struct attribute_spec c_common_attribute_table[] =
> ...
>


> I assume potential attributes means attributes that will trigger different
components of GCC. Can you point out such potential attributes such as
alias.



>
> 3) similarly for variables:
>
> https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html#Common-Variable-Attributes


Few of variables attributes like packed, unused, section, aligned are
already implemented in Csmith.


>
> 4) and similarly for types
>
> https://gcc.gnu.org/onlinedocs/gcc/Common-Type-Attributes.html#Common-Type-Attribute
> 

5) One big question about csmith I have. It's quite easy to come up with a
> test-case which
> causes an ICE. But it's more difficult to come up with a test-case that is
> miscompiled
> by a compiler. It's mainly due to an invalid behavior in the generated
> test-case.
> One can theoretically catch that with sanitizers (ASAN, UBSAN, ...). But
> still, it's
> not easy. Are you considering catching wrong-code issue?
>

I use option -fsanitize=undefined and valgrind to check undefined
behaviour. Are there any other ways to check it rather than sanitizers?

Thanks,
Shubham


>
> Thanks,
> Martin
>

Re: GCC GSOC 2019

[Shubham Narlawar]

On Wed, Apr 3, 2019 at 10:01 PM Martin Jambor  wrote:

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

Thanks for the suggestion. I have added function attribute alias, const and
externally_visible in my proposal.
My bad, I forgot to add const.

Also, suggest some more attributes like alias which will help to exercise
different components of GCC, so that I can update my proposal accordingly.

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

Thanks
Shubham


> Thanks,
>
> Martin
>
>

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

GSoC

[Muhammad Shehzad]

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. I wanted to know which
mailing list should I subscribe to?

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

Regards,
Muhammad Shehzad

Re: Show name of compiler options when linking

[Jonathan Wakely]

On Thu, 4 Apr 2019 at 11:10, Jonathan Wakely wrote:
>
> On Thu, 4 Apr 2019 at 10:56, Peter Olsson wrote:
> >
> > Hello,
> >
> > I often want to link to specific compiler options in your online docs
> > but the problem is that the named anchors are placed after the name of
> > the option so when the link is clicked it will only show the
> > description.
> >
> > Example:
> >   https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wshadow
> >   Will show the description for -Wshadow but not the name -Wshadow itself.
> >
> > I think it would be very useful to be able to link in such a way that
> > the name of the option also becomes visible. If this somehow breaks
> > backwards compatibility you could introduce new ones that refers to
> > the name and let the old ones refer to the description like it is
> > today.
>
> Yes, it's annoying. The HTML is auto-generated by the makeinfo
> program, so as far as I know we don't have much control over the
> placement of those anchors.

Maybe it's because we have @opindex entries after the @item e.g.

@item -Wfatal-errors
@opindex Wfatal-errors
@opindex Wno-fatal-errors

But I don't know texinfo or makeinfo well enough to be sure, or if we
can do it differently.

Re: Show name of compiler options when linking

[Jonathan Wakely]

On Thu, 4 Apr 2019 at 10:56, Peter Olsson wrote:
>
> Hello,
>
> I often want to link to specific compiler options in your online docs
> but the problem is that the named anchors are placed after the name of
> the option so when the link is clicked it will only show the
> description.
>
> Example:
>   https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wshadow
>   Will show the description for -Wshadow but not the name -Wshadow itself.
>
> I think it would be very useful to be able to link in such a way that
> the name of the option also becomes visible. If this somehow breaks
> backwards compatibility you could introduce new ones that refers to
> the name and let the old ones refer to the description like it is
> today.

Yes, it's annoying. The HTML is auto-generated by the makeinfo
program, so as far as I know we don't have much control over the
placement of those anchors.

Show name of compiler options when linking

[Peter Olsson]

Hello,

I often want to link to specific compiler options in your online docs
but the problem is that the named anchors are placed after the name of
the option so when the link is clicked it will only show the
description.

Example:
  https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wshadow
  Will show the description for -Wshadow but not the name -Wshadow itself.

I think it would be very useful to be able to link in such a way that
the name of the option also becomes visible. If this somehow breaks
backwards compatibility you could introduce new ones that refers to
the name and let the old ones refer to the description like it is
today.

Best Regards,

Peter

A big fan

Re: GCC GSOC 2019

[Martin Liška]

On 4/3/19 6:31 PM, Martin Jambor wrote:
> 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
> 

Hi.

Just for the record, Martin Jambor asked me to co-mentor during time period
when Andi will be on vacation (if I'm correct).

I have couple of questions/ideas about the proposal:

1) I would not spend much time with nested functions, it's quite legacy
C extension
2) for functions, I would basically include add potential attribute:
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#Common-Function-Attributes

see:
gcc/c-family/c-attribs.c:242
const struct attribute_spec c_common_attribute_table[] =
...

3) similarly for variables:
https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html#Common-Variable-Attributes

4) and similarly for types
https://gcc.gnu.org/onlinedocs/gcc/Common-Type-Attributes.html#Common-Type-Attributes

5) One big question about csmith I have. It's quite easy to come up with a 
test-case which
causes an ICE. But it's more difficult to come up with a test-case that is 
miscompiled
by a compiler. It's mainly due to an invalid behavior in the generated 
test-case.
One can theoretically catch that with sanitizers (ASAN, UBSAN, ...). But still, 
it's
not easy. Are you considering catching wrong-code issue?

Thanks,
Martin