__sync_fetch_and_add_4 in libstdc++

__sync_fetch_and_add_4 in libstdc++

[Maciej (Matchek) Bliziński]

Hello gcc-help,

When compiling gmp on Solaris 9 i386, using gcc (4.3.3 and 4.6.1),
I've come across a problem where the linking stage of the t-access.o
object would result in an error:

libtool: link: /opt/csw/bin/g++-4.6 -mtune=i686 -O2 -pipe -m32
-march=i386 -fexceptions -m32 -march=i386 -o .libs/t-assign t-assign.o
 -L/home/maciej/src/opencsw/pkg/libgmp/trunk/work/solaris9-i386/build-isa-i386/gmp-5.0.2/.libs
-L/opt/csw/lib/. -L/opt/csw/lib ../../tests/.libs/libtests.a
../../.libs/libgmpxx.so
/home/maciej/src/opencsw/pkg/libgmp/trunk/work/solaris9-i386/build-isa-i386/gmp-5.0.2/.libs/libgmp.so
/opt/csw/lib/libstdc++.so -lm ../../.libs/libgmp.so -Wl,-R
-Wl,/opt/csw/lib
ld: warning: file ../../.libs/libgmp.so: linked to
/home/maciej/src/opencsw/pkg/libgmp/trunk/work/solaris9-i386/build-isa-i386/gmp-5.0.2/.libs/libgmp.so:
attempted multiple inclusion of file
ld: warning: file /opt/csw/lib/./libstdc++.so: linked to
/opt/csw/lib/libstdc++.so: attempted multiple inclusion of file
Undefined                       first referenced
 symbol                             in file
__sync_fetch_and_add_4              t-assign.o
ld: fatal: Symbol referencing errors. No output written to .libs/t-assign

A similar problem was encountered in the past[1].

The porting FAQ at OpenCSW[2] contains information about a workaround
for this problem: disable optimization during compilation.  Other
workarounds found on the web suggest changing the target architecture
to i686.  Not satisfied with these workarounds, I've done some digging
with help from friends (kudos to Joerg Schilling!).

The GCC invocation used to compile this object was:

/opt/csw/bin/g++-4.6 -DHAVE_CONFIG_H -I. -I../.. -I../.. -I../../tests
 -fexceptions -I/opt/csw/include  -mtune=i686 -O2 -pipe -m32
-march=i386 -fexceptions -c -o t-assign.o t-assign.cc

I've generated the assembly file from t-assign.cc and found references
to __sync_fetch_and_add_4:

.L213:
        subl    $4, %edi
        movl    $-1, 4(%esp)
        movl    %edi, (%esp)
        call    __sync_fetch_and_add_4
        jmp     .L77

I've looked up the function name in the GCC documentation[3], and
found out that it's got to do with the capabilities of the target CPU
architecture.  If the target architecture doesn't have the opcode for
specific atomic operations, libstdc++ generates a compatibility
function, called __sync_fetch_and_add_4.  In my case, it looks like
during the libstdc++ compilation, this function was not generated.
Later on, when g++ is used with -march=i386, it knows that i386 has no
required opcode and creates a dangling reference to
__sync_fetch_and_add_4.

The fix would probably involve compiling libstdc++ in such a way, that
__sync_fetch_and_add_4 would be generated.  Do you have an idea how to
achieve this?

Regards,
Maciej

[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28671
[2] http://wiki.opencsw.org/porting-faq#toc6
[3] http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/doc/xml/manual/concurrency_extensions.xml?view=markup

Re: __sync_fetch_and_add_4 in libstdc++

[Jonathan Wakely]

2011/9/24 Maciej (Matchek) Bliziński:
>
> The fix would probably involve compiling libstdc++ in such a way, that
> __sync_fetch_and_add_4 would be generated.  Do you have an idea how to
> achieve this?

Don't use -march=i386

Does Solaris i86pc even work on i386 hardware? If not, it's ridiculous
to tell GCC to produce code for that architecture.

Re: __sync_fetch_and_add_4 in libstdc++

[Ian Lance Taylor]

"Maciej (Matchek) Bliziński" <maciej@opencsw.org> writes:

> Other
> workarounds found on the web suggest changing the target architecture
> to i686.  Not satisfied with these workarounds, I've done some digging
> with help from friends (kudos to Joerg Schilling!).

...

> The fix would probably involve compiling libstdc++ in such a way, that
> __sync_fetch_and_add_4 would be generated.  Do you have an idea how to
> achieve this?

I recommend changing the target architecture to i686.  The easy way to
do this is to add --with-arch-32=i686 when you run configure.  You don't
have to use i686--you can use the minimum processor type that you expect
to encounter.

Ian

Re: __sync_fetch_and_add_4 in libstdc++

[Maciej (Matchek) Bliziński]

2011/9/24 Ian Lance Taylor <iant@google.com>:
> "Maciej (Matchek) Bliziński" <maciej@opencsw.org> writes:
>> The fix would probably involve compiling libstdc++ in such a way, that
>> __sync_fetch_and_add_4 would be generated.  Do you have an idea how to
>> achieve this?
>
> I recommend changing the target architecture to i686.  The easy way to
> do this is to add --with-arch-32=i686 when you run configure.  You don't
> have to use i686--you can use the minimum processor type that you expect
> to encounter.

I have an update on the issue.  I raised this topic at the OpenCSW
summit last week in Kiel[1].  The need to compile for sparcv8 and i386
comes from OpenCSW supporting Solaris 9.  However, Oracle is soon
dropping support for Solaris 9, and we'll follow by changing the
support level from full to best effort.

On Solaris 10, the situation is better, because the minimal supported
architectures are Intel without the f00f bug and sparcv8+.  The lowest
Intel architecture without the f00f bug is pentium pro.  The
conclusion was that we raise the default architecture levels for
Solaris 10 to sparcv8+ and pentium pro.  When we deprecate Solaris 9,
we will no longer have the requirement of compiling for i386 and
sparcv8.

I also noticed that the __sync_fetch_and_add_4 problem which used to
occur when compiling for sparcv8 with gcc-4.3.3, is gone in gcc-4.6.1.
According to Joerg, sparcv8 does have the necessary opcodes, so the
change could be attributed to improved sparc support in gcc-4.6.x.

Ian and Jonathan, thanks for the help!

Maciej

[1] Meeting minutes from Sunday: http://t.co/AZeElR1L

Re: __sync_fetch_and_add_4 in libstdc++

[Jonathan Wakely]

2011/9/29 Maciej (Matchek) Bliziński:
>
> I have an update on the issue.  I raised this topic at the OpenCSW
> summit last week in Kiel[1].  The need to compile for sparcv8 and i386
> comes from OpenCSW supporting Solaris 9.  However, Oracle is soon
> dropping support for Solaris 9, and we'll follow by changing the
> support level from full to best effort.

So Solaris 9 actually works on i386?!?  Or is that just what your
current minimum happens to be?

In case it's not clear, by i386 I do not mean x86 family, I mean the
80386, which Wikipedia tells me had a maximum clock rate of 40MHz.

"Before you can deploy Solaris, you must make sure your system can
handle it. At a minimum, your system should have a Pentium processor
running at 133 Mhz. Solaris recommends that the system run at least
500 Mhz."
http://www.techrepublic.com/article/preparing-to-install-solaris-9-on-an-intel-server/5056145

"Minimum system requirements are as follows: Pentium CPU (PII is
better - see below) "
http://www.parkansky.com/tutorials/bdlogsol.htm#install

Even if it technically runs (which the www tells me it doesn't), do
you have any OpenCSW users on i386 or are you crippling the software
to support non-existent users?

Good luck! :-)

Re: __sync_fetch_and_add_4 in libstdc++

[Maciej (Matchek) Bliziński]

2011/9/29 Jonathan Wakely <jwakely.gcc@gmail.com>:
> 2011/9/29 Maciej (Matchek) Bliziński:
>>
>> I have an update on the issue.  I raised this topic at the OpenCSW
>> summit last week in Kiel[1].  The need to compile for sparcv8 and i386
>> comes from OpenCSW supporting Solaris 9.  However, Oracle is soon
>> dropping support for Solaris 9, and we'll follow by changing the
>> support level from full to best effort.
>
> So Solaris 9 actually works on i386?!?  Or is that just what your
> current minimum happens to be?
>
> In case it's not clear, by i386 I do not mean x86 family, I mean the
> 80386, which Wikipedia tells me had a maximum clock rate of 40MHz.
>
> "Before you can deploy Solaris, you must make sure your system can
> handle it. At a minimum, your system should have a Pentium processor
> running at 133 Mhz. Solaris recommends that the system run at least
> 500 Mhz."
> http://www.techrepublic.com/article/preparing-to-install-solaris-9-on-an-intel-server/5056145
>
> "Minimum system requirements are as follows: Pentium CPU (PII is
> better - see below) "
> http://www.parkansky.com/tutorials/bdlogsol.htm#install
>
> Even if it technically runs (which the www tells me it doesn't), do
> you have any OpenCSW users on i386 or are you crippling the software
> to support non-existent users?

Um... yes, we are!

The original discussion predates my involvement in the project, so I
can't report accurately why building for 386 is the policy.  I think
it also was Solaris 8 that the policy was set for.  The Solaris 8
hardware compatibility table[1] lists Pentium as the lowest Intel
processor it runs on, so I agree that setting 386 as the base
instruction set is not necessary.

I'm guilty of disrupting the consensus at OpenCSW multiple times
already, so I need to be careful when questioning yet another element
of the packaging policy.  At least for the GCC package and all its
dependencies, I've got dispensation to build for Pentium Pro.

Maciej

[1] http://download.oracle.com/docs/cd/E19455-01/806-1054/6jac8mmsb/index.html