Re: Missed optimization with const member
On 05/07/2017 17:24, Martin Sebor wrote:
[*] While the example (copied below) is valid, accessing the object
after someFunction() has returned via a reference or pointer to it
is not.
void somefunction(const Object& object);
{
void* p = &object;
object.~Object();
new(p) Object();
}
I think it's problematic as explained in p0532r0.pdf. We construct and
destroy objects in the internal buffer of std::vector and we don't
update the pointer every time. I don't see myself understanding when
std::launder must be used, looks too expert-grade feature.
Best,
Ion
timeouts/malloc failures in ada tests?
I see large numbers of timeouts in Ada tests on trunk in parallel run s (make -j96) on x86_64. Messages like the one below appear in the logs, suggesting some sort of heap corruption. I'm having trouble reproducing it outside the rest of the test suite (i.e., by just running the Ada tests by themselves) but maybe I'm doing it wrong. Unless this is a known problem I can try to pinpoint it closer if someone could share the magic spell to run just Ada tests to speed up the debugging. Is it (a known problem)? Martin PS I've been using make -j96 for a long time on this machine and this a recent regression. The machine has 56 cores, 200GB RAM, and runs Fedora 25. spawn -ignore SIGHUP /opt/notnfs/msebor/build/gcc-81117/gcc/gnatclean -c -q -n d ispatch2_p gnatclean: malloc.c:2403: sysmalloc: Assertion `(old_top == initial_top (av) && old_size == 0) || ((unsigned long) (old_size) >= MINSIZE && prev_inuse (old_top) && ((unsigned long) old_end & (pagesize - 1)) == 0)' failed. WARNING: program timed out
Re: timeouts/malloc failures in ada tests?
> I see large numbers of timeouts in Ada tests on trunk in parallel > run s (make -j96) on x86_64. Messages like the one below appear > in the logs, suggesting some sort of heap corruption. I'm having > trouble reproducing it outside the rest of the test suite (i.e., > by just running the Ada tests by themselves) but maybe I'm doing > it wrong. Unless this is a known problem I can try to pinpoint > it closer if someone could share the magic spell to run just Ada > tests to speed up the debugging. > > Is it (a known problem)? No, but regressions were recently introduced in the ACATS testsuite: === acats tests === FAIL: cb4008a FAIL: cb41001 so this could be related. Ada is not enabled by default so this is not surprising. It's OK for small changes and bug fixes, but people making extensive changes to the compiler should really consider enabling it (and it's a very good testbed). -- Eric Botcazou
Re: timeouts/malloc failures in ada tests?
On 7/7/2017 17:38, Eric Botcazou wrote: I see large numbers of timeouts in Ada tests on trunk in parallel run s (make -j96) on x86_64. Messages like the one below appear in the logs, suggesting some sort of heap corruption. I'm having trouble reproducing it outside the rest of the test suite (i.e., by just running the Ada tests by themselves) but maybe I'm doing it wrong. Unless this is a known problem I can try to pinpoint it closer if someone could share the magic spell to run just Ada tests to speed up the debugging. Is it (a known problem)? No, but regressions were recently introduced in the ACATS testsuite: === acats tests === FAIL: cb4008a FAIL: cb41001 so this could be related. Ada is not enabled by default so this is not surprising. It's OK for small changes and bug fixes, but people making extensive changes to the compiler should really consider enabling it (and it's a very good testbed). Good timing on this post! I just finished my first test build in a while using a new unwind patch for dragonfly (it moved the signal trampoline, breaking the previous unwind) and I saw these exact two failures. Even though the new patch has been in use for months, I was still thinking it caused the test failures. Thanks for piping up, Eric! :) John P.S. I'll post the dragonfly-specific unwind patch to the patches mail list later today. It's been tested internally for weeks.
x86 branches vs conditional moves
Hi,
Curious about this codegen:
- https://godbolt.org/g/5XxP5S
Why does gcc branch on _Bool, but emits a conditional move for an integer? can
it emit cmovne instead of branching? also curious where one would change this
to learn about GCC internals.
It’s not a bug, but it is a performance issue (*1).
I was just curious under which conditions the ternary operator is lowered to
cmov on x86 and found this difference in lowering.
Michael
[1] https://github.com/xiadz/cmov
#include
extern int a;
extern int b;
extern int c;
extern _Bool C;
int select_int()
{
return c ? a : b;
}
_Bool select_bool()
{
return C ? a : b;
}
_Bool a_bool()
{
return 2;
}
select_int():
mov eax, DWORD PTR c[rip]
testeax, eax
mov eax, DWORD PTR a[rip]
cmove eax, DWORD PTR b[rip]
ret
select_bool():
cmp BYTE PTR C[rip], 0
jne .L8
mov eax, DWORD PTR b[rip]
testeax, eax
setne al
ret
.L8:
mov edx, DWORD PTR a[rip]
testedx, edx
setne al
ret
a_bool():
mov eax, 1
ret
