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: RFA: Remove alias usage from libgcc/sync.c

On Fri, Oct 11, 2013 at 11:43 AM, Richard Sandiford
<> wrote:
> Jakub Jelinek <> writes:
>> On Fri, Oct 11, 2013 at 10:17:41AM +0200, Richard Biener wrote:
>>> asm(".alias __sync_synchronize sync_synchronize");
>> It is .set, but not everywhere.
>> /* The MIPS assembler has different syntax for .set. We set it to
>>    .dummy to trap any errors.  */
>> #undef SET_ASM_OP
>> #define SET_ASM_OP "\t.dummy\t"
>> But perhaps it would require fewer variants than providing inline asm
>> of the __sync_* builtin by hand for all the targets that need it.
> Yeah, that's why I prefer the sed approach.  GCC knows how to do exactly
> what we want, and what syntax to use.  We just need to take its output and
> change the function name.
> And like Richard says, parsing top-level asms would be fair game,
> especially if GCC and binutils ever were integrated (for
> So using top-level asms seems like putting off the inevitable
> (albeit putting it off further than __asm renaming).
> Do either of you object to the sed thing?

Well, ideally there would be a way to not lie about symbol names to GCC.
That is, have a "native" way of telling GCC what to do here (which is
as far as I understand to emit the code for the builtin-handled $SYM
in a function with $SYM - provide the out-of-line copy for a builtin).

For the __sync functions it's unfortunate that the library function has
the same 'name' as the builtin and the builtin doesn't have an alternate
spelling.  So - can't we just add __builtin__sync_... spellings and use

__sync_synchronize ()
  __builtin_sync_syncronize ();

?  (what if __builtin_sync_syncronize expands to a libcall?  if it can't,
what's the point of the library function?)

Why does a simple

__sync_synchronize ()
  __sync_synchronize ();

not work?  On x86_64 I get from that:


(similar to how you can have a definition of memcpy () and have
another memcpy inside it inline-expanded)


> Thanks,
> Richard

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