This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Building on gcc112 is stuck in msgfmt

On 08/29/2017 11:15 AM, Stefan Ring wrote:
> On Tue, Aug 29, 2017 at 9:32 AM, Martin Liška <> wrote:
>> On 08/28/2017 09:15 PM, Martin Liška wrote:
>>> On 08/28/2017 04:06 PM, Jeff Law wrote:
>>>> On 08/28/2017 01:16 AM, Martin Liška wrote:
>>>>> Hello.
>>>>> I've just repeatedly seen stuck in build process:
>>>>> make[5]: Entering directory `/home/marxin/Programming/gcc/objdir/powerpc64le-unknown-linux-gnu/libstdc++-v3/po'
>>>>> msgfmt -o ../../../../libstdc++-v3/po/de.po
>>>>> 49        __asm volatile ("sc; mfcr %0"
>>>>> Missing separate debuginfos, use: debuginfo-install gettext-
>>>>> (gdb) bt
>>>>> #0  0x00003fff85d8bac8 in sys_futex0 (val=-1, op=128, addr=0x3fff85db0520 <acc_device_lock>) at ../../../libgomp/config/linux/powerpc/futex.h:49
>>>>> #1  futex_wait (val=-1, addr=0x3fff85db0520 <acc_device_lock>) at ../../../libgomp/config/linux/powerpc/futex.h:62
>>>>> #2  do_wait (val=-1, addr=<optimized out>) at ../../../libgomp/config/linux/wait.h:67
>>>>> #3  gomp_mutex_lock_slow (mutex=0x3fff85db0520 <acc_device_lock>, oldval=<optimized out>) at ../../../libgomp/config/linux/mutex.c:63
>>>>> #4  0x00003fff85d98b04 in gomp_mutex_lock (mutex=0x3fff85db0520 <acc_device_lock>) at ../../../libgomp/config/linux/mutex.h:57
>>>>> #5  goacc_register (disp=0x3fff85db0090 <host_dispatch>) at ../../../libgomp/oacc-init.c:74
>>>>> #6  0x00003fff85d983fc in goacc_host_init () at ../../../libgomp/oacc-host.c:265
>>>>> #7  0x00003fff85d99c88 in goacc_runtime_initialize () at ../../../libgomp/oacc-init.c:657
>>>>> #8  0x00003fff85d7882c in initialize_env () at ../../../libgomp/env.c:1340
>>>>> #9  0x00003fff86525c74 in _dl_init_internal () from /lib64/
>>>>> #10 0x00003fff865119cc in _dl_start_user () from /lib64/
>>> I did the same with the same result. Note that I can see the same problem
>>> on gcc110 machine :/
> [...]
>> Looks it uses different invocation of futex syscall. In order to have it working I needed to configure gettext w/ --disable-openmp.
>> Note that the former invocation of msgfmt contains just a single futex syscall, so should not be blocked by anything else.
> Then it looks very much like libgomp got its memory barriers wrong for
> powerpc64.

Huh. I see more strange things happening on the machine. Couple of tests have been running for a long time.
All somewhere in:

(gdb) bt
#0  0x00003fff950e58e4 in syscall () from /lib64/
#1  0x00003fff94dbbdc4 in __cxxabiv1::__cxa_guard_acquire (g=0x3fff94f26d40 <guard variable for (anonymous namespace)::__future_category_instance()::__fec>) at ../../../../libstdc++-v3/libsupc++/
#2  0x00003fff94dfaf80 in __future_category_instance () at ../../../../../libstdc++-v3/src/c++11/
#3  std::future_category () at ../../../../../libstdc++-v3/src/c++11/
#4  0x00003fff94da98e8 in __static_initialization_and_destruction_0 (__priority=65535, __initialize_p=1) at ../../../../libstdc++-v3/src/c++11/
#5 () at ../../../../libstdc++-v3/src/c++11/
#6  0x00003fff96105c74 in _dl_init_internal () from /lib64/
#7  0x00003fff960f19cc in _dl_start_user () from /lib64/

Looks the tests finish, but execution time is incredible long.

There must be something wrong with the system, maybe kernel-related?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]