This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: allow certain kinds of inputs to top level asm()-s

>>> On 06.07.10 at 10:12, Jakub Jelinek <> wrote:
> On Tue, Jul 06, 2010 at 08:39:06AM +0100, Jan Beulich wrote:
>> This is so that use of symbols referenced in these asm()-s can be
>> properly tracked by the compiler, just like is the case for all other
>> asm()-s. I'm particularly looking forward to use this in the Linux
>> kernel.
> I'd say it is a bad idea to have in this case the input arguments after
> first :, there should be two :'s before those.  You can of course for
> toplevel asms require that there are no output operands (like we already do
> require e.g. for asm goto).

I tend to disagree (and intentionally coded it the way it is) - there is,
afaics, no possible way for top level asm()-s to have outputs. I'm not
very familiar with asm goto-s yet, but would suspect they can
theoretically have outputs.

> Also note that address of symbols with "i" constraint might not work on all
> targets, certainly won't work on many targets with -fpic/-fPIC (so the
> testcase needs to be guarded with { target !fpic } or something similar).
> It might not even work on some targets where -fpic/-fPIC is the default.

Hmm, that wouldn't be good - the construct ought to work regardless
of -fPIC imo. I have to admit that I don't see why you think this
wouldn't work, so any insight would be appreciated.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]