[Bug ada/66167] New: Scalar Storage Order attribute has no effect on 2 dimensional arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66167 Bug ID: 66167 Summary: Scalar Storage Order attribute has no effect on 2 dimensional arrays Product: gcc Version: 6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: daniel.merrill at psware dot com Target Milestone: --- running on a little endian machine with a scalar storage order of High_Order_First does not byte swap the values when accessed through a 2 dimensional array i.e. type foo is array (foo_range, bar_range) of float. I can provide an example program if that will help reproduce the issue. Thanks.
[Bug ada/65476] New: Long_Float array does not byte swap correctly when set to Scalar_Storage_Order with High Order First
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65476 Bug ID: 65476 Summary: Long_Float array does not byte swap correctly when set to Scalar_Storage_Order with High Order First Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: daniel.merrill at psware dot com CC: ebotcazou at gcc dot gnu.org Created attachment 35067 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=35067action=edit code to reproduce the issue. When an array of Long_Floats is set to a scalar_storage_order of High_Order_First, only the two 32 bit words that make up the 64 bit value are swapped with each other but the bytes under those words are not swapped properly. Attached is a simple program that reproduces the behavior. If you examine the stored values you could get the right value by performing a byte swap on the underlying 32 bit value.
[Bug ada/64985] New: Default Scalar Storage Order Fails when an address is associated with a record
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64985 Bug ID: 64985 Summary: Default Scalar Storage Order Fails when an address is associated with a record Product: gcc Version: 5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: daniel.merrill at psware dot com CC: ebotcazou at gcc dot gnu.org Created attachment 34707 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34707action=edit Addresses failure when default scalar storage order is set. The ada compiler crashes when trying to link a record which contains an address and is set to a different scalar storage order than the default. Example code to reproduce the problem included.
[Bug ada/63725] Scalar_Storage_Order and nested string subtypes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63725 --- Comment #2 from Dan Merrill daniel.merrill at psware dot com --- Is this what you are proposing? type string_type is new string (1..15); for string_type'Scalar_Storage_Order use System.High_Order_First; type string_array is array (1..2) of string_type; for string_array'Scalar_Storage_Order use System.High_Order_First; type BigEndianInt32Array is array (1..10) of int32; type bigEndianType is record ThirtyTwoBits : int32; SixteenBits : int16; TestStrings : string_array; end record; for bigEndianType use record ThirtyTwoBits at 0 range 0 .. 31; SixteenBits at 0 range 32 .. 47; TestStrings at 0 range 48 .. 287; end record; for bigEndianType'Bit_Order use System.High_Order_First; for bigEndianType'Scalar_Storage_Order use System.High_Order_First; ? That seems to work, but in a non trivial case doesn't that make string_type non inter operable with other string types? In reality I don't care what the scalar storage order of the string is because they are just bytes and should work the same across both platforms. It seems like string_type shouldn't even need a scalar storage order applied to it.
[Bug ada/63725] New: Scalar_Storage_Order is required for nested string types, but cannot be added to those types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63725 Bug ID: 63725 Summary: Scalar_Storage_Order is required for nested string types, but cannot be added to those types Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: daniel.merrill at psware dot com Created attachment 33878 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33878action=edit demonstrates the problem with nested string types and scalar storage order Target: i686-pc-linux-gnu Configured with: ../configure --enable-languages=c,c++,ada --disable-multilib -- with-gcc --with-gnu-ld --with-gnu-as --target=i686-pc-linux-gnu --prefix=/c/gcc- ade -v --with-sysroot=/c/gcc-ade/i686-pc-linux-gnu --includedir=/c/gcc-ade/i686- pc-linux-gnu/usr/include Thread model: posix gcc version 4.10.0 20140706 (experimental) (GCC) This is a build of the svn://gcc.gnu.org/svn/gcc/branches/scalar-storage-order branch. when the following is defined and compiled with gnatmake main.adb: subtype string_type is string (1..15); type string_array is array (1..2) of string_type; for string_array'Scalar_Storage_Order use System.High_Order_First; type BigEndianInt32Array is array (1..10) of int32; type bigEndianType is record ThirtyTwoBits : int32; SixteenBits : int16; TestStrings : string_array; end record; for bigEndianType use record ThirtyTwoBits at 0 range 0 .. 31; SixteenBits at 0 range 32 .. 47; TestStrings at 0 range 48 .. 79; end record; for bigEndianType'Bit_Order use System.High_Order_First; for bigEndianType'Scalar_Storage_Order use System.High_Order_First; the following compiler error is produced: main.adb:17:04: nested composite must have explicit scalar storage order You are unable to fix this because the nested type is a subtype of string and you cannot define a scalar_storage_order attribute for a subtype.
