Why must loop variables be signed in a parallel for?

流过昼夜 提交于 2019-12-04 06:16:23

According to OpenMP 3.0 specification: http://www.openmp.org/mp-documents/spec30.pdf, for variable may be of a signed or unsigned integer type, see 2.5.1 Loop Construct. The question is whether given OpenMP implementation matches this latest specification.

Jacob

Quoting from Why aren't unsigned OpenMP index variables allowed? :

According to the OpenMP 2.0 C/C++ API specification (pdf), section 2.4.1, that's one of the restrictions of the for loop. No reason is given for it, but I suspect it's just to simplify the assumptions that the code and compiler have to make, since there's special code to ensure that the range doesn't overflow the maximum value of the type.

OpenMP 3.0 apparently allows for unsigned types too, but I haven't seen it in action yet.

In short, it's part of the standard and the next version will allow unsigned integers.

Here's a possible reason behind that. The same article says that

  • b, ub, incr are loop invariant signed integer expressions and
  • exit_cond takes form: iv <= ub or iv < ub or iv >= ub or iv > ub (where iv is the iteration variable you ask about)

since the exit_cond condition involves a comparison and the comparison is done against a signed ub variable the loop variable iv has to be signed to avoid possible problems with signed/unsigned comparison.

To answer your first question about gcc. No, it seems that gcc easily accepts unsigned or size_t loop variables in something like

#pragma omp parallel for
for (size_t i = 0; i < N; ++i) {
  /* do it */
}

at least mine (gcc v 4.4 on a 64bit ubuntu) doesn't complain and does the right thing.

易学教程内所有资源均来自网络或用户发布的内容,如有违反法律规定的内容欢迎反馈
该文章没有解决你所遇到的问题?点击提问,说说你的问题,让更多的人一起探讨吧!