diff options
author | Eric Botcazou <ebotcazou@adacore.com> | 2023-06-21 16:06:52 +0200 |
---|---|---|
committer | Marc Poulhiès <poulhies@adacore.com> | 2023-07-03 15:26:13 +0200 |
commit | abc202d8c58e75940e27b324756c68504965f0ee (patch) | |
tree | 2ef6a69b6e0a2ed1c9a67ab14368bf2abe60405e /gcc/ada/exp_ch8.adb | |
parent | a7a89c370c0ac78fb08eec49cb08b1a23cc4c8b7 (diff) | |
download | gcc-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