Upcoming repository freez

[Giuseppe Congiu]

Dear All,

The PAPI repository will be frozen on October 28th to prepare for the next release.

If you plan to submit a PR please do before October 28th

Best,
Giuseppe Congiu

[William Cohen]

Hi Giuseppe,

Thanks for the heads up. I will take a look and see if there are any issues with what is currently in the git repository before the upcoming release.

-Will

[William Cohen]

On 10/14/22 10:56, Giuseppe Congiu wrote:

Hi,

I have been working on packaging the current papi git repository to see if there are any clean up or fixes needed. At this point I have a papi SRPM building. There were a couple minor fixes that I put in a pull request:


https://bitbucket.org/icl/papi/pull-requests/378

It took me a couple tries to get papi building. IIRC components most components would build only if added to the --with-components="...". I was a bit surprised when I was getting errors related to the sde component when it wasn't enabled in the rpm build. Got errors like the following:

/usr/bin/ld: /home/wcohen/rpmbuild/BUILD/papi-6.0.0/src/libsde.a(sde_lib_s.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld: /home/wcohen/rpmbuild/BUILD/papi-6.0.0/src/libsde.a(sde_lib_datastructures_s.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIE
/usr/bin/ld: /home/wcohen/rpmbuild/BUILD/papi-6.0.0/src/libsde.a(sde_lib_misc_s.o): relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a PIE object; recompile with -fPIE
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:56: papi_native_avail] Error 1
make[1]: Leaving directory '/home/wcohen/rpmbuild/BUILD/papi-6.0.0/src/utils'
make: *** [Makefile.inc:245: utils] Error 2

I did some digging around in the git commits and found that this likely triggered by commmit 3e54ecd717b1337359deadfd319512bfa1a3dbce which looks like it aways build the .a unless --with-libsde=no is in the configure. Shouldn't not including the sde component also disable building the libraries?

I will do some more testing and examination of PAPI now that I have a builable RPM.

-Will

[Giuseppe Congiu]

Hi Will,

The libsde is independent from the sde component. By default, as you pointed out, we chose to always build it. The reason is that libsde can be used independently from PAPI, as other tools might decide to access software defined events without PAPI as intermediary.

—Giuseppe

[Heike Jagode]

Giuseppe,

Just to clarify: only PAPI can access SDEs. As of today, there are no "other tools that might decide to access SDEs".

Thanks,

Heike

--
You received this message because you are subscribed to the Google Groups "ptools-perfapi" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ptools-perfap...@icl.utk.edu.
To view this discussion on the web visit https://groups.google.com/a/icl.utk.edu/d/msgid/ptools-perfapi/FA340B9D-EEA6-41B6-A94D-0354025CAC57%40icl.utk.edu.

--

______________________________________
Heike Jagode, Ph.D., Research Asst. Professor
Innovative Computing Laboratory, University of Tennessee Knoxville
http://icl.utk.edu/~jagode/

[Anthony Danalis]

Hi Will,

Indeed libsde is built independently of the component, and it's built
by default. The reason behind this design is so that third party
libraries that *export* software defined events can link properly even
if a PAPI user does not want to access those events. The sde component
on the other hand is the part of PAPI that accesses the software
defined events in a third party library. Its existence or not has
nothing to do with libsde.
However, your problem seems to be with the generation of the static
library specifically. If this is true, then we could avoid building
libsde.a if the user configures PAPI with the flag
--with-static-lib=no
Is that an acceptable solution from your end?

thanks,
Anthony

> --
> You received this message because you are subscribed to the Google Groups "perfapi-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to perfapi-deve...@icl.utk.edu.
> To view this discussion on the web visit https://groups.google.com/a/icl.utk.edu/d/msgid/perfapi-devel/1ab3de4b-963c-8b25-2b9c-9e94db0c4fc4%40redhat.com.

[William Cohen]

On 10/18/22 16:08, Anthony Danalis wrote:
> Hi Will,
>
> Indeed libsde is built independently of the component, and it's built
> by default. The reason behind this design is so that third party
> libraries that *export* software defined events can link properly even
> if a PAPI user does not want to access those events. The sde component
> on the other hand is the part of PAPI that accesses the software
> defined events in a third party library. Its existence or not has
> nothing to do with libsde.
> However, your problem seems to be with the generation of the static
> library specifically. If this is true, then we could avoid building
> libsde.a if the user configures PAPI with the flag
> --with-static-lib=no
> Is that an acceptable solution from your end?

Yes, that is what I was thinking. PAPI should not be building any static library (.a file) when --with-static-lib=no is specified in the configuration. For the time being I have --with-libsde=no in the configuration to allow the papi rpm to build.

-Will

[Anthony Danalis]

On Tue, Oct 18, 2022 at 4:23 PM William Cohen <wco...@redhat.com> wrote:
>
> On 10/18/22 16:08, Anthony Danalis wrote:
> > Hi Will,
> >
> > Indeed libsde is built independently of the component, and it's built
> > by default. The reason behind this design is so that third party
> > libraries that *export* software defined events can link properly even
> > if a PAPI user does not want to access those events. The sde component
> > on the other hand is the part of PAPI that accesses the software
> > defined events in a third party library. Its existence or not has
> > nothing to do with libsde.
> > However, your problem seems to be with the generation of the static
> > library specifically. If this is true, then we could avoid building
> > libsde.a if the user configures PAPI with the flag
> > --with-static-lib=no
> > Is that an acceptable solution from your end?
>
> Yes, that is what I was thinking. PAPI should not be building any static library (.a file) when --with-static-lib=no is specified in the configuration. For the time being I have --with-libsde=no in the configuration to allow the papi rpm to build.
>
> -Will

HI Will,

Commit 4b6000d should fix the problem you were having. Can you
please try it and let us know if it works as expected for you?

thanks,
Anthony

[William Cohen]

Did another round of packaging the papi git as an RPM. I eliminated the "--with-libsde=no" from the configure and the rpm built fine, no libsde.a being built. Thanks,

-Will

[Anthony Danalis]

Great! Thanks for the quick response Will.

Anthony

[William Cohen]

On 10/14/22 10:56, Giuseppe Congiu wrote:

Hi,

I have been trying out rpms of the papi get checkout on various machines. A couple things I noticed comparing the results with the older version of Fedora papi.

The validation_tests/papi_br_msp for the git repo version failing on aarch64 and AMD machines where it PASSED before. Run of the papi_br_msp on the same AMD process or the query_device_simple_f below:

$ /usr/share/papi/validation_tests/papi_br_msp

Testing the PAPI_BR_MSP event.

Part 1: Testing that easy to predict loop has few misses
Testing a loop with 1500000 branches (100 times):
On a simple loop like this, miss rate should be very small.
Average number of branch misses: 3

Part 2

Testing a function that branches based on a random number
The loop has 14403278 branches
500000 are random branches.

Out of 14403278 branches, 32305 were mispredicted
Assuming a good random number generator and no freaky luck
The mispredicts should be roughly between 125000 and 375000
Mispredicts too low
FAILED!!!
Line # 183 Error: Error too low
Some tests require special hardware, permissions, OS, compilers
or library versions. PAPI may still function perfectly on your
system without the particular feature being tested here.



The usr/share/papi/components/sysdetect/tests/query_device_simple_f puts a lots of null characters in the output for Vendor that are visible when looking at the output with an editor such as emacs.

/usr/share/papi/components/sysdetect/tests/query_device_simple_f > b
emacs b

Vendor : AuthenticAMD\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0( 2 )
Id : 0
Name : AMD Ryzen 3 3250U with Radeon Graphics
CPUID : 23 / 24 / 1
Sockets : 1
Numa regions : 1
Cores/socket : 2
Cores/numa : 4
SMT/core : 2
L1i cache : size/line size/lines/associativity 64 64 1024 4
L1d cache : size/line size/lines/associativity 32 64 512 8
L2 cache : size/line size/lines/associativity 512 64 8192 8
L3 cache : size/line size/lines/associativity 4096 64 8192 16
Numa 0 threads:
0
1
2
3



On another machine that had PCP installed it looks like the pcp component is causing some issues:

-Running ctests/failed_events: PASSED
+Running ctests/failed_events: components/pcp/linux-pcp.c:1751:_pcp_ntv_name_to_code Failed to find name='INVALID_EVENT', hash=109.
+components/pcp/linux-pcp.c:1751:_pcp_ntv_name_to_code Failed to find name='AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA', hash=68.
+components/pcp/linux-pcp.c:1751:_pcp_ntv_name_to_code Failed to find name='AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
...

+components/pcp/linux-pcp.c:1751:_pcp_ntv_name_to_code Failed to find name='UNHALTED_CORE_CYCLESe=0', hash=117.
+components/pcp/linux-pcp.c:1751:_pcp_ntv_name_to_code Failed to find name='UNHALTED_CORE_CYCLESi=0', hash=377.
+components/pcp/linux-pcp.c:1751:_pcp_ntv_name_to_code Failed to find name='UNHALTED_CORE_CYCLESc=0', hash=499.
+components/pcp/linux-pcp.c:1751:_pcp_ntv_name_to_code Failed to find name='UNHALTED_CORE_CYCLESt=0', hash=68.
+components/pcp/linux-pcp.c:1751:_pcp_ntv_name_to_code Failed to find name='UNHALTED_CORE_CYCLES:inx=0', hash=235.
+components/pcp/linux-pcp.c:1751:_pcp_ntv_name_to_code Failed to find name='UNHALTED_CORE_CYCLES:intxp=0', hash=356.
+components/pcp/linux-pcp.c:1751:_pcp_ntv_name_to_code Failed to find name='UNHALTED_CORE_CYCLESu=0', hash=133.
+components/pcp/linux-pcp.c:1751:_pcp_ntv_name_to_code Failed to find name='UNHALTED_CORE_CYCLESk=0', hash=507.
+components/pcp/linux-pcp.c:1751:_pcp_ntv_name_to_code Failed to find name='UNHALTED_CORE_CYCLES:perid=0', hash=105.
+components/pcp/linux-pcp.c:1751:_pcp_ntv_name_to_code Failed to find name='UNHALTED_CORE_CYCLES:frq=0', hash=212.
+components/pcp/linux-pcp.c:1751:_pcp_ntv_name_to_code Failed to find name='UNHALTED_CORE_CYCLES:exl=0', hash=58.
+components/pcp/linux-pcp.c:1751:_pcp_ntv_name_to_code Failed to find name='UNHALTED_CORE_CYCLES:g=0', hash=58.
+components/pcp/linux-pcp.c:1751:_pcp_ntv_name_to_code Failed to find name='UNHALTED_CORE_CYCLES:h=0', hash=123.
...

-Will

[Anthony Danalis]

Hello Will,

I cannot reproduce the problem with the branch validation test. Can
you give us more details on the hardware you ran it on?
I tried on an AMD EPYC 7413 and got the following successful result:

$ ./papi_br_msp

Testing the PAPI_BR_MSP event.

Part 1: Testing that easy to predict loop has few misses
Testing a loop with 1500000 branches (100 times):
On a simple loop like this, miss rate should be very small.

Average number of branch misses: 5

Part 2

Testing a function that branches based on a random number

The loop has 14000056 branches
500000 are random branches.

Out of 14000056 branches, 283425 were mispredicted

Assuming a good random number generator and no freaky luck
The mispredicts should be roughly between 125000 and 375000

PASSED


thanks,
Anthony

> --
> You received this message because you are subscribed to the Google Groups "perfapi-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to perfapi-deve...@icl.utk.edu.

> To view this discussion on the web visit https://groups.google.com/a/icl.utk.edu/d/msgid/perfapi-devel/251e3f98-c749-7de1-f307-a1960b21e2eb%40redhat.com.

[William Cohen]

On 10/27/22 16:49, Anthony Danalis wrote:
> Hello Will,
>
> I cannot reproduce the problem with the branch validation test. Can
> you give us more details on the hardware you ran it on?
> I tried on an AMD EPYC 7413 and got the following successful result:
>
> $ ./papi_br_msp
>
> Testing the PAPI_BR_MSP event.
>
> Part 1: Testing that easy to predict loop has few misses
> Testing a loop with 1500000 branches (100 times):
> On a simple loop like this, miss rate should be very small.
> Average number of branch misses: 5
>
> Part 2
>
> Testing a function that branches based on a random number
> The loop has 14000056 branches
> 500000 are random branches.
>
> Out of 14000056 branches, 283425 were mispredicted
> Assuming a good random number generator and no freaky luck
> The mispredicts should be roughly between 125000 and 375000
>
> PASSED
>
>
> thanks,
> Anthony

Hi Anthony,

I have also seen the validation_tests/papi_br_msp and validation_tests/papi_br_prc fail on an Intel with the following /proc/cpuinfo:

processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 158
model name : Intel(R) Xeon(R) CPU E3-1505M v6 @ 3.00GHz
stepping : 9
microcode : 0xf0
cpu MHz : 3000.000
cache size : 8192 KB

The AMD machine was the following CPU information:

Both the machines are running relatively updated versions of Fedora 36:

vendor_id : AuthenticAMD
cpu family : 23
model : 24
model name : AMD Ryzen 3 3250U with Radeon Graphics
stepping : 1
microcode : 0x8108109
cpu MHz : 1208.956
cache size : 512 KB

I am wondering if these failures might be some side-effect of what code the Fedora 36 GCC is generating for the test:

gcc-12.2.1-2.fc36.x86_64

There are scratch builds of the papi rpm I am using at:

https://koji.fedoraproject.org/koji/taskinfo?taskID=93598856

According to the scratch build on F36 the test is being built with -O2 and LTO:

gcc -O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -g -Wextra -Wall -DPAPI_NUM_COMP=15 -O2 -I../testlib -I.. -I. -c papi_br_msp.c

Measures might need to be taken to turn off optimization for some of the tests.

-Will

[Anthony Danalis]

Will, thanks for the additional info. I changed the validation test
(commit: 0dd5075). Can you please check if the updated version still
suffers from the same problem on your machine(s)?

thanks,
Anthony

[William Cohen]

On 11/1/22 13:59, Anthony Danalis wrote:
> Will, thanks for the additional info. I changed the validation test
> (commit: 0dd5075). Can you please check if the updated version still
> suffers from the same problem on your machine(s)?
>
> thanks,
> Anthony

Hi Anthony,

Just tried a fresh git checkout on the same machine and below are the current results. The papi_br_msp still fails. -Will

Running Event Validation Tests

Running validation_tests/cycles_validation: PASSED
Running validation_tests/flops_validation: PASSED
Running validation_tests/fp_validation_hl: PASSED
Running validation_tests/papi_br_cn: PASSED
Running validation_tests/papi_br_ins: PASSED
Running validation_tests/papi_br_msp: FAILED!!!
Line # 186 Error: Error too low

Some tests require special hardware, permissions, OS, compilers
or library versions. PAPI may still function perfectly on your
system without the particular feature being tested here.

Running validation_tests/papi_br_ntk: PASSED
Running validation_tests/papi_br_prc: FAILED!!!
Line # 210 Error: Error too low

Some tests require special hardware, permissions, OS, compilers
or library versions. PAPI may still function perfectly on your
system without the particular feature being tested here.

Running validation_tests/papi_br_tkn: PASSED
Running validation_tests/papi_br_ucn: PASSED
Running validation_tests/papi_dp_ops: PASSED
Running validation_tests/papi_fp_ops: SKIPPED
Running validation_tests/papi_hw_int: SKIPPED
Running validation_tests/papi_l1_dca: SKIPPED
Running validation_tests/papi_l1_dcm: FAILED!!!
Line # 204 Error: Error too high

Some tests require special hardware, permissions, OS, compilers
or library versions. PAPI may still function perfectly on your
system without the particular feature being tested here.

Running validation_tests/papi_l2_dca:
WARNING Line # 209 Warning: Error too high
PASSED with WARNING
Running validation_tests/papi_l2_dcm:
WARNING Line # 206 Warning: Error too high
PASSED with WARNING
Running validation_tests/papi_l2_dcr:
WARNING Line # 188 Warning: Error too high
PASSED with WARNING
Running validation_tests/papi_l2_dcw:
WARNING Line # 195 Warning: Error too high
WARNING Line # 199 Warning: Average results OK but some measurements low
PASSED with WARNING
Running validation_tests/papi_ld_ins: PASSED
Running validation_tests/papi_ref_cyc: PASSED
Running validation_tests/papi_sp_ops: PASSED
Running validation_tests/papi_sr_ins: FAILED!!!
Line # 139 Error: Error too high

Some tests require special hardware, permissions, OS, compilers
or library versions. PAPI may still function perfectly on your
system without the particular feature being tested here.

Running validation_tests/papi_tot_cyc: PASSED
Running validation_tests/papi_tot_ins: PASSED