public inbox for gcc-cvs@sourceware.org
help / color / mirror / Atom feed
* [gcc(refs/users/aoliva/heads/testme)] Set_Is_Known_Valid only if Safe_To_Capture_Value
@ 2022-05-06  7:18 Alexandre Oliva
  0 siblings, 0 replies; 2+ messages in thread
From: Alexandre Oliva @ 2022-05-06  7:18 UTC (permalink / raw)
  To: gcc-cvs

https://gcc.gnu.org/g:8f34a56593106fdd4e8458158afcb9f52954c51c

commit 8f34a56593106fdd4e8458158afcb9f52954c51c
Author: Alexandre Oliva <oliva@adacore.com>
Date:   Thu Feb 17 03:12:06 2022 -0300

    Set_Is_Known_Valid only if Safe_To_Capture_Value
    
    Library-level variables with initializers could have Is_Known_Valid
    set when analyzing their definition, and the flag would only be
    cleared when analyzing a statement that assigned to them. Procedures
    and functions analyzed before the flag got cleared could skip validity
    checking for the corresponding variable. This patch fixes this
    problem: we no longer set Is_Known_Valid when analyzing initializers
    of library-level variables,and use the same Safe_To_Capture_Value
    predicate that prevents assignments from recording known-valid states.
    
    This causes any variable with an initialization value, that would have
    had its initializer value used as its known constant value if the use
    is analyzed before any assignment to the variable, to no longer be
    regarded as holding a constant value. Some might turn out to have a
    constant value, after all, but we don't know that yet: we can only
    tell after analyzing every subprogram that could possibly assign to
    it. At the points where Safe_To_Capture_Value calls are introduced,
    Never_Set_In_Source does not yet hold its final value.
    
    
    [changelog]
    * exp_ch3.adb (Expand_N_Object_Declaration): Guard Set_Is_Known_Valid
    with Safe_To_Capture_Value.

Diff:
---
 gcc/ada/exp_ch3.adb | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/gcc/ada/exp_ch3.adb b/gcc/ada/exp_ch3.adb
index 50f46fb479e..7ce297f3f3b 100644
--- a/gcc/ada/exp_ch3.adb
+++ b/gcc/ada/exp_ch3.adb
@@ -7536,6 +7536,7 @@ package body Exp_Ch3 is
             elsif Comes_From_Source (N)
               and then Is_Discrete_Type (Typ)
               and then Expr_Known_Valid (Expr)
+              and then Safe_To_Capture_Value (N, Def_Id)
             then
                Set_Is_Known_Valid (Def_Id);
 
@@ -7566,7 +7567,9 @@ package body Exp_Ch3 is
               and then not Is_Generic_Type (Etype (Def_Id))
             then
                Ensure_Valid (Expr);
-               Set_Is_Known_Valid (Def_Id);
+               if Safe_To_Capture_Value (N, Def_Id) then
+                  Set_Is_Known_Valid (Def_Id);
+               end if;
             end if;
          end if;


^ permalink raw reply	[flat|nested] 2+ messages in thread

* [gcc(refs/users/aoliva/heads/testme)] Set_Is_Known_Valid only if Safe_To_Capture_Value
@ 2022-01-27  9:49 Alexandre Oliva
  0 siblings, 0 replies; 2+ messages in thread
From: Alexandre Oliva @ 2022-01-27  9:49 UTC (permalink / raw)
  To: gcc-cvs

https://gcc.gnu.org/g:d053f8453346a4f29b894610f496a39064200c8a

commit d053f8453346a4f29b894610f496a39064200c8a
Author: Alexandre Oliva <oliva@adacore.com>
Date:   Wed Dec 29 08:44:54 2021 -0300

    Set_Is_Known_Valid only if Safe_To_Capture_Value
    
    Library-level variables with initializers could have Is_Known_Valid
    set when analyzing their definition, and the flag would only be
    cleared when analyzing a statement that assigned to them. Procedures
    and functions analyzed before the flag got cleared could skip validity
    checking for the corresponding variable. This patch fixes this
    problem: we no longer set Is_Known_Valid when analyzing initializers
    of library-level variables,and use the same Safe_To_Capture_Value
    predicate that prevents assignments from recording known-valid states.
    
    This causes any variable with an initialization value, that would have
    had its initializer value used as its known constant value if the use
    is analyzed before any assignment to the variable, to no longer be
    regarded as holding a constant value. Some might turn out to have a
    constant value, after all, but we don't know that yet: we can only
    tell after analyzing every subprogram that could possibly assign to
    it. At the points where Safe_To_Capture_Value calls are introduced,
    Never_Set_In_Source does not yet hold its final value.
    
    
    [changelog]
    * exp_ch3.adb (Expand_N_Object_Declaration): Guard Set_Is_Known_Valid
    with Safe_To_Capture_Value.

Diff:
---
 gcc/ada/exp_ch3.adb | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/gcc/ada/exp_ch3.adb b/gcc/ada/exp_ch3.adb
index 50f46fb479e..7ce297f3f3b 100644
--- a/gcc/ada/exp_ch3.adb
+++ b/gcc/ada/exp_ch3.adb
@@ -7536,6 +7536,7 @@ package body Exp_Ch3 is
             elsif Comes_From_Source (N)
               and then Is_Discrete_Type (Typ)
               and then Expr_Known_Valid (Expr)
+              and then Safe_To_Capture_Value (N, Def_Id)
             then
                Set_Is_Known_Valid (Def_Id);
 
@@ -7566,7 +7567,9 @@ package body Exp_Ch3 is
               and then not Is_Generic_Type (Etype (Def_Id))
             then
                Ensure_Valid (Expr);
-               Set_Is_Known_Valid (Def_Id);
+               if Safe_To_Capture_Value (N, Def_Id) then
+                  Set_Is_Known_Valid (Def_Id);
+               end if;
             end if;
          end if;


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2022-05-06  7:18 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-05-06  7:18 [gcc(refs/users/aoliva/heads/testme)] Set_Is_Known_Valid only if Safe_To_Capture_Value Alexandre Oliva
  -- strict thread matches above, loose matches on Subject: below --
2022-01-27  9:49 Alexandre Oliva

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).