Re: Using __sync_* builtins within libgcc code

Re: Using __sync_* builtins within libgcc code

[Uros Bizjak]

Hello!

> I'm making some modifications to exception handling inside of unwind-dw2-fde.c that I'd like to use __sync_bool_compare_and_swap for, unfortunately I can't seem to figure out how to
> correctly use builtins in the context of libgcc.

> I've tried a bunch of different things, but I consistently get the error

> bin/../lib/gcc/i686-pc-linux-gnu/4.3.1/../../../libgcc_s.so: undefined reference to `__sync_bool_compare_and_swap_4'

> so clearly I'm not getting this symbol included correctly when I build. Any advice would be appreciated.

You have to compile library with -march=i486 to activate these
instructions.  Alternatively, you can use
__GCC_HAVE_SYNC_COMPARE_AND_SWAP_{1, 2, 4, 8, 16} to fall back to
generic implementation.

Uros.

Using __sync_* builtins within libgcc code

[Luke Dalessandro]

I'm making some modifications to exception handling inside of unwind-dw2-fde.c 
that I'd like to use __sync_bool_compare_and_swap for, unfortunately I can't 
seem to figure out how to correctly use builtins in the context of libgcc.

I've tried a bunch of different things, but I consistently get the error

   bin/../lib/gcc/i686-pc-linux-gnu/4.3.1/../../../libgcc_s.so: undefined 
reference to `__sync_bool_compare_and_swap_4'

so clearly I'm not getting this symbol included correctly when I build. Any 
advice would be appreciated.

Luke

Re: Using __sync_* builtins within libgcc code

[Paolo Carlini]

Luke Dalessandro wrote:
> I'm making some modifications to exception handling inside of 
> unwind-dw2-fde.c that I'd like to use __sync_bool_compare_and_swap 
> for, unfortunately I can't seem to figure out how to correctly use 
> builtins in the context of libgcc.
>
> I've tried a bunch of different things, but I consistently get the error
>
>   bin/../lib/gcc/i686-pc-linux-gnu/4.3.1/../../../libgcc_s.so: 
> undefined reference to `__sync_bool_compare_and_swap_4'
>
> so clearly I'm not getting this symbol included correctly when I 
> build. Any advice would be appreciated.
Isn't this the well know, annoying, issue that the default 
sub-architecture is i386 and the builtins are only available on i486 and 
later?

Maybe you can usefully exploit the recently added 
__GCC_HAVE_SYNC_COMPARE_AND_SWAP_* macros or add a few more along the 
same way...

Paolo.

Re: Using __sync_* builtins within libgcc code

[Joseph S. Myers]

On Tue, 10 Jun 2008, Paolo Carlini wrote:

> Luke Dalessandro wrote:
> > I'm making some modifications to exception handling inside of
> > unwind-dw2-fde.c that I'd like to use __sync_bool_compare_and_swap for,
> > unfortunately I can't seem to figure out how to correctly use builtins in
> > the context of libgcc.
> > 
> > I've tried a bunch of different things, but I consistently get the error
> > 
> >   bin/../lib/gcc/i686-pc-linux-gnu/4.3.1/../../../libgcc_s.so: undefined
> > reference to `__sync_bool_compare_and_swap_4'
> > 
> > so clearly I'm not getting this symbol included correctly when I build. Any
> > advice would be appreciated.
> Isn't this the well know, annoying, issue that the default sub-architecture is
> i386 and the builtins are only available on i486 and later?

I hold that it is a bug that i686-* tools default to -march=i386 instead 
of -march=i686 (whereas e.g. sparcv9-* tools default to -mcpu=sparcv9, and 
-mcpu means -march for SPARC).  My --with-arch-32 etc. patch 
<http://gcc.gnu.org/ml/gcc-patches/2008-06/msg00124.html> (config/i386 
part pending review) would facilitate fixing this bug by making i686-* 
imply --with-arch-32=i686 instead of --with-cpu-32=i686, while leaving the 
64-bit defaults (for which mode -march=i686 is invalid) unaffected.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Using __sync_* builtins within libgcc code

[Paolo Carlini]

Joseph S. Myers wrote:
> I hold that it is a bug that i686-* tools default to -march=i386 instead 
> of -march=i686 (whereas e.g. sparcv9-* tools default to -mcpu=sparcv9, and 
> -mcpu means -march for SPARC).
Seconded.

Paolo.

Re: Using __sync_* builtins within libgcc code

[H.J. Lu]

On Tue, Jun 10, 2008 at 02:27:17PM +0200, Paolo Carlini wrote:
> Joseph S. Myers wrote:
>> I hold that it is a bug that i686-* tools default to -march=i386 instead 
>> of -march=i686 (whereas e.g. sparcv9-* tools default to -mcpu=sparcv9, and 
>> -mcpu means -march for SPARC).
> Seconded.
>

What arch should be used for -m32 on x86-64? Personally, I think
it should be at least i686, if not SSE2.


H.J.

Re: Using __sync_* builtins within libgcc code

[Joseph S. Myers]

On Tue, 10 Jun 2008, H.J. Lu wrote:

> On Tue, Jun 10, 2008 at 02:27:17PM +0200, Paolo Carlini wrote:
> > Joseph S. Myers wrote:
> >> I hold that it is a bug that i686-* tools default to -march=i386 instead 
> >> of -march=i686 (whereas e.g. sparcv9-* tools default to -mcpu=sparcv9, and 
> >> -mcpu means -march for SPARC).
> > Seconded.
> >
> 
> What arch should be used for -m32 on x86-64? Personally, I think
> it should be at least i686, if not SSE2.

-march=x86-64, I'd say, if you're configuring as x86_64-* (so assuming 
those 32-bit features present on all 64-bit processors).  Obviously, 
subject to override from --with-arch-32 or --with-arch.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: Using __sync_* builtins within libgcc code

[H.J. Lu]

On Tue, Jun 10, 2008 at 7:42 AM, Joseph S. Myers
<joseph@codesourcery.com> wrote:
> On Tue, 10 Jun 2008, H.J. Lu wrote:
>
>> On Tue, Jun 10, 2008 at 02:27:17PM +0200, Paolo Carlini wrote:
>> > Joseph S. Myers wrote:
>> >> I hold that it is a bug that i686-* tools default to -march=i386 instead
>> >> of -march=i686 (whereas e.g. sparcv9-* tools default to -mcpu=sparcv9, and
>> >> -mcpu means -march for SPARC).
>> > Seconded.
>> >
>>
>> What arch should be used for -m32 on x86-64? Personally, I think
>> it should be at least i686, if not SSE2.
>
> -march=x86-64, I'd say, if you're configuring as x86_64-* (so assuming
> those 32-bit features present on all 64-bit processors).  Obviously,
> subject to override from --with-arch-32 or --with-arch.
>

Works for me.

Thanks.

-- 
H.J.

Re: Using __sync_* builtins within libgcc code

[Andrew Haley]

H.J. Lu wrote:
> On Tue, Jun 10, 2008 at 02:27:17PM +0200, Paolo Carlini wrote:
>> Joseph S. Myers wrote:
>>> I hold that it is a bug that i686-* tools default to -march=i386 instead 
>>> of -march=i686 (whereas e.g. sparcv9-* tools default to -mcpu=sparcv9, and 
>>> -mcpu means -march for SPARC).
>> Seconded.
>>
> 
> What arch should be used for -m32 on x86-64? Personally, I think
> it should be at least i686, if not SSE2.

I suppose that depends on your opinion as to why people use -32 on x86_64.
If it's just to make programs smaller, then i686 makes sense, but if it's
to make programs that will run on another, smaller (older?) box it doesn't.

I think we should be conservative, and assume little.

Andrew.

Re: Using __sync_* builtins within libgcc code

[Ross Smith]

Paolo Carlini wrote:
> Joseph S. Myers wrote:
>> I hold that it is a bug that i686-* tools default to -march=i386 
>> instead of -march=i686 (whereas e.g. sparcv9-* tools default to 
>> -mcpu=sparcv9, and -mcpu means -march for SPARC).
 >
> Seconded.

I've long been of the opinion that -march=native should be the default.

-- Ross Smith

Re: Using __sync_* builtins within libgcc code

[Luke Dalessandro]

Paolo Carlini wrote:
> Luke Dalessandro wrote:
>> I'm making some modifications to exception handling inside of 
>> unwind-dw2-fde.c that I'd like to use __sync_bool_compare_and_swap 
>> for, unfortunately I can't seem to figure out how to correctly use 
>> builtins in the context of libgcc.
>>
>> I've tried a bunch of different things, but I consistently get the error
>>
>>   bin/../lib/gcc/i686-pc-linux-gnu/4.3.1/../../../libgcc_s.so: 
>> undefined reference to `__sync_bool_compare_and_swap_4'
>>
> Maybe you can usefully exploit the recently added 
> __GCC_HAVE_SYNC_COMPARE_AND_SWAP_* macros or add a few more along the 
> same way...

Thank you Paolo, this allows me to wrap cas in a function that falls back to a 
mutex for targets that don't support builtins.

I was aware of the i386 restriction, but didn't realize that i686-* platforms 
still defaulted to i386.

Thanks for everyone's help.

Luke