libatomic, 32-bit object code vs. 64-bit object, GCC 8.3.0

Kacvinsky, Tom
Thu Jun 20 20:26:00 GMT 2019


> -----Original Message-----
> From: Jonathan Wakely <>
> Sent: Thursday, June 20, 2019 11:54 AM
> To: Kacvinsky, Tom <>
> Cc:
> Subject: Re: libatomic, 32-bit object code vs. 64-bit object, GCC 8.3.0
> On Thu, 20 Jun 2019 at 16:19, Kacvinsky, Tom <>
> wrote:
> >
> > Hi,
> >
> > I have built a 32-bit GCC 8.3.0 (no multi-lib support) on RHEL 5 and a
> > 64-bit GCC 8.3.0 (again, no multi-lib support) on CentOS 5.11.  What I
> > find interesting is that when I go to compile a program that will need
> > atomic locks (a Boost template class pulled in via a header file), the
> > 32-bit object code requires the library -latomic, but 64-bit object code does
> not require that.
> >
> > Looking over "info gcc" I see a multitude of options for atomic
> > operations.  The take away for me sis that for architectures that have
> > an instruction set that has support for atomic operations, libatomic is not
> necessary, but for other architectures, it is.
> Right. Sort of. It depends what kind of variables you're using the atomic
> operations with.
> libatomic can still be needed on x86_64, but only for types larger than 64-bits.

OK, for our purposes we are using integral types of 64-bits wide or less.

> On i386 you need libatomic even for 32-bit integers, as it has no atomic
> operations. i586 has 64-bit atomics though.
> So if you configured your 32-bit compiler for i386, not i586 or later, then by
> default it will want to use libatomic for all atomic ops.

If  by configuring GCC for i386 you mean having i386 in the build triplet (used in the
the --build option), then yes indeed I compiled my 32-bit GCC for i386.  Not sure if
we should target i586 (or higher).

All of that said, it's not a problem to use libatomic, I just wanted to understand why
our 32-bit product needs libatomic but our 64-bit product does not.

Thanks for the help.


More information about the Gcc-help mailing list