parallel make check: duplicated test results
Since a few months, I'm having a lot of trouble comparing test results
using contrib/compare_tests because there are duplicated test results
when using parallel make check.
make -k -j10 check RUNTESTFLAGS=--target_board=unix/\{-m32,-m64\}
will sometimes run:
Executing on host:
/home/manuel/test3/224844M/build/gcc/testsuite/g++2/../../xg++
-B/home/manuel/test3/224844M/build/gcc/testsuite/g++2/../../
/home/manuel/test3/src/gcc/testsuite/c-c++-common/torture/pr42834.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++
-I/home/manuel/test3/224844M/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu
-I/home/manuel/test3/224844M/build/x86_64-unknown-linux-gnu/libstdc++-v3/include
-I/home/manuel/test3/src/libstdc++-v3/libsupc++
-I/home/manuel/test3/src/libstdc++-v3/include/backward
-I/home/manuel/test3/src/libstdc++-v3/testsuite/util
-fmessage-length=0 -O0
-L/home/manuel/test3/224844M/build/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-B/home/manuel/test3/224844M/build/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-L/home/manuel/test3/224844M/build/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-lm -m64 -o ./pr42834.exe(timeout = 300)
Executing on host:
/home/manuel/test3/224844M/build/gcc/testsuite/g++1/../../xg++
-B/home/manuel/test3/224844M/build/gcc/testsuite/g++1/../../
/home/manuel/test3/src/gcc/testsuite/c-c++-common/torture/pr42834.c
-fno-diagnostics-show-caret -fdiagnostics-color=never -nostdinc++
-I/home/manuel/test3/224844M/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu
-I/home/manuel/test3/224844M/build/x86_64-unknown-linux-gnu/libstdc++-v3/include
-I/home/manuel/test3/src/libstdc++-v3/libsupc++
-I/home/manuel/test3/src/libstdc++-v3/include/backward
-I/home/manuel/test3/src/libstdc++-v3/testsuite/util
-fmessage-length=0 -O0
-L/home/manuel/test3/224844M/build/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-B/home/manuel/test3/224844M/build/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-L/home/manuel/test3/224844M/build/x86_64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-lm -m64 -o ./pr42834.exe(timeout = 300)
These two are exactly the same tests. But if the same duplication does
not happen in the reference results given to compare_tests, then it
will report it as a new test that PASS. I get dozens of this all the
time.
Is nobody seeing this? Is it a known problem with parallel make check?
If so, can we work-around it in compare_tests?
Cheers,
Manuel.
Re: set_src_cost lying comment
On Tue, Jun 23, 2015 at 11:05:45PM -0600, Jeff Law wrote: > I certainly agree that the cost of a move, logicals and arithmetic is > essentially the same at the chip level for many processors. But a copy has > other properties that make it "cheaper" -- namely we can often propagate it > away or arrange for the source & dest of the copy to have the same hard > register which achieves the same effect. > > So one could argue that a copy should have cost 0 as it has a reasonable > chance of just going away, while logicals, alu operations on the appropriate > chips should have a cost of 1. That's an interesting point, and perhaps true for rtl expansion. I'm not so sure it is correct for later rtl passes where you'd like to discourage register moves.. Case in point: The rs6000 backend happens to use zero for the cost of setting registers to simple constants. That might be an accident, but when I fixed this by making (set (reg) (const_int)) cost one insn as it actually does for a range of constants, I found some call sequences regressesd. A call like foo(0,0) is better as (set (reg r3) (const_int 0)) li 3,0 (set (reg r4) (const_int 0)) li 4,0 (call ...)bl foo rather than (set (reg r3) (const_int 0)) li 3,0 (set (reg r4) (reg r3)) mr 4,3 (call ...)bl foo CSE will say the second sequence is cheaper if loading a constant is more expensive than a copy. In reality the second sequence is less preferable since you have a register dependency. A similar problem happens with foo(x+1,x+1) which currently emits (set (reg r3) (plus (reg x) (const_int 1))) (set (reg r4) (reg r3)) for the arg setup insns. On modern processors it would be better as (set (reg r3) (plus (reg x) (const_int 1))) (set (reg r4) (plus (reg x) (const_int 1))) So in these examples we'd really like register moves to cost one insn. Hmm, at least, moves from hard regs ought to cost something. -- Alan Modra Australia Development Lab, IBM
[RFC] Difference between gcc and g++ drivers
Hi,
Glibc 2.22 will have libm.so implemented as linker script helping to
link as needed against vector math library libmvec.so without addition
of -lmvec (for not static builds). Another words -lm is enough to link
against libmvec.so.
But g++ driver inserts -lm for linker command, gcc griver not.
It gives different behavior of g++ and gcc (I mean Glibc 2.22
installed system-wide):
g++ -fopenmp -ffast-math -O1 cos.c (compiled, -lm passed to linker by driver)
gcc -fopenmp -ffast-math -O1 cos.c (linker error because of no -lm passed)
/tmp/cclVmUxv.o: In function `main':
cos.c:(.text+0x3a): undefined reference to `_ZGVbN2v_cos'
cos.c:(.text+0x6b): undefined reference to `cos'
collect2: error: ld returned 1 exit status
cos.c:
#include
int N = 3200;
double b[3200];
double a[3200];
int main (void)
{
int i;
#pragma omp simd
for (i = 0; i < N; i += 1)
{
b[i] = cos (a[i]);
}
return (0);
}
For static builds with gcc needed to add both options with the
following order: -lmvec -lm.
For static builds with g++ needed to add only -lmvec.
Can anybody tell something about this difference in drivers?
May be needed fix for g++ driver to add also -lmvec if GLIBC version
>= 2.22 found on configure?
May be some other way needed to achieve similar drivers behavior?
--
WBR,
Andrew
Re: [RFC] Difference between gcc and g++ drivers
On 06/24/2015 03:12 PM, Andrew Senkevich wrote: > Can anybody tell something about this difference in drivers? It's a UNIX tradition to require -lm for the floating-point library in C programs. It doesn't make much sense now, but it's hard to change it. Andrew.
Re: set_src_cost lying comment
On 06/24/2015 03:18 AM, Alan Modra wrote: On Tue, Jun 23, 2015 at 11:05:45PM -0600, Jeff Law wrote: I certainly agree that the cost of a move, logicals and arithmetic is essentially the same at the chip level for many processors. But a copy has other properties that make it "cheaper" -- namely we can often propagate it away or arrange for the source & dest of the copy to have the same hard register which achieves the same effect. So one could argue that a copy should have cost 0 as it has a reasonable chance of just going away, while logicals, alu operations on the appropriate chips should have a cost of 1. That's an interesting point, and perhaps true for rtl expansion. I'm not so sure it is correct for later rtl passes where you'd like to discourage register moves.. It was the best I could come up with :-) I certainly don't know the history behind the choices. Case in point: The rs6000 backend happens to use zero for the cost of setting registers to simple constants. That might be an accident, but when I fixed this by making (set (reg) (const_int)) cost one insn as it actually does for a range of constants, I found some call sequences regressesd. A call like foo(0,0) is better as (set (reg r3) (const_int 0)) li 3,0 (set (reg r4) (const_int 0)) li 4,0 (call ...) bl foo rather than (set (reg r3) (const_int 0)) li 3,0 (set (reg r4) (reg r3)) mr 4,3 (call ...) bl foo CSE will say the second sequence is cheaper if loading a constant is more expensive than a copy. In reality the second sequence is less preferable since you have a register dependency. Agreed 100%. A similar problem happens with foo(x+1,x+1) which currently emits (set (reg r3) (plus (reg x) (const_int 1))) (set (reg r4) (reg r3)) for the arg setup insns. On modern processors it would be better as (set (reg r3) (plus (reg x) (const_int 1))) (set (reg r4) (plus (reg x) (const_int 1))) So in these examples we'd really like register moves to cost one insn. Hmm, at least, moves from hard regs ought to cost something. Agreed again. These are good examples of things the costing model simply wasn't ever designed to consider -- because they weren't significant issues on the m68k, vax and other ports in the gcc-1 era. So I don't really know how to tell you to proceed -- I've considered the costing models fundamentally flawed for many years, but haven't ever tried to come up with something that works better. Jeff
Re: [RFC] Difference between gcc and g++ drivers
On Wed, 24 Jun 2015, Andrew Senkevich wrote: > Can anybody tell something about this difference in drivers? libstdc++ uses libm - that's probably why g++ links it in by default. Modern good practice would say that it should only be linked directly into a program (should only end up listed in DT_NEEDED) if actually required by that program, not if only used indirectly by libstdc++. > May be needed fix for g++ driver to add also -lmvec if GLIBC version > >= 2.22 found on configure? I don't think that's a good idea (even if you depend on the glibc version on the target, for which there is various existing precedent, depending on *how that version is configured* doesn't seem such a good idea, and libmvec is an optional feature only supported at all on x86_64). -- Joseph S. Myers jos...@codesourcery.com
RE: set_src_cost lying comment
-Original Message- From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Jeff Law Sent: Wednesday, June 24, 2015 10:36 AM To: gcc@gcc.gnu.org Subject: Re: set_src_cost lying comment On 06/21/2015 11:57 PM, Alan Modra wrote: > set_src_cost says it is supposed to > /* Return the cost of moving X into a register, relative to the cost > of a register move. SPEED_P is true if optimizing for speed rather > than size. */ > > Now, set_src_cost of a register move (set (reg1) (reg2)), is zero. > Why? Well, set_src_cost is used just on the right hand side of a SET, > so the cost is that of (reg2), which is zero according to rtlanal.c > rtx_cost. targetm.rtx_costs doesn't get a chance to modify this. > > Now consider (set (reg1) (ior (reg2) (reg3))), for which set_src_cost > on rs6000 currently returns COSTS_N_INSNS(1). It seems to me that > this also ought to return zero, if the set_src_cost comment is to be > believed. I'd claim the right hand side of this expression costs the > same as a register move. A register move machine insn "mr reg1,reg2" > is encoded as "or reg1,reg2,reg2" on rs6000! >>Certainly seems inconsistent -- all the costing stuff should be revisited. >>The basic design for costing dates back to the m68k/vax era. >>I certainly agree that the cost of a move, logicals and arithmetic is >>essentially the same at the chip level for many processors. But a copy has >>other properties >>that make it "cheaper" -- namely we can often propagate it >>away or arrange for the source & dest of the copy to have the same hard >>register which achieves >>the same effect. I have seen for target like Microblaze, making the changes in the cost of move instructions not same at the chip level cost/latency improves the performance for Mibench/EEMBC benchmarks. Also changing the cost of branch instruction and sometimes making it zero also improves the performance for Mibench/EEMBC benchmarks. >>So one could argue that a copy should have cost 0 as it has a reasonable >>chance of just going away, while logicals, alu operations on the appropriate >>chips >>should have a cost of 1. Thanks & Regards Ajit jeff
Re: set_src_cost lying comment
> These are good examples of things the costing model > simply wasn't ever designed to consider -- because they weren't > significant issues on the m68k, vax and other ports in the gcc-1 era. > > So I don't really know how to tell you to proceed -- I've considered the > costing models fundamentally flawed for many years, but haven't ever > tried to come up with something that works better. I'm not sure I'd call it "fundamentally flawed" or that it wasn't "designed to consider" these things. I see the costing model as meant as a *heuristic* for making choices, not as a precise metric for anything. Certainly, a lot of people worked on that model, including both of us, during the gcc-2 RISC porting days. I see the "flaw" as trying to use it for too much. There's a limit to the amount of decisions you can make with purely local data. When trying to decide whether a source should be a constant or a register, you have to look at: - the chances the reg-reg copy can be eliminated - register pressure - whether there's room to insn schedule around any conflicts Unless you look at the whole picture, you're just guessing, which is, of course, what a heuristic is all about!
RE: set_src_cost lying comment
-Original Message- From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of Richard Kenner Sent: Wednesday, June 24, 2015 9:28 PM To: l...@redhat.com Cc: gcc@gcc.gnu.org Subject: Re: set_src_cost lying comment > These are good examples of things the costing model simply wasn't ever > designed to consider -- because they weren't significant issues on > the m68k, vax and other ports in the gcc-1 era. > > So I don't really know how to tell you to proceed -- I've considered > the costing models fundamentally flawed for many years, but haven't > ever tried to come up with something that works better. >>I'm not sure I'd call it "fundamentally flawed" or that it wasn't "designed >>to consider" these things. I see the costing model as meant as a *heuristic* >>for >>making choices, not as a precise metric for anything. Certainly, a lot >>of people worked on that model, including both of us, during the gcc-2 RISC >>porting days. >>I see the "flaw" as trying to use it for too much. There's a limit to the >>amount of decisions you can make with purely local data. When trying to >>decide >>whether a source should be a constant or a register, you have to >>look at: >>- the chances the reg-reg copy can be eliminated >>- register pressure >>- whether there's room to insn schedule around any conflicts Increasing or decreasing the cost of moves affects the Optimal Coalescing. Also the Live range splitting that generates the shuffle code at the border if the registers in the partner live ranges are different/ Splitted live ranges where a partner has register and another partner in memory, then a store would be needed otherwise a load is generated with respect to the live range has memory and the partner live ranges in register then a load will be generated. All these conditions and heuristics are associated with move cost for x86 and other Architecture. Thanks & Regards Ajit >>Unless you look at the whole picture, you're just guessing, which is, of >>course, what a heuristic is all about!
Re: set_src_cost lying comment
On 06/24/2015 03:18 AM, Alan Modra wrote: So in these examples we'd really like register moves to cost one insn. Hmm, at least, moves from hard regs ought to cost something. The more I think about it, the more I think that's a reasonable step. Nothing should have cost 0. Jeff
gcc-4.9-20150624 is now available
Snapshot gcc-4.9-20150624 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20150624/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.9 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_9-branch revision 224927 You'll find: gcc-4.9-20150624.tar.bz2 Complete GCC MD5=ddf107309cffe63bc0cbfe53baef39eb SHA1=735ed9ed0d1980f2bbaaf393ca93af8eaee5f949 Diffs from 4.9-20150617 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.9 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.
Re: parallel make check: duplicated test results
On 24.06.2015 13:41, Manuel López-Ibáñez wrote:
> Is nobody seeing this? Is it a known problem with parallel make check?
> If so, can we work-around it in compare_tests?
>
> Cheers,
>
> Manuel.
>
Actually I don't get such problem, but I run the testsuite in a slightly
different way, so you might want to try it in order to see, if that
works for you:
#!/bin/bash
# (... snip ...)
# Check multilib configuration
if "${BUILD_DIR}/gcc/xgcc" --print-multi-lib | fgrep -q 'm32'; then
TARGET_BOARD_PARAM='unix\{-m32,\}'
else
TARGET_BOARD_PARAM='unix'
fi
rm -rf "${TEST_DIR}"
mkdir -p "${TEST_DIR}"
cd "${BUILD_DIR}"
make -k -j${NUM_JOBS} check
RUNTESTFLAGS="--target_board=${TARGET_BOARD_PARAM}" \
> >(tee "${TEST_DIR}/test.log") 2> >(tee
"${TEST_DIR}/test_err.log"
>&2) || true
"${SRC_DIR}/contrib/test_summary" -t | tail -n+2 | head -n-3 >
"${TEST_DIR}/test_summary.log"
"${SRC_DIR}/contrib/testsuite-management/validate_failures.py"
"--build_dir=${BUILD_DIR}" --produce_manifest
--manifest="${TEST_DIR}/manifest.xfail"
for FNAME in "${TEST_DIR}/test_summary.log" "${TEST_DIR}/manifest.xfail"; do
if [ -f "${FNAME}" ]; then
sed -i'' -e 's/==[0-9]\+==/==[PID]==/g' "${FNAME}"
fi
done
${SRC_DIR} is the directory where GCC repository is checked out.
${BUILD_DIR} is build root, and ${TEST_DIR} is the destination for reports.
Now, the two differences: I don't have a slash in RUNTESTFLAGS (and I
probably even recall that I used to have a slash but removed it for some
reason). Second, I don't use compare_tests, but instead produce test
summaries and manifests and then use diff.
Notice that there is a couple of other nice tricks here:
1. The two "tee" commands allow to save separate stdout and stderr logs
(the build log is also processed in a similar manner) and at the same
time copy them to stdout (in my case - to Jenkins console output).
2. test_summary is convenient because it groups the list of failures by
component and architecture. But is also contains some statistics like
the total number of tests and current date (which will differ from build
to build). In contrast, manifest contains only the list of failures,
i.e. it is more diff-friendly.
3. Address sanitizer prints process ID in failure message. I replace it
by "[PID]", so it does not change across builds.
By the way, what is the policy of test results mailing list? I actually
run nightly builds of GCC trunk and could post them if that makes sense.
(though it's plain old x86_64-unknown-linux-gnu multilib; I build and
test C, C++, LTO, Fortran, Objective C and Go).
--
Regards,
Mikhail Maltsev
