This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: libgcc/sync.c vs. cgraph alias tracking
- From: Jan Hubicka <hubicka at ucw dot cz>
- To: gcc at gcc dot gnu dot org, jh at suse dot cz, rdsandiford at googlemail dot com
- Date: Wed, 9 Oct 2013 01:57:26 +0200
- Subject: Re: libgcc/sync.c vs. cgraph alias tracking
- Authentication-results: sourceware.org; auth=none
- References: <87fvsbr0ud dot fsf at talisman dot default>
> 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