diff options
author | Steve Baird <baird@adacore.com> | 2022-09-28 10:32:00 -0700 |
---|---|---|
committer | Marc Poulhiès <poulhies@adacore.com> | 2022-10-06 11:22:48 +0200 |
commit | b1006d33b330c11952156dd41dae3a3bb2076a76 (patch) | |
tree | 41ed964681264d0807a54663fb2b5ed276f012b5 /gcc/ada/gcc-interface/utils.cc | |
parent | f775d362aa73353ce07a51c259ca0a3e1f41ba3b (diff) | |
download | gcc-b1006d33b330c11952156dd41dae3a3bb2076a76.zip gcc-b1006d33b330c11952156dd41dae3a3bb2076a76.tar.gz gcc-b1006d33b330c11952156dd41dae3a3bb2076a76.tar.bz2 |
ada: Incorrect inferences drawn from if/elsif/while conditions with -gnatVo
Within the first (respectively, second) statement list of this if statement
declare
X : constant Integer := ... ;
begin
if X > 0 then
...;
else
...;
end if;
end;
we can safely assume that X is greater (respectively, not greater) than 0.
Fix a bug that incorrectly computed the region in which such assumptions
can be made to include the condition of the if-statement. This bug usually
had no effect because semantic analysis/simplification of the condition was
already complete before the code containing the bug was executed.
Unfortunately, this is not true in some cases involving -gnatVo validity
checking. In these cases, the bug could result in incorrect simplification
of the condition at compile time. This, in turn, could lead to incorrect
unconditional execution of one arm of the if-statement at run time. Similar
errors appear to be possible for the conditions of an elsif or a while loop;
the fix addresses these cases as well, although corresponding problems with
these constructs have not been demonstrated.
gcc/ada/
* exp_util.adb
(Get_Current_Value_Condition): Treat references occurring within
the condition of an if statement, an elsif, or a while loop in the
same way as references that occur before the start of that
enclosing construct.
Diffstat (limited to 'gcc/ada/gcc-interface/utils.cc')
0 files changed, 0 insertions, 0 deletions