libatomic, 32-bit object code vs. 64-bit object, GCC 8.3.0
Thu Jun 20 20:26:00 GMT 2019
> -----Original Message-----
> From: Jonathan Wakely <firstname.lastname@example.org>
> Sent: Thursday, June 20, 2019 11:54 AM
> To: Kacvinsky, Tom <Tom.Kacvinsky@vector.com>
> Cc: email@example.com
> 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 <Tom.Kacvinsky@vector.com>
> > 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