From: Jeff Law <law@redhat.com>
To: Laurent Alfonsi <laurent.alfonsi@st.com>,
"gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH] Fix PR49718 : allow no_instrument_function attribute in class member definition/declaration
Date: Wed, 15 Jan 2014 19:25:00 -0000 [thread overview]
Message-ID: <52D6E092.9010205@redhat.com> (raw)
In-Reply-To: <52CEAF7B.7010101@st.com>
On 01/09/14 07:17, Laurent Alfonsi wrote:
> On 01/09/14 06:02, Jeff Law wrote:
>> On 01/08/14 02:05, Laurent Alfonsi wrote:
>>> All,
>>>
>>> I was looking at PR49718. I have enclosed a simple fix for this bug
>>> report.
>>>
>>> 2014-01-07 Laurent Alfonsi <laurent.alfonsi@st.com>
>>>
>>> * c-family/c-common.c
>>> (handle_no_instrument_function_attribute): Allow
>>> no_instrument_function attribute in class member
>>> definition/declaration.
>>>
>>>
>>> Looking at the implementation of the function attributes, I see no
>>> reason anymore to keep this error message.
>>> Let me know if I missed something.
>>> I have also added a testcase in the enclosed patch.
>>>
>>> 2014-01-07 Laurent Alfonsi <laurent.alfonsi@st.com>
>>>
>>> PR c++/49718
>>> * g++.dg/pr49718.C: New
>> Isn't the idea here that if we've already generated the function body
>> (presumably with instrumentation) that a no-instrument attribute
>> appearing on a later declaration won't do anything useful?
>>
>> jeff
>>
>>
> Jeff,
>
> You are right. That's probably the reason.
> From what i can see, the code instrumentation is performed in the
> gimplification pass (gimplify_function_tree), and the function attribute
> is handled and attached earlier in the parsing phase.
>
> I ve checked with an example like :
> ---8<------8<------8<------8<------8<---
> int foo () {
> return 2;
> }
>
> int bar () {
> return 1;
> }
>
> int foo () __attribute__((no_instrument_function));
> ---8<------8<------8<------8<------8<---
> The attribute is well honored on foo function.
> I might need to add this test case too.
Thanks. I checked with Jakub and he confirmed that all the flags to
disable unit-at-a-time mode are gone and there's no way to generate
gimple for a function prior to parsing the entire TU.
That means this patch should be OK. I don't see you in the MAINTAINERS
file or with an account on gcc.gnu.org, so I'll check it in for you shortly.
Thanks for your patience,
Jeff
next prev parent reply other threads:[~2014-01-15 19:25 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-08 9:05 Laurent Alfonsi
2014-01-09 5:02 ` Jeff Law
2014-01-09 14:18 ` Laurent Alfonsi
2014-01-15 8:51 ` Laurent Alfonsi
2014-01-15 19:25 ` Jeff Law [this message]
2014-01-16 8:41 ` Laurent Alfonsi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=52D6E092.9010205@redhat.com \
--to=law@redhat.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=laurent.alfonsi@st.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).