What is this error,how do I get rid of it

What is this error,how do I get rid of it

Imagen de newport_j

I got no reply to this question when I posted it last yesterday, so I must post it again. Any help appreciated.

Ichanged my main to cilk_main and got the following error:

error: ISO C++ forbids declaration of 'cilk_main' with no type

This complaint was made only after I added cilk to main to get cilk_main in my program code asI was instructed to doina previous forum post. That change in my code did get rid of a lotof errors, but created this one

I am just unsure whatis causing this and how do I get rid of it.

Newport_j

publicaciones de 8 / 0 nuevos
Último envío
Para obtener más información sobre las optimizaciones del compilador, consulte el aviso sobre la optimización.
Imagen de William Leiserson (Intel)
Imagen de newport_j

What you say is true. Putting int in front of cilk_main does eliminate the error. However, the Intel Cilk++ SDK Programmers Guide on page 14 where it talks about converting a basic C/C++ program to Cilk it merely states that tochange main() to cilk_main() is the only step required. It says nothing about adding int in front of the wholeoperation.

In fact when I worked that problem as a learning exercise the program ran with no int in front of cilk_main(). I saw the error explained in a FAQ section of a earlier Cilk paper and it said to do the exact same thing as you said.

So why do it now (put int in front of cilk_main()) and not before?

Newport_j

Imagen de William Leiserson (Intel)

The short answer is that the Cilk++ compiler rejected it because the C++ compiler _should_ have rejected it.

The longer answer is: The C++ standard says that, "[main]shall have a return type of type int, but otherwise its type is implementation-defined. All implementations shall allow both of the following definitions of main

int main () { /* . . . */ }

and

int main (int argc , char * argv []) { /* . . . */ }"

(section 3.6.1: Main function)

Strictly speaking, main() returns an int. I know you can do short-cuts like omitting the type in C. But I'm a little surprised that the C++ compiler actually compiled it without at least giving you a warning.

Imagen de newport_j

I believe it and thank you for the information.

Apparently this is a common error, sinceI found it addressed in a earlier paper on Cilk and it was in the frequently asked questions section. So this must be a common mistake. Is the suggestion to change main() to cilk_main() correct as far as it goes (on page 14 in the Intell Cilk Programmers Guide)? It just does not go far enough? I can check, but in that example, I do not remember putting an int before cilk_main() when I worked that exercise.

Also, where canI read about reducers outside of that above guide. I still am having a hard time understanding them.

Again, thanks for your help.

Newport_j

Imagen de William Leiserson (Intel)

I'm not surprised that it's a common error. I've seen many programs that use "void main()" which is anathema in C++. ;)

The general idea behind reducers is that you have some non-local variable on which your parallel program races. E.g.,

voidfoo (int &n) {
++n;
}

voidbar () {
int c= 0;
cilk_spawn foo(c);
foo(c);
cilk_sync;
printf("c = %d\n", c);
}

There is a race on "c" which is operated on in parallel in both calls to foo(). If c were a reducer hyperobject, however, each worker would see its own copy of c and be able to operate on it without conflicting with any other worker. At the cilk_sync, the various copies would be merged together to produce the same value as c had before bar() had any parallelism.

There are a few examples that use reducers that ship with Cilk++. They might help with a practical knowledge of reducers. On a more theoretical level, the paper, "Reducers and Other Cilk++ Hyperobjects" (Frigo, Halpern, Leiserson, Lewin-Berlin) says a bit about how they work:

http://www.fftw.org/~athena/papers/hyper.pdf

Imagen de newport_j

I use c a lot more than c++. I know c and I know c++, but not as well. I also know that c is a subset of c++ except for three instances, where the c component of c++ is is not the same as ANSI c. is this one of those three?

Newport_j

Imagen de William Leiserson (Intel)

This is definitely one of those ways. I'd be surprised if there were only two other ways, however. My understanding is that the standards bodies have tried to keep them reasonably consistent, but they have both evolved in their own directions.

Inicie sesión para dejar un comentario.