host side subscript out of range


exhibit A:

int lint[1];

lint[0] = A;
lint[1] = B;

i can not think of a case where exhibit A as device code did not raise a compiler warning: ‘subscript out of range’
if it occurred before, i can not recall it; in fact, i have become accustomed to the ‘device side compiler’ complaining about such instances, to my benefit

but, at the same time, as much as the ‘device side compiler’ complains about it, the ‘host side compiler’ liberally overlooks this, from time to time it seems
i have lost count of the number of cases where such subscript errors occurred, with the host not raising warnings, leaving me to subsequently start a debugging mission 200 lines later

should the compiler raise host side subscript out of range warnings at all times?
should this be considered a bug, or not?

I could not trigger any device code warnings creating a simple kernel around what you have shown:

$ cat
#include <stdio.h>

__global__ void kernel(int a){

  int lint[1];
  lint[0] = a+5;
  lint[1] = a+6;

  printf("0: %d, 1: %d\n", lint[0], lint[1]);

int main(){

$ nvcc -o xx

“I could not trigger any device code warnings”

that was my point

i am arguing host side; the compiler seems to slip up on this host side - sometimes; not always
i can not think of device side cases; however, i can think of host side cases
i encountered 1 today, and at least 2 in the last 2 weeks

should this be considered a bug - can you confirm this perhaps, given that it is host side
i do not know whether gnu as c compiler considers it a bug or permissible, hence the reason why the compiler does not always warn about it

i do not want to waste time on a reproduction case, before i know it is indeed a bug

The C++ standard places only very modest requirements on compilers with regards to warnings. Best I know, standard-compliant compilers are not required to warn about out-of-bounds accesses for arrays. Whether to emit a warning in such cases is up to the compiler vendor. Note: The C++ standard is very voluminous. Should I have overlooked a relevant requirement for out-of-bounds checks, please point to the relevant section.

Since you are referring specifically to host code, you would want to check the documentation for MSVC, clang, or gcc (depending on your platform) to see whether they make any promises regarding out-of-bounds checks. In practical terms, you could try specifying a higher warning level for the host compiler using nvcc’s -Xcompiler flag.

For what it is worth, the older versions of MSVC and the Intel compiler I have available to me do not emit warnings for the case stated in the thread-starting post, even at the highest warning level.

it may seem a trivial case at first; but, when the host is ‘responsible’ for the device, it should be clear that it is not
sometimes i pick it up before and whilst debugging; sometimes i miss it, even with eyes (thought to be) wide open
the host function does not ‘break’ altogether and thus seems right, even when stepping it
and if the host function sets up or controls device functionality, the error is quickly amplified

if the compiler is not going to warn about this in a consistent manner, i shall have to find an alternative solution
i have to double check that valgrind picks it up; the problem with valgrind is that debugging is normally incremental and stepwise
best option i can think of thus far is to use a common, slightly oversized working array allocated before any host function, and used by all host functions