This is the mail archive of the gcc@gcc.gnu.org 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: libgcc/sync.c vs. cgraph alias tracking


> MIPS16 code can't do atomic operations directly, so it calls into out-of-line
> versions that are compiled as -mno-mips16.  These out-of-line versions use
> the same open-coded implementation as you'd get in normal -mno-mips16 code.

Hmm, and I assume you don't want to use target attribute for this...
> 
> This is done by libgcc/sync.c, which contains code like like:
> 
>   static void
>   sync_synchronize (void)
>   {
>     __sync_synchronize ();
>   }
>   typeof (sync_synchronize) __sync_synchronize
>     __attribute__((alias ("sync_synchronize")));
> 
> With the recent cgraph changes, we follow the alias and the function becomes
> an infinite loop.

Yep, here you define two symbols of same assembler name, so they will be identified.
How exactly the code worked before?

Honza
> 
> The code above was always a bit of a hack, so it's not surprising it broke.
> Is this a valid use of aliases?  If not, can anyone think of a better
> way of doing it?  If so, any suggestions on how to fix it?  I made a
> couple of flailing attempts but they both caused other problems...
> 
> Sorry if this has already been reported btw.
> 
> Thanks,
> Richard


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