This makes the compiler issue an unconditional warning for an overlay
that changes the scalar storage order, i.e. for an address clause when
the overlaid and the underlying objects are of array or record types
that have opposite scalar storage order.  The reason is that the code
generator does not support toggling the scalar storage order through
the use of aliasing or type punning.

Tested on x86_64-pc-linux-gnu, committed on trunk

gcc/ada/

        * sem_ch13.adb (Analyze_Attribute_Definition_Clause) <Address>:
        Issue an unconditional warning for an overlay that changes the
        scalar storage order.
diff --git a/gcc/ada/sem_ch13.adb b/gcc/ada/sem_ch13.adb
--- a/gcc/ada/sem_ch13.adb
+++ b/gcc/ada/sem_ch13.adb
@@ -6075,10 +6075,10 @@ package body Sem_Ch13 is
                           (N, U_Ent, No_Uint, O_Ent, Off);
                      end if;
 
-                     --  If the overlay changes the storage order, mark the
-                     --  entity as being volatile to block any optimization
-                     --  for it since the construct is not really supported
-                     --  by the back end.
+                     --  If the overlay changes the storage order, warn since
+                     --  the construct is not really supported by the back end.
+                     --  Also mark the entity as being volatile to block the
+                     --  optimizer, even if there is no warranty on the result.
 
                      if (Is_Record_Type (Etype (U_Ent))
                           or else Is_Array_Type (Etype (U_Ent)))
@@ -6087,6 +6087,8 @@ package body Sem_Ch13 is
                        and then Reverse_Storage_Order (Etype (U_Ent)) /=
                                 Reverse_Storage_Order (Etype (O_Ent))
                      then
+                        Error_Msg_N
+                          ("??overlay changes scalar storage order", Expr);
                         Set_Treat_As_Volatile (U_Ent);
                      end if;
 


Reply via email to