search for: check_xyz_passed

...in some cases, global state. > They do not modify a program's global state, but they do print output on > failures and can abort the program. I'm wondering if adding the > readnone/readonly attributes to these run-time checks is safe. Instead, how about having a readnone function check_xyz_passed that returns a boolean saying whether the check passed. Call check_xyz, examine the return value, and call the abort routine if it returned false. Ciao, Duncan.

Dear All, Are functions marked as readnone or readonly in the LLVM IR allowed to generate output or to exhibit exceptional behavior (e.g., calling abort(), generating an MMU fault, etc.)? The SAFECode compiler has a set of run-time checks that pass or fail based solely on the input arguments and, in some cases, global state. They do not modify a program's global state, but they do print

...lobal state. >> They do not modify a program's global state, but they do print output on >> failures and can abort the program. I'm wondering if adding the >> readnone/readonly attributes to these run-time checks is safe. > Instead, how about having a readnone function check_xyz_passed that returns > a boolean saying whether the check passed. Call check_xyz, examine the return > value, and call the abort routine if it returned false. We can do that for load/store checks. GEP checks may be a little more tricky (at least for SAFECode); they either return the real pointer...