On 4/4/19 1:44 PM, Shubham Narlawar wrote: > On Thu, Apr 4, 2019 at 2:13 PM Martin Liška <mli...@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 >>
