In general for any OS running on any processor it is the job of the OS to conceal the existence of certain faults from the application. E.g. page faults, or perhaps unaligned access traps may be transparently fixed by the OS and the application restarted without any notification that this had happened.
The best way for the application to tell whether a fault was raised would be to time the execution. Many processors provide very high resolution timers, and Itanium is no exception. The "ar.itc" register may be readable by an application (it is possible for an OS to prevent this since there is a PSR.si bit that makes reading ar.itc a privileged operation).
There is the possibility for false positives using this method. If an interrupt occurs, or if the application exceeds its timeslice and is context switched. Or on a threaded processor implementation (series 9000) the processor may switch to the other thread.
Some care is also required on Itanium that you really measure what you think you are measuring since a read from ar.itc may not be completed in the "obvious" linear program order. E.g. to time a load instruction, you should read ar.itc before the load, but you should be sure to consume the value read (use it as an operand in another instruction) before re-reading ar.itc.
Some other feedback we got on thistopic froma member of the engineering team:
The followingis for floating-point exceptions only -- faults (invalid, denormal, divide-by-zero) or traps (underflow, overflow, inexact). You can unmask (enable) the exceptionyou areinterested in. Without a user floating-point exception handler to resume execution if such an exception occurs (it is not very easy to write one), the user program will be terminated by the OS if a floating-point exception occurs during its execution.