This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Ada] Expand type of static expressions in GNATprove mode

In the special mode for GNATprove, expand the type of static expressions
like done during compilation, to both get suitable legality checks and
increase the precision of the formal analysis.

There is no impact on compilation.

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

2019-07-09  Yannick Moy  <>


	* exp_util.adb (Expand_Subtype_From_Expr): Still expand the type
	of static expressions in GNATprove_Mode.
	* sem_ch3.adb (Analyze_Object_Declaration): Remove obsolete
	special case for GNATprove_Mode.
--- gcc/ada/exp_util.adb
+++ gcc/ada/exp_util.adb
@@ -5067,9 +5067,15 @@ package body Exp_Util is
       --  may be constants that depend on the bounds of a string literal, both
       --  standard string types and more generally arrays of characters.
-      --  In GNATprove mode, these extra subtypes are not needed
-      if GNATprove_Mode then
+      --  In GNATprove mode, these extra subtypes are not needed, unless Exp is
+      --  a static expression. In that case, the subtype will be constrained
+      --  while the original type might be unconstrained, so expanding the type
+      --  is necessary both for passing legality checks in GNAT and for precise
+      --  analysis in GNATprove.
+      if GNATprove_Mode
+        and then not Is_Static_Expression (Exp)
+      then
       end if;

--- gcc/ada/sem_ch3.adb
+++ gcc/ada/sem_ch3.adb
@@ -4592,14 +4592,6 @@ package body Sem_Ch3 is
             elsif Is_Interface (T) then
-            --  In GNATprove mode, Expand_Subtype_From_Expr does nothing. Thus,
-            --  we should prevent the generation of another Itype with the
-            --  same name as the one already generated, or we end up with
-            --  two identical types in GNATprove.
-            elsif GNATprove_Mode then
-               null;
             --  If the type is an unchecked union, no subtype can be built from
             --  the expression. Rewrite declaration as a renaming, which the
             --  back-end can handle properly. This is a rather unusual case,

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]