Re: GCC GSOC 2019

[Martin Liška <mliska at suse dot cz>]

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