forked from OSchip/llvm-project
c58c64d05c
Unit numbers must fit on a default integer. It is however possible that the user provides the unit number in UNIT with a wider integer type. In such case, lowering was previously silently narrowing the value and passing the result to the BeginXXX runtime entry points. Cases where the conversion caused overflow were not reported/caught. Most existing compilers catch these errors and raise an IO error. Add a CheckUnitNumberInRange runtime API to do the same in f18. This runtime API has its own error management interface (i.e., does not use GetIoMsg, EndIo, and EnableHandlers) because the usual error management requires BeginXXX to be called to set up the error management. But in this case, the BeginXXX cannot be called since the bad unit number that would be provided to it overflew (and in the worst case scenario, the narrowed value could point to a different valid unit already in use). Hence I decided to make an API that must be called before the BeginXXX and should trigger the whole BeginXXX/.../EndIoStatement to be skipped in case the unit number is too big and the user enabled error recovery. Note that CheckUnitNumberInRange accepts negative numbers (as long as they can fit on a default integer), because unit numbers may be negative if they were created by NEWUNIT. Differential Revision: https://reviews.llvm.org/D123157 |
||
|---|---|---|
| .. | ||
| Common | ||
| Decimal | ||
| Evaluate | ||
| Frontend | ||
| Optimizer | ||
| Runtime | ||
| CMakeLists.txt | ||