This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
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 <mliska@suse.cz> 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 de.mo ../../../../libstdc++-v3/po/de.po
>>>>>
>>>>> 49 __asm volatile ("sc; mfcr %0"
>>>>> Missing separate debuginfos, use: debuginfo-install gettext-0.18.2.1-4.el7.ppc64le
>>>>> (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/ld64.so.2
>>>>> #10 0x00003fff865119cc in _dl_start_user () from /lib64/ld64.so.2
>>>>>
>>> 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/libc.so.6
#1 0x00003fff94dbbdc4 in __cxxabiv1::__cxa_guard_acquire (g=0x3fff94f26d40 <guard variable for (anonymous namespace)::__future_category_instance()::__fec>) at ../../../../libstdc++-v3/libsupc++/guard.cc:302
#2 0x00003fff94dfaf80 in __future_category_instance () at ../../../../../libstdc++-v3/src/c++11/future.cc:65
#3 std::future_category () at ../../../../../libstdc++-v3/src/c++11/future.cc:79
#4 0x00003fff94da98e8 in __static_initialization_and_destruction_0 (__priority=65535, __initialize_p=1) at ../../../../libstdc++-v3/src/c++11/compatibility-thread-c++0x.cc:50
#5 _GLOBAL__sub_I_compatibility_thread_c__0x.cc(void) () at ../../../../libstdc++-v3/src/c++11/compatibility-thread-c++0x.cc:200
#6 0x00003fff96105c74 in _dl_init_internal () from /lib64/ld64.so.2
#7 0x00003fff960f19cc in _dl_start_user () from /lib64/ld64.so.2
Looks the tests finish, but execution time is incredible long.
There must be something wrong with the system, maybe kernel-related?
Martin