This is the mail archive of the
mailing list for the GCC project.
[Ada] Expand type of static expressions in GNATprove mode
- From: Pierre-Marie de Rodat <derodat at adacore dot com>
- To: gcc-patches at gcc dot gnu dot org
- Cc: Yannick Moy <moy at adacore dot com>
- Date: Tue, 9 Jul 2019 03:52:00 -0400
- Subject: [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 <email@example.com>
* 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.
@@ -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)
@@ -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
-- 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,