Hi, > -----Original Message----- > From: Jonathan Wakely <jwakely.gcc@xxxxxxxxx> > Sent: Thursday, June 20, 2019 11:54 AM > To: Kacvinsky, Tom <Tom.Kacvinsky@xxxxxxxxxx> > Cc: gcc-help@xxxxxxxxxxx > 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@xxxxxxxxxx> > 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. Tom