From: Vladimir Makarov <vmakarov@redhat.com>
To: Jakub Jelinek <jakub@redhat.com>
Cc: Andy Lutomirski <luto@kernel.org>,
gcc@gcc.gnu.org,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
"H. Peter Anvin" <hpa@zytor.com>, Ingo Molnar <mingo@kernel.org>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: gcc feature request / RFC: extra clobbered regs
Date: Wed, 01 Jul 2015 14:12:26 -0400 [thread overview]
Message-ID: <55942D8A.7060105@redhat.com> (raw)
In-Reply-To: <20150701174333.GA10247@tucnak.redhat.com>
On 07/01/2015 01:43 PM, Jakub Jelinek wrote:
> On Wed, Jul 01, 2015 at 01:35:16PM -0400, Vladimir Makarov wrote:
>> Actually it raise a question for me. If we describe that a function
>> clobbers more than calling convention and then use it as a value (assigning
>> a variable or passing as an argument) and loosing a track of it and than
>> call it. How can RA know what the call clobbers actually. So for the
>> function with the attributes we should prohibit use it as a value or make
>> the attributes as a part of the function type, or at least say it is unsafe.
>> So now I see this as a *bigger problem* with this extension. Although I
>> guess it already exists as we have description of different ABI as an
>> extension.
> Unfortunately target attribute is function decl attribute rather than
> function type. And having more attributes affect switchable targets will be
> non-fun.
>
>
Making attributes a part of type probably creates a lot issues too.
Although I am not a front-end developer, still I think it is hard to
implement in front-end. Sticking fully to this approach, it would be
logical to describe this as a debug info (I am not sure it is even
possible).
Portability would be an issue too. It is hard to prevent for a regular
C developer to assign such function to variable because it is ok on his
system while the compilation of such code may fail on another system.
next prev parent reply other threads:[~2015-07-01 18:12 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-30 21:22 gcc feature request / RFC: extra clobbered regs Andy Lutomirski
2015-06-30 21:32 ` H. Peter Anvin
2015-06-30 21:37 ` Jakub Jelinek
2015-06-30 21:41 ` H. Peter Anvin
2015-06-30 21:48 ` Andy Lutomirski
2015-06-30 21:52 ` H. Peter Anvin
2015-06-30 21:55 ` Andy Lutomirski
2015-06-30 22:02 ` H. Peter Anvin
2015-07-01 4:20 ` Jeff Law
2015-07-01 15:23 ` Vladimir Makarov
2015-07-01 15:27 ` Andy Lutomirski
2015-07-01 17:57 ` Vladimir Makarov
2015-07-01 15:31 ` Jakub Jelinek
2015-07-01 17:35 ` Vladimir Makarov
2015-07-01 17:38 ` Andy Lutomirski
2015-07-01 17:43 ` Jakub Jelinek
2015-07-01 18:12 ` Vladimir Makarov [this message]
2015-07-01 20:09 ` Andy Lutomirski
2015-07-02 6:16 ` H. Peter Anvin
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=55942D8A.7060105@redhat.com \
--to=vmakarov@redhat.com \
--cc=gcc@gcc.gnu.org \
--cc=hpa@zytor.com \
--cc=jakub@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=luto@kernel.org \
--cc=mingo@kernel.org \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
/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