diff options
author | Pat Rogers <rogers@adacore.com> | 2019-07-01 13:35:53 +0000 |
---|---|---|
committer | Pierre-Marie de Rodat <pmderodat@gcc.gnu.org> | 2019-07-01 13:35:53 +0000 |
commit | 76fd94165a00ca6371c557e855cdd47a3b823da8 (patch) | |
tree | 81e0504293682ea93b4cf9e90adb2186f75865d0 /gcc | |
parent | 339ff2f61d916b1d2d449ed0f3d477c1a0510bf6 (diff) | |
download | gcc-76fd94165a00ca6371c557e855cdd47a3b823da8.zip gcc-76fd94165a00ca6371c557e855cdd47a3b823da8.tar.gz gcc-76fd94165a00ca6371c557e855cdd47a3b823da8.tar.bz2 |
[Ada] Correct size in representation clauses documentation
2019-07-01 Pat Rogers <rogers@adacore.com>
gcc/ada/
* doc/gnat_rm/representation_clauses_and_pragmas.rst: Correct
size indicated for R as a component of an array.
* gnat_rm.texi: Regenerate.
From-SVN: r272869
Diffstat (limited to 'gcc')
-rw-r--r-- | gcc/ada/ChangeLog | 6 | ||||
-rw-r--r-- | gcc/ada/doc/gnat_rm/representation_clauses_and_pragmas.rst | 25 | ||||
-rw-r--r-- | gcc/ada/gnat_rm.texi | 27 |
3 files changed, 41 insertions, 17 deletions
diff --git a/gcc/ada/ChangeLog b/gcc/ada/ChangeLog index 5cd8d90..e624e6b 100644 --- a/gcc/ada/ChangeLog +++ b/gcc/ada/ChangeLog @@ -1,3 +1,9 @@ +2019-07-01 Pat Rogers <rogers@adacore.com> + + * doc/gnat_rm/representation_clauses_and_pragmas.rst: Correct + size indicated for R as a component of an array. + * gnat_rm.texi: Regenerate. + 2019-07-01 Justin Squirek <squirek@adacore.com> * libgnat/s-win32.ads: Add definition for ULONG, modify diff --git a/gcc/ada/doc/gnat_rm/representation_clauses_and_pragmas.rst b/gcc/ada/doc/gnat_rm/representation_clauses_and_pragmas.rst index 5ad8e03..82dc97c 100644 --- a/gcc/ada/doc/gnat_rm/representation_clauses_and_pragmas.rst +++ b/gcc/ada/doc/gnat_rm/representation_clauses_and_pragmas.rst @@ -610,14 +610,23 @@ alignment of the type (this is true for all types). In some cases the end record; -On a typical 32-bit architecture, the X component will be four bytes, and -require four-byte alignment, and the Y component will be one byte. In this -case ``R'Value_Size`` will be 40 (bits) since this is the minimum size -required to store a value of this type, and for example, it is permissible -to have a component of type R in an outer array whose component size is -specified to be 48 bits. However, ``R'Object_Size`` will be 64 (bits), -since it must be rounded up so that this value is a multiple of the -alignment (4 bytes = 32 bits). +On a typical 32-bit architecture, the X component will occupy four bytes +and the Y component will occupy one byte, for a total of 5 bytes. As a +result ``R'Value_Size`` will be 40 (bits) since this is the minimum size +required to store a value of this type. For example, it is permissible +to have a component of type R in an array whose component size is +specified to be 40 bits. + +However, ``R'Object_Size`` will be 64 (bits). The difference is due to +the alignment requirement for objects of the record type. The X +component will require four-byte alignment because that is what type +Integer requires, whereas the Y component, a Character, will only +require 1-byte alignment. Since the alignment required for X is the +greatest of all the components' alignments, that is the alignment +required for the enclosing record type, i.e., 4 bytes or 32 bits. As +indicated above, the actual object size must be rounded up so that it is +a multiple of the alignment value. Therefore, 40 bits rounded up to the +next multiple of 32 yields 64 bits. For all other types, the ``Object_Size`` and ``Value_Size`` are the same (and equivalent to the RM attribute ``Size``). diff --git a/gcc/ada/gnat_rm.texi b/gcc/ada/gnat_rm.texi index 85bc144..39a8a1e 100644 --- a/gcc/ada/gnat_rm.texi +++ b/gcc/ada/gnat_rm.texi @@ -21,7 +21,7 @@ @copying @quotation -GNAT Reference Manual , Sep 24, 2018 +GNAT Reference Manual , May 27, 2019 AdaCore @@ -18982,14 +18982,23 @@ type R is record end record; @end example -On a typical 32-bit architecture, the X component will be four bytes, and -require four-byte alignment, and the Y component will be one byte. In this -case @code{R'Value_Size} will be 40 (bits) since this is the minimum size -required to store a value of this type, and for example, it is permissible -to have a component of type R in an outer array whose component size is -specified to be 48 bits. However, @code{R'Object_Size} will be 64 (bits), -since it must be rounded up so that this value is a multiple of the -alignment (4 bytes = 32 bits). +On a typical 32-bit architecture, the X component will occupy four bytes +and the Y component will occupy one byte, for a total of 5 bytes. As a +result @code{R'Value_Size} will be 40 (bits) since this is the minimum size +required to store a value of this type. For example, it is permissible +to have a component of type R in an array whose component size is +specified to be 40 bits. + +However, @code{R'Object_Size} will be 64 (bits). The difference is due to +the alignment requirement for objects of the record type. The X +component will require four-byte alignment because that is what type +Integer requires, whereas the Y component, a Character, will only +require 1-byte alignment. Since the alignment required for X is the +greatest of all the components' alignments, that is the alignment +required for the enclosing record type, i.e., 4 bytes or 32 bits. As +indicated above, the actual object size must be rounded up so that it is +a multiple of the alignment value. Therefore, 40 bits rounded up to the +next multiple of 32 yields 64 bits. For all other types, the @code{Object_Size} and @code{Value_Size} are the same (and equivalent to the RM attribute @code{Size}). |