Assignment between restrict pointers "alpha" and "alpha_in" is not allowed. Only outer-to-inner scope assignments between restrict pointers are allowed. #6
Comments
|
Whether or not XLC is right, woe to he who ignores restrict warnings. |
|
Jeff, Best thing to do in the short term is to insert a “#define restrict /* nothing */“ in the bli_config.h for bgq. What’s going on below can be fixed by a couple of extra curly braces. As an example, XLC will complain about: But it won’t complain about: So basically to use restrict pointers on bgq, BLIS just needs a ton of extra curly braces. -Tyler On Apr 3, 2014, at 3:33 PM, Jeff Hammond notifications@github.com wrote:
|
|
As Tyler pointed out, BLIS is not yet completely restrict-compliant. This is partially my fault for misusing the keyword to begin with, and partially gcc's fault for not informing me of the misuse with a warning. :) I am trying to fix these as I find them, but it's kind of like whack-a-mole. Especially since none of my primary development machines have xlc. |
|
I will add the curly braces rather than give up the benefits of anti-aliasing. Field: you can get an an ALCF account from me any time. |
|
This particular instances (config/bgq/kernels/1/bli_axpyv_opt_var1.c) can easily be fixed even without curlies. I will push a new commit soon. Thanks for the offer, Jeff. I will take you up on it sometime! |
Details: - Fixed improper usage of restrict keyword in axpyv and dotv bgq kernels. (However, there may be other instances of similar misuse elsewhere in BLIS.) Thanks to Jeff Hammond for reporting this issue.
|
Jeff: please confirm that this has been fixed. If not, I suspect it is because there are other instances of the same problem that the build process now gets to that it was not getting to previously. If so, let's just keep the issue/thread going till we stomp them all out. |
|
With the latest commit, I saw this: I fixed like this: Don't ask me why vec_lds won't take a restrict pointer. http://pic.dhe.ibm.com/infocenter/compbg/v121v141/index.jsp?topic=%2Fcom.ibm.xlcpp121.bg.doc%2Fcompiler_ref%2Fvec_lds.html does not mention this semantic restriction. |
|
Thanks again, Jeff. |
This needs fixing properly somehow, but using -O3 (at least with gcc 8.3),
we get this:
Program received signal SIGILL, Illegal instruction.
0x000000001004c660 in bli_cntx_init_power9_ref (cntx=0x103e06b0)
at ref_kernels/bli_cntx_ref.c:456
456 for ( i = 0; i < BLIS_NUM_LEVEL3_OPS; ++i ) vfuncs[ i ] = NULL;
(gdb) bt
#0 0x000000001004c660 in bli_cntx_init_power9_ref (cntx=0x103e06b0)
at ref_kernels/bli_cntx_ref.c:456
flame#1 0x000000001004c0a8 in bli_cntx_init_power9 (cntx=<optimized out>)
at config/power9/bli_cntx_init_power9.c:42
flame#2 0x000000001003c85c in bli_gks_register_cntx (id=BLIS_ARCH_POWER9,
nat_fp=0x1004c090 <bli_cntx_init_power9>,
ref_fp=0x1004c0d0 <bli_cntx_init_power9_ref>, ind_fp=<optimized out>)
at frame/base/bli_gks.c:373
flame#3 0x000000001003c97c in bli_gks_init () at frame/base/bli_gks.c:155
flame#4 0x000000001003cfe8 in bli_init_apis () at frame/base/bli_init.c:78
flame#5 0x00007ffff7e045a8 in __pthread_once_slow () from /lib64/libpthread.so.0
flame#6 0x00000000100492e8 in bli_pthread_once (once=<optimized out>,
init=<optimized out>) at frame/thread/bli_pthread.c:314
flame#7 0x000000001003d138 in bli_init_once () at frame/base/bli_init.c:104
flame#8 bli_init_auto () at frame/base/bli_init.c:54
flame#9 0x0000000010011300 in cdotc_ (n=<optimized out>, x=<optimized out>,
incx=<optimized out>, y=<optimized out>, incy=<optimized out>)
at frame/compat/bla_dot.c:89
flame#10 0x0000000010002a48 in check2_ (sfac=0x103d14dc <sfac>)
at blastest/src/cblat1.c:529
flame#11 0x0000000010001ef4 in main () at blastest/src/cblat1.c:112
XLC is the only compiler I've ever seen that gives these warnings, but I think they are formally legit. On the other hand, they may be false positives in practice.
The text was updated successfully, but these errors were encountered: