GCC GSOC 2019

GCC GSOC 2019

[Shubham Narlawar]

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

Re: GCC GSOC 2019

[Martin Jambor]

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

Re: GCC GSOC 2019

[Shubham Narlawar]

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
>

Re: GCC GSOC 2019

[Martin Jambor]

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

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

Re: GCC GSOC 2019

[Shubham Narlawar]

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
>

Re: GCC GSOC 2019

[Martin Liška]

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

Re: GCC GSOC 2019

[Shubham Narlawar]

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

Re: GCC GSOC 2019

[Shubham Narlawar]

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