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.

10 post / 0 nuovi
Ultimo contenuto
Per informazioni complete sulle ottimizzazioni del compilatore, consultare l'Avviso sull'ottimizzazione

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 For 1:1 technical support: http://premier.intel.com 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 For 1:1 technical support: http://premier.intel.com 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

Lascia un commento

Eseguire l'accesso per aggiungere un commento. Non siete membri? Iscriviti oggi