* GCC GSOC 2019
@ 2019-02-09 19:14 Shubham Narlawar
2019-02-18 18:26 ` Martin Jambor
0 siblings, 1 reply; 9+ messages in thread
From: Shubham Narlawar @ 2019-02-09 19:14 UTC (permalink / raw)
To: gcc; +Cc: Andi Kleen
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.
Thanks and Regards.
Shubham Narlawar
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: GCC GSOC 2019
2019-02-09 19:14 GCC GSOC 2019 Shubham Narlawar
@ 2019-02-18 18:26 ` Martin Jambor
2019-03-29 4:01 ` Shubham Narlawar
0 siblings, 1 reply; 9+ messages in thread
From: Martin Jambor @ 2019-02-18 18:26 UTC (permalink / raw)
To: Shubham Narlawar, gcc; +Cc: Andi Kleen
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: GCC GSOC 2019
2019-02-18 18:26 ` Martin Jambor
@ 2019-03-29 4:01 ` Shubham Narlawar
2019-04-03 16:31 ` Martin Jambor
0 siblings, 1 reply; 9+ messages in thread
From: Shubham Narlawar @ 2019-03-29 4:01 UTC (permalink / raw)
To: gcc; +Cc: Martin Jambor
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
Thanks.
Shubham
On Mon, Feb 18, 2019 at 11:55 PM Martin Jambor <mjambor@suse.cz> wrote:
> 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
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: GCC GSOC 2019
2019-03-29 4:01 ` Shubham Narlawar
@ 2019-04-03 16:31 ` Martin Jambor
2019-04-04 8:43 ` Martin Liška
2019-04-04 11:26 ` Shubham Narlawar
0 siblings, 2 replies; 9+ messages in thread
From: Martin Jambor @ 2019-04-03 16:31 UTC (permalink / raw)
To: Shubham Narlawar, gcc; +Cc: Martin Liska
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: GCC GSOC 2019
2019-04-03 16:31 ` Martin Jambor
@ 2019-04-04 8:43 ` Martin Liška
2019-04-04 11:44 ` Shubham Narlawar
2019-04-04 11:26 ` Shubham Narlawar
1 sibling, 1 reply; 9+ messages in thread
From: Martin Liška @ 2019-04-04 8:43 UTC (permalink / raw)
To: Martin Jambor, Shubham Narlawar, gcc
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: GCC GSOC 2019
2019-04-03 16:31 ` Martin Jambor
2019-04-04 8:43 ` Martin Liška
@ 2019-04-04 11:26 ` Shubham Narlawar
1 sibling, 0 replies; 9+ messages in thread
From: Shubham Narlawar @ 2019-04-04 11:26 UTC (permalink / raw)
To: Martin Jambor, gcc; +Cc: Martin Liska
On Wed, Apr 3, 2019 at 10:01 PM Martin Jambor <mjambor@suse.cz> 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
>
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: GCC GSOC 2019
2019-04-04 8:43 ` Martin Liška
@ 2019-04-04 11:44 ` Shubham Narlawar
2019-04-05 12:07 ` Martin Liška
0 siblings, 1 reply; 9+ messages in thread
From: Shubham Narlawar @ 2019-04-04 11:44 UTC (permalink / raw)
To: Martin Liška, gcc; +Cc: Martin Jambor
On Thu, Apr 4, 2019 at 2:13 PM Martin Liška <mliska@suse.cz> 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
> <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?
>
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
>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: GCC GSOC 2019
2019-04-04 11:44 ` Shubham Narlawar
@ 2019-04-05 12:07 ` Martin Liška
2019-04-07 13:00 ` Shubham Narlawar
0 siblings, 1 reply; 9+ messages in thread
From: Martin Liška @ 2019-04-05 12:07 UTC (permalink / raw)
To: Shubham Narlawar, gcc; +Cc: Martin Jambor
On 4/4/19 1:44 PM, Shubham Narlawar wrote:
> On Thu, Apr 4, 2019 at 2:13 PM Martin Liška <mliska@suse.cz> 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?
Yes.
>
>
>> 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
I would be more interested in lambda functions, which is also kind of a nested function.
>
>
>> 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.
Basically majority of them can stress a component in GCC. More you add better coverage
we'll have.
>
>
>
>>
>> 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.
Great then.
>
>
>>
>> 4) and similarly for types
>>
>> https://gcc.gnu.org/onlinedocs/gcc/Common-Type-Attributes.html#Common-Type-Attribute
>> <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?
>>
>
> I use option -fsanitize=undefined and valgrind to check undefined
> behaviour. Are there any other ways to check it rather than sanitizers?
I'm not aware of any others. I'm curious if you we able to find a wrong-code
with your periodic csmith runner?
Thanks for working on csmith,
Martin
>
> Thanks,
> Shubham
>
>
>>
>> Thanks,
>> Martin
>>
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: GCC GSOC 2019
2019-04-05 12:07 ` Martin Liška
@ 2019-04-07 13:00 ` Shubham Narlawar
0 siblings, 0 replies; 9+ messages in thread
From: Shubham Narlawar @ 2019-04-07 13:00 UTC (permalink / raw)
To: Martin Liška, gcc; +Cc: Martin Jambor
On Fri, Apr 5, 2019 at 5:37 PM Martin Liška <mliska@suse.cz> wrote:
> On 4/4/19 1:44 PM, Shubham Narlawar wrote:
> > On Thu, Apr 4, 2019 at 2:13 PM Martin Liška <mliska@suse.cz> 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?
>
> Yes.
>
> >
> >
> >> 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
>
> I would be more interested in lambda functions, which is also kind of a
> nested function.
>
AFAIK, lambda expressions are strictly based on c++ 11 standard and Csmith
is only random C code generator and not C++. In this gsoc timeline, I am
extending Csmith for C extensions.
>
> >
> >
> >> 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.
>
> Basically majority of them can stress a component in GCC. More you add
> better coverage
> we'll have.
I will definitely try to add more attributes rather than mentioned
attributes if time permits.
>
> >
> >
> >
> >>
> >> 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.
>
> Great then.
>
> >
> >
> >>
> >> 4) and similarly for types
> >>
> >>
> https://gcc.gnu.org/onlinedocs/gcc/Common-Type-Attributes.html#Common-Type-Attribute
> >> <
> 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?
> >>
> >
> > I use option -fsanitize=undefined and valgrind to check undefined
> > behaviour. Are there any other ways to check it rather than sanitizers?
>
> I'm not aware of any others. I'm curious if you we able to find a
> wrong-code
> with your periodic csmith runner?
>
> Thanks for working on csmith,
> Martin
>
Thanks.
Shubham
>
> >
> > Thanks,
> > Shubham
> >
> >
> >>
> >> Thanks,
> >> Martin
> >>
>
>
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2019-04-07 13:00 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-02-09 19:14 GCC GSOC 2019 Shubham Narlawar
2019-02-18 18:26 ` Martin Jambor
2019-03-29 4:01 ` Shubham Narlawar
2019-04-03 16:31 ` Martin Jambor
2019-04-04 8:43 ` Martin Liška
2019-04-04 11:44 ` Shubham Narlawar
2019-04-05 12:07 ` Martin Liška
2019-04-07 13:00 ` Shubham Narlawar
2019-04-04 11:26 ` Shubham Narlawar
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).