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