[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

autoconf stalls while checking "atomic builtins for 64 bit data types"



Hi there,

while trying to rebuild a few packages on my fairly old hppa box (PA8600
CPU) I noticed some of them like rsyslog and syslog-ng stall during
configure, with a conftest program eating 100% CPU. Funnily, killing
that process does not abort the build and produces a usable package.

This started a few weeks ago, unfortunately I cannot tell easily when
precisely. Probably in July.

Still this asked for investigation. So ...

The failing test is "checking whether the compiler provides atomic
builtins for 64 bit data types..."

A stripped down conftest.c still fails:

----->8------>8------>8------>8------>8------>8------>8------>8-----
int main()
{
    unsigned long long val = 1010;

    if (__sync_fetch_and_add(&val, 1010) != 1010 || val != 2020)
        return 1;
    return 0;
}
-----8<------8<------8<------8<------8<------8<------8<------8<-----

The compiler invocation, resembling the one used by autoconf, was:

gcc -o reprod -g -O0 -W -Wall -Wformat-security -Wshadow -Wcast-align -Wpointer-arith -Wmissing-format-attribute -g   reprod.c

The gcc version is as currently in unstable: 7.2.0-7

The actual stalling happens in __sync_fetch_and_add_8

The last statement gdb shows is

0x00010748 in __sync_fetch_and_add_8 ()

which is about 35 instructions into this function

   10744:       08 04 02 57     copy r4,r23
!  10748:       e4 00 81 60     be,l b0(sr2,r0),sr0,r31
   1074c:       34 14 00 04     ldi 2,r20

After interrupting, the next shown instruction is

Program received signal SIGINT, Interrupt.
0x00010788 in __sync_fetch_and_add_8 ()

   10784:       e8 00 00 0a     b,l,n 10790 <__sync_fetch_and_add_8+0xc0>,r0
!  10788:       8a a6 3f 05     cmpb,<> r6,r21,10710 <__sync_fetch_and_add_8+0x40>
   1078c:       08 00 02 40     nop

As there is TTBOMK no public hppa porterbox, I cannot check this on
different hardware. The buildd appearently had no problem with this.

Can anyboddy try to reproduce the problem, and provide an idea who is
to blame for this? I can think of several causes, but that's not the
place for wild-guessing.

    Christoph

Attachment: signature.asc
Description: Digital signature


Reply to: