Re: Building on gcc112 is stuck in msgfmt

[Martin Liška]

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  0x3fff85d8bac8 in sys_futex0 (val=-1, op=128, addr=0x3fff85db0520 
>>> ) at ../../../libgomp/config/linux/powerpc/futex.h:49
>>> #1  futex_wait (val=-1, addr=0x3fff85db0520 ) at 
>>> ../../../libgomp/config/linux/powerpc/futex.h:62
>>> #2  do_wait (val=-1, addr=) at 
>>> ../../../libgomp/config/linux/wait.h:67
>>> #3  gomp_mutex_lock_slow (mutex=0x3fff85db0520 , 
>>> oldval=) at ../../../libgomp/config/linux/mutex.c:63
>>> #4  0x3fff85d98b04 in gomp_mutex_lock (mutex=0x3fff85db0520 
>>> ) at ../../../libgomp/config/linux/mutex.h:57
>>> #5  goacc_register (disp=0x3fff85db0090 ) at 
>>> ../../../libgomp/oacc-init.c:74
>>> #6  0x3fff85d983fc in goacc_host_init () at 
>>> ../../../libgomp/oacc-host.c:265
>>> #7  0x3fff85d99c88 in goacc_runtime_initialize () at 
>>> ../../../libgomp/oacc-init.c:657
>>> #8  0x3fff85d7882c in initialize_env () at ../../../libgomp/env.c:1340
>>> #9  0x3fff86525c74 in _dl_init_internal () from /lib64/ld64.so.2
>>> #10 0x3fff865119cc in _dl_start_user () from /lib64/ld64.so.2
>>>
>>> $ msgfmt --version
>>> msgfmt (GNU gettext-tools) 0.18.2
>>>
>>> Is it a known issue, has anybody spotted that as well?
>> Yea, my ppc64le builds from late last week are stumbling on this as
>> well.  Could well be an environment thing -- if I go into
>> /libstdc++-v3/po and "make", it works just fine.
> 
> I did the same with the same result. Note that I can see the same problem
> on gcc110 machine :/
> 
> Martin
> 
>>
>> jeff
>>
> 

Hi.

So I've just tried to build latest 0.19.8 and it behaves the same. There's 
strace:

[pid 21880] set_tid_address(0x3fff80718f30) = 21880
[pid 21880] set_robust_list(0x3fff80718f40, 24) = 0
[pid 21880] rt_sigaction(SIGRTMIN, {0x3fff7fef6670, [], SA_SIGINFO}, NULL, 8) = 0
[pid 21880] rt_sigaction(SIGRT_1, {0x3fff7fef6770, [], SA_RESTART|SA_SIGINFO}, 
NULL, 8) = 0
[pid 21880] rt_sigprocmask(SIG_UNBLOCK, [RTMIN RT_1], NULL, 8) = 0
[pid 21880] getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, 
rlim_max=RLIM64_INFINITY}) = 0
[pid 21880] openat(AT_FDCWD, "/sys/devices/system/cpu", 
O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3
[pid 21880] brk(0)  = 0x1001ad6
[pid 21880] brk(0x1001ad9)  = 0x1001ad9
[pid 21880] getdents(3, /* 177 entries */, 32768) = 5576
[pid 21880] getdents(3, /* 0 entries */, 32768) = 0
[pid 21880] close(3)= 0
[pid 21880] sched_getaffinity(21880, 24, {, , 
}) = 24
[pid 21880] futex(0x3fff7ff70520, FUTEX_WAIT_PRIVATE, -1, NULLProcess 20859 
detached

Compared to situation when one directly invokes the command:

sched_getaffinity(23878, 24, {, , }) = 
24
open("/usr/lib/locale/locale-archive", O_RDONLY|O_CLOEXEC) = 3
fstat(3, {st_mode=S_IFREG|0644, st_size=109675168, ...}) = 0
mmap(NULL, 109675168, PROT_READ, MAP_PRIVATE, 3, 0) = 0x3fff9a7b
close(3)= 0
open("../../../../libstdc++-v3/po/de.po", O_RDONLY) = 3
fstat(3, {st_mode=S_IFREG|0664, st_size=749, ...}) = 0
mmap(NULL, 65536, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 
0x3fffa1c0
read(3, "# Translations needed for GNU C++ library locale implementation.\n# 
Copyright (C) 2001-2017 Free Software Foundation, Inc.\n# Benjamin Kosnik 
, 2001.\n#\n#, fuzzy\nmsgid \"\"\nmsgstr 
\"\"\n\"Project-Id-Version: libstdc++ 3.1.0\\n\"\n\"POT-Creation-Date: 
2001-07-31 08:49-0700\\n\"\n\"PO-Revision-Date: YEAR-MO-DA 
HO:MI+ZONE\\n\"\n\"Last-Translator: FULL NAME 
\\n\"\n\"Language-Team: LANGUAGE 
\\n\"\n\"MIME-Version: 1.0\\n\"\n\"Content-Type: text/plain; 
charset=ISO-8859-1\\n\"\n\"Content-Transfer-Encoding: 8-"..., 65536) = 749
open("/usr/lib64/gconv/gconv-modules.cache", O_RDONLY) = 4
fstat(4, {st_mode=S_IFREG|0644, st_size=26254, ...}) = 0
mmap(NULL, 26254, PROT_READ, MAP_SHARED, 4, 0) = 0x3fff9a7a
close(4)= 0
futex(0x3fffa16b25a0, FUTEX_WAKE_PRIVATE, 2147483647) = 0

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.

Martin

Re: Building on gcc112 is stuck in msgfmt

[Stefan Ring]

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 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  0x3fff85d8bac8 in sys_futex0 (val=-1, op=128, addr=0x3fff85db0520 
 ) at ../../../libgomp/config/linux/powerpc/futex.h:49
 #1  futex_wait (val=-1, addr=0x3fff85db0520 ) at 
 ../../../libgomp/config/linux/powerpc/futex.h:62
 #2  do_wait (val=-1, addr=) at 
 ../../../libgomp/config/linux/wait.h:67
 #3  gomp_mutex_lock_slow (mutex=0x3fff85db0520 , 
 oldval=) at ../../../libgomp/config/linux/mutex.c:63
 #4  0x3fff85d98b04 in gomp_mutex_lock (mutex=0x3fff85db0520 
 ) at ../../../libgomp/config/linux/mutex.h:57
 #5  goacc_register (disp=0x3fff85db0090 ) at 
 ../../../libgomp/oacc-init.c:74
 #6  0x3fff85d983fc in goacc_host_init () at 
 ../../../libgomp/oacc-host.c:265
 #7  0x3fff85d99c88 in goacc_runtime_initialize () at 
 ../../../libgomp/oacc-init.c:657
 #8  0x3fff85d7882c in initialize_env () at ../../../libgomp/env.c:1340
 #9  0x3fff86525c74 in _dl_init_internal () from /lib64/ld64.so.2
 #10 0x3fff865119cc 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.

Segfault generated by gcc-7

[Marco Varlese]

Hi,

I got a SEGFAULT in my program when compiling it with gcc-7 but it
is/was all good when using gcc-6.

The SEGFAULT happens due to the line below:
d_point = *p;

And a fix for it (with gcc-7) has been:
memcpy(&d_point, 
p, 
sizeof(d_point));

Does this make any sense to anybody?


Cheers,
Marco

Re: Segfault generated by gcc-7

[Markus Trippelsdorf]

On 2017.08.29 at 12:31 +0200, Marco Varlese wrote:
> Hi,
> 
> I got a SEGFAULT in my program when compiling it with gcc-7 but it
> is/was all good when using gcc-6.
> 
> The SEGFAULT happens due to the line below:
> d_point = *p;
> 
> And a fix for it (with gcc-7) has been:
> memcpy(&d_point, 
>   p, 
>   sizeof(d_point));
> 
> Does this make any sense to anybody?

No. Please open a bug and attach the full program that causes the crash.
Otherwise the issue is impossible to debug.

-- 
Markus

Re: Segfault generated by gcc-7

[Marek Polacek]

On Tue, Aug 29, 2017 at 12:31:39PM +0200, Marco Varlese wrote:
> Hi,
> 
> I got a SEGFAULT in my program when compiling it with gcc-7 but it
> is/was all good when using gcc-6.
> 
> The SEGFAULT happens due to the line below:
> d_point = *p;
> 
> And a fix for it (with gcc-7) has been:
> memcpy(&d_point, 
>   p, 
>   sizeof(d_point));
> 
> Does this make any sense to anybody?

Not without a stand-alone testcase.  See 
for more info.

Marek

Re: Segfault generated by gcc-7

[Markus Trippelsdorf]

On 2017.08.29 at 12:35 +0200, Markus Trippelsdorf wrote:
> On 2017.08.29 at 12:31 +0200, Marco Varlese wrote:
> > Hi,
> > 
> > I got a SEGFAULT in my program when compiling it with gcc-7 but it
> > is/was all good when using gcc-6.
> > 
> > The SEGFAULT happens due to the line below:
> > d_point = *p;
> > 
> > And a fix for it (with gcc-7) has been:
> > memcpy(&d_point, 
> > p, 
> > sizeof(d_point));
> > 
> > Does this make any sense to anybody?
> 
> No. Please open a bug and attach the full program that causes the crash.
> Otherwise the issue is impossible to debug.

But my guess would be a misaligned address. Try building with
-fsanitize=undefined and fix all issues the sanitizer points out.

-- 
Markus

Re: Building on gcc112 is stuck in msgfmt

[Martin Liška]

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 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  0x3fff85d8bac8 in sys_futex0 (val=-1, op=128, addr=0x3fff85db0520 
> ) at ../../../libgomp/config/linux/powerpc/futex.h:49
> #1  futex_wait (val=-1, addr=0x3fff85db0520 ) at 
> ../../../libgomp/config/linux/powerpc/futex.h:62
> #2  do_wait (val=-1, addr=) at 
> ../../../libgomp/config/linux/wait.h:67
> #3  gomp_mutex_lock_slow (mutex=0x3fff85db0520 , 
> oldval=) at ../../../libgomp/config/linux/mutex.c:63
> #4  0x3fff85d98b04 in gomp_mutex_lock (mutex=0x3fff85db0520 
> ) at ../../../libgomp/config/linux/mutex.h:57
> #5  goacc_register (disp=0x3fff85db0090 ) at 
> ../../../libgomp/oacc-init.c:74
> #6  0x3fff85d983fc in goacc_host_init () at 
> ../../../libgomp/oacc-host.c:265
> #7  0x3fff85d99c88 in goacc_runtime_initialize () at 
> ../../../libgomp/oacc-init.c:657
> #8  0x3fff85d7882c in initialize_env () at ../../../libgomp/env.c:1340
> #9  0x3fff86525c74 in _dl_init_internal () from /lib64/ld64.so.2
> #10 0x3fff865119cc 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  0x3fff950e58e4 in syscall () from /lib64/libc.so.6
#1  0x3fff94dbbdc4 in __cxxabiv1::__cxa_guard_acquire (g=0x3fff94f26d40 
) at 
../../../../libstdc++-v3/libsupc++/guard.cc:302
#2  0x3fff94dfaf80 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  0x3fff94da98e8 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  0x3fff96105c74 in _dl_init_internal () from /lib64/ld64.so.2
#7  0x3fff960f19cc 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

Re: Building on gcc112 is stuck in msgfmt

[Martin Liška]

On 08/29/2017 12:39 PM, Martin Liška wrote:
> (gdb) bt
> #0  0x3fff950e58e4 in syscall () from /lib64/libc.so.6
> #1  0x3fff94dbbdc4 in __cxxabiv1::__cxa_guard_acquire (g=0x3fff94f26d40 
>  namespace)::__future_category_instance()::__fec>) at 
> ../../../../libstdc++-v3/libsupc++/guard.cc:302
> #2  0x3fff94dfaf80 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  0x3fff94da98e8 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  0x3fff96105c74 in _dl_init_internal () from /lib64/ld64.so.2
> #7  0x3fff960f19cc in _dl_start_user () from /lib64/ld64.so.2

strace says about it:

futex(0x3fffa5226d40, FUTEX_WAIT, 0, NULL) = -1 EAGAIN (Resource temporarily 
unavailable)
futex(0x3fffa5226d40, FUTEX_WAIT, 0, NULL) = -1 EAGAIN (Resource temporarily 
unavailable)
futex(0x3fffa5226d40, FUTEX_WAIT, 0, NULL) = -1 EAGAIN (Resource temporarily 
unavailable)
futex(0x3fffa5226d40, FUTEX_WAIT, 0, NULL) = -1 EAGAIN (Resource temporarily 
unavailable)
futex(0x3fffa5226d40, FUTEX_WAIT, 0, NULL) = -1 EAGAIN (Resource temporarily 
unavailable)
futex(0x3fffa5226d40, FUTEX_WAIT, 0, NULL) = -1 EAGAIN (Resource temporarily 
unavailable)
futex(0x3fffa5226d40, FUTEX_WAIT, 0, NULL) = -1 EAGAIN (Resource temporarily 
unavailable)
futex(0x3fffa5226d40, FUTEX_WAIT, 0, NULL) = -1 EAGAIN (Resource temporarily 
unavailable)
futex(0x3fffa5226d40, FUTEX_WAIT, 0, NULL) = -1 EAGAIN (Resource temporarily 
unavailable)
futex(0x3fffa5226d40, FUTEX_WAIT, 0, NULL) = -1 EAGAIN (Resource temporarily 
unavailable)
futex(0x3fffa5226d40, FUTEX_WAIT, 0, NULL) = -1 EAGAIN (Resource temporarily 
unavailable)
futex(0x3fffa5226d40, FUTEX_WAIT, 0, NULL) = -1 EAGAIN (Resource temporarily 
unavailable)
futex(0x3fffa5226d40, FUTEX_WAIT, 0, NULL) = -1 EAGAIN (Resource temporarily 
unavailable)
futex(0x3fffa5226d40, FUTEX_WAIT, 0, NULL) = -1 EAGAIN (Resource temporarily 
unavailable)
futex(0x3fffa5226d40, FUTEX_WAIT, 0, NULL) = -1 EAGAIN (Resource temporarily 
unavailable)
futex(0x3fffa5226d40, FUTEX_WAIT, 0, NULL) = -1 EAGAIN (Resource temporarily 
unavailable)
futex(0x3fffa5226d40, FUTEX_WAIT, 0, NULL) = -1 EAGAIN (Resource temporarily 
unavailable)
futex(0x3fffa5226d40, FUTEX_WAIT, 0, NULL) = -1 EAGAIN (Resource temporarily 
unavailable)
futex(0x3fffa5226d40, FUTEX_WAIT, 0, NULL) = -1 EAGAIN (Resource temporarily 
unavailable)
futex(0x3fffa5226d40, FUTEX_WAIT, 0, NULL) = -1 EAGAIN (Resource temporarily 
unavailable)
...

Re: Building on gcc112 is stuck in msgfmt

[Markus Trippelsdorf]

On 2017.08.29 at 12:42 +0200, Martin Liška wrote:
> On 08/29/2017 12:39 PM, Martin Liška wrote:
> > (gdb) bt
> > #0  0x3fff950e58e4 in syscall () from /lib64/libc.so.6
> > #1  0x3fff94dbbdc4 in __cxxabiv1::__cxa_guard_acquire (g=0x3fff94f26d40 
> >  > namespace)::__future_category_instance()::__fec>) at 
> > ../../../../libstdc++-v3/libsupc++/guard.cc:302
> > #2  0x3fff94dfaf80 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  0x3fff94da98e8 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  0x3fff96105c74 in _dl_init_internal () from /lib64/ld64.so.2
> > #7  0x3fff960f19cc in _dl_start_user () from /lib64/ld64.so.2
> 
> strace says about it:
> 
> futex(0x3fffa5226d40, FUTEX_WAIT, 0, NULL) = -1 EAGAIN (Resource temporarily 
> unavailable)

To me the whole issue looks related to PR81931.
Are you using a clean build directory? Make sure you have the r251328
fix.

-- 
Markus

Re: Building on gcc112 is stuck in msgfmt

[Martin Liška]

On 08/29/2017 12:47 PM, Markus Trippelsdorf wrote:
> On 2017.08.29 at 12:42 +0200, Martin Liška wrote:
>> On 08/29/2017 12:39 PM, Martin Liška wrote:
>>> (gdb) bt
>>> #0  0x3fff950e58e4 in syscall () from /lib64/libc.so.6
>>> #1  0x3fff94dbbdc4 in __cxxabiv1::__cxa_guard_acquire (g=0x3fff94f26d40 
>>> >> namespace)::__future_category_instance()::__fec>) at 
>>> ../../../../libstdc++-v3/libsupc++/guard.cc:302
>>> #2  0x3fff94dfaf80 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  0x3fff94da98e8 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  0x3fff96105c74 in _dl_init_internal () from /lib64/ld64.so.2
>>> #7  0x3fff960f19cc in _dl_start_user () from /lib64/ld64.so.2
>>
>> strace says about it:
>>
>> futex(0x3fffa5226d40, FUTEX_WAIT, 0, NULL) = -1 EAGAIN (Resource temporarily 
>> unavailable)
> 
> To me the whole issue looks related to PR81931.
> Are you using a clean build directory? Make sure you have the r251328
> fix.>

Yep. Directory was cleaner. I don't have the revision. Let me re-test it.
How can it be related to the PR as msgfmt is taken from system?

Martin

Re: Building on gcc112 is stuck in msgfmt

[Markus Trippelsdorf]

On 2017.08.29 at 12:53 +0200, Martin Liška wrote:
> On 08/29/2017 12:47 PM, Markus Trippelsdorf wrote:
> > On 2017.08.29 at 12:42 +0200, Martin Liška wrote:
> >> On 08/29/2017 12:39 PM, Martin Liška wrote:
> >>> (gdb) bt
> >>> #0  0x3fff950e58e4 in syscall () from /lib64/libc.so.6
> >>> #1  0x3fff94dbbdc4 in __cxxabiv1::__cxa_guard_acquire 
> >>> (g=0x3fff94f26d40  >>> namespace)::__future_category_instance()::__fec>) at 
> >>> ../../../../libstdc++-v3/libsupc++/guard.cc:302
> >>> #2  0x3fff94dfaf80 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  0x3fff94da98e8 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  0x3fff96105c74 in _dl_init_internal () from /lib64/ld64.so.2
> >>> #7  0x3fff960f19cc in _dl_start_user () from /lib64/ld64.so.2
> >>
> >> strace says about it:
> >>
> >> futex(0x3fffa5226d40, FUTEX_WAIT, 0, NULL) = -1 EAGAIN (Resource 
> >> temporarily unavailable)
> > 
> > To me the whole issue looks related to PR81931.
> > Are you using a clean build directory? Make sure you have the r251328
> > fix.>
> 
> Yep. Directory was cleaner. I don't have the revision. Let me re-test it.
> How can it be related to the PR as msgfmt is taken from system?

It may load a broken libstdc++.so.6 that was build without the fix.

-- 
Markus

Re: Segfault generated by gcc-7

[Jonathan Wakely]

On 29 August 2017 at 11:38, Marek Polacek wrote:
> On Tue, Aug 29, 2017 at 12:31:39PM +0200, Marco Varlese wrote:
>> Hi,
>>
>> I got a SEGFAULT in my program when compiling it with gcc-7 but it
>> is/was all good when using gcc-6.
>>
>> The SEGFAULT happens due to the line below:
>> d_point = *p;
>>
>> And a fix for it (with gcc-7) has been:
>> memcpy(&d_point,
>>   p,
>>   sizeof(d_point));
>>
>> Does this make any sense to anybody?
>
> Not without a stand-alone testcase.  See 
> for more info.

Also please note that this mailing list is for discussing the
development of GCC itself. For help and support use the
gcc-h...@gcc.gnu.org list instead.

Re: Building on gcc112 is stuck in msgfmt

[Martin Liška]

On 08/29/2017 12:55 PM, Markus Trippelsdorf wrote:
> On 2017.08.29 at 12:53 +0200, Martin Liška wrote:
>> On 08/29/2017 12:47 PM, Markus Trippelsdorf wrote:
>>> On 2017.08.29 at 12:42 +0200, Martin Liška wrote:
 On 08/29/2017 12:39 PM, Martin Liška wrote:
> (gdb) bt
> #0  0x3fff950e58e4 in syscall () from /lib64/libc.so.6
> #1  0x3fff94dbbdc4 in __cxxabiv1::__cxa_guard_acquire 
> (g=0x3fff94f26d40  namespace)::__future_category_instance()::__fec>) at 
> ../../../../libstdc++-v3/libsupc++/guard.cc:302
> #2  0x3fff94dfaf80 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  0x3fff94da98e8 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  0x3fff96105c74 in _dl_init_internal () from /lib64/ld64.so.2
> #7  0x3fff960f19cc in _dl_start_user () from /lib64/ld64.so.2

 strace says about it:

 futex(0x3fffa5226d40, FUTEX_WAIT, 0, NULL) = -1 EAGAIN (Resource 
 temporarily unavailable)
>>>
>>> To me the whole issue looks related to PR81931.
>>> Are you using a clean build directory? Make sure you have the r251328
>>> fix.>
>>
>> Yep. Directory was cleaner. I don't have the revision. Let me re-test it.
>> How can it be related to the PR as msgfmt is taken from system?
> 
> It may load a broken libstdc++.so.6 that was build without the fix.
> 

Yep. I can confirm that it helped to update to a revision after r251328.

Martin

Re: gcc torture test pr52286.c

[Michael Matz]

Hi,

On Mon, 28 Aug 2017, Jeff Law wrote:

> >   asm ("" : "=r" (x) : "r" (y+z));
> >   asm ("" : "=r" (x) : "r" (z));
> >   asm ("" : "=r" (x) : "r" (42));
> 
> > 
> > (are we still agreeing on this?  I'm having a problem understanding why 
> > you think the above wouldn't work)
> 
> How do we represent the y+z case in particular.  Isn't that shoved into 
> a gimple temporary and ultimately a pseudo?

On the GIMPLE side asm operands (inputs) are generally transformed into 
is_gimple_val, i.e. constants or scalar temporaries.  Up to the RTL side 
this usually remains, i.e. yes, y+z will be placed into a pseudo.

Since (at least) introduction of GIMPLE, also constants (actually anything 
non-register_operand) will be rewritten into a pseudo already by cfgexpand 
if the alternative accepts only a reg (or matches one accepting only a 
reg).

But also LRA (and reload) will happily accept a constant in those operands 
and reload it into a reg (in reload/lra parlance, that alternative isn't 
matching as is, i.e. has loosers, but can be made matching by reloading, 
i.e. it's not failing).  It's generally the case that alternatives that 
accept a register can accept all kinds of operands as inputs (basically 
force_reg must work on it, so there are additional constraints like 
impossible modes and such).

That's also true for matching constraints were the matched one accepts a 
register: if the operands aren't operand_equal_p right now it merely means 
the alternative has loosers currently, but as registers are acceptable 
that's fine.  Matching constraints do add some further constraints, but 
not regarding the kinds of operands it accepts.  Like in this situation:

  asm("" : "=r" (op0): "2" (op1), "0" (op2));

(assuming op0/op1/op2 all don't match at the point of LRA), then to make 
op0 and op2 match a reload of op2 is needed.  But that'd invalidate the 
reload that was created for op1 to make that one match op2 (operands are 
matched/reloaded in order).  LRA can't deal with this situation so it 
gives up here.

All the gunk for this is in process_alt_operands().  As soon as either 
badop==false or any of winreg, win or did_match is set after constraint 
parsing the operand (of whatever form) is mostly acceptable (perhaps with 
reloads) under still some further constraints like mode checks and such.  
It's essentially the same code like in find_reloads (though I find the 
latter slightly easier to read, strangely enough :) ).

> > Which is a perfectly fine rvalue.  Input constraints never need lvalues 
> > (or objects).  Maybe you're confusing this all with one particularity that 
> > _if_ the input rvalue stems from an object and that object happens to be 
> > allocated to a hardreg (via an asm("regname") declaration) then this 
> > hardreg will be used as input register?  In that way some information 
> > from lvalues also flows into input operands, but it's not generally the 
> > case that they must be lvalues.
> True.  I'm not thinking in terms of lvalues and rvalues, but in terms of
> allocnos and pseudos that the allocators and reloaders operate on.

For all the above cases, i.e. when non-fitting alternatives accepting 
registers are involved, pseudos and hence allocnos will eventually be 
created.  The operands don't need to start out as pseudos.

> Going back to pshortis issue, it's interesting how the size of the input 
> operand is being used to determine the mode of the matching output 
> operand.  That ought to be not-too-difficult to find within GCC...  
> With any luck there'd be a useful comment in that code.

I think that is just a presentation problem.  The printing of asms is 
fairly unintuitive.  What he had was these two RTL dumps of the asm in 
question:

   (insn 6 5 7 2 (set (reg:SI 29 [ a ])
(asm_operands:SI ("") ("=r") 0
 [ (reg:HI 30) ]
 [ (asm_input:HI ("0") ] ...

(with integer 0)

   (insn 6 5 7 2 (set (reg:SI 29 [ a ])
(asm_operands:SI ("") ("=r") 0
[ (reg:SI 30) ]
[ (asm_input:SI ("0") ] ...

(with long 0).

What is unintuitive here is that '[ (reg:XX 30) ]' might be mistaken for 
an output operand and mode, because there's that other mentioning of 
'asm_input:XX'.  That's not true.  (reg:XX 30) is the first input, and 
hence correctly reflects HI/SI mode depending on type of value.  The 
output operand is actually the (asm_operands:SI ("") ("=r")), which has 
the correct SImode in both cases.  (And the asm_input:XX is there to have 
a place to store the constraint connected with the input)

Looking at asms with multiple outputs and inputs makes that more obvious.  
E.g.

long a,b, i,j;
asm volatile ("XXX" : "=r" (a), "=r" (b) : "0" (i), "1" (j), "r" (j));

comes out as 

  (insn 12 11 7 (parallel [
(set (reg:DI 87 [ a ])
(asm_operands/v:DI ("XXX") ("=r") 0 [
(reg:DI 89)
(reg:DI 90)
(reg:DI 91)
 

Re: gcc torture test pr52286.c

[Segher Boessenkool]

On Mon, Aug 28, 2017 at 05:49:22PM -0600, Jeff Law wrote:
> Going back to pshortis issue, it's interesting how the size of the input
> operand is being used to determine the mode of the matching output
> operand.  That ought to be not-too-difficult to find within GCC...  With
> any luck there'd be a useful comment in that code.

Yeah that was surprising, and could even be considered a bug.


Segher

Re: Building on gcc112 is stuck in msgfmt

[Jason Mancini]

Been doing stability testing on my x86_64 Ryzen cpu using openSUSE's 
(Tumbleweed) "gcc7.1.1 20170802" + compiling Linux kernel source.  Every so 
often, the build curiously stalls on a futex between cc1 and as.  cc1 is on the 
futex.  as is waiting to read.  Could that hang be related to what's being 
discussed here?

Update to Installing GCC Page

[Colin Prior]

Hello GCC folks

Please can you add:

UNIX Packages www.unixpackages.com to your list of providers of GCC for
Solaris.

We have been providing pre-compiled GCC for over 20 years, initially as
Sunfreeware and then transitioning to UNIX Packages in 2010.

Many thanks

Colin Prior
UNIX Packages
+1 206 310 4610
co...@unixpackages.com

Re: Building on gcc112 is stuck in msgfmt

[Markus Trippelsdorf]

On 2017.08.29 at 15:22 +, Jason Mancini wrote:
> Been doing stability testing on my x86_64 Ryzen cpu using openSUSE's
> (Tumbleweed) "gcc7.1.1 20170802" + compiling Linux kernel source.
> Every so often, the build curiously stalls on a futex between cc1 and
> as.  cc1 is on the futex.  as is waiting to read.  Could that hang be
> related to what's being discussed here?

No. Ryzen is buggy. If you have a chip that was produced before June
this year, your only option is to RMA it.

-- 
Markus

Re: Update to Installing GCC Page

[Anatoly Pugachev]

On Tue, Aug 29, 2017 at 6:59 PM, Colin Prior  wrote:
> Hello GCC folks
>
> Please can you add:
>
> UNIX Packages www.unixpackages.com to your list of providers of GCC for
> Solaris.
>
> We have been providing pre-compiled GCC for over 20 years, initially as
> Sunfreeware and then transitioning to UNIX Packages in 2010.

probably offtopic, so sorry...

sunfreeware was free for download (and I was using it for solaris 9/10
packages back in 2006), while unixpackages don't have free download
(for $50/year you have an option to download 10 packages), this was
the end of sunfreeware/unixpackages for me , and I started to use
opencsw.org [1]. I believe opencsw (package repo, bug tracker, build
farm, wiki, community) is a better candidate for the link, but it's up
for gcc site maintainers.

1. https://www.opencsw.org/

gcc-5-20170829 is now available

[gccadmin]

Snapshot gcc-5-20170829 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/5-20170829/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5-branch 
revision 251440

You'll find:

 gcc-5-20170829.tar.xzComplete GCC

  SHA256=db247faf2738f85a002ee9e7b5941bf1f8a4b45d81703535188918ca9b48fcd4
  SHA1=1cee23fa0a930730991f41ab3f782b2d8b809fea

Diffs from 5-20170822 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-5
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Redundant sign-extension instructions on RISC-V

[Michael Clark]

Dear GCC folk,


# Issue Background

We’re investigating an issue with redundant sign-extension instructions being 
emitted with the riscv backend. Firstly I would like to state that riscv is 
possibly a unique backend with respect to its canonical sign-extended register 
form due to the following:

- POINTERS_EXTEND_UNSIGNED is false, and the canonical form after 32-bit 
operations on RV64 is sign-extended not zero-extended.

- PROMOTE_MODE is defined on RV64 such that SI mode values are promoted to 
signed DI mode values holding SI mode subregs

- RISC-V does not have register aliases for these different modes, rather 
different instructions are selected to operate on different register widths.

- The 32-bit instructions sign-extend results. e.g. all shifts, add, sub, etc.

- Some instructions such as logical ops only have full word width variants 
(AND, OR, XOR) but these instructions maintain canonical form as there is no 
horizontal movement of bits.


# Issue Details

During porting from GCC 6.1 to GCC 7.1, the RISC-V port was changed to define 
TRULY_NOOP_TRUNCATION to 1 and PROMOTE_MODE was set up to promote values to 
wider modes. This was done to ensure ABI correctness so that registers holding 
narrower modes always contain canonical sign extended values.

The result of this is that sign_extend operations are inserted but later 
eliminated in ree/simplyfy_rtx. In testcase 3 the sign_extend is correctly 
eliminated, and indeed most 32-bit instructions are handled correctly. This is 
what the pattern looks like for a typical 32-bit instruction after expand:

;;
;; Full RTL generated for this function:
;;
(note 1 0 4 NOTE_INSN_DELETED)
(note 4 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(insn 2 4 3 2 (set (reg/v:DI 73 [ rs1 ])
   (reg:DI 10 a0 [ rs1 ])) "lshift.c":1 -1
(nil))
(note 3 2 6 2 NOTE_INSN_FUNCTION_BEG)
(insn 6 3 7 2 (set (reg:SI 74)
   (ashift:SI (subreg/s/u:SI (reg/v:DI 73 [ rs1 ]) 0)
   (const_int 24 [0x18]))) "lshift.c":1 -1
(nil))
(insn 7 6 8 2 (set (reg:DI 75)
   (sign_extend:DI (reg:SI 74))) "lshift.c":1 -1
(nil))
(insn 8 7 12 2 (set (reg:DI 72 [  ])
   (reg:DI 75)) "lshift.c":1 -1
(nil))
(insn 12 8 13 2 (set (reg/i:DI 10 a0)
   (reg:DI 72 [  ])) "lshift.c":1 -1
(nil))
(insn 13 12 0 2 (use (reg/i:DI 10 a0)) "lshift.c":1 -1
(nil))


# Problem test cases

- testcase 1 - open coded bswap - redundant sign extension instructions
- testcase 2 - open coded right shift - redundant sign extension instructions
- testcase 3 - open coded left shift - control / correct behaviour

It appears that the downside to the PROMOTE_MODE transition is that several 
redundant sign-extension operations are cropping up under specific 
circumstances. One of the first small isolators is testcase 1 (below), which is 
an open-coded bswap. You’ll notice the SEXT.W emitted before the return. This 
was then further isolated to an even simpler testcase 2 which is a single right 
shift which also emits SEXT.W before the return. A 32-bit left shift or other 
32-bit operations correctly have the redundant sign_extend eliminated.

We have isolated the code that prevented the right shift from having its 
redundant sign extension eliminated and it is target independent code in 
simplify-rtx. Code in simplify_unary_operation_1 assumes zero extension is more 
efficient, likely an assumption based on the fact that most platforms define 
POINTERS_EXTEND_UNSIGNED to true and naturally promote words to zero extended 
form vs sign extended form. The redundant sign extension appears to be due to 
an optimisation in simply_rtx that generates zero extend for right shifts where 
the value is non zero, based on the assumption that zero extend is” better”. 
This is not true on platforms that define POINTERS_EXTEND_UNSIGNED to false 
i.e. naturally promote subregister width operations to canonical sign-extended 
form internally.


# Partial resolution of test case 2

We have prepared a patch that disables the zero extend optimisation on 
platforms that define POINTERS_EXTEND_UNSIGNED. It fixes the issue in testcase 
2. We believe this fix is very low risk because right shift for values above 
zero will always have a zero sign bit, thus either sign or zero extension can 
be used (this is in the comment), however sign-extension is “better” on RISC-V 
and likely all other platforms with POINTERS_EXTEND_UNSIGNED false. Platforms 
like x86, Aarch64 and most others define POINTERS_EXTEND_UNSIGNED to 1 so would 
not be affected by this change.

Please review this candidate patch to fix the codegen issue for testcase 2.


diff --git a/gcc/simplify-rtx.c b/gcc/simplify-rtx.c
index ce632ae..25dd70f 100644
--- a/gcc/simplify-rtx.c
+++ b/gcc/simplify-rtx.c
@@ -1503,6 +1503,10 @@ simplify_unary_operation_1 (enum rtx_code code, 
machine_mode mode, rtx op)
  /* (sign_extend:M (lshiftrt:N  (const_int I))) is better as
 (zero_extend:M (lshiftrt:N  (const_int I))) if I is not 0.  */
  if (GET_

Re: Redundant sign-extension instructions on RISC-V

[Michael Clark]

> On 30 Aug 2017, at 12:36 PM, Michael Clark  wrote:
> 
> Dear GCC folk,
> 
> 
> # Issue Background
> 
> We’re investigating an issue with redundant sign-extension instructions being 
> emitted with the riscv backend. Firstly I would like to state that riscv is 
> possibly a unique backend with respect to its canonical sign-extended 
> register form due to the following:
> 
> - POINTERS_EXTEND_UNSIGNED is false, and the canonical form after 32-bit 
> operations on RV64 is sign-extended not zero-extended.
> 
> - PROMOTE_MODE is defined on RV64 such that SI mode values are promoted to 
> signed DI mode values holding SI mode subregs
> 
> - RISC-V does not have register aliases for these different modes, rather 
> different instructions are selected to operate on different register widths.
> 
> - The 32-bit instructions sign-extend results. e.g. all shifts, add, sub, etc.
> 
> - Some instructions such as logical ops only have full word width variants 
> (AND, OR, XOR) but these instructions maintain canonical form as there is no 
> horizontal movement of bits.
> 
> 
> # Issue Details
> 
> During porting from GCC 6.1 to GCC 7.1, the RISC-V port was changed to define 
> TRULY_NOOP_TRUNCATION to 1 and PROMOTE_MODE was set up to promote values to 
> wider modes. This was done to ensure ABI correctness so that registers 
> holding narrower modes always contain canonical sign extended values.
> 
> The result of this is that sign_extend operations are inserted but later 
> eliminated in ree/simplyfy_rtx. In testcase 3 the sign_extend is correctly 
> eliminated, and indeed most 32-bit instructions are handled correctly. This 
> is what the pattern looks like for a typical 32-bit instruction after expand:
> 
> ;;
> ;; Full RTL generated for this function:
> ;;
> (note 1 0 4 NOTE_INSN_DELETED)
> (note 4 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
> (insn 2 4 3 2 (set (reg/v:DI 73 [ rs1 ])
>   (reg:DI 10 a0 [ rs1 ])) "lshift.c":1 -1
>(nil))
> (note 3 2 6 2 NOTE_INSN_FUNCTION_BEG)
> (insn 6 3 7 2 (set (reg:SI 74)
>   (ashift:SI (subreg/s/u:SI (reg/v:DI 73 [ rs1 ]) 0)
>   (const_int 24 [0x18]))) "lshift.c":1 -1
>(nil))
> (insn 7 6 8 2 (set (reg:DI 75)
>   (sign_extend:DI (reg:SI 74))) "lshift.c":1 -1
>(nil))
> (insn 8 7 12 2 (set (reg:DI 72 [  ])
>   (reg:DI 75)) "lshift.c":1 -1
>(nil))
> (insn 12 8 13 2 (set (reg/i:DI 10 a0)
>   (reg:DI 72 [  ])) "lshift.c":1 -1
>(nil))
> (insn 13 12 0 2 (use (reg/i:DI 10 a0)) "lshift.c":1 -1
>(nil))
> 
> 
> # Problem test cases
> 
> - testcase 1 - open coded bswap - redundant sign extension instructions
> - testcase 2 - open coded right shift - redundant sign extension instructions
> - testcase 3 - open coded left shift - control / correct behaviour
> 
> It appears that the downside to the PROMOTE_MODE transition is that several 
> redundant sign-extension operations are cropping up under specific 
> circumstances. One of the first small isolators is testcase 1 (below), which 
> is an open-coded bswap. You’ll notice the SEXT.W emitted before the return. 
> This was then further isolated to an even simpler testcase 2 which is a 
> single right shift which also emits SEXT.W before the return. A 32-bit left 
> shift or other 32-bit operations correctly have the redundant sign_extend 
> eliminated.
> 
> We have isolated the code that prevented the right shift from having its 
> redundant sign extension eliminated and it is target independent code in 
> simplify-rtx. Code in simplify_unary_operation_1 assumes zero extension is 
> more efficient, likely an assumption based on the fact that most platforms 
> define POINTERS_EXTEND_UNSIGNED to true and naturally promote words to zero 
> extended form vs sign extended form. The redundant sign extension appears to 
> be due to an optimisation in simply_rtx that generates zero extend for right 
> shifts where the value is non zero, based on the assumption that zero extend 
> is” better”. This is not true on platforms that define 
> POINTERS_EXTEND_UNSIGNED to false i.e. naturally promote subregister width 
> operations to canonical sign-extended form internally.
> 
> 
> # Partial resolution of test case 2
> 
> We have prepared a patch that disables the zero extend optimisation on 
> platforms that define POINTERS_EXTEND_UNSIGNED. It fixes the issue in 
> testcase 2. We believe this fix is very low risk because right shift for 
> values above zero will always have a zero sign bit, thus either sign or zero 
> extension can be used (this is in the comment), however sign-extension is 
> “better” on RISC-V and likely all other platforms with 
> POINTERS_EXTEND_UNSIGNED false. Platforms like x86, Aarch64 and most others 
> define POINTERS_EXTEND_UNSIGNED to 1 so would not be affected by this change.
> 
> Please review this candidate patch to fix the codegen issue for testcase 2.
> 
> 
> diff --git a/gcc/simplify-rtx.c b/gcc/simplify-rtx.c
> index ce632ae..25dd70f 100644
> --- a/gcc/simplify-rtx.c
> +++ b/gcc/