aboutsummaryrefslogtreecommitdiff
path: root/gcc/ada/exp_ch8.adb
diff options
context:
space:
mode:
authorEric Botcazou <ebotcazou@adacore.com>2023-06-21 16:06:52 +0200
committerMarc Poulhiès <poulhies@adacore.com>2023-07-03 15:26:13 +0200
commitabc202d8c58e75940e27b324756c68504965f0ee (patch)
tree2ef6a69b6e0a2ed1c9a67ab14368bf2abe60405e /gcc/ada/exp_ch8.adb
parenta7a89c370c0ac78fb08eec49cb08b1a23cc4c8b7 (diff)
downloadgcc-abc202d8c58e75940e27b324756c68504965f0ee.zip
gcc-abc202d8c58e75940e27b324756c68504965f0ee.tar.gz
gcc-abc202d8c58e75940e27b324756c68504965f0ee.tar.bz2
ada: Fix discrepancy in expansion of untagged record equality
The expansion of the predefined equality operator for untagged record types can be done either in line, i.e. into the component-wise comparison of the operands, or out of line, i.e. into a call to a function implementing this comparison, and the heuristics of the selection are essentially based on the complexity of the implementation. For discriminated record types with a variant part, which comprise unchecked union types, the expansion is always done out of line. For nondiscriminated types, the expansion is done in line, unless one of the components is of a record type for which a user-defined equality operator exists, in which case the expansion is done out of line. For the third case, i.e. discriminated record types without a variant part, the expansion is always done in line. Now given that the discriminants are considered as mere components for the purpose of predefined equality in this case, there does not seem to be any reason for treating it differently from the second case above. gcc/ada/ * exp_ch3.adb (Build_Untagged_Equality): Rename into... (Build_Untagged_Record_Equality): ...this. (Expand_Freeze_Record_Type): Adjust to above renaming and invoke the procedure also for discriminated types without a variant part.
Diffstat (limited to 'gcc/ada/exp_ch8.adb')
0 files changed, 0 insertions, 0 deletions