cilkscreen returns 0 when races found

cilkscreen returns 0 when races found

When running cilkscreen on the compiled output of simple_race.cpp (that comes as an example with cilkscreen), we noticed that cilkscreen returns 0 even though races are found.

Is there any way to get it to return non-zero? This makes automated testing more difficult.

publicaciones de 10 / 0 nuevos
Último envío
Para obtener más información sobre las optimizaciones del compilador, consulte el aviso sobre la optimización.

Hi Zardosht,

I've submitted this feature request. The Cilk Plus team will consider it, and I'll keep you up to date on their status.

Brandon Hewitt Technical Consulting Engineer Tools Knowledge Base: "http://software.intel.com/en-us/articles/tools" Software Product Support info: "http://www.intel.com/software/support"

Hi Zardosht,

The version of cilkscreen available now that supports 12.1 now implements this functionality under a -c option passed to cilkscreen. Let me know if you have any further questions.

Brandon Hewitt Technical Consulting Engineer Tools Knowledge Base: "http://software.intel.com/en-us/articles/tools" Software Product Support info: "http://www.intel.com/software/support"

There may stil bel a minor bug in the way the new version of cilkscreen works. The manual says that the exit code the number of races detected. What if 256 races are detected? If you call exit(N) then the exit code equals N%256. Could cilkscreen return 0 when there a nonzero number of races?I think it would make more sense to return a particular exit code (specified on the command line) when a race is detected. Look at how valgrind handles --error-exitcode-Bradley

I hadn't realized that Linux limited the exit codes to 0-255. Is there a reason for the limit? The exit() function takes a full in, not a char.

In any event, I'll change it as follows:

If you don't specify -c, the return code is the value returned by the application. This matches the prior behavior.

If you specify -c , Cilkscreen will return if any errors are found. If no errors are found, Cilkscreen will return 0.

- Barry

It has to do with the way the wait(2) system call is designed. They pack a bunch of information into an integer (e.g., did the process exit or signal?) They allocated only 8 bits for the exit code.
Take a look at the man page for wait(2), looking at the documentation for WEXITSTATUS.This is a unix-ism. As far as I can tell, the C99 standard just defines EXIT_SUCCESS and EXIT_FAILURE. Other exit values are undefined. I think EXIT_SUCCESS is defined to be zero.
I understand that on Windows the exit code can be an integer. You could still get an overflow, and I don't know what happens.

Also, cilkscreen should return whatever the application returns if no errors are found:application returns 0, no cilkscreen errors --> return 0.application returns R, no cilkscreen errors --> return R.application returns R, cilkscreen errors, -c C specified --> return C.application returns R, cilkscreen errors, no C specified, return R.

> Also, cilkscreen should return whatever the application returns if no errors are found

Then how do you differentiate between "Cilkscreen found no errors" and "The application returned an error"?

- Barry

(a) It's usually not important to distinguish between Cilkscreen errors and application errors. We run cilkscreen (and valgrind) in automated tests. We need to know whether the test succeeded, not how it failed. If a test is failing we can watch it more carefully to figure out what's going on.(b) When we do need to distinguish, we use a different error code. For all the code we run under valgrind, we know what possible exit status codes it might use. We tell valgrind to use a different error code.We want to be able to use Cilkscreen the way we use Valgrind in automated tests.-Bradley

OK. That's what I'll implement.

- Barry

Inicie sesión para dejar un comentario.