The testing environment is Ubuntu 20.04.3 LTS installed on a machine with dual Intel Xeon E5-2699 v4 and Supermicro X10DAi motherboard. I try to compile and test VASP.6.3.0 with recent/latest Intel oneAPI base and hpc toolkits.
The test commands are as follows:
VASP_TESTSUITE_EXE_STD="mpirun -np $nranks -genv OMP_NUM_THREADS=$nthrds -genv I_MPI_PIN_DOMAIN=omp -genv KMP_AFFINITY=verbose,granularity=fine,compact,1,0 -genv KMP_STACKSIZE=512m /home/werner/Public/hpc/vasp/vasp.6.3.0/testsuite/../bin/vasp_std"
VASP_TESTSUITE_EXE_NCL="mpirun -np $nranks -genv OMP_NUM_THREADS=$nthrds -genv I_MPI_PIN_DOMAIN=omp -genv KMP_AFFINITY=verbose,granularity=fine,compact,1,0 -genv KMP_STACKSIZE=512m /home/werner/Public/hpc/vasp/vasp.6.3.0/testsuite/../bin/vasp_ncl"
VASP_TESTSUITE_EXE_GAM="mpirun -np $nranks -genv OMP_NUM_THREADS=$nthrds -genv I_MPI_PIN_DOMAIN=omp -genv KMP_AFFINITY=verbose,granularity=fine,compact,1,0 -genv KMP_STACKSIZE=512m /home/werner/Public/hpc/vasp/vasp.6.3.0/testsuite/../bin/vasp_gam"
I found that the time performance may be very different for a specific job with different combination of np (i.e., number of processes) and OMP_NUM_THREADS. In my test, I found that the combination of -np 16 and OMP_NUM_THREADS=16 is very time-consuming, and I terminated this testing step before it was over. For a summary of the time benchmarks corresponding to the tests here, see this file and the discussion here and for more detailed information.
So a natural question is: How to find the optimal combination of setting values for number of processes and OMP_NUM_THREADS in a particular computing task? Is there a rule of thumb?
The following is supplementary information as a reply to the comments given by Victor Eijkhout, Homer512 and Jérôme Richard:
See the related info give by inxi:
werner#X10DAi-00:~$ inxi -Cxxx
CPU: Topology: 2x 22-Core model: Intel Xeon E5-2699 v4 bits: 64 type: MT MCP SMP arch: Broadwell rev: 1
L2 cache: 110.0 MiB
flags: avx avx2 lm nx pae sse sse2 sse3 sse4_1 sse4_2 ssse3 vmx bogomips: 387287
Speed: 1200 MHz min/max: 1200/3600 MHz Core speeds (MHz): 1: 1200 2: 1202 3: 1202 4: 1202 5: 1200
6: 1202 7: 1203 8: 1201 9: 1204 10: 1201 11: 1654 12: 2007 13: 2204 14: 2200 15: 1245 16: 1202
17: 1202 18: 1202 19: 1203 20: 1202 21: 1203 22: 1202 23: 1202 24: 1201 25: 1202 26: 1202 27: 1201
28: 1202 29: 1202 30: 1202 31: 2066 32: 1202 33: 1202 34: 1202 35: 1203 36: 1202 37: 1202 38: 1202
39: 1202 40: 1202 41: 1200 42: 1516 43: 1200 44: 1200 45: 1200 46: 1202 47: 1200 48: 1200 49: 1200
50: 1200 51: 1201 52: 1201 53: 1201 54: 1201 55: 1200 56: 1201 57: 1204 58: 1200 59: 1200 60: 1609
61: 1871 62: 2200 63: 1251 64: 1201 65: 1201 66: 1201 67: 1200 68: 1203 69: 1200 70: 1201 71: 1201
72: 1201 73: 1201 74: 1201 75: 1200 76: 1200 77: 1200 78: 1201 79: 1203 80: 1523 81: 1201 82: 1200
83: 1200 84: 1201 85: 1201 86: 1200 87: 1200 88: 1204
werner#X10DAi-00:~$ inxi -Mxxx
Machine: Type: Desktop System: Supermicro product: X10DAi v: 123456789 serial: <superuser/root required>
Mobo: Supermicro model: X10DAI v: 1.02 serial: <superuser/root required> UEFI: American Megatrends
v: 3.2 date: 12/16/2019
werner#X10DAi-00:~$ inxi -Sxxx
System: Host: X10DAi-00 Kernel: 5.8.0-43-generic x86_64 bits: 64 compiler: N/A Desktop: GNOME 3.36.9
tk: GTK 3.24.20 wm: gnome-shell dm: GDM3 3.36.3 Distro: Ubuntu 20.04.3 LTS (Focal Fossa)
I retest the test discussed here. See the following for the time baseline and the corresponding combination of options:
nranks=4 nthrds=2
real 0m13.666s
user 1m20.643s
sys 0m4.314s
nranks=8 nthrds=2
real 0m11.908s
user 2m9.973s
sys 0m7.549s
nranks=12 nthrds=2
real 0m11.043s
user 2m55.062s
sys 0m11.161s
nranks=16 nthrds=2
real 0m11.087s
user 3m45.074s
sys 0m15.343s
nranks=4 nthrds=2
real 0m13.511s
user 1m19.949s
sys 0m4.185s
nranks=6 nthrds=4
real 0m13.736s
user 3m38.704s
sys 0m12.471s
nranks=8 nthrds=5
real 0m12.378s
user 5m13.113s
sys 0m18.022s
It seems that the above results are consistent with the comments given by Homer512:
Typical setups to test are one process per core (1-2 threads) or one
per LLC with as many threads as appropriate.
Regards,
HZ
Related
Compiling/Linking COBOL code for DB2 on a RHEL 8.6 server which is hitting an error.
Command running:
cob2 -F/etc/cob2.cfg -v myfile.cbl -L/opt/IBM/db2/V11.5/lib32 -I/opt/IBM/db2/V11.5/include/cobol_a -ldb2 -q"size(16384k)" -L. linkfile.a -o myfile.exe
db2level Informational tokens are "DB2 v11.5.0.0", "s1906101300", "DYN1906101300AMD64", and Fix Pack "0". Product is installed at "/opt/IBM/db2/V11.5"
cob2 -V Program cob2 Version 1.1.0 Built Mon Sep 27 10:39:30 2021
Error Message:
/usr/bin/ld: /usr/lib/gcc/x86_64-redhat-linux/8/../../../../lib/Scrtl.0(.text+0x1c): unresolvable R_386_GOTOFF relocation against symbol '__libc_csu_fini'
/usr/bin/ld: final link failed: Nonrepresentable section on output
collect2: error ld returned 1 exit status.
Tried changing various options but running out of options now.
I was expecting/hoping for a clean compile and link, and the .exe file available.
No CFLAGS and/or LDFLAGS set.
gcc -v Using built-in specs. COLLECT GCC=gcc COLLECT LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/8/lto-wrapper OFFLOAD_TARGET_NAMES=nvptx-none OFFLOAD_TARGET_DEFAULT=1 Target: x86_64-redhat-linux Configured with: ../configure --enable-bootstrap --enable-languages=c,c++,fortran,lto --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared --enable-threads=posix --enable-checking=release --enable-multilib --with-system-zlib --enable- __cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-objext --enable-linkr-build-id --with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin --enable-initfini-array --with-isl --disable-libmpx --enable-offload-targets=nvptx-none --without-cuda-driver --enable-gnu-indirect-function --enable-cet --with-tune-generic --with-arch_32=x86-64 --build=x86_64-redhat-linux Thread model: posix gcc version 8.5.0 20210514 (Red Hat 8.5.0-10) (GCC)
Incoming argument vector for cob2... [ 0] - 4: cpb2 [ 1] - 2: -# [ 2] - 15: -F/etc/cob2.cfg [ 3] - 2: -v [ 4] - 18: /tmp/out/myfile.cbl [ 5] - 10: linkfile.a [ 6] - 26: -L/opt/IBM/db2/V11.5/lib32 [ 7] - 36: -I/opt/IBM/db2/V11.5/include/cobol_a [ 8] - 5: -ldb2 [ 9] - 14: -qsize(16384K) [10] - 2: -o [11] - 20: /code/bin/myfile.exe
Outgoing environment variables... PATH: /opt/ibm/cobol/1.1.0/usr/bin/:/usr/bin:/etc:/usr/sbin:/usr/ucb:/home/user1///bin/usr/bin/X11:/sbin:/:/code/bin:/code/scripts/home/user1//sqllib/bin LIBPATH: /home/user1//sqllib/lib:/usr/lib:/lib LD_LIBRARY_PATH: /opt/ibm/cobol/rte/usr/lib/:/opt/ibm/cobol/rte/:/opt/ibm/cobol1.1.0/usr/lib:home/user1/sqllib/lib32:/home/user1//sqllib/lib32/gskit NLSPATH: /opt/ibm/cobol/rte/usr/lib/usr/share/locale/%L/%N:/opt/ibm/cobol/rte/usr/share/locale/%L/%N:/opt/ibm/cobol/1.1.0/usr/share/locale/%L/%N:/opt/IBM/db2/V11.5/msg/%L/%N:/opt/IBM/db2/V11.5/msg/en_US/%N SYSLIB: /opt/IBM/db2/V11.5/include/cobol_a:/opt/IBM/db2/V11.5/include/cobol_a
Outgoing argument vector for /opt/ibm/cobol/1.1.0/usr/bin/cob3 ... [ 0] - 33 /opt/ibm/cobol/1.1.0/usr/bin/cob3 [ 1] - 14 -qsize(16384K)
exec: /opt/ibm/cobol/1.1.0/usr/bin/cob3 -qsize(16384K) /tmp/myfile.cbl
Outgoing argument vector for /usr/bin/gcc ... [ 0] - 12: /usr/bin/gcc [ 1] - 4: -m32 [ 2] - 7: -shared [ 3] - 5: -fPIC [ 4] - 9: -rdynamic [ 5] - 28: -fasynchronous -unwind -tables [ 6] - 20: -W1, --hash-style=gnu [ 7] - 18: -W1, --export-dynam [ 8] - 14: -W1, -Bsymbolic [ 9] - 14: -W1, --build-id [10] - 22: -W1, --enable-new-dtags [11] - 11: -W1, -zrelro [12] - 9: -W1, -znow [13] - 10: -W1, -zdefs [14] - 18: -W1, -z,noexecstack [15] - 12: -W1, -znotext [16] - 27: -W1, ---allow-shlib-undefined [17] - 4: -pie [18] - 5: -fPIE [19] - 15: --fwhole-program [20] - 15: -W1, --as-needed [21] - 8: myfile.o [22] - 10: linkfile.a [23] - 26: -L/opt/IBM/db2/V11.5/lib32 [24] - 5: ldb2 [25] - 2: -o [26] - 19: /code/bin/myfile.exe [27] - 15: -W1, --no-omagic [28] - 13: -W1, Bdynamic [29] - 15: -W1, --as-needed [30] - 31: L/opt/ibm/cobol/1.1.0/usr/lib/ [31] - 29: L/opt/ibm/cobol/rte/usr/lib/ [32] - 10: -lcob2_32s [33] - 10: -lcob2_32r [34] - 9: -ldfp_32r [35] - 3: -lm [36] - 9: -lpthread [37] - 150: -W1, -rpath,/opt/ibm/cobol/rte/usr/lib/:/opt/ibm/cobol/rte/:/opt/ibm/cobol/1.1.0/usr/lib/:/home/user1//sqllib/lib32:/home/user1/sqllib/lib32/gskit
exec: /usr/bin/gcc -m32 -shared -fPIC -rdynamic -fasynchronous -unwind -tables -W1, --hash-style=gnu -W1, --export-dynam -W1, -Bsymbolic -W1, --build-id -W1, --enable-new-dtags -W1, -zrelro -W1, -znow -W1, -zdefs -W1, -z,noexecstack -W1, -znotext -W1, ---allow-shlib-undefined -pie -fPIE --fwhole-program -W1, --as-needed myfile.o linkfile.a -L/opt/IBM/db2/V11.5/lib32 ldb2 -o /code/bin/myfile.exe -W1, --no-omagic -W1, Bdynamic -W1, --as-needed L/opt/ibm/cobol/1.1.0/usr/lib/ L/opt/ibm/cobol/rte/usr/lib/ -lcob2_32s -lcob2_32r -ldfp_32r -lm -lpthread -W1, -rpath,/opt/ibm/cobol/rte/usr/lib/:/opt/ibm/cobol/rte/:/opt/ibm/cobol/1.1.0/usr/lib/:/home/user1//sqllib/lib32:/home/user1/sqllib/lib32/gskit
You get this error when incompatible compilation/link options and object/library files are present.
In your case your linkfile.a library may be built with different compilation options than the defaults for cob2, causing the symptom.
To resolve this, you should either arrange for linkfile.a to be rebuilt with similar options to your cobol object file (typically the -fPIC option is significant, there may be others), or use a different library that is already built in a compatible manner .
If you cannot do that, you need to plan a different way to interface from COBOL with the functionality that is provided in your linkfile.a , so refer to the developer(s) of that functionality for advice.
First I synthesized a CPU that supports RISCV32IM using verilog, but I can't test if the CPU is working properly. I hope a compiler(such as GCC) can generate instructions to help me test, but normal compilers can only generate EXE files that require the operating system. Obviously, my FPGA can't do this.
I only need a series of RISCV32IM instructions that can run on FPGA and can implement the corresponding functions. If I can, I want his first instruction to be the program entry, which will save me energy.
Of course you can it is somewhat trivial, you did or someone selected baremetal tab for you, it is a baremetal program I assume you want to run.
so.s
lui x2,0x22222
lui x3,0x33333
lui x4,0x44444
lui x5,0x55555
lui x6,0x66666
j .
riscv32-none-elf-as so.s -o so.o
riscv32-none-elf-objdump -d -Mnumeric so.o
so.o: file format elf32-littleriscv
Disassembly of section .text:
00000000 <.text>:
0: 22222137 lui x2,0x22222
4: 333331b7 lui x3,0x33333
8: 44444237 lui x4,0x44444
c: 555552b7 lui x5,0x55555
10: 66666337 lui x6,0x66666
14: 0000006f j 14 <.text+0x14>
now you can just
riscv32-none-elf-ld -Ttext=0 so.o -o so.elf
riscv32-none-elf-ld: warning: cannot find entry symbol _start; defaulting to 0000000000000000
riscv32-none-elf-objdump -d -Mnumeric so.elf
so.elf: file format elf32-littleriscv
Disassembly of section .text:
00000000 <__BSS_END__-0x1018>:
0: 22222137 lui x2,0x22222
4: 333331b7 lui x3,0x33333
8: 44444237 lui x4,0x44444
c: 555552b7 lui x5,0x55555
10: 66666337 lui x6,0x66666
14: 0000006f j 14 <__BSS_END__-0x1004>
but at least with arm and not sure about other binutils targets there are very very old, longstanding bugs in the tools when used like that (get gaps in the binary, etc). So
memmap
MEMORY
{
hello : ORIGIN = 0x00000000, LENGTH = 0x3000
}
SECTIONS
{
.text : { *(.text*) } > hello
.rodata : { *(.rodata*) } > hello
.bss : { *(.bss*) } > hello
.data : { *(.data*) } > hello
}
and
riscv32-none-elf-ld -T memmap so.o -o so.elf
riscv32-none-elf-objdump -d -Mnumeric so.elf
so.elf: file format elf32-littleriscv
Disassembly of section .text:
00000000 <.text>:
0: 22222137 lui x2,0x22222
4: 333331b7 lui x3,0x33333
8: 44444237 lui x4,0x44444
c: 555552b7 lui x5,0x55555
10: 66666337 lui x6,0x66666
14: 0000006f j 14 <.text+0x14>
so now you have an elf (or exe or whatever) you can
riscv32-none-elf-objcopy so.elf -O binary so.bin
hexdump -C so.bin
00000000 37 21 22 22 b7 31 33 33 37 42 44 44 b7 52 55 55 |7!"".1337BDD.RUU|
00000010 37 63 66 66 6f 00 00 00 |7cffo...|
00000018
or
riscv32-none-elf-objcopy --srec-forceS3 so.elf -O srec so.srec
cat so.srec
S00A0000736F2E7372656338
S3150000000037212222B731333337424444B75255554C
S30D00000010376366666F0000000D
S70500000000FA
or
riscv32-none-elf-objcopy so.elf -O ihex so.ihex
cat so.ihex
:1000000037212222B731333337424444B752555552
:08001000376366666F00000013
and so on.
Then you can also...
so.s
lui x2,0x00002
jal notmain
j .
.globl hello
hello:
ret
notmain.c
void hello ( unsigned int );
void notmain ( void )
{
unsigned int r;
for (r=0;r<32;r++)
{
hello(r);
}
}
build with commands like these
riscv32-none-elf-as -march=rv32im so.s -o so.o
riscv32-none-elf-gcc -O2 -c -fomit-frame-pointer -march=rv32im -mabi=ilp32 notmain.c -o notmain.o
riscv32-none-elf-ld -T memmap so.o notmain.o -o so.elf
riscv32-none-elf-objdump -D -Mnumeric so.elf
riscv32-none-elf-objcopy -O binary so.elf so.bin
giving
Disassembly of section .text:
00000000 <hello-0xc>:
0: 00002137 lui x2,0x2
4: 00c000ef jal x1,10 <notmain>
8: 0000006f j 8 <hello-0x4>
0000000c <hello>:
c: 00008067 ret
00000010 <notmain>:
10: ff010113 addi x2,x2,-16 # 1ff0 <notmain+0x1fe0>
14: 00812423 sw x8,8(x2)
18: 00912223 sw x9,4(x2)
1c: 00112623 sw x1,12(x2)
20: 00000413 li x8,0
24: 02000493 li x9,32
28: 00040513 mv x10,x8
2c: 00140413 addi x8,x8,1
30: fddff0ef jal x1,c <hello>
34: fe941ae3 bne x8,x9,28 <notmain+0x18>
38: 00c12083 lw x1,12(x2)
3c: 00812403 lw x8,8(x2)
40: 00412483 lw x9,4(x2)
44: 01010113 addi x2,x2,16
48: 00008067 ret
and you can use the .bin file or .srec or whatever you prefer.
basic bare metal stuff...gnu works great for this, very easy to use. llvm/clang is more complicated to figure out but technically will work as well.
I changed the line to
for (r=0;r<3200;r++)
because it was unrolling the loop. I gave up trying to keep track of the ever changing generic llvm tool command line options, so now I build specific for riscv32 and can then use the generic program names as cross tools...
clang -c -march=rv32im so.s -o so.o
clang -c -O2 -march=rv32im notmain.c -o notmain.o
ld.lld -T memmap so.o notmain.o -o so.elf
llvm-objcopy -O binary so.elf so.bin
llvm-objdump -D -Mnumeric so.elf
so.elf: file format elf32-littleriscv
Disassembly of section .text:
00000000 <.text>:
0: 37 21 00 00 lui x2, 2
4: ef 00 c0 00 jal 0x10 <notmain>
8: 6f 00 00 00 j 0x8 <.text+0x8>
0000000c <hello>:
c: 67 80 00 00 ret
00000010 <notmain>:
10: 13 01 01 ff addi x2, x2, -16
14: 23 26 11 00 sw x1, 12(x2)
18: 23 24 81 00 sw x8, 8(x2)
1c: 23 22 91 00 sw x9, 4(x2)
20: 13 04 00 00 li x8, 0
24: 37 15 00 00 lui x10, 1
28: 93 04 05 c8 addi x9, x10, -896
0000002c <.LBB0_1>:
2c: 13 05 04 00 mv x10, x8
30: ef f0 df fd jal 0xc <hello>
34: 13 04 14 00 addi x8, x8, 1
38: e3 1a 94 fe bne x8, x9, 0x2c <.LBB0_1>
3c: 83 20 c1 00 lw x1, 12(x2)
40: 03 24 81 00 lw x8, 8(x2)
44: 83 24 41 00 lw x9, 4(x2)
48: 13 01 01 01 addi x2, x2, 16
4c: 67 80 00 00 ret
I am lost on how SonarQube calculates conditions covered by tests.
Versions of tools used:
* JaCoCo 0.8.1
* SonarQube 7.4
This is my groovy code
boolean condition1(boolean b1, boolean b2) {
!b1 || !b2
}
boolean condition2(boolean b1, boolean b2) {
b1 || b2
}
boolean condition3(boolean b1, boolean b2) {
!b1 && !b2
}
boolean condition4(boolean b1, boolean b2) {
b1 && b2
}
boolean condition5(boolean b1, boolean b2) {
b1 && !b2
}
boolean condition6(boolean b1, boolean b2, boolean b3) {
b1 && b2 && b3
}
Here are the tests
void "test condition 1"() {
expect:
service.condition1(c1,c2)
where:
c1 | c2
true | true
true | false
false | true
false | false
}
void "test condition 2"() {
expect:
service.condition2(c1,c2)
where:
c1 | c2
true | true
true | false
false | true
false | false
}
void "test condition 3"() {
expect:
service.condition3(c1,c2)
where:
c1 | c2
true | true
true | false
false | true
false | false
}
void "test condition 4"() {
expect:
service.condition4(c1,c2)
where:
c1 | c2
true | true
true | false
false | true
false | false
}
void "test condition 5"() {
expect:
service.condition5(c1,c2)
where:
c1 | c2
true | true
true | false
false | true
false | false
}
void "test condition 6"() {
expect:
service.condition6(c1, c2, c3)
where:
c1 | c2 | c3
true | true | true
true | true | false
true | false | true
true | false | false
false | true | true
false | true | false
false | true | true
false | true | false
false | false | false
}
The code coverage report says those conditions are not satisfied and the followings are the only info I get
condition1. (11 of 22 conditions)
condition2. (7 of 14 conditions)
condition3. (11 of 22 conditions)
condition4. (7 of 14 conditions)
condition5. (9 of 18 conditions)
condition6. (11 of 22 conditions)
That means I am not able to reach 100% of covered tests although I believe logically did.
I am aware of SonarQube documentation
https://docs.sonarqube.org/latest/user-guide/metric-definitions/
where it says
On each line of code containing some boolean expressions, the condition coverage simply answers the following question: 'Has each boolean expression been evaluated both to true and false?'. This is the density of possible conditions in flow control structures that have been followed during unit tests execution
Anyone has an idea on how this actually works and what I am doing wrong here?
From similar questions (such as "Why is JaCoCo not covering my String switch statements?" and "How does assert groupType != null contain 4 branches")
JaCoCo performs analysis of bytecode
thus similarly - take a look at bytecode.
For Example.groovy
class Example {
boolean condition2(boolean b1, boolean b2) {
b1 || b2
}
}
Groovy compiler (groovyc --version)
Groovy compiler version 3.0.0-rc-1
Copyright 2003-2019 The Apache Software Foundation. http://groovy-lang.org/
generates (groovyc Example.groovy)
following bytecode (javap -v -p Example.class)
public boolean condition2(boolean, boolean);
descriptor: (ZZ)Z
flags: (0x0001) ACC_PUBLIC
Code:
stack=1, locals=4, args_size=3
0: invokestatic #20 // Method $getCallSiteArray:()[Lorg/codehaus/groovy/runtime/callsite/CallSite;
3: astore_3
4: invokestatic #38 // Method org/codehaus/groovy/runtime/BytecodeInterface8.isOrigZ:()Z
7: ifeq 25
10: getstatic #40 // Field __$stMC:Z
13: ifne 25
16: invokestatic #43 // Method org/codehaus/groovy/runtime/BytecodeInterface8.disabledStandardMetaClass:()Z
19: ifne 25
22: goto 42
25: iload_1
26: ifne 33
29: iload_2
30: ifeq 37
33: iconst_1
34: goto 38
37: iconst_0
38: ireturn
39: nop
40: nop
41: athrow
42: iload_1
43: ifne 50
46: iload_2
47: ifeq 54
50: iconst_1
51: goto 55
54: iconst_0
55: ireturn
56: nop
57: nop
58: nop
59: nop
60: nop
61: nop
62: nop
63: nop
64: athrow
LineNumberTable:
line 2: 4
line 3: 25
line 4: 39
line 3: 42
line 4: 56
LocalVariableTable:
Start Length Slot Name Signature
0 56 0 this LExample;
0 56 1 b1 Z
0 56 2 b2 Z
which contains 14 branches (2 branches per each conditional jump instruction ifeq and ifne), and your tests cover only half of them (execution path where first ifeq at offset 7 jumps to offset 25), which is absolutely consistent with what is reported by JaCoCo and hence shown in SonarQube.
And following discussion seems to be relevant here - http://groovy.329449.n5.nabble.com/Branch-coverage-issues-td5686725.html , because compilation of the same using --indy option (groovyc --indy Example.groovy) produces following bytecode
public boolean condition2(boolean, boolean);
descriptor: (ZZ)Z
flags: (0x0001) ACC_PUBLIC
Code:
stack=1, locals=3, args_size=3
0: iload_1
1: ifne 8
4: iload_2
5: ifeq 12
8: iconst_1
9: goto 13
12: iconst_0
13: ireturn
14: nop
15: nop
16: nop
17: nop
18: nop
19: nop
20: nop
21: nop
22: athrow
LineNumberTable:
line 3: 0
line 4: 14
LocalVariableTable:
Start Length Slot Name Signature
0 14 0 this LExample;
0 14 1 b1 Z
0 14 2 b2 Z
which contains only 4 branches.
I'm trying to generate a zobrist key for transposition tables in my chess engine.
Here's how I'm generating the 64 bit numbers,
as show here: How to generate 64 bit random numbers?
typedef unsigned long long U64;
std::random_device rd;
std::mt19937_64 mt(rd());
std::uniform_int_distribution<U64> dist(std::llround(std::pow(2,61)),
std::llround(std::pow(2,62)));
rand function:
U64 ZobristH::random64()
{
U64 ranUI = dist(mt);
return ranUI;
}
In order to try and make sure i'm generating random enough numbers I'm using a test distribution function I found online that looks like this (will later input data into excel and look at distribution):
int sampleSize = 2000;
int distArray[sampleSize];
int t = 0;
while (t < 10)
{
for (int i = 0; i < 10000; i++)
{
distArray[(int)(random64() % (sampleSize / 2))]++;
}
t++;
}
for (int i = 0; i < sampleSize; i++)
{
std::cout << distArray[i] << ", ";
}
the results I'm getting look a little something like this:
416763345, 417123246, 7913280, 7914356, 417726722, 417726718, 19, 83886102,
77332499, 14
Are these the decimal representation of binary numbers below 1000? Or am I doing something completely wrong?
Okay I did this to check out the distribution of random numbers; you can run this short program to generate a text file to look to see what values you are getting. Instead of using a function call I just used a lambda within the for loop and instead of setting the values into the array I wrote the values out to the text file before and after the post increment.
#include <iostream>
#include <fstream>
#include <iomanip>
#include <random>
#include <functional> // may not need - included in almost all of my apps
#include <algorithm> // same as above
typedef unsigned long long U64;
int main( int argc, char** argv ) {
std::random_device rd;
std::mt19937_64 mt( rd() );
std::uniform_int_distribution<U64> dist( std::llround( std::pow( 2, 61 ) ),
std::llround( std::pow( 2, 62 ) ) );
auto lambda = [&] { return dist(mt); };
const int sampleSize = 2000;
// int distArray[sampleSize];
int t = 0;
std::ofstream file( "samples.txt" );
while ( t < 10 ) {
file << "Sample: " << (t+1) << "\n";
for ( int i = 0; i < 10000; i++ ) {
auto val = static_cast<int>( (lambda() % (sampleSize / 2)) );
file << std::setw(5) << i << ": " << std::setw(6) << val << "\t"
<< std::setw(6) << val++ << "\n";
// distArray[...]
}
file << "\n\n";
t++;
}
file.close();
/* for ( int i = 0; i < sampleSize; i++ ) {
std::cout << distArray[i] << "\n";
}*/
// Quick & Dirty Way TO Pause The Console
std::cout << "\nPress any key and enter to quit.\n";
char c;
std::cin >> c;
return 0;
}
Then check out the text file that this program generates and if you scroll through the file you will see the distributions. The first column is the value before the post increment and the second column is after. The largest possible value before the post increment that I have seen is 1,000 and after the post increment is 999. I've built and ran this for both 32 & 64 bit platform versions and have seen similar results for the distributions and that they indeed have a uniform distribution.
Sample.txt - Small Version About 1,000 Entries Out The 1st Sample Set
Sample: 1
0: 342 341
1: 517 516
2: 402 401
3: 741 740
4: 238 237
5: 557 556
6: 35 34
7: 572 571
8: 205 204
9: 353 352
10: 301 300
11: 65 64
12: 223 222
13: 647 646
14: 185 184
15: 535 534
16: 97 96
17: 843 842
18: 716 715
19: 294 293
20: 485 484
21: 648 647
22: 406 405
23: 250 249
24: 245 244
25: 915 914
26: 888 887
27: 986 985
28: 345 344
29: 493 492
30: 654 653
31: 860 859
32: 921 920
33: 526 525
34: 793 792
35: 503 502
36: 939 938
37: 802 801
38: 142 141
39: 806 805
40: 540 539
41: 778 777
42: 787 786
43: 884 883
44: 109 108
45: 842 841
46: 794 793
47: 279 278
48: 821 820
49: 112 111
50: 438 437
51: 402 401
52: 69 68
53: 396 395
54: 196 195
55: 655 654
56: 859 858
57: 674 673
58: 417 416
59: 331 330
60: 632 631
61: 210 209
62: 641 640
63: 737 736
64: 838 837
65: 592 591
66: 562 561
67: 883 882
68: 750 749
69: 726 725
70: 253 252
71: 660 659
72: 57 56
73: 401 400
74: 919 918
75: 851 850
76: 345 344
77: 25 24
78: 300 299
79: 781 780
80: 695 694
81: 220 219
82: 378 377
83: 471 470
84: 281 280
85: 945 944
86: 536 535
87: 407 406
88: 431 430
89: 745 744
90: 32 31
91: 389 388
92: 358 357
93: 582 581
94: 820 819
95: 622 621
96: 459 458
97: 233 232
98: 594 593
99: 509 508
100: 260 259
101: 152 151
102: 148 147
103: 137 136
104: 945 944
105: 244 243
106: 968 967
107: 54 53
108: 420 419
109: 58 57
110: 678 677
111: 715 714
112: 780 779
113: 834 833
114: 241 240
115: 669 668
116: 722 721
117: 608 607
118: 805 804
119: 155 154
120: 220 219
121: 520 519
122: 740 739
123: 184 183
124: 198 197
125: 247 246
126: 115 114
127: 520 519
128: 457 456
129: 864 863
130: 659 658
131: 511 510
132: 718 717
133: 119 118
134: 588 587
135: 113 112
136: 518 517
137: 164 163
138: 375 374
139: 866 865
140: 382 381
141: 526 525
142: 621 620
143: 680 679
144: 147 146
145: 712 711
146: 408 407
147: 486 485
148: 7 6
149: 203 202
150: 741 740
151: 290 289
152: 810 809
153: 960 959
154: 449 448
155: 683 682
156: 997 996
157: 454 453
158: 131 130
159: 427 426
160: 157 156
161: 3 2
162: 427 426
163: 554 553
164: 806 805
165: 228 227
166: 431 430
167: 174 173
168: 845 844
169: 121 120
170: 397 396
171: 770 769
172: 17 16
173: 761 760
174: 736 735
175: 629 628
176: 772 771
177: 417 416
178: 739 738
179: 226 225
180: 301 300
181: 217 216
182: 746 745
183: 344 343
184: 607 606
185: 927 926
186: 428 427
187: 385 384
188: 287 286
189: 537 536
190: 705 704
191: 649 648
192: 127 126
193: 252 251
194: 160 159
195: 390 389
196: 282 281
197: 66 65
198: 659 658
199: 844 843
200: 358 357
201: 360 359
202: 872 871
203: 495 494
204: 695 694
205: 988 987
206: 969 968
207: 641 640
208: 799 798
209: 30 29
210: 109 108
211: 675 674
212: 345 344
213: 309 308
214: 807 806
215: 283 282
216: 457 456
217: 193 192
218: 972 971
219: 330 329
220: 914 913
221: 508 507
222: 624 623
223: 254 253
224: 342 341
225: 69 68
226: 918 917
227: 551 550
228: 148 147
229: 645 644
230: 905 904
231: 503 502
232: 980 979
233: 881 880
234: 137 136
235: 202 201
236: 808 807
237: 988 987
238: 497 496
239: 506 505
240: 576 575
241: 671 670
242: 874 873
243: 217 216
244: 808 807
245: 741 740
246: 14 13
247: 206 205
248: 894 893
249: 180 179
250: 4 3
251: 27 26
252: 62 61
253: 203 202
254: 392 391
255: 868 867
256: 673 672
257: 881 880
258: 664 663
259: 831 830
260: 293 292
261: 916 915
262: 860 859
263: 487 486
264: 642 641
265: 161 160
266: 881 880
267: 233 232
268: 423 422
269: 12 11
270: 398 397
271: 993 992
272: 323 322
273: 878 877
274: 114 113
275: 42 41
276: 58 57
277: 398 397
278: 878 877
279: 64 63
280: 873 872
281: 841 840
282: 506 505
283: 412 411
284: 545 544
285: 887 886
286: 17 16
287: 504 503
288: 350 349
289: 772 771
290: 16 15
291: 597 596
292: 553 552
293: 25 24
294: 324 323
295: 242 241
296: 580 579
297: 479 478
298: 702 701
299: 640 639
300: 173 172
301: 918 917
302: 678 677
303: 714 713
304: 258 257
305: 97 96
306: 304 303
307: 80 79
308: 394 393
309: 940 939
310: 985 984
311: 651 650
312: 42 41
313: 179 178
314: 672 671
315: 915 914
316: 160 159
317: 332 331
318: 887 886
319: 370 369
320: 850 849
321: 730 729
322: 395 394
323: 889 888
324: 114 113
325: 505 504
326: 381 380
327: 578 577
328: 762 761
329: 896 895
330: 793 792
331: 295 294
332: 488 487
333: 599 598
334: 182 181
335: 25 24
336: 623 622
337: 396 395
338: 898 897
339: 981 980
340: 645 644
341: 806 805
342: 205 204
343: 404 403
344: 234 233
345: 36 35
346: 659 658
347: 285 284
348: 62 61
349: 608 607
350: 632 631
351: 825 824
352: 585 584
353: 685 684
354: 14 13
355: 828 827
356: 720 719
357: 871 870
358: 88 87
359: 716 715
360: 879 878
361: 650 649
362: 464 463
363: 898 897
364: 930 929
365: 194 193
366: 997 996
367: 105 104
368: 776 775
369: 398 397
370: 962 961
371: 434 433
372: 954 953
373: 548 547
374: 989 988
375: 943 942
376: 229 228
377: 866 865
378: 554 553
379: 567 566
380: 379 378
381: 564 563
382: 738 737
383: 468 467
384: 660 659
385: 693 692
386: 784 783
387: 739 738
388: 662 661
389: 474 473
390: 545 544
391: 958 957
392: 703 702
393: 316 315
394: 571 570
395: 95 94
396: 497 496
397: 672 671
398: 676 675
399: 821 820
400: 368 367
401: 7 6
402: 817 816
403: 221 220
404: 839 838
405: 578 577
406: 635 634
407: 453 452
408: 70 69
409: 764 763
410: 78 77
411: 968 967
412: 295 294
413: 483 482
414: 392 391
415: 23 22
416: 389 388
417: 678 677
418: 150 149
419: 863 862
420: 677 676
421: 676 675
422: 455 454
423: 405 404
424: 126 125
425: 753 752
426: 821 820
427: 328 327
428: 773 772
429: 596 595
430: 645 644
431: 829 828
432: 377 376
433: 444 443
434: 813 812
435: 395 394
436: 794 793
437: 641 640
438: 98 97
439: 827 826
440: 824 823
441: 681 680
442: 736 735
443: 288 287
444: 560 559
445: 781 780
446: 556 555
447: 327 326
448: 820 819
449: 859 858
450: 686 685
451: 919 918
452: 267 266
453: 128 127
454: 583 582
455: 446 445
456: 783 782
457: 712 711
458: 378 377
459: 367 366
460: 52 51
461: 316 315
462: 780 779
463: 398 397
464: 435 434
465: 788 787
466: 380 379
467: 235 234
468: 748 747
469: 429 428
470: 91 90
471: 675 674
472: 853 852
473: 674 673
474: 277 276
475: 179 178
476: 264 263
477: 511 510
478: 514 513
479: 979 978
480: 845 844
481: 728 727
482: 904 903
483: 874 873
484: 750 749
485: 659 658
486: 376 375
487: 713 712
488: 393 392
489: 538 537
490: 896 895
491: 879 878
492: 347 346
493: 819 818
494: 210 209
495: 707 706
496: 869 868
497: 319 318
498: 832 831
499: 498 497
500: 71 70
501: 290 289
502: 861 860
503: 295 294
504: 888 887
505: 515 514
506: 222 221
507: 661 660
508: 813 812
509: 969 968
510: 547 546
511: 900 899
512: 58 57
513: 805 804
514: 428 427
515: 453 452
516: 23 22
517: 969 968
518: 718 717
519: 775 774
520: 395 394
521: 521 520
522: 522 521
523: 465 464
524: 317 316
525: 216 215
526: 254 253
527: 696 695
528: 677 676
529: 21 20
530: 318 317
531: 301 300
532: 142 141
533: 877 876
534: 486 485
535: 981 980
536: 516 515
537: 254 253
538: 328 327
539: 385 384
540: 2 1
541: 405 404
542: 387 386
543: 794 793
544: 48 47
545: 641 640
546: 814 813
547: 981 980
548: 354 353
549: 281 280
550: 561 560
551: 683 682
552: 247 246
553: 739 738
554: 370 369
555: 799 798
556: 680 679
557: 915 914
558: 638 637
559: 254 253
560: 705 704
561: 320 319
562: 640 639
563: 487 486
564: 47 46
565: 852 851
566: 749 748
567: 419 418
568: 300 299
569: 507 506
570: 141 140
571: 972 971
572: 895 894
573: 988 987
574: 279 278
575: 268 267
576: 392 391
577: 530 529
578: 679 678
579: 855 854
580: 246 245
581: 645 644
582: 624 623
583: 417 416
584: 203 202
585: 30 29
586: 9 8
587: 585 584
588: 573 572
589: 471 470
590: 504 503
591: 290 289
592: 588 587
593: 230 229
594: 351 350
595: 651 650
596: 615 614
597: 502 501
598: 352 351
599: 472 471
// 600 - 699 omitted to make space to fit answer
700: 247 246
701: 894 893
702: 809 808
703: 382 381
704: 81 80
705: 574 573
706: 507 506
707: 508 507
708: 569 568
709: 947 946
710: 384 383
711: 14 13
712: 627 626
713: 951 950
714: 825 824
715: 657 656
716: 206 205
717: 598 597
718: 300 299
719: 266 265
720: 909 908
721: 206 205
722: 126 125
723: 841 840
724: 586 585
725: 348 347
726: 100 99
727: 361 360
728: 695 694
729: 556 555
730: 66 65
731: 5 4
732: 686 685
733: 488 487
734: 149 148
735: 622 621
736: 476 475
737: 488 487
738: 371 370
739: 331 330
740: 965 964
741: 141 140
742: 396 395
743: 917 916
744: 31 30
745: 924 923
746: 283 282
747: 369 368
748: 519 518
749: 830 829
750: 688 687
751: 374 373
752: 41 40
753: 418 417
754: 766 765
755: 854 853
756: 453 452
757: 521 520
758: 640 639
759: 185 184
760: 41 40
761: 125 124
762: 723 722
763: 341 340
764: 142 141
765: 754 753
766: 459 458
767: 899 898
768: 166 165
769: 374 373
770: 572 571
771: 304 303
772: 352 351
773: 235 234
774: 879 878
775: 736 735
776: 576 575
777: 56 55
778: 102 101
779: 170 169
780: 208 207
781: 135 134
782: 919 918
783: 599 598
784: 37 36
785: 997 996
786: 922 921
787: 502 501
788: 29 28
789: 173 172
790: 54 53
791: 601 600
792: 535 534
793: 64 63
794: 723 722
795: 491 490
796: 685 684
797: 58 57
798: 272 271
799: 261 260
800: 81 80
801: 149 148
802: 129 128
803: 712 711
804: 377 376
805: 151 150
806: 514 513
807: 14 13
808: 838 837
809: 347 346
810: 517 516
811: 442 441
812: 264 263
813: 883 882
814: 447 446
815: 140 139
816: 195 194
817: 841 840
818: 218 217
819: 858 857
820: 28 27
821: 222 221
822: 223 222
823: 906 905
824: 873 872
825: 492 491
826: 826 825
827: 738 737
828: 307 306
829: 185 184
830: 525 524
831: 449 448
832: 646 645
833: 686 685
834: 942 941
835: 433 432
836: 881 880
837: 824 823
838: 641 640
839: 290 289
840: 897 896
841: 4 3
842: 124 123
843: 679 678
844: 524 523
845: 424 423
846: 282 281
847: 625 624
848: 414 413
849: 647 646
850: 129 128
851: 395 394
852: 720 719
853: 318 317
854: 262 261
855: 402 401
856: 413 412
857: 139 138
858: 549 548
859: 472 471
860: 162 161
861: 605 604
862: 67 66
863: 980 979
864: 465 464
865: 912 911
866: 219 218
867: 648 647
868: 619 618
869: 331 330
870: 625 624
871: 360 359
872: 425 424
873: 935 934
874: 89 88
875: 641 640
876: 535 534
877: 404 403
878: 966 965
879: 27 26
880: 281 280
881: 637 636
882: 57 56
883: 152 151
884: 156 155
885: 813 812
886: 340 339
887: 181 180
888: 921 920
889: 306 305
890: 101 100
891: 178 177
892: 417 416
893: 845 844
894: 904 903
895: 295 294
896: 346 345
897: 654 653
898: 357 356
899: 929 928
900: 195 194
901: 499 498
902: 377 376
903: 727 726
904: 570 569
905: 853 852
906: 71 70
907: 580 579
908: 642 641
909: 889 888
910: 559 558
911: 134 133
912: 324 323
913: 120 119
914: 991 990
915: 6 5
916: 708 707
917: 347 346
918: 929 928
919: 454 453
920: 636 635
921: 218 217
922: 739 738
923: 715 714
924: 87 86
925: 782 781
926: 670 669
927: 845 844
928: 79 78
929: 730 729
930: 58 57
931: 216 215
932: 711 710
933: 898 897
934: 871 870
935: 388 387
936: 389 388
937: 944 943
938: 927 926
939: 88 87
940: 617 616
941: 940 939
942: 948 947
943: 927 926
944: 646 645
945: 125 124
946: 615 614
947: 846 845
948: 705 704
949: 998 997
950: 304 303
951: 346 345
952: 675 674
953: 783 782
954: 129 128
955: 69 68
956: 17 16
957: 646 645
958: 559 558
959: 62 61
960: 807 806
961: 571 570
962: 54 53
963: 297 296
964: 771 770
965: 972 971
966: 829 828
967: 786 785
968: 650 649
969: 101 100
970: 705 704
971: 690 689
972: 365 364
973: 304 303
974: 82 81
975: 776 775
976: 495 494
977: 586 585
978: 556 555
979: 77 76
980: 640 639
981: 161 160
982: 910 909
983: 46 45
984: 43 42
985: 162 161
986: 514 513
987: 654 653
988: 668 667
989: 126 125
990: 254 253
991: 133 132
992: 398 397
993: 993 992
994: 357 356
995: 298 297
996: 519 518
997: 904 903
998: 382 381
999: 28 27
1000: 19 18
1001: 939 938
1002: 868 867
1003: 888 887
1004: 576 575
1005: 183 182
1006: 174 173
1007: 679 678
1008: 831 830
1009: 464 463
1010: 876 875
1011: 738 737
1012: 447 446
1013: 385 384
1014: 271 270
1015: 38 37
1016: 28 27
1017: 451 450
1018: 162 161
1019: 847 846
1020: 430 429
1021: 849 848
1022: 207 206
1023: 196 195
1024: 42 41
1025: 709 708
1026: 557 556
1027: 173 172
1028: 788 787
1029: 160 159
1030: 535 534
1031: 555 554
1032: 252 251
1033: 111 110
1034: 476 475
1035: 780 779
1036: 44 43
1037: 190 189
1038: 443 442
1039: 655 654
1040: 7 6
1041: 845 844
1042: 856 855
1043: 274 273
1044: 933 932
1045: 336 335
1046: 185 184
1047: 580 579
1048: 807 806
1049: 286 285
1050: 409 408
1051: 347 346
1052: 461 460
1053: 624 623
1054: 378 377
1055: 903 902
1056: 483 482
1057: 838 837
1058: 809 808
1059: 919 918
1060: 544 543
1061: 458 457
1062: 121 120
1063: 192 191
1064: 126 125
1065: 843 842
1066: 927 926
1067: 390 389
1068: 567 566
1069: 1000 999
Entry 1069 is the first occurrence in this sample set to reach 1,000. I've ran this about a dozen times both in 32bit and 64bit modes and I did not see any value go above 1,000.
I'm not sure but I think that this line in your code is what is giving you your problem(s):
distArray[(int)(random64() % (sampleSize / 2))]++;
mipsisa64-octeon-elf-gcc obj/zxmd_main.o obj/zxmd_mproc.o obj/zxmd_init.o obj/zxmd_pcie.o obj/libcvm-common.a obj/libcvm-pci-drv.a obj/libcvmhfao.a obj/libocteon-hfa.a /home/jianxi/Juson/JusonFlow/sdk/OCTEON-SDK/components/hfa/lib-octeon/pp/octeon/se/libpp.a obj/libcvmx.a obj/libzxexe.a obj/libfdt.a -mfix-cn63xxp1 -march=octeon2 -o cn63hw1.bin
gcc complain:
obj/libzxexe.a(zxmx_tim.o): In function `zxmx_init_tim':
/home/jianxi/Juson/JusonFlow/libexec/zxmx_tim.c:47: undefined reference to `cvmx_tim_setup'
But cvmx_tim_setup can be found in libcvmx.a:
[jianxi#jianxi obj]$ readelf -h libcvmx.a | grep "cvmx-tim.o" -A21
File: libcvmx.a(cvmx-tim.o)
ELF Header:
Magic: 7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, big endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: REL (Relocatable file)
Machine: MIPS R3000
Version: 0x1
Entry point address: 0x0
Start of program headers: 0 (bytes into file)
Start of section headers: 13424 (bytes into file)
Flags: 0x808d4001, noreorder, octeon2, eabi64, mips64r2
Size of this header: 52 (bytes)
Size of program headers: 0 (bytes)
Number of program headers: 0
Size of section headers: 40 (bytes)
Number of section headers: 33
Section header string table index: 30
[jianxi#jianxi obj]$ readelf -s cvmx-tim.o
27: 00000000 92 FUNC GLOBAL DEFAULT 1 cvmx_tim_start
28: 00000000 40 OBJECT GLOBAL DEFAULT 16 cvmx_tim
29: 00000060 56 FUNC GLOBAL DEFAULT 1 cvmx_tim_stop
30: 00000098 276 FUNC GLOBAL DEFAULT 1 cvmx_tim_shutdown
31: 000001b0 752 FUNC GLOBAL DEFAULT 1 cvmx_tim_setup
32: 00000000 0 NOTYPE GLOBAL DEFAULT UND cvmx_clock_get_rate
33: 00000000 0 NOTYPE GLOBAL DEFAULT UND cvmx_bootmem_alloc
34: 00000000 0 NOTYPE GLOBAL DEFAULT UND memset
35: 00000000 0 NOTYPE GLOBAL DEFAULT UND puts
36: 00000000 0 NOTYPE GLOBAL DEFAULT UND printf
When i added cvmx-tim.o in the command , gcc will be executed successfully：
mipsisa64-octeon-elf-gcc obj/cvmx-tim.o obj/zxmd_main.o obj/zxmd_mproc.o obj/zxmd_init.o obj/zxmd_pcie.o obj/libcvm-common.a obj/libcvm-pci-drv.a obj/libcvmhfao.a obj/libocteon-hfa.a /home/jianxi/Juson/JusonFlow/sdk/OCTEON-SDK/components/hfa/lib-octeon/pp/octeon/se/libpp.a obj/libcvmx.a obj/libzxexe.a obj/libfdt.a -mfix-cn63xxp1 -march=octeon2 -o cn63hw1.bin
And if put obj/libcvmx.a in front of obj/zxmd_main.o , gcc will report more errors.
Why gcc can not find cvmx-tim.o in the libcvmx.a?
The order of *.o will cause problems?
It's the order of the libraries:
obj/libcvmx.a obj/libzxexe.a
by the time the linker searches obj/libzxexe.a it has already processed obj/libcvmx.a - it won't search it again for anything that was not already been pulled in when obj/libcvmx.a was processed the first time around.
Change the order of those libraries to:
obj/libzxexe.a obj/libcvmx.a
Besides changing the order of the libraries, you can also force the cvmx_tim_setup to be a marked as 'undefined' symbol in command line. If the symbol is known to be required, then the linker will be on the lookout for it and remember the first library defining it.
add this flag to gcc command: -Wl,--undefined=cvmx_tim_setup
Additionally you can also experiment with --start-group and --end-group in gcc. --start-group (list of binaries to link) --end-group. This will allow a full circular closure for searches. But will cost some link performance.
Ref:
http://eli.thegreenplace.net/2013/07/09/library-order-in-static-linking
Paxym