[Ada] Improve pretty-printing of iterated component associations

[Marc Poulhiès via Gcc-patches]

Pretty-printing used mostly in the debugger now handles more Ada 2022
syntax features. In particular, now it correctly handles expressions like
"[for E of A when E /= X => E]".

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

gcc/ada/

* sprint.adb (Sprint_Node_Actual): Handle iterator_specification within
iterated_component_association and iterator_filter within
iterator_specification.diff --git a/gcc/ada/sprint.adb b/gcc/ada/sprint.adb
--- a/gcc/ada/sprint.adb
+++ b/gcc/ada/sprint.adb
@@ -1341,9 +1341,13 @@ package body Sprint is
  when N_Iterated_Component_Association =>
 Set_Debug_Sloc;
 Write_Str (" for ");
-Write_Id (Defining_Identifier (Node));
-Write_Str (" in ");
-Sprint_Bar_List (Discrete_Choices (Node));
+if Present (Iterator_Specification (Node)) then
+   Sprint_Node (Iterator_Specification (Node));
+else
+   Write_Id (Defining_Identifier (Node));
+   Write_Str (" in ");
+   Sprint_Bar_List (Discrete_Choices (Node));
+end if;
 Write_Str (" => ");
 Sprint_Node (Expression (Node));
 
@@ -2307,6 +2311,11 @@ package body Sprint is
 
 Sprint_Node (Name (Node));
 
+if Present (Iterator_Filter (Node)) then
+   Write_Str (" when ");
+   Sprint_Node (Iterator_Filter (Node));
+end if;
+
  when N_Itype_Reference =>
 Write_Indent_Str_Sloc ("reference ");
 Write_Id (Itype (Node));

[Ada] Fix syntax in documentation

[Marc Poulhiès via Gcc-patches]

Leading to a poorly formatted example section.

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

gcc/ada/

* doc/gnat_ugn/gnat_and_program_execution.rst: Fix rest syntax
* gnat_ugn.texi: Regenerate.diff --git a/gcc/ada/doc/gnat_ugn/gnat_and_program_execution.rst b/gcc/ada/doc/gnat_ugn/gnat_and_program_execution.rst
--- a/gcc/ada/doc/gnat_ugn/gnat_and_program_execution.rst
+++ b/gcc/ada/doc/gnat_ugn/gnat_and_program_execution.rst
@@ -844,9 +844,7 @@ assorted runtime routines and the output will vary from platform to platform.
 
 It is also possible to use ``GDB`` with these traceback addresses to debug
 the program. For example, we can break at a given code location, as reported
-in the stack traceback:
-
-  ::
+in the stack traceback::
 
  $ gdb -nw stb
 
@@ -870,9 +868,8 @@ Executables on recent Windows versions, in other words without using the switch
 with :switch:`--load` instead of the ``addr2line`` tool. The main difference
 is that you need to copy the Load Address output in the traceback ahead of the
 sequence of addresses. And the default mode of ``gnatsymbolize`` is equivalent
-to that of ``addr2line`` with the above switches, so none of them is needed:
+to that of ``addr2line`` with the above switches, so none of them is needed::
 
-  ::
  $ gnatmake stb -g -bargs -E
  $ stb
 


diff --git a/gcc/ada/gnat_ugn.texi b/gcc/ada/gnat_ugn.texi
--- a/gcc/ada/gnat_ugn.texi
+++ b/gcc/ada/gnat_ugn.texi
@@ -19023,15 +19023,12 @@ It is also possible to use @code{GDB} with these traceback addresses to debug
 the program. For example, we can break at a given code location, as reported
 in the stack traceback:
 
-@quotation
-
 @example
 $ gdb -nw stb
 
 (gdb) break *0x401373
 Breakpoint 1 at 0x401373: file stb.adb, line 5.
 @end example
-@end quotation
 
 It is important to note that the stack traceback addresses do not change when
 debug information is included. This is particularly useful because it makes it
@@ -19052,13 +19049,7 @@ is that you need to copy the Load Address output in the traceback ahead of the
 sequence of addresses. And the default mode of @code{gnatsymbolize} is equivalent
 to that of @code{addr2line} with the above switches, so none of them is needed:
 
-@quotation
-
-
-@table @asis
-
-@item ::
-
+@example
 $ gnatmake stb -g -bargs -E
 $ stb
 
@@ -19068,13 +19059,8 @@ Load address: 0x40
 Call stack traceback locations:
 0x401373 0x40138b 0x40139c 0x401335 0x4011c4 0x4011f1 0x77e892a4
 
-
-@table @asis
-
-@item $ gnatsymbolize –load stb 0x40 0x401373 0x40138b 0x40139c 0x401335
-
-0x4011c4 0x4011f1 0x77e892a4
-@end table
+$ gnatsymbolize --load stb 0x40 0x401373 0x40138b 0x40139c 0x401335
+   0x4011c4 0x4011f1 0x77e892a4
 
 0x00401373 Stb.P1 at stb.adb:5
 0x0040138B Stb.P2 at stb.adb:10
@@ -19083,8 +19069,7 @@ Call stack traceback locations:
 0x004011c4 __tmainCRTStartup at ???
 0x004011f1 mainCRTStartup at ???
 0x77e892a4 ??? at ???
-@end table
-@end quotation
+@end example
 
 @subsubheading Tracebacks From Exception Occurrences
 

[Ada] Cleanup expansion of attribute Priority

[Marc Poulhiès via Gcc-patches]

Semantically neutral cleanup after the main fix for expansion of
attribute Priority.

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

gcc/ada/

* einfo-utils.adb (Number_Entries): Refine type of a local variable.
* exp_attr.adb (Expand_N_Attribute_Reference): Rename Conctyp to
Prottyp; refactor repeated calls to New_Occurrence_Of; replace
Number_Entries with Has_Entries.
* exp_ch5.adb (Expand_N_Assignment_Statement): Likewise; remove Subprg
variable (apparently copy-pasted from expansion of the attribute).diff --git a/gcc/ada/einfo-utils.adb b/gcc/ada/einfo-utils.adb
--- a/gcc/ada/einfo-utils.adb
+++ b/gcc/ada/einfo-utils.adb
@@ -2081,7 +2081,7 @@ package body Einfo.Utils is

 
function Number_Entries (Id : E) return Nat is
-  N   : Int;
+  N   : Nat;
   Ent : Entity_Id;
 
begin


diff --git a/gcc/ada/exp_attr.adb b/gcc/ada/exp_attr.adb
--- a/gcc/ada/exp_attr.adb
+++ b/gcc/ada/exp_attr.adb
@@ -5667,22 +5667,22 @@ package body Exp_Attr is
   --  which is illegal, because of the lack of aliasing.
 
   when Attribute_Priority => Priority : declare
- Call   : Node_Id;
- Conctyp: Entity_Id;
- New_Itype  : Entity_Id;
- Object_Parm: Node_Id;
- Subprg : Entity_Id;
- RT_Subprg_Name : Node_Id;
+ Call: Node_Id;
+ New_Itype   : Entity_Id;
+ Object_Parm : Node_Id;
+ Prottyp : Entity_Id;
+ RT_Subprg   : RE_Id;
+ Subprg  : Entity_Id;
 
   begin
  --  Look for the enclosing protected type
 
- Conctyp := Current_Scope;
- while not Is_Protected_Type (Conctyp) loop
-Conctyp := Scope (Conctyp);
+ Prottyp := Current_Scope;
+ while not Is_Protected_Type (Prottyp) loop
+Prottyp := Scope (Prottyp);
  end loop;
 
- pragma Assert (Is_Protected_Type (Conctyp));
+ pragma Assert (Is_Protected_Type (Prottyp));
 
  --  Generate the actual of the call
 
@@ -5710,7 +5710,7 @@ package body Exp_Attr is
 New_Itype := Create_Itype (E_Access_Type, N);
 Set_Etype (New_Itype, New_Itype);
 Set_Directly_Designated_Type (New_Itype,
-  Corresponding_Record_Type (Conctyp));
+  Corresponding_Record_Type (Prottyp));
 Freeze_Itype (New_Itype, N);
 
 --  Generate:
@@ -5745,15 +5745,16 @@ package body Exp_Attr is
 
  --  Select the appropriate run-time subprogram
 
- if Number_Entries (Conctyp) = 0 then
-RT_Subprg_Name := New_Occurrence_Of (RTE (RE_Get_Ceiling), Loc);
+ if Has_Entries (Prottyp) then
+RT_Subprg := RO_PE_Get_Ceiling;
  else
-RT_Subprg_Name := New_Occurrence_Of (RTE (RO_PE_Get_Ceiling), Loc);
+RT_Subprg := RE_Get_Ceiling;
  end if;
 
  Call :=
Make_Function_Call (Loc,
- Name   => RT_Subprg_Name,
+ Name   =>
+   New_Occurrence_Of (RTE (RT_Subprg), Loc),
  Parameter_Associations => New_List (Object_Parm));
 
  Rewrite (N, Call);


diff --git a/gcc/ada/exp_ch5.adb b/gcc/ada/exp_ch5.adb
--- a/gcc/ada/exp_ch5.adb
+++ b/gcc/ada/exp_ch5.adb
@@ -2392,11 +2392,10 @@ package body Exp_Ch5 is
 
   if Ada_Version >= Ada_2005 then
  declare
-Call   : Node_Id;
-Conctyp: Entity_Id;
-Ent: Entity_Id;
-Subprg : Entity_Id;
-RT_Subprg_Name : Node_Id;
+Call  : Node_Id;
+Ent   : Entity_Id;
+Prottyp   : Entity_Id;
+RT_Subprg : RE_Id;
 
  begin
 --  Handle chains of renamings
@@ -2418,36 +2417,25 @@ package body Exp_Ch5 is
 
--  Look for the enclosing protected type
 
-   Conctyp := Current_Scope;
-   while not Is_Protected_Type (Conctyp) loop
-  Conctyp := Scope (Conctyp);
+   Prottyp := Current_Scope;
+   while not Is_Protected_Type (Prottyp) loop
+  Prottyp := Scope (Prottyp);
end loop;
 
-   pragma Assert (Is_Protected_Type (Conctyp));
-
-   --  Generate the first actual of the call
-
-   Subprg := Current_Scope;
-   while
- not (Is_Subprogram_Or_Entry (Subprg)
-  and then Present (Protected_Body_Subprogram (Subprg)))
-   loop
-  Subprg := Scope (Subprg);
-   end loop;
+   pragma Assert (Is_Protected_Type (Prottyp));
 
--  Select the appropriate run-time call
 
-   if Number_Entries (Conctyp) = 0 then
-  RT_Subprg_Name :=
-New_Occurrence_Of (RTE (RE_Set_Ceiling

[Ada] Fix crash for Default_Initial_Condition on derived enumeration type

[Marc Poulhiès via Gcc-patches]

This fixes a crash on the declaration of a private derived enumeration type
with the Default_Initial_Condition aspect and in the process makes a couple
of related adjustments: 1) removes the early freezing of implicit character
and numeric base types and 2) fixes an oversight in the implementation of
delayed representation aspects.

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

gcc/ada/

* aspects.ads (Delaying Evaluation of Aspect): Fix typos.
* exp_ch3.adb (Freeze_Type): Do not generate Invariant and DIC
procedures for internal types.
* exp_util.adb (Build_DIC_Procedure_Body): Adjust comment.
* freeze.adb (Freeze_Entity): Call Inherit_Delayed_Rep_Aspects for
subtypes and derived types only after the base or parent type has
been frozen.  Remove useless freezing for first subtype.
(Freeze_Fixed_Point_Type): Call Inherit_Delayed_Rep_Aspects too.
* layout.adb (Set_Elem_Alignment): Deal with private types.
* sem_ch3.adb (Build_Derived_Enumeration_Type): Build the implicit
base as an itype and do not insert its declaration in the tree.
(Build_Derived_Numeric_Type): Do not freeze the implicit base.
(Derived_Standard_Character): Likewise.
(Constrain_Enumeration): Inherit the chain of representation items
instead of replacing it.
* sem_ch13.ads (Inherit_Aspects_At_Freeze_Point): Add ??? comment.
(Inherit_Delayed_Rep_Aspects): Declare.
* sem_ch13.adb (Analyze_Aspects_At_Freeze_Point): Do not invoke
Inherit_Delayed_Rep_Aspects.
(Inherit_Aspects_At_Freeze_Point): Deal with private types.
(Inherit_Delayed_Rep_Aspects): Move to library level.

patch.diff.gz
Description: application/gzip

[Ada] Remove excessive guards against inserting empty lists of actions

[Marc Poulhiès via Gcc-patches]

Call to Insert_Actions with empty list does nothing, so there is no need to
guard against such calls. Code cleanup; behavior is unaffected.

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

gcc/ada/

* freeze.adb (Freeze_Itype): Remove excessive guard.
* sem_ch5.adb (Analyze_Loop_Parameter_Specification): Likewise.diff --git a/gcc/ada/freeze.adb b/gcc/ada/freeze.adb
--- a/gcc/ada/freeze.adb
+++ b/gcc/ada/freeze.adb
@@ -9653,9 +9653,7 @@ package body Freeze is
   Set_Has_Delayed_Freeze (T);
   L := Freeze_Entity (T, N);
 
-  if Is_Non_Empty_List (L) then
- Insert_Actions (N, L);
-  end if;
+  Insert_Actions (N, L);
end Freeze_Itype;
 
--


diff --git a/gcc/ada/sem_ch5.adb b/gcc/ada/sem_ch5.adb
--- a/gcc/ada/sem_ch5.adb
+++ b/gcc/ada/sem_ch5.adb
@@ -3365,9 +3365,7 @@ package body Sem_Ch5 is
  declare
 Flist : constant List_Id := Freeze_Entity (Id, N);
  begin
-if Is_Non_Empty_List (Flist) then
-   Insert_Actions (N, Flist);
-end if;
+Insert_Actions (N, Flist);
  end;
   end if;
 

[Ada] Cleanup analysis of iterator specifications

[Marc Poulhiès via Gcc-patches]

Code cleanup; semantics is unaffected.

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

gcc/ada/

* sem_ch5.adb (Check_Subtype_Definition): Remove redundant call to
Present; style cleanup.diff --git a/gcc/ada/sem_ch5.adb b/gcc/ada/sem_ch5.adb
--- a/gcc/ada/sem_ch5.adb
+++ b/gcc/ada/sem_ch5.adb
@@ -2211,7 +2211,7 @@ package body Sem_Ch5 is
 
   procedure Check_Subtype_Definition (Comp_Type : Entity_Id) is
   begin
- if not Present (Subt) then
+ if No (Subt) then
 return;
  end if;
 
@@ -2231,9 +2231,8 @@ package body Sem_Ch5 is
   Subt, Comp_Type);
 end if;
 
- elsif Present (Subt)
-   and then (not Covers (Base_Type (Bas), Comp_Type)
-  or else not Subtypes_Statically_Match (Bas, Comp_Type))
+ elsif not Covers (Base_Type (Bas), Comp_Type)
+   or else not Subtypes_Statically_Match (Bas, Comp_Type)
  then
 if Is_Array_Type (Typ) then
Error_Msg_NE
@@ -2330,7 +2329,7 @@ package body Sem_Ch5 is
   Decl :=
 Make_Full_Type_Declaration (Loc,
   Defining_Identifier => S,
-  Type_Definition  =>
+  Type_Definition =>
 New_Copy_Tree
   (Access_To_Subprogram_Definition (Subt)));
end if;

[Ada] Cleanup analysis of quantified expressions with empty ranges

[Marc Poulhiès via Gcc-patches]

Cleanup handling of quantified expressions before using it as an inspiration
for fixing the handling of iterated component associations. Behavior is
unaffected.

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

gcc/ada/

* sem_ch4.adb
(Is_Empty_Range): Move error reporting to the caller.
(Analyze_Qualified_Expression): Move error reporting from 
Is_Empty_Range;
add matching call to End_Scope before rewriting and returning.diff --git a/gcc/ada/sem_ch4.adb b/gcc/ada/sem_ch4.adb
--- a/gcc/ada/sem_ch4.adb
+++ b/gcc/ada/sem_ch4.adb
@@ -4394,9 +4394,8 @@ package body Sem_Ch4 is
 
procedure Analyze_Quantified_Expression (N : Node_Id) is
   function Is_Empty_Range (Typ : Entity_Id) return Boolean;
-  --  If the iterator is part of a quantified expression, and the range is
-  --  known to be statically empty, emit a warning and replace expression
-  --  with its static value. Returns True if the replacement occurs.
+  --  Return True if the iterator is part of a quantified expression and
+  --  the range is known to be statically empty.
 
   function No_Else_Or_Trivial_True (If_Expr : Node_Id) return Boolean;
   --  Determine whether if expression If_Expr lacks an else part or if it
@@ -4407,36 +4406,12 @@ package body Sem_Ch4 is
   
 
   function Is_Empty_Range (Typ : Entity_Id) return Boolean is
- Loc : constant Source_Ptr := Sloc (N);
-
   begin
- if Is_Array_Type (Typ)
+ return Is_Array_Type (Typ)
and then Compile_Time_Known_Bounds (Typ)
and then
- (Expr_Value (Type_Low_Bound  (Etype (First_Index (Typ >
-  Expr_Value (Type_High_Bound (Etype (First_Index (Typ)
- then
-Preanalyze_And_Resolve (Condition (N), Standard_Boolean);
-
-if All_Present (N) then
-   Error_Msg_N
- ("??quantified expression with ALL "
-  & "over a null range has value True", N);
-   Rewrite (N, New_Occurrence_Of (Standard_True, Loc));
-
-else
-   Error_Msg_N
- ("??quantified expression with SOME "
-  & "over a null range has value False", N);
-   Rewrite (N, New_Occurrence_Of (Standard_False, Loc));
-end if;
-
-Analyze (N);
-return True;
-
- else
-return False;
- end if;
+ Expr_Value (Type_Low_Bound  (Etype (First_Index (Typ >
+ Expr_Value (Type_High_Bound (Etype (First_Index (Typ;
   end Is_Empty_Range;
 
   -
@@ -4456,6 +4431,7 @@ package body Sem_Ch4 is
   --  Local variables
 
   Cond: constant Node_Id := Condition (N);
+  Loc : constant Source_Ptr := Sloc (N);
   Loop_Id : Entity_Id;
   QE_Scop : Entity_Id;
 
@@ -4466,7 +4442,7 @@ package body Sem_Ch4 is
   --  expression. The scope is needed to provide proper visibility of the
   --  loop variable.
 
-  QE_Scop := New_Internal_Entity (E_Loop, Current_Scope, Sloc (N), 'L');
+  QE_Scop := New_Internal_Entity (E_Loop, Current_Scope, Loc, 'L');
   Set_Etype  (QE_Scop, Standard_Void_Type);
   Set_Scope  (QE_Scop, Current_Scope);
   Set_Parent (QE_Scop, N);
@@ -4482,11 +4458,30 @@ package body Sem_Ch4 is
  Preanalyze (Iterator_Specification (N));
 
  --  Do not proceed with the analysis when the range of iteration is
- --  empty. The appropriate error is issued by Is_Empty_Range.
+ --  empty.
 
  if Is_Entity_Name (Name (Iterator_Specification (N)))
and then Is_Empty_Range (Etype (Name (Iterator_Specification (N
  then
+Preanalyze_And_Resolve (Condition (N), Standard_Boolean);
+End_Scope;
+
+--  Emit a warning and replace expression with its static value
+
+if All_Present (N) then
+   Error_Msg_N
+ ("??quantified expression with ALL "
+  & "over a null range has value True", N);
+   Rewrite (N, New_Occurrence_Of (Standard_True, Loc));
+
+else
+   Error_Msg_N
+ ("??quantified expression with SOME "
+  & "over a null range has value False", N);
+   Rewrite (N, New_Occurrence_Of (Standard_False, Loc));
+end if;
+
+Analyze (N);
 return;
  end if;
 

[Ada] Fix resolution of iterated component association

[Marc Poulhiès via Gcc-patches]

For iterator specification appearing inside an iterated component
association, we just did ad-hoc, incomplete checks and delayed a proper
analysis until the iterated component association is expanded into loop (and
then reanalyzed).

However, when the iterated component association is not expanded, e.g.
because we are in semantic checking mode, GNATprove mode or inside a
generic, then the AST lacked any processing or error reporting.

This is fixed by reusing the existing analysis of iterator specifications,
as they also appear in other constructs, e.g. in quantified expressions.

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

gcc/ada/

* sem_aggr.adb (Resolve_Iterated_Component_Association): Split
processing of cases with and without iterator specification; reuse
analysis of iterator specification; improve diagnostics for
premature usage of iterator index in discrete choices.diff --git a/gcc/ada/sem_aggr.adb b/gcc/ada/sem_aggr.adb
--- a/gcc/ada/sem_aggr.adb
+++ b/gcc/ada/sem_aggr.adb
@@ -1742,8 +1742,6 @@ package body Sem_Aggr is
  Loc : constant Source_Ptr := Sloc (N);
  Id  : constant Entity_Id  := Defining_Identifier (N);
 
- Id_Typ : Entity_Id := Any_Type;
-
  ---
  -- Remove_References --
  ---
@@ -1779,37 +1777,29 @@ package body Sem_Aggr is
   begin
  Error_Msg_Ada_2022_Feature ("iterated component", Loc);
 
- if Present (Iterator_Specification (N)) then
-Analyze (Name (Iterator_Specification (N)));
+ --  Create a scope in which to introduce an index, to make it visible
+ --  for the analysis of component expression.
 
---  We assume that the domain of iteration cannot be overloaded.
+ Scop := New_Internal_Entity (E_Loop, Current_Scope, Loc, 'L');
+ Set_Etype  (Scop, Standard_Void_Type);
+ Set_Parent (Scop, Parent (N));
+ Push_Scope (Scop);
 
-declare
-   Domain : constant Node_Id := Name (Iterator_Specification (N));
-   D_Type : constant Entity_Id := Etype (Domain);
-   Elt: Entity_Id;
-begin
-   if Is_Array_Type (D_Type) then
-  Id_Typ := Component_Type (D_Type);
+ --  If there is iterator specification, then its preanalysis will make
+ --  the index visible.
 
-   else
-  if Has_Aspect (D_Type, Aspect_Iterable) then
- Elt :=
-   Get_Iterable_Type_Primitive (D_Type, Name_Element);
- if No (Elt) then
-Error_Msg_N
-  ("missing Element primitive for iteration", Domain);
- else
-Id_Typ := Etype (Elt);
- end if;
-  else
- Error_Msg_N ("cannot iterate over", Domain);
-  end if;
-   end if;
-end;
+ if Present (Iterator_Specification (N)) then
+Preanalyze (Iterator_Specification (N));
+
+ --  Otherwise, analyze discrete choices and make the index visible
 
  else
-Id_Typ := Index_Typ;
+--  Insert index name into current scope but don't decorate it yet,
+--  so that a premature usage of this name in discrete choices will
+--  be nicely diagnosed.
+
+Enter_Name (Id);
+
 Choice := First (Discrete_Choices (N));
 
 while Present (Choice) loop
@@ -1835,25 +1825,13 @@ package body Sem_Aggr is
 
Next (Choice);
 end loop;
- end if;
-
- --  Create a scope in which to introduce an index, which is usually
- --  visible in the expression for the component, and needed for its
- --  analysis.
 
- Scop := New_Internal_Entity (E_Loop, Current_Scope, Loc, 'L');
- Set_Etype  (Scop, Standard_Void_Type);
- Set_Parent (Scop, Parent (N));
- Push_Scope (Scop);
+--  Decorate the index variable
 
- --  Insert and decorate the index variable in the current scope.
- --  The expression has to be analyzed once the index variable is
- --  directly visible.
-
- Enter_Name (Id);
- Set_Etype (Id, Id_Typ);
- Mutate_Ekind (Id, E_Variable);
- Set_Scope (Id, Scop);
+Set_Etype (Id, Index_Typ);
+Mutate_Ekind (Id, E_Variable);
+Set_Scope (Id, Scop);
+ end if;
 
  --  Analyze  expression without expansion, to verify legality.
  --  When generating code, we then remove references to the index

[Ada] New gnatbind switch -k

[Marc Poulhiès via Gcc-patches]

This switch can be used to disable the effect of -F when using -n
explicitly or implicitly.

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

gcc/ada/

* bindgen.adb (Gen_Elab_Calls): Check for Check_Elaboration_Flags.
* bindusg.adb (Display): Add -k.
* opt.ads (Check_Elaboration_Flags): New.
* switch-b.adb (Scan_Binder_Switches): Add processing of -k.
* doc/gnat_ugn/building_executable_programs_with_gnat.rst: Add
documentation for -k and -K.
* gnat_ugn.texi: Regenerate.diff --git a/gcc/ada/bindgen.adb b/gcc/ada/bindgen.adb
--- a/gcc/ada/bindgen.adb
+++ b/gcc/ada/bindgen.adb
@@ -1544,6 +1544,7 @@ package body Bindgen is
 
Check_Elab_Flag :=
  Units.Table (Unum_Spec).Set_Elab_Entity
+   and then Check_Elaboration_Flags
and then not CodePeer_Mode
and then (Force_Checking_Of_Elaboration_Flags
   or Interface_Library_Unit


diff --git a/gcc/ada/bindusg.adb b/gcc/ada/bindusg.adb
--- a/gcc/ada/bindusg.adb
+++ b/gcc/ada/bindusg.adb
@@ -156,6 +156,11 @@ package body Bindusg is
 ("  -I-   Don't look for sources & library files in default "
  & "directory");
 
+  --  Line for -k switch
+
+  Write_Line
+("  -kDisable checking of elaboration flags");
+
   --  Line for -K switch
 
   Write_Line


diff --git a/gcc/ada/doc/gnat_ugn/building_executable_programs_with_gnat.rst b/gcc/ada/doc/gnat_ugn/building_executable_programs_with_gnat.rst
--- a/gcc/ada/doc/gnat_ugn/building_executable_programs_with_gnat.rst
+++ b/gcc/ada/doc/gnat_ugn/building_executable_programs_with_gnat.rst
@@ -6534,6 +6534,22 @@ be presented in subsequent sections.
   ALI file named in the ``gnatbind`` command line.
 
 
+  .. index:: -k  (gnatbind)
+
+:switch:`-k`
+  Disable checking of elaboration flags. When using :switch:`-n`
+  either explicitly or implicitly, :switch:`-F` is also implied,
+  unless :switch:`-k` is used. This switch should be used with care
+  and you should ensure manually that elaboration routines are not called
+  twice unintentionally.
+
+
+  .. index:: -K  (gnatbind)
+
+:switch:`-K`
+  Give list of linker options specified for link.
+
+
   .. index:: -l  (gnatbind)
 
 :switch:`-l`


diff --git a/gcc/ada/gnat_ugn.texi b/gcc/ada/gnat_ugn.texi
--- a/gcc/ada/gnat_ugn.texi
+++ b/gcc/ada/gnat_ugn.texi
@@ -15724,6 +15724,22 @@ Do not look for sources in the current directory where @code{gnatbind} was
 invoked, and do not look for ALI files in the directory containing the
 ALI file named in the @code{gnatbind} command line.
 
+@geindex -k (gnatbind)
+
+@item @code{-k}
+
+Disable checking of elaboration flags. When using @code{-n}
+either explicitly or implicitly, @code{-F} is also implied,
+unless @code{-k} is used. This switch should be used with care
+and you should ensure manually that elaboration routines are not called
+twice unintentionally.
+
+@geindex -K (gnatbind)
+
+@item @code{-K}
+
+Give list of linker options specified for link.
+
 @geindex -l (gnatbind)
 
 @item @code{-l}
@@ -29292,8 +29308,8 @@ to permit their use in free software.
 
 @printindex ge
 
-@anchor{cf}@w{  }
 @anchor{gnat_ugn/gnat_utility_programs switches-related-to-project-files}@w{  }
+@anchor{cf}@w{  }
 
 @c %**end of body
 @bye


diff --git a/gcc/ada/opt.ads b/gcc/ada/opt.ads
--- a/gcc/ada/opt.ads
+++ b/gcc/ada/opt.ads
@@ -267,6 +267,10 @@ package Opt is
--  Set to True to detect whether subprogram parameters and function results
--  alias the same object(s).
 
+   Check_Elaboration_Flags : Boolean := True;
+   --  GNATBIND
+   --  Set to False if switch -k is set.
+
Check_Float_Overflow : Boolean := False;
--  GNAT
--  Set to True to check that operations on predefined unconstrained float


diff --git a/gcc/ada/switch-b.adb b/gcc/ada/switch-b.adb
--- a/gcc/ada/switch-b.adb
+++ b/gcc/ada/switch-b.adb
@@ -379,6 +379,12 @@ package body Switch.B is
Bad_Switch (Switch_Chars);
 end if;
 
+ --  Processing for k switch
+
+ when 'k' =>
+Ptr := Ptr + 1;
+Check_Elaboration_Flags := False;
+
  --  Processing for K switch
 
  when 'K' =>

[Ada] Detect expansion of iterated component associations into loops

[Marc Poulhiès via Gcc-patches]

Iterated component associations are expanded into loops, which GNAT
should detect as violating restriction No_Implicit_Loops; same for
iterated element associations and delta array aggregates.

Part of cleanups for correct handling of iterated component associations
in SPARK.

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

gcc/ada/

* exp_aggr.adb
(Two_Pass_Aggregate_Expansion): Expand into implicit rather than
ordinary loops, to detect violations of restriction
No_Implicit_Loops.
(Generate_Loop): Likewise for delta array aggregates.diff --git a/gcc/ada/exp_aggr.adb b/gcc/ada/exp_aggr.adb
--- a/gcc/ada/exp_aggr.adb
+++ b/gcc/ada/exp_aggr.adb
@@ -6430,7 +6430,7 @@ package body Exp_Aggr is
  Left_Opnd  => New_Occurrence_Of (Size_Id, Loc),
  Right_Opnd => Make_Integer_Literal (Loc, 1)));
 
-One_Loop := Make_Loop_Statement (Loc,
+One_Loop := Make_Implicit_Loop_Statement (N,
   Iteration_Scheme =>
 Make_Iteration_Scheme (Loc,
   Iterator_Specification => New_Copy_Tree (Iter)),
@@ -6562,7 +6562,7 @@ package body Exp_Aggr is
   Attribute_Name => Name_Last)),
Then_Statements => New_List (Incr));
 
-One_Loop := Make_Loop_Statement (Loc,
+One_Loop := Make_Implicit_Loop_Statement (N,
   Iteration_Scheme =>
 Make_Iteration_Scheme (Loc,
   Iterator_Specification => Copy_Separate_Tree (Iter)),
@@ -8000,7 +8000,7 @@ package body Exp_Aggr is
  end if;
 
  return
-   Make_Loop_Statement (Loc,
+   Make_Implicit_Loop_Statement (C,
  Iteration_Scheme =>
Make_Iteration_Scheme (Sl,
  Loop_Parameter_Specification =>

[Ada] Suppress warnings in trivial subprograms with finalization

[Marc Poulhiès via Gcc-patches]

There are heuristics for suppressing warnings about unused objects in
trivial cases. In particular, we try to suppress warnings here:

   function F (A : Integer) return Some_Type;
  X : Some_Type;
   begin
  raise Not_Yet_Implemented;
  return X;
   end F;

But it doesn't work if Some_Type is controlled. This patch fixes that
bug.

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

gcc/ada/

* sem_ch6.adb
(Analyze_Subprogram_Body_Helper): Use First_Real_Statement to deal
with this case. Note that First_Real_Statement is likely to be
removed as part of this ticket, so this is a temporary fix.diff --git a/gcc/ada/sem_ch6.adb b/gcc/ada/sem_ch6.adb
--- a/gcc/ada/sem_ch6.adb
+++ b/gcc/ada/sem_ch6.adb
@@ -5409,14 +5409,20 @@ package body Sem_Ch6 is
   --  we have a special test to set X as apparently assigned to suppress
   --  the warning.
 
-  declare
- Stm : Node_Id;
+  --  If X above is controlled, we need to use First_Real_Statement to skip
+  --  generated finalization-related code. Otherwise (First_Real_Statement
+  --  is Empty), we just get the first statement.
 
+  declare
+ Stm : Node_Id := First_Real_Statement (HSS);
   begin
+ if No (Stm) then
+Stm := First (Statements (HSS));
+ end if;
+
  --  Skip call markers installed by the ABE mechanism, labels, and
  --  Push_xxx_Error_Label to find the first real statement.
 
- Stm := First (Statements (HSS));
  while Nkind (Stm) in N_Call_Marker | N_Label | N_Push_xxx_Label loop
 Next (Stm);
  end loop;

[Ada] Enable Error_Msg_GNAT_Extension for mixed decl/stmts

[Marc Poulhiès via Gcc-patches]

Enable mixing of declarative items and statements under
the -gnatX switch. The previous version used the -gnat2022
switch.

In addition, change the error message so that it advertises
the new feature when it is disabled. Instead of:

declarations must come before "begin"

we now say (without -gnatX):

declarations mixed with statements is a GNAT-specific extension
unit must be compiled with -gnatX or use pragma Extensions_Allowed (On)

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

gcc/ada/

* par-ch5.adb
(P_Sequence_Of_Statements): Call Error_Msg_GNAT_Extension to give
the error message.diff --git a/gcc/ada/par-ch5.adb b/gcc/ada/par-ch5.adb
--- a/gcc/ada/par-ch5.adb
+++ b/gcc/ada/par-ch5.adb
@@ -242,8 +242,8 @@ package body Ch5 is
 
   --  In Ada 2022, we allow declarative items to be mixed with
   --  statements. The loop below alternates between calling
-  --  P_Declarative_Items to parse zero or more declarative items, and
-  --  parsing a statement.
+  --  P_Declarative_Items to parse zero or more declarative items,
+  --  and parsing a statement.
 
   loop
  Ignore (Tok_Semicolon);
@@ -255,26 +255,17 @@ package body Ch5 is
   (Statement_List, Declare_Expression => False,
In_Spec => False, In_Statements => True);
 
---  Use the length of the list to determine whether we parsed any
---  declarative items. If so, it's an error pre-2022. ???We should
---  be calling Error_Msg_Ada_2022_Feature below, to advertise the
---  new feature, but that causes a lot of test diffs, so for now,
---  we mimic the old "...before begin" message.
+--  Use the length of the list to determine whether we parsed
+--  any declarative items. If so, it's an error unless language
+--  extensions are enabled.
 
 if List_Length (Statement_List) > Num_Statements then
if All_Errors_Mode or else No (Decl_Loc) then
   Decl_Loc := Sloc (Pick (Statement_List, Num_Statements + 1));
 
-  if False then
- Error_Msg_Ada_2022_Feature
-   ("declarations mixed with statements",
-Sloc (Pick (Statement_List, Num_Statements + 1)));
-  else
- if Ada_Version < Ada_2022 then
-Error_Msg
-  ("declarations must come before BEGIN", Decl_Loc);
- end if;
-  end if;
+  Error_Msg_GNAT_Extension
+("declarations mixed with statements",
+ Sloc (Pick (Statement_List, Num_Statements + 1)));
end if;
 end if;
  end;

[Ada] Cleanup resolution of iterated component association

[Marc Poulhiès via Gcc-patches]

Tune names of local entities.

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

gcc/ada/

* sem_aggr.adb (Resolve_Iterated_Component_Association): Change
generic name Ent to a more intuitive Scop; rename Remove_Ref to
Remove_Reference, so it can be instantiated as a traversal routine
with plural name.diff --git a/gcc/ada/sem_aggr.adb b/gcc/ada/sem_aggr.adb
--- a/gcc/ada/sem_aggr.adb
+++ b/gcc/ada/sem_aggr.adb
@@ -1748,11 +1748,11 @@ package body Sem_Aggr is
  -- Remove_References --
  ---
 
- function Remove_Ref (N : Node_Id) return Traverse_Result;
- --  Remove references to the entity Id after analysis, so it can be
+ function Remove_Reference (N : Node_Id) return Traverse_Result;
+ --  Remove reference to the entity Id after analysis, so it can be
  --  properly reanalyzed after construct is expanded into a loop.
 
- function Remove_Ref (N : Node_Id) return Traverse_Result is
+ function Remove_Reference (N : Node_Id) return Traverse_Result is
  begin
 if Nkind (N) = N_Identifier
and then Present (Entity (N))
@@ -1763,15 +1763,15 @@ package body Sem_Aggr is
 end if;
 Set_Analyzed (N, False);
 return OK;
- end Remove_Ref;
+ end Remove_Reference;
 
- procedure Remove_References is new Traverse_Proc (Remove_Ref);
+ procedure Remove_References is new Traverse_Proc (Remove_Reference);
 
  --  Local variables
 
  Choice : Node_Id;
  Dummy  : Boolean;
- Ent: Entity_Id;
+ Scop   : Entity_Id;
  Expr   : Node_Id;
 
   --  Start of processing for Resolve_Iterated_Component_Association
@@ -1841,10 +1841,10 @@ package body Sem_Aggr is
  --  visible in the expression for the component, and needed for its
  --  analysis.
 
- Ent := New_Internal_Entity (E_Loop, Current_Scope, Loc, 'L');
- Set_Etype  (Ent, Standard_Void_Type);
- Set_Parent (Ent, Parent (N));
- Push_Scope (Ent);
+ Scop := New_Internal_Entity (E_Loop, Current_Scope, Loc, 'L');
+ Set_Etype  (Scop, Standard_Void_Type);
+ Set_Parent (Scop, Parent (N));
+ Push_Scope (Scop);
 
  --  Insert and decorate the index variable in the current scope.
  --  The expression has to be analyzed once the index variable is
@@ -1853,7 +1853,7 @@ package body Sem_Aggr is
  Enter_Name (Id);
  Set_Etype (Id, Id_Typ);
  Mutate_Ekind (Id, E_Variable);
- Set_Scope (Id, Ent);
+ Set_Scope (Id, Scop);
 
  --  Analyze  expression without expansion, to verify legality.
  --  When generating code, we then remove references to the index

[Ada] Fix detection of unused warning suppression

[Marc Poulhiès via Gcc-patches]

The comment for Warnings_Off says: "clients should generally not test
this flag directly, but instead use function Has_Warnings_Off".

Primarily a code cleanup, as this only affects minor a corner case.

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

gcc/ada/

* sem_ch13.adb (Validate_Unchecked_Conversions): Use
Has_Warnings_Off.
* sem_elab.adb (Check_Internal_Call_Continue): Likewise.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
@@ -17726,7 +17726,9 @@ package body Sem_Ch13 is
  begin
 --  Skip if function marked as warnings off
 
-if Warnings_Off (Act_Unit) or else Serious_Errors_Detected > 0 then
+if Has_Warnings_Off (Act_Unit)
+  or else Serious_Errors_Detected > 0
+then
goto Continue;
 end if;
 


diff --git a/gcc/ada/sem_elab.adb b/gcc/ada/sem_elab.adb
--- a/gcc/ada/sem_elab.adb
+++ b/gcc/ada/sem_elab.adb
@@ -18767,9 +18767,9 @@ package body Sem_Elab is
  T : constant Entity_Id := Etype (First_Formal (E));
   begin
  if Is_Controlled (T) then
-if Warnings_Off (T)
+if Has_Warnings_Off (T)
   or else (Ekind (T) = E_Private_Type
-and then Warnings_Off (Full_View (T)))
+and then Has_Warnings_Off (Full_View (T)))
 then
goto Output;
 end if;

[Ada] Secondary stack and i-c*

[Marc Poulhiès via Gcc-patches]

Extend the previous changes related to Ada.Tags trigerring a
dependency on the secondary stack to various i-c* packages.

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

gcc/ada/

* ali.adb (Scan_ALI): Special case i-c*.ali when setting
Sec_Stack_Used.diff --git a/gcc/ada/ali.adb b/gcc/ada/ali.adb
--- a/gcc/ada/ali.adb
+++ b/gcc/ada/ali.adb
@@ -2079,15 +2079,24 @@ package body ALI is
--  Processing for SS
 
elsif C = 'S' then
-  --  Special case: a-tags.ali by itself should not set
+  --  Special case: a-tags/i-c* by themselves should not set
   --  Sec_Stack_Used, only if other code uses the secondary
   --  stack should we set this flag. This ensures that we do
   --  not bring the secondary stack unnecessarily when using
-  --  Ada.Tags and not actually using the secondary stack.
+  --  one of these packages and not actually using the
+  --  secondary stack.
 
-  if Get_Name_String (F) /= "a-tags.ali" then
- Opt.Sec_Stack_Used := True;
-  end if;
+  declare
+ File : constant String := Get_Name_String (F);
+  begin
+ if File /= "a-tags.ali"
+   and then File /= "i-c.ali"
+   and then File /= "i-cstrin.ali"
+   and then File /= "i-cpoint.ali"
+ then
+Opt.Sec_Stack_Used := True;
+ end if;
+  end;
 
--  Invalid switch starting with S
 

[Ada] Fix bogus discriminant check failure for type with predicate

[Marc Poulhiès via Gcc-patches]

This reorders the processing in Freeze_Entity_Checks so that building the
predicate functions, which first requires building discriminated checking
functions for record types with a variant part, is done after processing
and checking this variant part.

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

gcc/ada/

* sem_ch13.adb (Freeze_Entity_Checks): Build predicate functions
only after checking the variant part of a record type, if any.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
@@ -12901,139 +12901,6 @@ package body Sem_Ch13 is
 
   Inside_Freezing_Actions := Inside_Freezing_Actions - 1;
 
-  --  If we have a type with predicates, build predicate function. This is
-  --  not needed in the generic case, nor within e.g. TSS subprograms and
-  --  other predefined primitives. For a derived type, ensure that the
-  --  parent type is already frozen so that its predicate function has been
-  --  constructed already. This is necessary if the parent is declared
-  --  in a nested package and its own freeze point has not been reached.
-
-  if Is_Type (E)
-and then Nongeneric_Case
-and then Has_Predicates (E)
-and then Predicate_Check_In_Scope (N)
-  then
- declare
-Atyp : constant Entity_Id := Nearest_Ancestor (E);
- begin
-if Present (Atyp)
-  and then Has_Predicates (Atyp)
-  and then not Is_Frozen (Atyp)
-then
-   Freeze_Before (N, Atyp);
-end if;
- end;
-
- --  Before we build a predicate function, ensure that discriminant
- --  checking functions are available. The predicate function might
- --  need to call these functions if the predicate references
- --  any components declared in a variant part.
- if Ekind (E) = E_Record_Type and then Has_Discriminants (E) then
-Build_Or_Copy_Discr_Checking_Funcs (Parent (E));
- end if;
-
- Build_Predicate_Function (E, N);
-  end if;
-
-  --  If type has delayed aspects, this is where we do the preanalysis at
-  --  the freeze point, as part of the consistent visibility check. Note
-  --  that this must be done after calling Build_Predicate_Function or
-  --  Build_Invariant_Procedure since these subprograms fix occurrences of
-  --  the subtype name in the saved expression so that they will not cause
-  --  trouble in the preanalysis.
-
-  --  This is also not needed in the generic case
-
-  if Nongeneric_Case
-and then Has_Delayed_Aspects (E)
-and then Scope (E) = Current_Scope
-  then
- declare
-Ritem : Node_Id;
-
- begin
---  Look for aspect specification entries for this entity
-
-Ritem := First_Rep_Item (E);
-while Present (Ritem) loop
-   if Nkind (Ritem) = N_Aspect_Specification
- and then Entity (Ritem) = E
- and then Is_Delayed_Aspect (Ritem)
-   then
-  if Get_Aspect_Id (Ritem) in Aspect_CPU
-| Aspect_Dynamic_Predicate
-| Aspect_Predicate
-| Aspect_Static_Predicate
-| Aspect_Priority
-  then
---  Retrieve the visibility to components and discriminants
---  in order to properly analyze the aspects.
-
- Push_Type (E);
- Check_Aspect_At_Freeze_Point (Ritem);
-
- --  In the case of predicate aspects, there will be
- --  a corresponding Predicate pragma associated with
- --  the aspect, and the expression of the pragma also
- --  needs to be analyzed at this point, to ensure that
- --  Save_Global_References will capture global refs in
- --  expressions that occur in generic bodies, for proper
- --  later resolution of the pragma in instantiations.
-
- if Is_Type (E)
-   and then Inside_A_Generic
-   and then Has_Predicates (E)
-   and then Present (Aspect_Rep_Item (Ritem))
- then
-declare
-   Pragma_Args : constant List_Id :=
- Pragma_Argument_Associations
-   (Aspect_Rep_Item (Ritem));
-   Pragma_Expr : constant Node_Id :=
- Expression (Next (First (Pragma_Args)));
-begin
-   if Present (Pragma_Expr) then
-  Analyze_And_Resolve
- 

[Ada] Cleanup resolution of aggregates with mixed component associations

[Marc Poulhiès via Gcc-patches]

Code cleanup only; semantics is unaffected.

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

gcc/ada/

* sem_aggr.adb (Resolve_Array_Aggregate): Change an inconsistent
use of False into its local equivalent Failure.diff --git a/gcc/ada/sem_aggr.adb b/gcc/ada/sem_aggr.adb
--- a/gcc/ada/sem_aggr.adb
+++ b/gcc/ada/sem_aggr.adb
@@ -1926,7 +1926,7 @@ package body Sem_Aggr is
 and then No (Component_Associations (N))
 and then not Null_Record_Present (N)
   then
- return False;
+ return Failure;
   end if;
 
   --  Disable the warning for GNAT Mode to allow for easier transition.
@@ -1966,7 +1966,7 @@ package body Sem_Aggr is
   Error_Msg_N ("mixed iterated component association"
& " (RM 4.3.3 (17.1/5))",
   Assoc);
-  return False;
+  return Failure;
end if;
 
Next (Assoc);
@@ -1985,7 +1985,7 @@ package body Sem_Aggr is
   Error_Msg_N ("mixed iterated component association"
 & " (RM 4.3.3 (17.1/5))",
   Assoc);
-  return False;
+  return Failure;
end if;
 
Next (Assoc);

[Ada] Fix double identifiers in iterated component association

[Marc Poulhiès via Gcc-patches]

The iterated_component_association grammar construct appears in Ada RM
in two syntactic forms: with iterator_specification and with
defining_identifier. This is now properly reflected in the GNAT AST,
while previously we had two defining_identifiers regardless of the
syntactic form.

Cleanup related to handling of iterated_component_association in SPARK.
Behavior of the compiler itself should not be affected.

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

gcc/ada/

* exp_aggr.adb (Two_Pass_Aggregate_Expansion): Expand iterated
component association with an unanalyzed copy of iterated
expression. The previous code worked only because the expanded
loop used both an analyzed copy of the iterator_specification and
an analyzed copy of the iterated expression. Now the iterated
expression is reanalyzed in the context of the expanded loop.
* par-ch4.adb (Build_Iterated_Component_Association): Don't set
defining identifier when iterator specification is present.
* sem_aggr.adb (Resolve_Iterated_Association): Pick index name
from the iterator specification.
* sem_elab.adb (Traverse_Potential_Scenario): Handle iterated
element association just like iterated component association. Not
strictly part of this fix, but still worth for the completeness.
* sem_res.adb (Resolve): Pick index name from the iterator
specification, when present.
* sem_util.adb (Traverse_More): For completeness, just like the
change in Traverse_Potential_Scenario.
* sinfo.ads
(ITERATED_COMPONENT_ASSOCIATION): Fix and complete description.
(ITERATED_ELEMENT_ASSOCIATION): Likewise.diff --git a/gcc/ada/exp_aggr.adb b/gcc/ada/exp_aggr.adb
--- a/gcc/ada/exp_aggr.adb
+++ b/gcc/ada/exp_aggr.adb
@@ -6536,7 +6536,7 @@ package body Exp_Aggr is
 Prefix => New_Occurrence_Of (TmpE, Loc),
 Expressions =>
   New_List (New_Occurrence_Of (Index_Id, Loc))),
-   Expression => New_Copy_Tree (Expression (Assoc)));
+   Expression => Copy_Separate_Tree (Expression (Assoc)));
 
 --  Advance index position for insertion.
 
@@ -7500,11 +7500,11 @@ package body Exp_Aggr is
 
 --  Iterated_Component_Association.
 
-Loop_Id :=
-  Make_Defining_Identifier (Loc,
-Chars => Chars (Defining_Identifier (Comp)));
-
 if Present (Iterator_Specification (Comp)) then
+   Loop_Id :=
+ Make_Defining_Identifier (Loc,
+   Chars => Chars (Defining_Identifier
+  (Iterator_Specification (Comp;
L_Iteration_Scheme :=
  Make_Iteration_Scheme (Loc,
Iterator_Specification => Iterator_Specification (Comp));
@@ -7513,6 +7513,9 @@ package body Exp_Aggr is
--  Loop_Parameter_Specification is parsed with a choice list.
--  where the range is the first (and only) choice.
 
+   Loop_Id :=
+ Make_Defining_Identifier (Loc,
+   Chars => Chars (Defining_Identifier (Comp)));
L_Range := Relocate_Node (First (Discrete_Choices (Comp)));
 
L_Iteration_Scheme :=


diff --git a/gcc/ada/par-ch4.adb b/gcc/ada/par-ch4.adb
--- a/gcc/ada/par-ch4.adb
+++ b/gcc/ada/par-ch4.adb
@@ -3554,7 +3554,6 @@ package body Ch4 is
  when Tok_Of =>
 Restore_Scan_State (State);
 Scan;  -- past OF
-Set_Defining_Identifier (Assoc_Node, Id);
 Iter_Spec := P_Iterator_Specification (Id);
 Set_Iterator_Specification (Assoc_Node, Iter_Spec);
 


diff --git a/gcc/ada/sem_aggr.adb b/gcc/ada/sem_aggr.adb
--- a/gcc/ada/sem_aggr.adb
+++ b/gcc/ada/sem_aggr.adb
@@ -3053,7 +3053,8 @@ package body Sem_Aggr is
 
  elsif Present (Iterator_Specification (Comp)) then
 Copy:= Copy_Separate_Tree (Iterator_Specification (Comp));
-Id_Name := Chars (Defining_Identifier (Comp));
+Id_Name :=
+  Chars (Defining_Identifier (Iterator_Specification (Comp)));
 
 Analyze (Copy);
 Typ := Etype (Defining_Identifier (Copy));


diff --git a/gcc/ada/sem_elab.adb b/gcc/ada/sem_elab.adb
--- a/gcc/ada/sem_elab.adb
+++ b/gcc/ada/sem_elab.adb
@@ -3339,7 +3339,9 @@ package body Sem_Elab is
Traverse_List (Else_Actions (Scen));
 
 elsif Nkind (Scen) in
-N_Component_Association | N_Iterated_Component_Association
+N_Component_Association
+  | N_Iterated_Component_Association
+  | N_Iterated_Element_Association
 then
Traverse_List (Loop_Actions (Scen));
 


diff --git a/gcc/ada/sem_res.adb b/gcc/ada/sem_res.adb
--- a/gcc/ada/sem_res.adb
+++ b/gcc/ada/sem_res.a

[Ada] Small cleanup in body of System.Value_R

[Marc Poulhiès via Gcc-patches]

This is mostly stylistic but also adds a couple of missing comments.

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

gcc/ada/

* libgnat/s-valuer.adb (Scan_Decimal_Digits): Consistently avoid
initializing local variables.
(Scan_Integral_Digits): Likewise.
(Scan_Raw_Real): Likewise and add a couple of comments.diff --git a/gcc/ada/libgnat/s-valuer.adb b/gcc/ada/libgnat/s-valuer.adb
--- a/gcc/ada/libgnat/s-valuer.adb
+++ b/gcc/ada/libgnat/s-valuer.adb
@@ -184,7 +184,7 @@ package body System.Value_R is
   UmaxB : constant Uns := Precision_Limit / Uns (Base);
   --  Numbers bigger than UmaxB overflow if multiplied by base
 
-  Precision_Limit_Reached : Boolean := False;
+  Precision_Limit_Reached : Boolean;
   --  Set to True if addition of a digit will cause Value to be superior
   --  to Precision_Limit.
 
@@ -198,7 +198,7 @@ package body System.Value_R is
   Temp : Uns;
   --  Temporary
 
-  Trailing_Zeros : Natural := 0;
+  Trailing_Zeros : Natural;
   --  Number of trailing zeros at a given point
 
begin
@@ -209,12 +209,17 @@ package body System.Value_R is
  Precision_Limit_Reached := True;
   else
  Extra := 0;
+ Precision_Limit_Reached := False;
   end if;
 
   if Round then
  Precision_Limit_Just_Reached := False;
   end if;
 
+  --  Initialize trailing zero counter
+
+  Trailing_Zeros := 0;
+
   --  The function precondition is that the first character is a valid
   --  digit.
 
@@ -362,7 +367,7 @@ package body System.Value_R is
   UmaxB : constant Uns := Precision_Limit / Uns (Base);
   --  Numbers bigger than UmaxB overflow if multiplied by base
 
-  Precision_Limit_Reached : Boolean := False;
+  Precision_Limit_Reached : Boolean;
   --  Set to True if addition of a digit will cause Value to be superior
   --  to Precision_Limit.
 
@@ -383,6 +388,8 @@ package body System.Value_R is
   Scale := 0;
   Extra := 0;
 
+  Precision_Limit_Reached := False;
+
   if Round then
  Precision_Limit_Just_Reached := False;
   end if;
@@ -494,28 +501,32 @@ package body System.Value_R is
   After_Point : Boolean;
   --  True if a decimal should be parsed
 
-  Base_Char : Character := ASCII.NUL;
-  --  Character used to set the base. If Nul this means that default
+  Base_Char : Character;
+  --  Character used to set the base. If it is Nul, this means that default
   --  base is used.
 
-  Base_Violation : Boolean := False;
+  Base_Violation : Boolean;
   --  If True some digits where not in the base. The real is still scanned
   --  till the end even if an error will be raised.
 
+  Expon : Integer;
+  --  Exponent as an Integer
+
   Index : Integer;
   --  Local copy of string pointer
 
   Start : Positive;
+  --  Index of the first non-blank character
 
   Value : Uns;
   --  Mantissa as an Integer
 
-  Expon : Integer;
-
begin
   --  The default base is 10
 
-  Base := 10;
+  Base   := 10;
+  Base_Char  := ASCII.NUL;
+  Base_Violation := False;
 
   --  We do not tolerate strings with Str'Last = Positive'Last
 

[Ada] Create internal type for null array aggregate as an itype

[Marc Poulhiès via Gcc-patches]

Internal type created for the null array aggregate of Ada 2022 was
created as a temporary entity and then flagged as internal, but it is
better to create this type directly as an itype.

In particular, when the null array aggregate appears in a spec
expression, its type declaration will not be attached to the AST.
An itype will have Associated_Node_For_Itype, so that the context of
the type can be recovered, which is what GNATprove does.

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

gcc/ada/

* sem_aggr.adb (Resolve_Null_Array_Aggregate): Create internal
type for the aggregate as an itype.diff --git a/gcc/ada/sem_aggr.adb b/gcc/ada/sem_aggr.adb
--- a/gcc/ada/sem_aggr.adb
+++ b/gcc/ada/sem_aggr.adb
@@ -4088,7 +4088,10 @@ package body Sem_Aggr is
   Index  : Node_Id;
   Lo, Hi : Node_Id;
   Constr : constant List_Id := New_List;
-  Subt   : constant Entity_Id := Make_Temporary (Loc, 'S');
+  Subt   : constant Entity_Id :=
+Create_Itype (Ekind   => E_Array_Subtype,
+  Related_Nod => N,
+  Suffix  => 'S');
 
begin
   --  Create a constrained subtype with null dimensions
@@ -4134,7 +4137,6 @@ package body Sem_Aggr is
   Make_Index_Or_Discriminant_Constraint (Loc, Constr)));
 
   Insert_Action (N, Decl);
-  Set_Is_Internal (Subt);
   Analyze (Decl);
   Set_Etype (N, Subt);
   Set_Compile_Time_Known_Aggregate (N);

[Ada] Bad Default_Initial_Condition check for a not-default-initialized object

[Marc Poulhiès via Gcc-patches]

No Default_Initial_Condition check should be generated for an object
declaration that has an explicit initial value. Previously this was
implemented by testing the Has_Init_Expression flag, but this only works
if the object declaration was created by the parser (since only the
parser sets that attribute, at least currently).

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

gcc/ada/

* exp_ch3.adb
(Expand_N_Object_Declaration): In deciding whether to emit a DIC
check, we were previously testing the Has_Init_Expression flag.
Continue to test that flag as before, but add a test for the
syntactic presence of an initial value in the object declaration.
This new test would not supersede the old test in the case where
an explicit initial value has been eliminated as part of some tree
transformation.diff --git a/gcc/ada/exp_ch3.adb b/gcc/ada/exp_ch3.adb
--- a/gcc/ada/exp_ch3.adb
+++ b/gcc/ada/exp_ch3.adb
@@ -7850,6 +7850,7 @@ package body Exp_Ch3 is
 and then Present (DIC_Procedure (Typ))
 and then not Has_Null_Body (DIC_Procedure (Typ))
 and then not Has_Init_Expression (N)
+and then No (Expr)
 and then not Is_Imported (Def_Id)
   then
  declare

[Ada] Cleanup iteration over aggregate component associations

[Marc Poulhiès via Gcc-patches]

Code cleanup related to fixes for iterated component associations in
GNATprove ; semantics is unaffected.

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

gcc/ada/

* sem_aggr.adb
(Resolve_Container_Aggregate): Style cleanup.
(Resolve_Record_Aggregate): Remove redundant guard.diff --git a/gcc/ada/sem_aggr.adb b/gcc/ada/sem_aggr.adb
--- a/gcc/ada/sem_aggr.adb
+++ b/gcc/ada/sem_aggr.adb
@@ -3182,7 +3182,7 @@ package body Sem_Aggr is
 end if;
  end;
 
-  elsif  Present (Add_Named_Subp) then
+  elsif Present (Add_Named_Subp) then
  declare
 --  Retrieves types of container, key, and element from the
 --  specified insertion procedure.
@@ -5048,9 +5048,7 @@ package body Sem_Aggr is
   --OTHERS cannot be used.
   --Positional and named associations cannot be mixed.
 
-  if Present (Component_Associations (N))
-and then Present (First (Component_Associations (N)))
-  then
+  if Present (Component_Associations (N)) then
  declare
 Assoc : Node_Id;
 

[Ada] Move check for null array aggregates to expansion

[Marc Poulhiès via Gcc-patches]

Despite recent changes to runtime checks for null array aggregates,
GNATprove still struggles with N_Raise_Constraint_Error nodes inserted
into AST by aggregate resolution. The ultimate fix is to move these
checks to expansion (which is disabled in GNATprove mode) and explicitly
emit a proof check in the GNATprove backend.

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

gcc/ada/

* exp_aggr.adb (Check_Bounds): Move code and comment related to
check for null array aggregate from Resolve_Null_Array_Aggregate.
* sem_aggr.ads (Is_Null_Aggregate): Move spec from unit body.
* sem_aggr.adb (Resolve_Null_Array_Aggregate): Move check to
expansion.diff --git a/gcc/ada/exp_aggr.adb b/gcc/ada/exp_aggr.adb
--- a/gcc/ada/exp_aggr.adb
+++ b/gcc/ada/exp_aggr.adb
@@ -5734,7 +5734,8 @@ package body Exp_Aggr is
 
   procedure Check_Bounds (Aggr_Bounds_Node, Index_Bounds_Node : Node_Id);
   --  Checks that the bounds of Aggr_Bounds are within the bounds defined
-  --  by Index_Bounds.
+  --  by Index_Bounds. For null array aggregate (Ada 2022) check that the
+  --  aggregate bounds define a null range.
 
   procedure Check_Same_Aggr_Bounds (Sub_Aggr : Node_Id; Dim : Pos);
   --  Checks that in a multidimensional array aggregate all subaggregates
@@ -5850,6 +5851,22 @@ package body Exp_Aggr is
  Cond : Node_Id := Empty;
 
   begin
+ --  For a null array aggregate check that high bound (i.e., low
+ --  bound predecessor) exists. Fail if low bound is low bound of
+ --  base subtype (in all cases, including modular).
+
+ if Is_Null_Aggregate (N) then
+Insert_Action (N,
+  Make_Raise_Constraint_Error (Loc,
+Condition =>
+  Make_Op_Eq (Loc,
+New_Copy_Tree (Aggr_Bounds.First),
+New_Copy_Tree
+  (Type_Low_Bound (Base_Type (Etype (Ind_Bounds.First),
+Reason=> CE_Range_Check_Failed));
+return;
+ end if;
+
  --  Generate the following test:
 
  --[constraint_error when


diff --git a/gcc/ada/sem_aggr.adb b/gcc/ada/sem_aggr.adb
--- a/gcc/ada/sem_aggr.adb
+++ b/gcc/ada/sem_aggr.adb
@@ -404,10 +404,6 @@ package body Sem_Aggr is
--  The bounds of the aggregate itype are cooked up to look reasonable
--  (in this particular case the bounds will be 1 .. 2).
 
-   function Is_Null_Aggregate (N : Node_Id) return Boolean;
-   --  Returns True for a "[]" aggregate (an Ada 2022 feature), even after
-   --  it has been transformed by expansion. Returns False otherwise.
-
procedure Make_String_Into_Aggregate (N : Node_Id);
--  A string literal can appear in a context in which a one dimensional
--  array of characters is expected. This procedure simply rewrites the
@@ -419,9 +415,6 @@ package body Sem_Aggr is
--  is constrained). If the subtype is unconstrained, then the bounds
--  are determined in much the same way as the bounds for a null string
--  literal with no applicable index constraint.
-   --  Emit a check that the bounds for each dimension define a null
-   --  range; no check is emitted if it is statically known that the
-   --  check would succeed.
 
-
--  Delta aggregate processing --
@@ -4102,7 +4095,6 @@ package body Sem_Aggr is
   Loc: constant Source_Ptr := Sloc (N);
   Typ: constant Entity_Id := Etype (N);
 
-  Check  : Node_Id;
   Index  : Node_Id;
   Lo, Hi : Node_Id;
   Constr : constant List_Id := New_List;
@@ -4127,18 +4119,6 @@ package body Sem_Aggr is
  Attribute_Name => Name_Pred,
  Expressions=> New_List (New_Copy_Tree (Lo)));
 
- --  Check that high bound (i.e., low bound predecessor) exists.
- --  Fail if low bound is low bound of base subtype (in all cases,
- --  including modular).
-
- Check :=
-   Make_Raise_Constraint_Error (Loc,
- Condition =>
-   Make_Op_Le (Loc, New_Copy_Tree (Lo), New_Copy_Tree (Hi)),
- Reason => CE_Range_Check_Failed);
-
- Insert_Action (N, Check);
-
  Append (Make_Range (Loc, New_Copy_Tree (Lo), Hi), Constr);
  Analyze_And_Resolve (Last (Constr), Etype (Index));
 


diff --git a/gcc/ada/sem_aggr.ads b/gcc/ada/sem_aggr.ads
--- a/gcc/ada/sem_aggr.ads
+++ b/gcc/ada/sem_aggr.ads
@@ -43,6 +43,10 @@ package Sem_Aggr is
 
--  WARNING: There is a matching C declaration of this subprogram in fe.h
 
+   function Is_Null_Aggregate (N : Node_Id) return Boolean;
+   --  Returns True for a "[]" aggregate (an Ada 2022 feature), even after
+   --  it has been transformed by expansion. Returns False otherwise.
+
function Is_Null_Array_Aggregate_High_Bound (N : Node_Id) return Boolean;
--  Returns True for the high bound of a null array aggregate.
 

[Ada] Remove no longer referenced GNATprove utility routine for itypes

[Marc Poulhiès via Gcc-patches]

Code cleanup related to itypes for Ada 2022 null array aggregates.
Remove routine that was added in 2011 but is not referenced by
GNATprove since 2015.

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

gcc/ada/

* sem_util.ads (Itype_Has_Declaration): Remove spec.
* sem_util.adb (Itype_Has_Declaration): Remove body.diff --git a/gcc/ada/sem_util.adb b/gcc/ada/sem_util.adb
--- a/gcc/ada/sem_util.adb
+++ b/gcc/ada/sem_util.adb
@@ -22167,19 +22167,6 @@ package body Sem_Util is
   pragma Assert (No (Actual));
end Iterate_Call_Parameters;
 
-   ---
-   -- Itype_Has_Declaration --
-   ---
-
-   function Itype_Has_Declaration (Id : Entity_Id) return Boolean is
-   begin
-  pragma Assert (Is_Itype (Id));
-  return Present (Parent (Id))
-and then Nkind (Parent (Id)) in
-   N_Full_Type_Declaration | N_Subtype_Declaration
-and then Defining_Entity (Parent (Id)) = Id;
-   end Itype_Has_Declaration;
-
-
-- Kill_Current_Values --
-


diff --git a/gcc/ada/sem_util.ads b/gcc/ada/sem_util.ads
--- a/gcc/ada/sem_util.ads
+++ b/gcc/ada/sem_util.ads
@@ -2561,11 +2561,6 @@ package Sem_Util is
--  Calls Handle_Parameter for each pair of formal and actual parameters of
--  a function, procedure, or entry call.
 
-   function Itype_Has_Declaration (Id : Entity_Id) return Boolean;
-   --  Applies to Itypes. True if the Itype is attached to a declaration for
-   --  the type through its Parent field, which may or not be present in the
-   --  tree.
-
procedure Kill_Current_Values (Last_Assignment_Only : Boolean := False);
--  This procedure is called to clear all constant indications from all
--  entities in the current scope and in any parent scopes if the current

[Ada] Single-element Append performance improvement

[Marc Poulhiès via Gcc-patches]

Ada.Containers.Vectors has two Append procedures that take an
Element value; one takes a Count parameter and one does not
(the count is implicitly one for the latter). For the former version,
there was code that took a faster path if certain conditions were met
and otherwise took a slower path; one of the prerequisite conditions
for this was Count = 1. For the latter version, no such special-case
detection was performed; the more general code was always executed.
Move the special-case detection/handling code from the former version into
the latter and change the former version to simply call the latter version
if Count = 1. Also apply same change to Ada.Containers.Indefinite_Vectors.

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

gcc/ada/

* libgnat/a-coinve.adb, libgnat/a-convec.adb
(Append): If the Append that takes an Element and a Count is
called with Count = 1, then call the Append that does not take a
Count parameter; otherwise call the code that handles the general
case. Move the special case detection/handling code that was
formerly in that version of Append into the version that does not
take a Count parameter, so that now both versions get the
performance benefit.diff --git a/gcc/ada/libgnat/a-coinve.adb b/gcc/ada/libgnat/a-coinve.adb
--- a/gcc/ada/libgnat/a-coinve.adb
+++ b/gcc/ada/libgnat/a-coinve.adb
@@ -197,12 +197,29 @@ is
   Count : Count_Type)
is
begin
-  --  In the general case, we pass the buck to Insert, but for efficiency,
-  --  we check for the usual case where Count = 1 and the vector has enough
-  --  room for at least one more element.
+  --  In the general case, we take the slow path; for efficiency,
+  --  we check for the common case where Count = 1 .
 
-  if Count = 1
-and then Container.Elements /= null
+  if Count = 1 then
+ Append (Container, New_Item);
+  else
+ Append_Slow_Path (Container, New_Item, Count);
+  end if;
+   end Append;
+
+   
+   -- Append --
+   
+
+   procedure Append (Container : in out Vector;
+ New_Item  :Element_Type)
+   is
+   begin
+  --  For performance, check for the common special case where the
+  --  container already has room for at least one more element.
+  --  In the general case, pass the buck to Insert.
+
+  if Container.Elements /= null
 and then Container.Last /= Container.Elements.Last
   then
  TC_Check (Container.TC);
@@ -223,23 +240,11 @@ is
 Container.Elements.EA (New_Last) := new Element_Type'(New_Item);
 Container.Last := New_Last;
  end;
-
   else
- Append_Slow_Path (Container, New_Item, Count);
+ Insert (Container, Last_Index (Container) + 1, New_Item, 1);
   end if;
end Append;
 
-   
-   -- Append --
-   
-
-   procedure Append (Container : in out Vector;
-New_Item   :Element_Type)
-   is
-   begin
-  Insert (Container, Last_Index (Container) + 1, New_Item, 1);
-   end Append;
-
--
-- Append_Slow_Path --
--


diff --git a/gcc/ada/libgnat/a-convec.adb b/gcc/ada/libgnat/a-convec.adb
--- a/gcc/ada/libgnat/a-convec.adb
+++ b/gcc/ada/libgnat/a-convec.adb
@@ -173,27 +173,11 @@ is
   Count : Count_Type)
is
begin
-  --  In the general case, we pass the buck to Insert, but for efficiency,
-  --  we check for the usual case where Count = 1 and the vector has enough
-  --  room for at least one more element.
-
-  if Count = 1
-and then Container.Elements /= null
-and then Container.Last /= Container.Elements.Last
-  then
- TC_Check (Container.TC);
-
- --  Increment Container.Last after assigning the New_Item, so we
- --  leave the Container unmodified in case Finalize/Adjust raises
- --  an exception.
-
- declare
-New_Last : constant Index_Type := Container.Last + 1;
- begin
-Container.Elements.EA (New_Last) := New_Item;
-Container.Last := New_Last;
- end;
+  --  In the general case, we take the slow path; for efficiency,
+  --  we check for the common case where Count = 1 .
 
+  if Count = 1 then
+ Append (Container, New_Item);
   else
  Append_Slow_Path (Container, New_Item, Count);
   end if;
@@ -222,7 +206,28 @@ is
  New_Item  :Element_Type)
is
begin
-  Insert (Container, Last_Index (Container) + 1, New_Item, 1);
+  --  For performance, check for the common special case where the
+  --  container already has room for at least one more element.
+  --  In the general case, pass the buck to Insert.
+
+  if Container.Elements /= null
+and then Container.Last /= Container.Elements.Last
+  then
+ 

[Ada] Remove VMS specific routine that is no longer referenced

[Marc Poulhiès via Gcc-patches]

Code cleanup related to resctrition No_Local_Allocators.

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

gcc/ada/

* exp_util.ads (Entry_Names_OK): Remove spec.
* exp_util.adb (Entry_Names_OK): Remove body.diff --git a/gcc/ada/exp_util.adb b/gcc/ada/exp_util.adb
--- a/gcc/ada/exp_util.adb
+++ b/gcc/ada/exp_util.adb
@@ -5187,19 +5187,6 @@ package body Exp_Util is
   end if;
end Ensure_Defined;
 
-   
-   -- Entry_Names_OK --
-   
-
-   function Entry_Names_OK return Boolean is
-   begin
-  return
-not Restricted_Profile
-  and then not Global_Discard_Names
-  and then not Restriction_Active (No_Implicit_Heap_Allocations)
-  and then not Restriction_Active (No_Local_Allocators);
-   end Entry_Names_OK;
-
---
-- Evaluate_Name --
---


diff --git a/gcc/ada/exp_util.ads b/gcc/ada/exp_util.ads
--- a/gcc/ada/exp_util.ads
+++ b/gcc/ada/exp_util.ads
@@ -509,11 +509,6 @@ package Exp_Util is
--  used to ensure that an Itype is properly defined outside a conditional
--  construct when it is referenced in more than one branch.
 
-   function Entry_Names_OK return Boolean;
-   --  Determine whether it is appropriate to dynamically allocate strings
-   --  which represent entry [family member] names. These strings are created
-   --  by the compiler and used by GDB.
-
procedure Evaluate_Name (Nam : Node_Id);
--  Remove all side effects from a name which appears as part of an object
--  renaming declaration. Similarly to Force_Evaluation, it removes the

[Ada] Fix insertion of a runtime check for null array aggregate

[Marc Poulhiès via Gcc-patches]

A null array aggregate of Ada 2022 requires a conditional runtime check
that was inserted as an if-statement. While gigi can handle statements
inserted into a list of declarations, in GNATprove such a statement will
cause a crash. It is better to insert a conditional raise node, which is
properly handled by both gigi and GNATprove.

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

gcc/ada/

* sem_aggr.adb (Resolve_Null_Array_Aggregate): Insert check as a
Raise_Constraint_Error node and not an If_Statement.diff --git a/gcc/ada/sem_aggr.adb b/gcc/ada/sem_aggr.adb
--- a/gcc/ada/sem_aggr.adb
+++ b/gcc/ada/sem_aggr.adb
@@ -4113,12 +4113,10 @@ package body Sem_Aggr is
  --  including modular).
 
  Check :=
-   Make_If_Statement (Loc,
+   Make_Raise_Constraint_Error (Loc,
  Condition =>
Make_Op_Le (Loc, New_Copy_Tree (Lo), New_Copy_Tree (Hi)),
- Then_Statements =>
-   New_List (Make_Raise_Constraint_Error
-   (Loc, Reason => CE_Range_Check_Failed)));
+ Reason => CE_Range_Check_Failed);
 
  Insert_Action (N, Check);
 

[Ada] Fix inconsistent building of itypes for null array aggregates

[Marc Poulhiès via Gcc-patches]

To analyze Ada 2022 null array aggregates we introduced a dedicated
routine and bypassed the code for ordinary array aggregates. However,
the types for the array indexes created by this dedicated routine
differed from the types created for ordinary array aggregates, i.e.
itypes for null array aggregates were associated with the array subtype
declaration, while itypes for ordinary array aggregates were associated
with the aggregate itself. These differences cause trouble for various
routines in GNATprove.

This patch reduces the special handling of null array aggregates and
reuses the building of itypes for ordinary array aggregates.

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

gcc/ada/

* sem_aggr.adb
(Array_Aggr_Subtype): Bypass call to Collect_Aggr_Bound with
dedicated code for null array aggregates.
(Resolve_Array_Aggregate): Remove special handling of null array
aggregates.
(Resolve_Array_Aggregate): Create bounds, but let
Array_Aggr_Subtype create itype entities.diff --git a/gcc/ada/sem_aggr.adb b/gcc/ada/sem_aggr.adb
--- a/gcc/ada/sem_aggr.adb
+++ b/gcc/ada/sem_aggr.adb
@@ -567,7 +567,29 @@ package body Sem_Aggr is
   end if;
 
   Set_Parent (Index_Constraints, N);
-  Collect_Aggr_Bounds (N, 1);
+
+  --  When resolving a null aggregate we created a list of aggregate bounds
+  --  for the consecutive dimensions. The bounds for the first dimension
+  --  are attached as the Aggregate_Bounds of the aggregate node.
+
+  if Is_Null_Aggregate (N) then
+ declare
+This_Range : Node_Id := Aggregate_Bounds (N);
+ begin
+for J in 1 .. Aggr_Dimension loop
+   Aggr_Range (J) := This_Range;
+   Next_Index (This_Range);
+
+   --  Remove bounds from the list, so they can be reattached as
+   --  the First_Index/Next_Index again by the code that also
+   --  handles non-null aggregates.
+
+   Remove (Aggr_Range (J));
+end loop;
+ end;
+  else
+ Collect_Aggr_Bounds (N, 1);
+  end if;
 
   --  Build the list of constrained indexes of our aggregate itype
 
@@ -1203,9 +1225,6 @@ package body Sem_Aggr is
 
Aggr_Subtyp := Any_Composite;
 
-elsif Is_Null_Aggr then
-   Aggr_Subtyp := Etype (N);
-
 else
Aggr_Subtyp := Array_Aggr_Subtype (N, Typ);
 end if;
@@ -4084,16 +4103,16 @@ package body Sem_Aggr is
   Typ: constant Entity_Id := Etype (N);
 
   Check  : Node_Id;
-  Decl   : Node_Id;
   Index  : Node_Id;
   Lo, Hi : Node_Id;
   Constr : constant List_Id := New_List;
-  Subt   : constant Entity_Id :=
-Create_Itype (Ekind   => E_Array_Subtype,
-  Related_Nod => N,
-  Suffix  => 'S');
 
begin
+  --  Attach the list of constraints at the location of the aggregate, so
+  --  the individual constraints can be analyzed.
+
+  Set_Parent (Constr, N);
+
   --  Create a constrained subtype with null dimensions
 
   Index := First_Index (Typ);
@@ -4120,25 +4139,14 @@ package body Sem_Aggr is
 
  Insert_Action (N, Check);
 
- Append (Make_Range (Loc, Lo, Hi), Constr);
+ Append (Make_Range (Loc, New_Copy_Tree (Lo), Hi), Constr);
+ Analyze_And_Resolve (Last (Constr), Etype (Index));
 
  Index := Next_Index (Index);
   end loop;
 
-  Decl := Make_Subtype_Declaration (Loc,
-Defining_Identifier => Subt,
-Subtype_Indication  =>
-  Make_Subtype_Indication (Loc,
-Subtype_Mark =>
-  New_Occurrence_Of (Base_Type (Typ), Loc),
-Constraint =>
-  Make_Index_Or_Discriminant_Constraint (Loc, Constr)));
-
-  Insert_Action (N, Decl);
-  Analyze (Decl);
-  Set_Etype (N, Subt);
   Set_Compile_Time_Known_Aggregate (N);
-  Set_Aggregate_Bounds (N, New_Copy_Tree (First_Index (Etype (N;
+  Set_Aggregate_Bounds (N, First (Constr));
 
   return True;
end Resolve_Null_Array_Aggregate;

Re: libsanitizer: merge from upstream

[Martin Liška]

On 9/4/22 21:50, Iain Sandoe wrote:
> Hi Martin,
> 
>> On 30 Aug 2022, at 11:53, Martin Liška  wrote:
>>
>> On 5/4/22 10:59, Martin Liška wrote:
>>> Hello.
>> I've just done one more merge from upstream.
>> Upstream revision: 84a71d5259c2682403cdbd8710592410a2f128ab.
> 
> Which (again) breaks bootstrap on Darwin (since upstream uses features
> and APIs not present in GCC and/or supported by the systems we support).

Hi.

Can you please report that to upstream and create a patch that would
be accepted by upstream?

Thanks,
Martin

> 
> Worked around as below; we will need to find a way to handle the
> macOS 13+ changes.
> 
> Iain
> 
> 
> [pushed] [libsanitizer, Darwin] Fix bootstrap after recent merge.
> 
> The latest merge to libsanitizer includes changes to handle macOS 13+.
> However, these changes are incompatible with GCC and so we need to find
> an alternate solution.  To restore bootstrap back this change out until
> the alternate can be found.
> ---
>  .../sanitizer_procmaps_mac.cpp| 62 +++
>  1 file changed, 10 insertions(+), 52 deletions(-)
> 
> diff --git a/libsanitizer/sanitizer_common/sanitizer_procmaps_mac.cpp 
> b/libsanitizer/sanitizer_common/sanitizer_procmaps_mac.cpp
> index 4b0e6781976..ba4259acd46 100644
> --- a/libsanitizer/sanitizer_common/sanitizer_procmaps_mac.cpp
> +++ b/libsanitizer/sanitizer_common/sanitizer_procmaps_mac.cpp
> @@ -146,8 +146,13 @@ static bool IsDyldHdr(const mach_header *hdr) {
>  // until we hit a Mach header matching dyld instead. These recurse
>  // calls are expensive, but the first memory map generation occurs
>  // early in the process, when dyld is one of the only images loaded,
> -// so it will be hit after only a few iterations.  These assumptions don't 
> hold
> -// on macOS 13+ anymore (dyld itself has moved into the shared cache).
> +// so it will be hit after only a few iterations.  These assumptions don't
> +// hold on macOS 13+ anymore (dyld itself has moved into the shared cache).
> +
> +// FIXME: Unfortunately, the upstream revised version to deal with macOS 13+
> +// is incompatible with GCC and also uses APIs not available on earlier
> +// systems which we support; backed out for now.
> +
>  static mach_header *GetDyldImageHeaderViaVMRegion() {
>vm_address_t address = 0;
>  
> @@ -171,64 +176,17 @@ static mach_header *GetDyldImageHeaderViaVMRegion() {
>}
>  }
>  
> -extern "C" {
> -struct dyld_shared_cache_dylib_text_info {
> -  uint64_t version;  // current version 2
> -  // following fields all exist in version 1
> -  uint64_t loadAddressUnslid;
> -  uint64_t textSegmentSize;
> -  uuid_t dylibUuid;
> -  const char *path;  // pointer invalid at end of iterations
> -  // following fields all exist in version 2
> -  uint64_t textSegmentOffset;  // offset from start of cache
> -};
> -typedef struct dyld_shared_cache_dylib_text_info
> -dyld_shared_cache_dylib_text_info;
> -
> -extern bool _dyld_get_shared_cache_uuid(uuid_t uuid);
> -extern const void *_dyld_get_shared_cache_range(size_t *length);
> -extern int dyld_shared_cache_iterate_text(
> -const uuid_t cacheUuid,
> -void (^callback)(const dyld_shared_cache_dylib_text_info *info));
> -}  // extern "C"
> -
> -static mach_header *GetDyldImageHeaderViaSharedCache() {
> -  uuid_t uuid;
> -  bool hasCache = _dyld_get_shared_cache_uuid(uuid);
> -  if (!hasCache)
> -return nullptr;
> -
> -  size_t cacheLength;
> -  __block uptr cacheStart = (uptr)_dyld_get_shared_cache_range(&cacheLength);
> -  CHECK(cacheStart && cacheLength);
> -
> -  __block mach_header *dyldHdr = nullptr;
> -  int res = dyld_shared_cache_iterate_text(
> -  uuid, ^(const dyld_shared_cache_dylib_text_info *info) {
> -CHECK_GE(info->version, 2);
> -mach_header *hdr =
> -(mach_header *)(cacheStart + info->textSegmentOffset);
> -if (IsDyldHdr(hdr))
> -  dyldHdr = hdr;
> -  });
> -  CHECK_EQ(res, 0);
> -
> -  return dyldHdr;
> -}
> -
>  const mach_header *get_dyld_hdr() {
>if (!dyld_hdr) {
>  // On macOS 13+, dyld itself has moved into the shared cache.  Looking 
> it up
>  // via vm_region_recurse_64() causes spins/hangs/crashes.
> +// FIXME: find a way to do this compatible with GCC.
>  if (GetMacosAlignedVersion() >= MacosVersion(13, 0)) {
> -  dyld_hdr = GetDyldImageHeaderViaSharedCache();
> -  if (!dyld_hdr) {
>  VReport(1,
> -"Failed to lookup the dyld image header in the shared cache 
> on "
> -"macOS 13+ (or no shared cache in use).  Falling back to "
> +"looking up the dyld image header in the shared cache on "
> +"macOS 13+ is not yet supported.  Falling back to "
>  "lookup via vm_region_recurse_64().\n");
>  dyld_hdr = GetDyldImageHeaderViaVMRegion();
> -  }
>  } else {
>dyld_hdr = GetDyldImageHeaderViaVMRegion();
>  }

Re: libsanitizer: merge from upstream

[Rainer Orth]

Hi Martin,

> On 9/4/22 21:50, Iain Sandoe wrote:
>> Hi Martin,
>> 
>>> On 30 Aug 2022, at 11:53, Martin Liška  wrote:
>>>
>>> On 5/4/22 10:59, Martin Liška wrote:
 Hello.
>>> I've just done one more merge from upstream.
>>> Upstream revision: 84a71d5259c2682403cdbd8710592410a2f128ab.
>> 
>> Which (again) breaks bootstrap on Darwin (since upstream uses features
>> and APIs not present in GCC and/or supported by the systems we support).
>
> Hi.
>
> Can you please report that to upstream and create a patch that would
> be accepted by upstream?

this may be difficult, unfortunately.  Some time ago, I tried to get an
answer to the question which macOS versions are supposed to be supported
by upstream LLVM and got nothing, despite the massive involvement of
Apple in the project.  Still, it's certainly worth a try.

As a datapoint, both recent libsanitizer imports broke Solaris 11.3
bootstrap, which is still supported by GCC, but never was by LLVM.  In
the first case, I managed to get a patch in to fix that (and a
non-trivial one at that), in the current case I even created the
breakage myself by (again) forgetting that upstream eventually gets
imported into GCC with its wider range of supported Solaris versions.

Rainer

-- 
-
Rainer Orth, Center for Biotechnology, Bielefeld University

Re: [PATCH][DOCS] gcc-13: document removal of STABS

[Martin Liška]

On 9/2/22 10:29, Gerald Pfeifer wrote:
> Hi Martin,
> 
> On Fri, 2 Sep 2022, Martin Liška wrote:
>> +The support for emitting the STABS debugging format has been removed
>> +  (includes -gstabs and -gxcoff options) 
>> which means
>> +  the support for dbx debugger is removed.
> 
> how about slightly rephrasing this and breaking up the sentence for easier 
> consumption?
> 
>Support for emitting the STABS debugging format (including the
>  -gstabs and -gxcoff options) has been removed.
>  (This means the dbx debugger is no longer 
>  supported, either.)
> 
> Just a suggestion, feel free to take what you like (only the removals and 
> addition of "the" should stay.)

I like your suggestion!

Cheers,
Martin

> 
> And if you have an idea how to phrase my second sentence a little nicer, 
> absolutely go for it.
> 
> Thanks,
> Gerald

Re: [PATCH 1/3] STABS: remove -gstabs and -gxcoff functionality

[Martin Liška]

On 9/2/22 10:54, Richard Biener wrote:
> On Fri, Sep 2, 2022 at 9:00 AM Martin Liška  wrote:
>>
>> On 9/1/22 13:18, Richard Biener wrote:
>>> I presume WarnRemoved will diagnose use of -gstabs but not fail
>>> compilation.  Will -gstabs then still enable -g (with the default debug
>>> format)?
>>
>> No, it won't set -g option.
> 
> That was the usual side-effect - I wonder if we want to emit extra
> diagnostic when one of the obsolete options is given but -g is not
> enabled in the end or whether we want to preserve the debug info
> enablement effect?

I would leave it for now and see if somebody would complain about
the current behavior.

> 
>>>
>>> Please followup with a gcc-13/changes.html entry.
>>
>> Sure.
>>
>>>
>>> I notice we have VMS_DEBUGGING_INFO left.  From a quick look
>>> it is used by alpha*-dec-* (exclusively) and ia64-hp-*vms*  (maybe
>>> also supports DWARF, it is ELF at least).  One of the goals of
>>> non-DWARF removal was to get rid of debug hooks and instead allow
>>> "free-form" early debug generation from the frontends.
>>
>> Can you please explain what you mean by the free-form and what's expected
>> to do with the VMS_DEBUGGING_INFO macro?
> 
> Well, VMS debugging would go, just like STABS.

Can go now, or shall we deprecate it in GCC 13 first?

> With "free-form" I mean
> that frontend code could call into the dwarf2out API directly, creating
> DWARF DIEs for language specific info (we probably want to export more
> and/or nicer APIs for such use).

Ok, so bypassing dwarf2_debug_hooks, right? I can leave it to you such API
improvement. What do you think?

Cheers,
Martin

> 
> Richard.
> 
>> Cheers,
>> Martin

Re: [PATCH] rs6000: Don't ICE when we disassemble an MMA variable [PR101322]

[Kewen.Lin via Gcc-patches]

on 2022/9/1 22:17, Peter Bergner wrote:
> On 9/1/22 3:29 AM, Kewen.Lin wrote:
>>> I have no idea why ptr_vector_*_type would behave differently here than
>>> build_pointer_type (vector_*_type_node).  Using the build_pointer_type()
>>> fixed it for me, so that's why I went with it. :-)  Maybe this is a bug
>>> in lto???
>>
>> Thanks for your time to reproduce this!
>>
>> The only difference is that ptr_vector_*_type are built from the
>> qualified_type based on vector_*_type_node, instead of directly from
>> vector_*_type_node.  I'm interested to have a further look at this later.
> 
> If you look into this, please let me know.  I'd like to know what you
> find out.

I just filed PR106833 for it.

BR,
Kewen

Re: [PATCH] libcpp, v3: Named universal character escapes and delimited escape sequence tweaks

[Jakub Jelinek via Gcc-patches]

On Sat, Sep 03, 2022 at 12:54:31PM +0200, Jakub Jelinek via Gcc-patches wrote:
> On Sat, Sep 03, 2022 at 12:29:52PM +0200, Jakub Jelinek wrote:
> > On Thu, Sep 01, 2022 at 03:00:28PM -0400, Jason Merrill wrote:
> > > We might as well use the same flag name, and document it to mean what it
> > > currently means for GCC.
> > 
> > Ok, following patch introduces -Wunicode (on by default).
> > 
> > > It looks like this is handling \N{abc}, for which "incomplete" seems like
> > > the wrong description; it's complete, just wrong, and the diagnostic 
> > > doesn't
> > > help correct it.
> > 
> > And also will emit the is not a valid universal character with did you mean
> > if it matches loosely, otherwise will use the not terminated with } after
> > ... wording.
> > 
> > Ok if it passes bootstrap/regtest?
> 
> Actually, treating the !strict case like the strict case except for always
> warning instead of error if outside of literals is simpler.
> 
> The following version does that.  The only difference on the testcases is in
> the
> int f = a\N{abc});
> cases where it emits different diagnostics.

And this version passed successfully bootstrap/regtest.

Jakub

Re: [PATCH v2] rs6000/test: Fix empty TU in some cases of effective targets [PR106345]

[Kewen.Lin via Gcc-patches]

Hi Segher,

Gentle ping this patch as you wanted empty TU issue to be fixed
first at the discussion [1].  Thanks in advance for your time!

[1] https://gcc.gnu.org/pipermail/gcc-patches/2022-September/600927.html

BR,
Kewen

on 2022/7/25 14:26, Kewen.Lin via Gcc-patches wrote:
> Hi,
> 
> As the failure of test case gcc.target/powerpc/pr92398.p9-.c in
> PR106345 shows, some test sources for some powerpc effective
> targets use empty translation unit wrongly.  The test sources
> could go with options like "-ansi -pedantic-errors", then those
> effective target checkings will fail unexpectedly with the
> error messages like:
> 
>   error: ISO C forbids an empty translation unit [-Wpedantic]
> 
> This patch is to fix empty TUs with one dummy function definition
> accordingly.
> 
> Excepting for the failures on gcc.target/powerpc/pr92398.p9-.c
> fixed, I can see it helps to bring back some testing coverage like:
> 
> NA->PASS: gcc.target/powerpc/pr92398.p9+.c
> NA->PASS: gcc.target/powerpc/pr93453-1.c
> 
> Tested as before.
> 
> v1: https://gcc.gnu.org/pipermail/gcc-patches/2022-July/598602.html
> v2: Use dummy function instead of dummy int as Segher suggested.
> 
> Segher, does this v2 look good to you?
> 
> BR,
> Kewen
> -
>   PR testsuite/106345
> 
> gcc/testsuite/ChangeLog:
> 
>   * lib/target-supports.exp (check_effective_target_powerpc_sqrt): Add
>   a function definition to avoid pedwarn about empty translation unit.
>   (check_effective_target_has_arch_pwr5): Likewise.
>   (check_effective_target_has_arch_pwr6): Likewise.
>   (check_effective_target_has_arch_pwr7): Likewise.
>   (check_effective_target_has_arch_pwr8): Likewise.
>   (check_effective_target_has_arch_pwr9): Likewise.
>   (check_effective_target_has_arch_pwr10): Likewise.
>   (check_effective_target_has_arch_ppc64): Likewise.
>   (check_effective_target_ppc_float128): Likewise.
>   (check_effective_target_ppc_float128_insns): Likewise.
>   (check_effective_target_powerpc_vsx): Likewise.
> ---
>  gcc/testsuite/lib/target-supports.exp | 33 +++
>  1 file changed, 33 insertions(+)
> 
> diff --git a/gcc/testsuite/lib/target-supports.exp 
> b/gcc/testsuite/lib/target-supports.exp
> index 4ed7b25b9a4..06484330178 100644
> --- a/gcc/testsuite/lib/target-supports.exp
> +++ b/gcc/testsuite/lib/target-supports.exp
> @@ -6259,9 +6259,12 @@ proc check_effective_target_powerpc_sqrt { } {
>  }
> 
>  return [check_no_compiler_messages powerpc_sqrt object {
> + void test (void)
> + {
>   #ifndef _ARCH_PPCSQ
>   #error _ARCH_PPCSQ is not defined
>   #endif
> + }
>  } {}]
>  }
> 
> @@ -6369,71 +6372,92 @@ proc check_effective_target_powerpc_p9modulo_ok { } {
>  # as provided by the test.
>  proc check_effective_target_has_arch_pwr5 { } {
>   return [check_no_compiler_messages_nocache arch_pwr5 assembly {
> + void test (void)
> + {
>   #ifndef _ARCH_PWR5
>   #error does not have power5 support.
>   #else
>   /* "has power5 support" */
>   #endif
> + }
>   } [current_compiler_flags]]
>  }
> 
>  proc check_effective_target_has_arch_pwr6 { } {
>   return [check_no_compiler_messages_nocache arch_pwr6 assembly {
> + void test (void)
> + {
>   #ifndef _ARCH_PWR6
>   #error does not have power6 support.
>   #else
>   /* "has power6 support" */
>   #endif
> + }
>   } [current_compiler_flags]]
>  }
> 
>  proc check_effective_target_has_arch_pwr7 { } {
>   return [check_no_compiler_messages_nocache arch_pwr7 assembly {
> + void test (void)
> + {
>   #ifndef _ARCH_PWR7
>   #error does not have power7 support.
>   #else
>   /* "has power7 support" */
>   #endif
> + }
>   } [current_compiler_flags]]
>  }
> 
>  proc check_effective_target_has_arch_pwr8 { } {
>   return [check_no_compiler_messages_nocache arch_pwr8 assembly {
> + void test (void)
> + {
>   #ifndef _ARCH_PWR8
>   #error does not have power8 support.
>   #else
>   /* "has power8 support" */
>   #endif
> + }
>   } [current_compiler_flags]]
>  }
> 
>  proc check_effective_target_has_arch_pwr9 { } {
>   return [check_no_compiler_messages_nocache arch_pwr9 assembly {
> + void test (void)
> + {
>   #ifndef _ARCH_PWR9
>   #error does not have power9 support.
>   #else
>   /* "has power9 support" */
>   #endif
> + }
>   } [current_compiler_flags]]
>  }
> 
>  proc check_effective_target_has_arch_pwr10 { } {
>   return [check_no_compiler_messages_nocache arch_pwr10 assembly {
> +

Re: Extend fold_vec_perm to fold VEC_PERM_EXPR in VLA manner

[Prathamesh Kulkarni via Gcc-patches]

On Mon, 29 Aug 2022 at 11:38, Prathamesh Kulkarni
 wrote:
>
> On Wed, 17 Aug 2022 at 18:09, Prathamesh Kulkarni
>  wrote:
> >
> > Hi,
> > The attached prototype patch extends fold_vec_perm to fold VEC_PERM_EXPR
> > in VLA manner, and currently handles the following cases:
> > (a) fixed len arg0, arg1 and fixed len sel.
> > (b) fixed len arg0, arg1 and vla sel
> > (c) vla arg0, arg1 and vla sel with arg0, arg1 being VECTOR_CST.
> >
> > It seems to work for the VLA tests written in
> > test_vec_perm_vla_folding (), and am working thru the fallout observed in
> > regression testing.
> >
> > Does the approach taken in the patch look in the right direction ?
> > I am not sure if I have got the conversion from "sel_index"
> > to index of either arg0, or arg1 entirely correct.
> > I would be grateful for suggestions on the patch.
> ping https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599888.html
ping * 2 https://gcc.gnu.org/pipermail/gcc-patches/2022-August/599888.html

Thanks,
Prathamesh
>
> Thanks,
> Prathamesh
> >
> > Thanks,
> > Prathamesh

Re: ICE after folding svld1rq to vec_perm_expr duing forwprop

[Prathamesh Kulkarni via Gcc-patches]

On Mon, 29 Aug 2022 at 11:53, Prathamesh Kulkarni
 wrote:
>
> On Thu, 18 Aug 2022 at 18:20, Prathamesh Kulkarni
>  wrote:
> >
> > On Thu, 18 Aug 2022 at 18:14, Prathamesh Kulkarni
> >  wrote:
> > >
> > > On Wed, 17 Aug 2022 at 17:01, Richard Biener  
> > > wrote:
> > > >
> > > > On Tue, Aug 16, 2022 at 6:30 PM Richard Sandiford
> > > >  wrote:
> > > > >
> > > > > Prathamesh Kulkarni  writes:
> > > > > > On Tue, 9 Aug 2022 at 18:42, Richard Biener 
> > > > > >  wrote:
> > > > > >>
> > > > > >> On Tue, Aug 9, 2022 at 12:10 PM Prathamesh Kulkarni
> > > > > >>  wrote:
> > > > > >> >
> > > > > >> > On Mon, 8 Aug 2022 at 14:27, Richard Biener 
> > > > > >> >  w>> > >
> > > > > >> > >
> > > > > >> > >   /* If result vector has greater length than input vector,
> > > > > >> > > + then allow permuting two vectors as long as:
> > > > > >> > > + a) sel.nelts_per_pattern == 1
> > > > > >> > > + b) sel.npatterns == len of input vector.
> > > > > >> > > + The intent is to permute input vectors, and
> > > > > >> > > + dup the elements in resulting vector to target vector 
> > > > > >> > > length.  */
> > > > > >> > > +
> > > > > >> > > +  if (maybe_gt (TYPE_VECTOR_SUBPARTS (type),
> > > > > >> > > +   TYPE_VECTOR_SUBPARTS (TREE_TYPE (arg0
> > > > > >> > > +{
> > > > > >> > > +  nelts = sel.encoding ().npatterns ();
> > > > > >> > > +  if (sel.encoding ().nelts_per_pattern () != 1
> > > > > >> > > + || (!known_eq (nelts, TYPE_VECTOR_SUBPARTS 
> > > > > >> > > (TREE_TYPE (arg0)
> > > > > >> > > +   return NULL_TREE;
> > > > > >> > > +}
> > > > > >> > >
> > > > > >> > > so the only case you add is non-VLA to VLA and there
> > > > > >> > > explicitely only the case of a period that's same as the
> > > > > >> > > element count in the input vectors.
> > > > > >> > >
> > > > > >> > >
> > > > > >> > > @@ -2602,6 +2602,9 @@ dump_generic_node (pretty_printer *pp, 
> > > > > >> > > tree
> > > > > >> > > node, int spc, dump_flags_t flags,
> > > > > >> > > pp_space (pp);
> > > > > >> > >   }
> > > > > >> > >   }
> > > > > >> > > +   if (VECTOR_TYPE_P (TREE_TYPE (node))
> > > > > >> > > +   && !TYPE_VECTOR_SUBPARTS (TREE_TYPE 
> > > > > >> > > (node)).is_constant ())
> > > > > >> > > + pp_string (pp, ", ... ");
> > > > > >> > > pp_right_brace (pp);
> > > > > >> > >
> > > > > >> > > btw, I do wonder if VLA CONSTRUCTORs are a "thing"?  Are they?
> > > > > >> > Well, it got created for the following case after folding:
> > > > > >> > svint32_t f2(int a, int b, int c, int d)
> > > > > >> > {
> > > > > >> >   int32x4_t v = {a, b, c, d};
> > > > > >> >   return svld1rq_s32 (svptrue_b8 (), &v[0]);
> > > > > >> > }
> > > > > >> >
> > > > > >> > The svld1rq_s32 call gets folded to:
> > > > > >> > v = {a, b, c, d}
> > > > > >> > lhs = VEC_PERM_EXPR
> > > > > >> >
> > > > > >> > fold_vec_perm then folds the above VEC_PERM_EXPR to
> > > > > >> > VLA constructor, since elements in v (in_elts) are not constant, 
> > > > > >> > and
> > > > > >> > need_ctor is thus true:
> > > > > >> > lhs = {a, b, c, d, ...}
> > > > > >> > I added "..." to make it more explicit that it's a VLA 
> > > > > >> > constructor.
> > > > > >>
> > > > > >> But I doubt we do anything reasonable with such a beast?  Do we?
> > > > > >> I suppose it's like a vec_duplicate if you view it as V1TImode
> > > > > >> but do we actually make sure to do this duplication?
> > > > > > I am not sure. As mentioned above, the current code-gen for VLA
> > > > > > constructor looks pretty bad.
> > > > > > Should we avoid folding VLA constructors for now ?
> > > > >
> > > > > VLA constructors aren't really a thing.  At least, the only VLA vector
> > > > > you could represent with current CONSTRUCTOR nodes is a fixed-length
> > > > > sequence at the start of an otherwise zero vector.  I'm not sure
> > > > > we even use that though (perhaps we do and I've forgotten).
> > > > >
> > > > > > I guess these are 2 different issues:
> > > > > > (a) Resolving ICE with VEC_PERM_EXPR for above aarch64 tests.
> > > > > > (b) Extending fold_vec_perm to handle vectors with differing 
> > > > > > lengths.
> > > > > >
> > > > > > For (a), I think the issue with using:
> > > > > > res_type = gimple_assign_lhs (stmt)
> > > > > > in previous patch, was that op2's type will change to match 
> > > > > > tgt_units,
> > > > > > if we go thru
> > > > > > (code == VIEW_CONVERT_EXPR || code2 == VIEW_CONVERT_EXPR) branch,
> > > > > > and may thus not be same as len(lhs_type) anymore, and hit the 
> > > > > > assert
> > > > > > in fold_vec_perm.
> > > > > >
> > > > > > IIUC, for lhs = VEC_PERM_EXPR, we now have the
> > > > > > following semantics:
> > > > > > (1) Element types for lhs, rhs1 and rhs2 should be the same.
> > > > > > (2) len(lhs) == len(mask) and len(rhs1) == len(rhs2).
> > > > >
> > > > > Yeah.
> > > > >
> > > > > > The attached patch changes res_type from TREE_TYPE (arg0) to 
>

Re: [COMMITTED] Be even more conservative in intersection of NANs.

[Richard Biener via Gcc-patches]

On Mon, Sep 5, 2022 at 8:24 AM Aldy Hernandez via Gcc-patches
 wrote:
>
> Intersecting two ranges where one is a NAN is keeping the sign bit of
> the NAN range.  This is not correct as the sign bits may not match.
>
> I think the only time we're absolutely sure about the intersection of
> a NAN and something else, is when both are a NAN with exactly the same
> properties (sign bit).  If we're intersecting two NANs of differing
> sign, we can decide later whether that's undefined or just a NAN with
> no known sign.  For now I've done the latter.
>
> I'm still mentally working on intersections involving NANs, especially
> if we want to keep track of signbits.  For now, let's be extra careful
> and only do things we're absolutely sure about.
>
> Later we may want to fold the intersect of [NAN,NAN] and say [3,5]
> with the posibility of NAN, to a NAN, but I'm not 100% sure.

The intersection of [NAN, NAN] and [3, 5] is empty.  The intersection
of [NAN, NAN] and VARYING is [NAN, NAN].

Not sure why you think NAN is somehow special?  I suppose that
[NAN, NAN] is actually implemented as ][ U NAN (empty range
plus aside NaN bit)

Richard.

>  As I've
> said before, setting varying is always a safe choice, because it means
> we know nothing and ranger won't attempt to optimize anything.
>
> gcc/ChangeLog:
>
> * value-range.cc (early_nan_resolve): Remove.
> (frange::intersect): Handle NANs.
> ---
>  gcc/value-range.cc | 35 ---
>  1 file changed, 16 insertions(+), 19 deletions(-)
>
> diff --git a/gcc/value-range.cc b/gcc/value-range.cc
> index c9f42fe272c..9c561415971 100644
> --- a/gcc/value-range.cc
> +++ b/gcc/value-range.cc
> @@ -444,24 +444,6 @@ frange::normalize_kind ()
>return false;
>  }
>
> -// If both operands are definitely NAN, do nothing as they combine
> -// perfectly.  If OTOH, only one is a NAN, set R to VARYING as they
> -// can't be neither unioned nor intersected.  Return TRUE if we
> -// changed anything.
> -
> -static inline bool
> -early_nan_resolve (frange &r, const frange &other)
> -{
> -  gcc_checking_assert (r.get_nan ().yes_p () || other.get_nan ().yes_p ());
> -
> -  // There's nothing to do for both NANs.
> -  if (r.get_nan ().yes_p () == other.get_nan ().yes_p ())
> -return false;
> -  // ?? Perhaps the intersection of a NAN and anything is a NAN ??.
> -  r.set_varying (r.type ());
> -  return true;
> -}
> -
>  bool
>  frange::union_ (const vrange &v)
>  {
> @@ -532,8 +514,23 @@ frange::intersect (const vrange &v)
>*this = r;
>return true;
>  }
> +
> +  // If two NANs are not exactly the same, drop to an unknown NAN,
> +  // otherwise there's nothing to do.
> +  if (get_nan ().yes_p () && r.get_nan ().yes_p ())
> +{
> +  if (m_props == r.m_props)
> +   return false;
> +
> +  *this = frange_nan (m_type);
> +  return true;
> +}
> +  // ?? Perhaps the intersection of a NAN and anything is a NAN ??.
>if (get_nan ().yes_p () || r.get_nan ().yes_p ())
> -return early_nan_resolve (*this, r);
> +{
> +  set_varying (m_type);
> +  return true;
> +}
>
>bool changed = m_props.intersect (r.m_props);
>
> --
> 2.37.1
>

Re: [PATCH 1/3] STABS: remove -gstabs and -gxcoff functionality

[Richard Biener via Gcc-patches]

On Mon, Sep 5, 2022 at 9:59 AM Martin Liška  wrote:
>
> On 9/2/22 10:54, Richard Biener wrote:
> > On Fri, Sep 2, 2022 at 9:00 AM Martin Liška  wrote:
> >>
> >> On 9/1/22 13:18, Richard Biener wrote:
> >>> I presume WarnRemoved will diagnose use of -gstabs but not fail
> >>> compilation.  Will -gstabs then still enable -g (with the default debug
> >>> format)?
> >>
> >> No, it won't set -g option.
> >
> > That was the usual side-effect - I wonder if we want to emit extra
> > diagnostic when one of the obsolete options is given but -g is not
> > enabled in the end or whether we want to preserve the debug info
> > enablement effect?
>
> I would leave it for now and see if somebody would complain about
> the current behavior.
>
> >
> >>>
> >>> Please followup with a gcc-13/changes.html entry.
> >>
> >> Sure.
> >>
> >>>
> >>> I notice we have VMS_DEBUGGING_INFO left.  From a quick look
> >>> it is used by alpha*-dec-* (exclusively) and ia64-hp-*vms*  (maybe
> >>> also supports DWARF, it is ELF at least).  One of the goals of
> >>> non-DWARF removal was to get rid of debug hooks and instead allow
> >>> "free-form" early debug generation from the frontends.
> >>
> >> Can you please explain what you mean by the free-form and what's expected
> >> to do with the VMS_DEBUGGING_INFO macro?
> >
> > Well, VMS debugging would go, just like STABS.
>
> Can go now, or shall we deprecate it in GCC 13 first?

Let's ask VMS maintainers - what's the state of DWARF support in VMS?
Is there active use of alpha*-dec-* or ia64-hp-*vms*?

> > With "free-form" I mean
> > that frontend code could call into the dwarf2out API directly, creating
> > DWARF DIEs for language specific info (we probably want to export more
> > and/or nicer APIs for such use).
>
> Ok, so bypassing dwarf2_debug_hooks, right? I can leave it to you such API
> improvement. What do you think?

Sure, it shouldn't be part of this series.

Richard.

> Cheers,
> Martin
>
> >
> > Richard.
> >
> >> Cheers,
> >> Martin
>

Re: [COMMITTED] Be even more conservative in intersection of NANs.

[Jakub Jelinek via Gcc-patches]

On Mon, Sep 05, 2022 at 11:00:54AM +0200, Richard Biener wrote:
> On Mon, Sep 5, 2022 at 8:24 AM Aldy Hernandez via Gcc-patches
>  wrote:
> >
> > Intersecting two ranges where one is a NAN is keeping the sign bit of
> > the NAN range.  This is not correct as the sign bits may not match.
> >
> > I think the only time we're absolutely sure about the intersection of
> > a NAN and something else, is when both are a NAN with exactly the same
> > properties (sign bit).  If we're intersecting two NANs of differing
> > sign, we can decide later whether that's undefined or just a NAN with
> > no known sign.  For now I've done the latter.
> >
> > I'm still mentally working on intersections involving NANs, especially
> > if we want to keep track of signbits.  For now, let's be extra careful
> > and only do things we're absolutely sure about.
> >
> > Later we may want to fold the intersect of [NAN,NAN] and say [3,5]
> > with the posibility of NAN, to a NAN, but I'm not 100% sure.
> 
> The intersection of [NAN, NAN] and [3, 5] is empty.  The intersection
> of [NAN, NAN] and VARYING is [NAN, NAN].

I think [3.0, 5.0] printed that way currently means U maybe NAN,
it would be [3.0, 5.0] !NAN if it was known not to be NAN.

Jakub

Re: ICE after folding svld1rq to vec_perm_expr duing forwprop

[Richard Biener via Gcc-patches]

On Mon, Sep 5, 2022 at 10:54 AM Prathamesh Kulkarni
 wrote:
>
> On Mon, 29 Aug 2022 at 11:53, Prathamesh Kulkarni
>  wrote:
> >
> > On Thu, 18 Aug 2022 at 18:20, Prathamesh Kulkarni
> >  wrote:
> > >
> > > On Thu, 18 Aug 2022 at 18:14, Prathamesh Kulkarni
> > >  wrote:
> > > >
> > > > On Wed, 17 Aug 2022 at 17:01, Richard Biener 
> > > >  wrote:
> > > > >
> > > > > On Tue, Aug 16, 2022 at 6:30 PM Richard Sandiford
> > > > >  wrote:
> > > > > >
> > > > > > Prathamesh Kulkarni  writes:
> > > > > > > On Tue, 9 Aug 2022 at 18:42, Richard Biener 
> > > > > > >  wrote:
> > > > > > >>
> > > > > > >> On Tue, Aug 9, 2022 at 12:10 PM Prathamesh Kulkarni
> > > > > > >>  wrote:
> > > > > > >> >
> > > > > > >> > On Mon, 8 Aug 2022 at 14:27, Richard Biener 
> > > > > > >> >  w>> > >
> > > > > > >> > >
> > > > > > >> > >   /* If result vector has greater length than input vector,
> > > > > > >> > > + then allow permuting two vectors as long as:
> > > > > > >> > > + a) sel.nelts_per_pattern == 1
> > > > > > >> > > + b) sel.npatterns == len of input vector.
> > > > > > >> > > + The intent is to permute input vectors, and
> > > > > > >> > > + dup the elements in resulting vector to target vector 
> > > > > > >> > > length.  */
> > > > > > >> > > +
> > > > > > >> > > +  if (maybe_gt (TYPE_VECTOR_SUBPARTS (type),
> > > > > > >> > > +   TYPE_VECTOR_SUBPARTS (TREE_TYPE (arg0
> > > > > > >> > > +{
> > > > > > >> > > +  nelts = sel.encoding ().npatterns ();
> > > > > > >> > > +  if (sel.encoding ().nelts_per_pattern () != 1
> > > > > > >> > > + || (!known_eq (nelts, TYPE_VECTOR_SUBPARTS 
> > > > > > >> > > (TREE_TYPE (arg0)
> > > > > > >> > > +   return NULL_TREE;
> > > > > > >> > > +}
> > > > > > >> > >
> > > > > > >> > > so the only case you add is non-VLA to VLA and there
> > > > > > >> > > explicitely only the case of a period that's same as the
> > > > > > >> > > element count in the input vectors.
> > > > > > >> > >
> > > > > > >> > >
> > > > > > >> > > @@ -2602,6 +2602,9 @@ dump_generic_node (pretty_printer *pp, 
> > > > > > >> > > tree
> > > > > > >> > > node, int spc, dump_flags_t flags,
> > > > > > >> > > pp_space (pp);
> > > > > > >> > >   }
> > > > > > >> > >   }
> > > > > > >> > > +   if (VECTOR_TYPE_P (TREE_TYPE (node))
> > > > > > >> > > +   && !TYPE_VECTOR_SUBPARTS (TREE_TYPE 
> > > > > > >> > > (node)).is_constant ())
> > > > > > >> > > + pp_string (pp, ", ... ");
> > > > > > >> > > pp_right_brace (pp);
> > > > > > >> > >
> > > > > > >> > > btw, I do wonder if VLA CONSTRUCTORs are a "thing"?  Are 
> > > > > > >> > > they?
> > > > > > >> > Well, it got created for the following case after folding:
> > > > > > >> > svint32_t f2(int a, int b, int c, int d)
> > > > > > >> > {
> > > > > > >> >   int32x4_t v = {a, b, c, d};
> > > > > > >> >   return svld1rq_s32 (svptrue_b8 (), &v[0]);
> > > > > > >> > }
> > > > > > >> >
> > > > > > >> > The svld1rq_s32 call gets folded to:
> > > > > > >> > v = {a, b, c, d}
> > > > > > >> > lhs = VEC_PERM_EXPR
> > > > > > >> >
> > > > > > >> > fold_vec_perm then folds the above VEC_PERM_EXPR to
> > > > > > >> > VLA constructor, since elements in v (in_elts) are not 
> > > > > > >> > constant, and
> > > > > > >> > need_ctor is thus true:
> > > > > > >> > lhs = {a, b, c, d, ...}
> > > > > > >> > I added "..." to make it more explicit that it's a VLA 
> > > > > > >> > constructor.
> > > > > > >>
> > > > > > >> But I doubt we do anything reasonable with such a beast?  Do we?
> > > > > > >> I suppose it's like a vec_duplicate if you view it as V1TImode
> > > > > > >> but do we actually make sure to do this duplication?
> > > > > > > I am not sure. As mentioned above, the current code-gen for VLA
> > > > > > > constructor looks pretty bad.
> > > > > > > Should we avoid folding VLA constructors for now ?
> > > > > >
> > > > > > VLA constructors aren't really a thing.  At least, the only VLA 
> > > > > > vector
> > > > > > you could represent with current CONSTRUCTOR nodes is a fixed-length
> > > > > > sequence at the start of an otherwise zero vector.  I'm not sure
> > > > > > we even use that though (perhaps we do and I've forgotten).
> > > > > >
> > > > > > > I guess these are 2 different issues:
> > > > > > > (a) Resolving ICE with VEC_PERM_EXPR for above aarch64 tests.
> > > > > > > (b) Extending fold_vec_perm to handle vectors with differing 
> > > > > > > lengths.
> > > > > > >
> > > > > > > For (a), I think the issue with using:
> > > > > > > res_type = gimple_assign_lhs (stmt)
> > > > > > > in previous patch, was that op2's type will change to match 
> > > > > > > tgt_units,
> > > > > > > if we go thru
> > > > > > > (code == VIEW_CONVERT_EXPR || code2 == VIEW_CONVERT_EXPR) branch,
> > > > > > > and may thus not be same as len(lhs_type) anymore, and hit the 
> > > > > > > assert
> > > > > > > in fold_vec_perm.
> > > > > > >
> > > > > > > IIUC, for lhs = VEC

Re: [COMMITTED] Be even more conservative in intersection of NANs.

[Aldy Hernandez via Gcc-patches]

On Mon, Sep 5, 2022 at 11:06 AM Jakub Jelinek  wrote:
>
> On Mon, Sep 05, 2022 at 11:00:54AM +0200, Richard Biener wrote:
> > On Mon, Sep 5, 2022 at 8:24 AM Aldy Hernandez via Gcc-patches
> >  wrote:
> > >
> > > Intersecting two ranges where one is a NAN is keeping the sign bit of
> > > the NAN range.  This is not correct as the sign bits may not match.
> > >
> > > I think the only time we're absolutely sure about the intersection of
> > > a NAN and something else, is when both are a NAN with exactly the same
> > > properties (sign bit).  If we're intersecting two NANs of differing
> > > sign, we can decide later whether that's undefined or just a NAN with
> > > no known sign.  For now I've done the latter.
> > >
> > > I'm still mentally working on intersections involving NANs, especially
> > > if we want to keep track of signbits.  For now, let's be extra careful
> > > and only do things we're absolutely sure about.
> > >
> > > Later we may want to fold the intersect of [NAN,NAN] and say [3,5]
> > > with the posibility of NAN, to a NAN, but I'm not 100% sure.
> >
> > The intersection of [NAN, NAN] and [3, 5] is empty.  The intersection
> > of [NAN, NAN] and VARYING is [NAN, NAN].
>
> I think [3.0, 5.0] printed that way currently means U maybe NAN,
> it would be [3.0, 5.0] !NAN if it was known not to be NAN.

Right.  I don't print any of the "maybe" properties, just if they're
definitely set or definitely clear.  I'm open to suggestions as to how
to display them.  Perhaps NAN, !NAN, ?NAN.

I'm mostly worried about removing a NAN from the IL that was going to
signal, or some such.  While I agree with you Richard, I just want to
make real sure, because getting something wrong in the frange or
range-ops bowels means the problem becomes pervasive to all of ranger
...and threader...and loop ch...and vrp, etc etc.  I just want to take
more time to test things.  I promise it won't stay varying too long.

Aldy

Re: [COMMITTED] Be even more conservative in intersection of NANs.

[Richard Biener via Gcc-patches]

On Mon, Sep 5, 2022 at 11:06 AM Jakub Jelinek  wrote:
>
> On Mon, Sep 05, 2022 at 11:00:54AM +0200, Richard Biener wrote:
> > On Mon, Sep 5, 2022 at 8:24 AM Aldy Hernandez via Gcc-patches
> >  wrote:
> > >
> > > Intersecting two ranges where one is a NAN is keeping the sign bit of
> > > the NAN range.  This is not correct as the sign bits may not match.
> > >
> > > I think the only time we're absolutely sure about the intersection of
> > > a NAN and something else, is when both are a NAN with exactly the same
> > > properties (sign bit).  If we're intersecting two NANs of differing
> > > sign, we can decide later whether that's undefined or just a NAN with
> > > no known sign.  For now I've done the latter.
> > >
> > > I'm still mentally working on intersections involving NANs, especially
> > > if we want to keep track of signbits.  For now, let's be extra careful
> > > and only do things we're absolutely sure about.
> > >
> > > Later we may want to fold the intersect of [NAN,NAN] and say [3,5]
> > > with the posibility of NAN, to a NAN, but I'm not 100% sure.
> >
> > The intersection of [NAN, NAN] and [3, 5] is empty.  The intersection
> > of [NAN, NAN] and VARYING is [NAN, NAN].
>
> I think [3.0, 5.0] printed that way currently means U maybe NAN,
> it would be [3.0, 5.0] !NAN if it was known not to be NAN.

Uh, that's confusing.  So [3, 5] U maybe NAN intersected with
][ NAN is ][ NAN.  [3, 5] !NAN intersected with ][ NAN is ][ !NAN.

In fact [3, 5] U maybe NAN is just [3, 5] U NAN, there's no "maybe" ranges,
if the value may be NAN then NAN is in the value-range.  So it's either
[3, 5] U NAN or [3, 5] (without U NAN).

Richard.

>
> Jakub
>

Re: [COMMITTED] Be even more conservative in intersection of NANs.

[Richard Biener via Gcc-patches]

On Mon, Sep 5, 2022 at 11:12 AM Aldy Hernandez  wrote:
>
> On Mon, Sep 5, 2022 at 11:06 AM Jakub Jelinek  wrote:
> >
> > On Mon, Sep 05, 2022 at 11:00:54AM +0200, Richard Biener wrote:
> > > On Mon, Sep 5, 2022 at 8:24 AM Aldy Hernandez via Gcc-patches
> > >  wrote:
> > > >
> > > > Intersecting two ranges where one is a NAN is keeping the sign bit of
> > > > the NAN range.  This is not correct as the sign bits may not match.
> > > >
> > > > I think the only time we're absolutely sure about the intersection of
> > > > a NAN and something else, is when both are a NAN with exactly the same
> > > > properties (sign bit).  If we're intersecting two NANs of differing
> > > > sign, we can decide later whether that's undefined or just a NAN with
> > > > no known sign.  For now I've done the latter.
> > > >
> > > > I'm still mentally working on intersections involving NANs, especially
> > > > if we want to keep track of signbits.  For now, let's be extra careful
> > > > and only do things we're absolutely sure about.
> > > >
> > > > Later we may want to fold the intersect of [NAN,NAN] and say [3,5]
> > > > with the posibility of NAN, to a NAN, but I'm not 100% sure.
> > >
> > > The intersection of [NAN, NAN] and [3, 5] is empty.  The intersection
> > > of [NAN, NAN] and VARYING is [NAN, NAN].
> >
> > I think [3.0, 5.0] printed that way currently means U maybe NAN,
> > it would be [3.0, 5.0] !NAN if it was known not to be NAN.
>
> Right.  I don't print any of the "maybe" properties, just if they're
> definitely set or definitely clear.  I'm open to suggestions as to how
> to display them.  Perhaps NAN, !NAN, ?NAN.

There's no NAN tristate.  Your "definitely NAN" would be simply
][ NAN, that is, the value range only contains NAN.  Your !NAN
is  and non NAN.  Likewise for the sign, the
range either includes -NAN and NAN or one or none of those.
For signed zeros you either have [-0, upper-bound] or [0, upper-bound]
where it either includes both -0 and 0 or just one of them

> I'm mostly worried about removing a NAN from the IL that was going to
> signal, or some such.  While I agree with you Richard, I just want to
> make real sure, because getting something wrong in the frange or
> range-ops bowels means the problem becomes pervasive to all of ranger
> ...and threader...and loop ch...and vrp, etc etc.  I just want to take
> more time to test things.  I promise it won't stay varying too long.

There's sNANs and qNANs, but I think for value-ranges we should
concern ourselves only with qNANs for now and leave sNANs VARYING.
All operations only ever produce qNANs (loads can produce sNANs).

Richard.

> Aldy
>

Re: [PATCH] rs6000: Use NO_EXPR to cast to MMA pointer types

[Richard Biener via Gcc-patches]

On Fri, Sep 2, 2022 at 7:24 PM Segher Boessenkool
 wrote:
>
> On Fri, Sep 02, 2022 at 12:02:54PM -0500, Peter Bergner wrote:
> > On 9/2/22 11:31 AM, Segher Boessenkool wrote:
> > > (Did you also look at non-MMA VIEW_CONVERT_EXPR uses btw?)
> >
> > I did.  It seemed they were all related to pointers to vectors and I 
> > remember
> > you mentioning that as one of the reasons for using VIEW_CONVERT_EXPR over
> > NOP_EXPR, so I left them alone to be safe.
>
> Huh?  I have no idea what you mean here.
>
> Casting from one pointer type to another never needs it.  Casting from a
> scalar integer type to a pointer type not either AFAIKi.  But I am not a
> Gimple expert, all this might be wrong, it isn't documented anywbere :-(

NOP_EXPR is for conversions between types with the same kind
(and pointer-to-integer and integer-to-pointer
conversions when pointer and integer are of the same size).
When used on vectors it converts the vector elements.  When you want to
re-interpret V4SI as V4SF you need VIEW_CONVERT_EXPR (bit_cast),
likewise V4SI interpreted as V16QI needs that.

Think of VIEW_CONVERT as bit_cast and NOP_EXPR as conversion.
Of course for some conversions (like unsigned int to int) you can also
use a VIEW_CONVERT since it's semantically the same.  In those cases
we canonicalize to NOP_EXPR via folding.

Richard.

>
>
> Segher

Re: ICE after folding svld1rq to vec_perm_expr duing forwprop

[Prathamesh Kulkarni via Gcc-patches]

On Mon, 5 Sept 2022 at 14:39, Richard Biener  wrote:
>
> On Mon, Sep 5, 2022 at 10:54 AM Prathamesh Kulkarni
>  wrote:
> >
> > On Mon, 29 Aug 2022 at 11:53, Prathamesh Kulkarni
> >  wrote:
> > >
> > > On Thu, 18 Aug 2022 at 18:20, Prathamesh Kulkarni
> > >  wrote:
> > > >
> > > > On Thu, 18 Aug 2022 at 18:14, Prathamesh Kulkarni
> > > >  wrote:
> > > > >
> > > > > On Wed, 17 Aug 2022 at 17:01, Richard Biener 
> > > > >  wrote:
> > > > > >
> > > > > > On Tue, Aug 16, 2022 at 6:30 PM Richard Sandiford
> > > > > >  wrote:
> > > > > > >
> > > > > > > Prathamesh Kulkarni  writes:
> > > > > > > > On Tue, 9 Aug 2022 at 18:42, Richard Biener 
> > > > > > > >  wrote:
> > > > > > > >>
> > > > > > > >> On Tue, Aug 9, 2022 at 12:10 PM Prathamesh Kulkarni
> > > > > > > >>  wrote:
> > > > > > > >> >
> > > > > > > >> > On Mon, 8 Aug 2022 at 14:27, Richard Biener 
> > > > > > > >> >  w>> > >
> > > > > > > >> > >
> > > > > > > >> > >   /* If result vector has greater length than input vector,
> > > > > > > >> > > + then allow permuting two vectors as long as:
> > > > > > > >> > > + a) sel.nelts_per_pattern == 1
> > > > > > > >> > > + b) sel.npatterns == len of input vector.
> > > > > > > >> > > + The intent is to permute input vectors, and
> > > > > > > >> > > + dup the elements in resulting vector to target 
> > > > > > > >> > > vector length.  */
> > > > > > > >> > > +
> > > > > > > >> > > +  if (maybe_gt (TYPE_VECTOR_SUBPARTS (type),
> > > > > > > >> > > +   TYPE_VECTOR_SUBPARTS (TREE_TYPE (arg0
> > > > > > > >> > > +{
> > > > > > > >> > > +  nelts = sel.encoding ().npatterns ();
> > > > > > > >> > > +  if (sel.encoding ().nelts_per_pattern () != 1
> > > > > > > >> > > + || (!known_eq (nelts, TYPE_VECTOR_SUBPARTS 
> > > > > > > >> > > (TREE_TYPE (arg0)
> > > > > > > >> > > +   return NULL_TREE;
> > > > > > > >> > > +}
> > > > > > > >> > >
> > > > > > > >> > > so the only case you add is non-VLA to VLA and there
> > > > > > > >> > > explicitely only the case of a period that's same as the
> > > > > > > >> > > element count in the input vectors.
> > > > > > > >> > >
> > > > > > > >> > >
> > > > > > > >> > > @@ -2602,6 +2602,9 @@ dump_generic_node (pretty_printer 
> > > > > > > >> > > *pp, tree
> > > > > > > >> > > node, int spc, dump_flags_t flags,
> > > > > > > >> > > pp_space (pp);
> > > > > > > >> > >   }
> > > > > > > >> > >   }
> > > > > > > >> > > +   if (VECTOR_TYPE_P (TREE_TYPE (node))
> > > > > > > >> > > +   && !TYPE_VECTOR_SUBPARTS (TREE_TYPE 
> > > > > > > >> > > (node)).is_constant ())
> > > > > > > >> > > + pp_string (pp, ", ... ");
> > > > > > > >> > > pp_right_brace (pp);
> > > > > > > >> > >
> > > > > > > >> > > btw, I do wonder if VLA CONSTRUCTORs are a "thing"?  Are 
> > > > > > > >> > > they?
> > > > > > > >> > Well, it got created for the following case after folding:
> > > > > > > >> > svint32_t f2(int a, int b, int c, int d)
> > > > > > > >> > {
> > > > > > > >> >   int32x4_t v = {a, b, c, d};
> > > > > > > >> >   return svld1rq_s32 (svptrue_b8 (), &v[0]);
> > > > > > > >> > }
> > > > > > > >> >
> > > > > > > >> > The svld1rq_s32 call gets folded to:
> > > > > > > >> > v = {a, b, c, d}
> > > > > > > >> > lhs = VEC_PERM_EXPR
> > > > > > > >> >
> > > > > > > >> > fold_vec_perm then folds the above VEC_PERM_EXPR to
> > > > > > > >> > VLA constructor, since elements in v (in_elts) are not 
> > > > > > > >> > constant, and
> > > > > > > >> > need_ctor is thus true:
> > > > > > > >> > lhs = {a, b, c, d, ...}
> > > > > > > >> > I added "..." to make it more explicit that it's a VLA 
> > > > > > > >> > constructor.
> > > > > > > >>
> > > > > > > >> But I doubt we do anything reasonable with such a beast?  Do 
> > > > > > > >> we?
> > > > > > > >> I suppose it's like a vec_duplicate if you view it as V1TImode
> > > > > > > >> but do we actually make sure to do this duplication?
> > > > > > > > I am not sure. As mentioned above, the current code-gen for VLA
> > > > > > > > constructor looks pretty bad.
> > > > > > > > Should we avoid folding VLA constructors for now ?
> > > > > > >
> > > > > > > VLA constructors aren't really a thing.  At least, the only VLA 
> > > > > > > vector
> > > > > > > you could represent with current CONSTRUCTOR nodes is a 
> > > > > > > fixed-length
> > > > > > > sequence at the start of an otherwise zero vector.  I'm not sure
> > > > > > > we even use that though (perhaps we do and I've forgotten).
> > > > > > >
> > > > > > > > I guess these are 2 different issues:
> > > > > > > > (a) Resolving ICE with VEC_PERM_EXPR for above aarch64 tests.
> > > > > > > > (b) Extending fold_vec_perm to handle vectors with differing 
> > > > > > > > lengths.
> > > > > > > >
> > > > > > > > For (a), I think the issue with using:
> > > > > > > > res_type = gimple_assign_lhs (stmt)
> > > > > > > > in previous patch, was that op2's type will change to match 
> > > > > > >

Re: [COMMITTED] Be even more conservative in intersection of NANs.

[Aldy Hernandez via Gcc-patches]

On Mon, Sep 5, 2022 at 11:14 AM Richard Biener
 wrote:
>
> On Mon, Sep 5, 2022 at 11:06 AM Jakub Jelinek  wrote:
> >
> > On Mon, Sep 05, 2022 at 11:00:54AM +0200, Richard Biener wrote:
> > > On Mon, Sep 5, 2022 at 8:24 AM Aldy Hernandez via Gcc-patches
> > >  wrote:
> > > >
> > > > Intersecting two ranges where one is a NAN is keeping the sign bit of
> > > > the NAN range.  This is not correct as the sign bits may not match.
> > > >
> > > > I think the only time we're absolutely sure about the intersection of
> > > > a NAN and something else, is when both are a NAN with exactly the same
> > > > properties (sign bit).  If we're intersecting two NANs of differing
> > > > sign, we can decide later whether that's undefined or just a NAN with
> > > > no known sign.  For now I've done the latter.
> > > >
> > > > I'm still mentally working on intersections involving NANs, especially
> > > > if we want to keep track of signbits.  For now, let's be extra careful
> > > > and only do things we're absolutely sure about.
> > > >
> > > > Later we may want to fold the intersect of [NAN,NAN] and say [3,5]
> > > > with the posibility of NAN, to a NAN, but I'm not 100% sure.
> > >
> > > The intersection of [NAN, NAN] and [3, 5] is empty.  The intersection
> > > of [NAN, NAN] and VARYING is [NAN, NAN].
> >
> > I think [3.0, 5.0] printed that way currently means U maybe NAN,
> > it would be [3.0, 5.0] !NAN if it was known not to be NAN.
>
> Uh, that's confusing.  So [3, 5] U maybe NAN intersected with
> ][ NAN is ][ NAN.  [3, 5] !NAN intersected with ][ NAN is ][ !NAN.

I'm confused.  What's ][ ??.

For clarity in the discussion, let's say ?NAN, NAN, and !NAN for the
NAN property.

I would expect:
[3,5] ?NAN U NAN = [3,5] ?NAN
[3,5] !NAN U NAN = [3,5] ?NAN
[3,5] !NAN ^ NAN = []
NAN !SIGN ^ NAN SIGN = [] (differing signs)
[3,5] ?NAN ^ NAN = NAN
[3,5] !NAN ^ NAN = []

Also, definite NANs must have a real_nan() on both sides of the
endpoints.  They must be the same.  And that real_nan() could have a
sign bit.  So we could have:
  [NAN, NAN] ?SIGN  (sign unknown-- default)
  [NAN, NAN] SIGN (negative NAN)
  [NAN, NAN] !SIGN (positive NAN)

The above is enforced by the setter and verify_range.

Note, that setting the definite NAN property (fp_prop::YES) to a
range, makes it a NAN.  That is, we will forcibly change the range to
[NAN, NAN].  There's also an assert making sure you're not setting
!NAN on a [NAN, NAN].

A varying has all the property bits set to unknown.  So effectively
?NAN and ?SIGN.

Do you agree?

Aldy

>
> In fact [3, 5] U maybe NAN is just [3, 5] U NAN, there's no "maybe" ranges,
> if the value may be NAN then NAN is in the value-range.  So it's either
> [3, 5] U NAN or [3, 5] (without U NAN).
>
> Richard.
>
> >
> > Jakub
> >
>

Re: [COMMITTED] Be even more conservative in intersection of NANs.

[Richard Biener via Gcc-patches]

On Mon, Sep 5, 2022 at 11:28 AM Aldy Hernandez  wrote:
>
> On Mon, Sep 5, 2022 at 11:14 AM Richard Biener
>  wrote:
> >
> > On Mon, Sep 5, 2022 at 11:06 AM Jakub Jelinek  wrote:
> > >
> > > On Mon, Sep 05, 2022 at 11:00:54AM +0200, Richard Biener wrote:
> > > > On Mon, Sep 5, 2022 at 8:24 AM Aldy Hernandez via Gcc-patches
> > > >  wrote:
> > > > >
> > > > > Intersecting two ranges where one is a NAN is keeping the sign bit of
> > > > > the NAN range.  This is not correct as the sign bits may not match.
> > > > >
> > > > > I think the only time we're absolutely sure about the intersection of
> > > > > a NAN and something else, is when both are a NAN with exactly the same
> > > > > properties (sign bit).  If we're intersecting two NANs of differing
> > > > > sign, we can decide later whether that's undefined or just a NAN with
> > > > > no known sign.  For now I've done the latter.
> > > > >
> > > > > I'm still mentally working on intersections involving NANs, especially
> > > > > if we want to keep track of signbits.  For now, let's be extra careful
> > > > > and only do things we're absolutely sure about.
> > > > >
> > > > > Later we may want to fold the intersect of [NAN,NAN] and say [3,5]
> > > > > with the posibility of NAN, to a NAN, but I'm not 100% sure.
> > > >
> > > > The intersection of [NAN, NAN] and [3, 5] is empty.  The intersection
> > > > of [NAN, NAN] and VARYING is [NAN, NAN].
> > >
> > > I think [3.0, 5.0] printed that way currently means U maybe NAN,
> > > it would be [3.0, 5.0] !NAN if it was known not to be NAN.
> >
> > Uh, that's confusing.  So [3, 5] U maybe NAN intersected with
> > ][ NAN is ][ NAN.  [3, 5] !NAN intersected with ][ NAN is ][ !NAN.
>
> I'm confused.  What's ][ ??.

It's the empty range.

> For clarity in the discussion, let's say ?NAN, NAN, and !NAN for the
> NAN property.
>
> I would expect:
> [3,5] ?NAN U NAN = [3,5] ?NAN
> [3,5] !NAN U NAN = [3,5] ?NAN
> [3,5] !NAN ^ NAN = []
> NAN !SIGN ^ NAN SIGN = [] (differing signs)
> [3,5] ?NAN ^ NAN = NAN
> [3,5] !NAN ^ NAN = []
>
> Also, definite NANs must have a real_nan() on both sides of the
> endpoints.  They must be the same.  And that real_nan() could have a
> sign bit.  So we could have:
>   [NAN, NAN] ?SIGN  (sign unknown-- default)
>   [NAN, NAN] SIGN (negative NAN)
>   [NAN, NAN] !SIGN (positive NAN)
>
> The above is enforced by the setter and verify_range.

I think having NAN in the endpoints is confusing since NANs
do not behave with ordered compares.  That is, [-NAN, +NAN]
would not make sense.  A value-range of either -INF or +INFs
would be a two element [-INF, -INF] U [+INF, +INF] range.

So a definite NAN should IMHO be ][ (empty range of non-NAN
values) U NAN.  And if there's a negative and a positive NAN
then we probably should simply have two NAN flags, +NAN and
-NAN.  I'm not sure how tracking the sign bit separately is
useful.  "sign bit set" is simply [-INF, -0] U -NAN (if the value
could be a NAN)?

> Note, that setting the definite NAN property (fp_prop::YES) to a
> range, makes it a NAN.  That is, we will forcibly change the range to
> [NAN, NAN].  There's also an assert making sure you're not setting
> !NAN on a [NAN, NAN].
>
> A varying has all the property bits set to unknown.  So effectively
> ?NAN and ?SIGN.
>
> Do you agree?

No, I'm very confused about having [3, 5] ?NAN, [3, 5] NAN and [3, 5] !NAN.

Richard.

> Aldy
>
> >
> > In fact [3, 5] U maybe NAN is just [3, 5] U NAN, there's no "maybe" ranges,
> > if the value may be NAN then NAN is in the value-range.  So it's either
> > [3, 5] U NAN or [3, 5] (without U NAN).
> >
> > Richard.
> >
> > >
> > > Jakub
> > >
> >
>

Re: [COMMITTED] Be even more conservative in intersection of NANs.

[Aldy Hernandez via Gcc-patches]

On Mon, Sep 5, 2022 at 11:18 AM Richard Biener
 wrote:
>
> On Mon, Sep 5, 2022 at 11:12 AM Aldy Hernandez  wrote:
> >
> > On Mon, Sep 5, 2022 at 11:06 AM Jakub Jelinek  wrote:
> > >
> > > On Mon, Sep 05, 2022 at 11:00:54AM +0200, Richard Biener wrote:
> > > > On Mon, Sep 5, 2022 at 8:24 AM Aldy Hernandez via Gcc-patches
> > > >  wrote:
> > > > >
> > > > > Intersecting two ranges where one is a NAN is keeping the sign bit of
> > > > > the NAN range.  This is not correct as the sign bits may not match.
> > > > >
> > > > > I think the only time we're absolutely sure about the intersection of
> > > > > a NAN and something else, is when both are a NAN with exactly the same
> > > > > properties (sign bit).  If we're intersecting two NANs of differing
> > > > > sign, we can decide later whether that's undefined or just a NAN with
> > > > > no known sign.  For now I've done the latter.
> > > > >
> > > > > I'm still mentally working on intersections involving NANs, especially
> > > > > if we want to keep track of signbits.  For now, let's be extra careful
> > > > > and only do things we're absolutely sure about.
> > > > >
> > > > > Later we may want to fold the intersect of [NAN,NAN] and say [3,5]
> > > > > with the posibility of NAN, to a NAN, but I'm not 100% sure.
> > > >
> > > > The intersection of [NAN, NAN] and [3, 5] is empty.  The intersection
> > > > of [NAN, NAN] and VARYING is [NAN, NAN].
> > >
> > > I think [3.0, 5.0] printed that way currently means U maybe NAN,
> > > it would be [3.0, 5.0] !NAN if it was known not to be NAN.
> >
> > Right.  I don't print any of the "maybe" properties, just if they're
> > definitely set or definitely clear.  I'm open to suggestions as to how
> > to display them.  Perhaps NAN, !NAN, ?NAN.
>
> There's no NAN tristate.  Your "definitely NAN" would be simply
> ][ NAN, that is, the value range only contains NAN.  Your !NAN
> is  and non NAN.  Likewise for the sign, the
> range either includes -NAN and NAN or one or none of those.
> For signed zeros you either have [-0, upper-bound] or [0, upper-bound]
> where it either includes both -0 and 0 or just one of them

But there is a tristate.  We may definitely have a NAN, definitely not
have a NAN, or the state of the NAN is unknown.  Say [3,5] ?NAN.
That's [3,5] with the possibility of a NAN.  On the true side of x >=
5.0, we'd have [5.0, INF] !NAN.  On the false side we'd have [-INF,
5.0] ?NAN.

With this representation we can fold __builtin_isnan() even on an
unknown value... say on the true side of x == y we know that both x
and y cannot be NANs...but on the false side we know nothing so there
is the possibility of a NAN.

I do like your idea for signed zeros.  I think I could make it work
and get rid of the sign bit.

Aldy

>
> > I'm mostly worried about removing a NAN from the IL that was going to
> > signal, or some such.  While I agree with you Richard, I just want to
> > make real sure, because getting something wrong in the frange or
> > range-ops bowels means the problem becomes pervasive to all of ranger
> > ...and threader...and loop ch...and vrp, etc etc.  I just want to take
> > more time to test things.  I promise it won't stay varying too long.
>
> There's sNANs and qNANs, but I think for value-ranges we should
> concern ourselves only with qNANs for now and leave sNANs VARYING.
> All operations only ever produce qNANs (loads can produce sNANs).
>
> Richard.
>
> > Aldy
> >
>

Re: [COMMITTED] Be even more conservative in intersection of NANs.

[Richard Biener via Gcc-patches]

On Mon, Sep 5, 2022 at 11:41 AM Aldy Hernandez  wrote:
>
> On Mon, Sep 5, 2022 at 11:18 AM Richard Biener
>  wrote:
> >
> > On Mon, Sep 5, 2022 at 11:12 AM Aldy Hernandez  wrote:
> > >
> > > On Mon, Sep 5, 2022 at 11:06 AM Jakub Jelinek  wrote:
> > > >
> > > > On Mon, Sep 05, 2022 at 11:00:54AM +0200, Richard Biener wrote:
> > > > > On Mon, Sep 5, 2022 at 8:24 AM Aldy Hernandez via Gcc-patches
> > > > >  wrote:
> > > > > >
> > > > > > Intersecting two ranges where one is a NAN is keeping the sign bit 
> > > > > > of
> > > > > > the NAN range.  This is not correct as the sign bits may not match.
> > > > > >
> > > > > > I think the only time we're absolutely sure about the intersection 
> > > > > > of
> > > > > > a NAN and something else, is when both are a NAN with exactly the 
> > > > > > same
> > > > > > properties (sign bit).  If we're intersecting two NANs of differing
> > > > > > sign, we can decide later whether that's undefined or just a NAN 
> > > > > > with
> > > > > > no known sign.  For now I've done the latter.
> > > > > >
> > > > > > I'm still mentally working on intersections involving NANs, 
> > > > > > especially
> > > > > > if we want to keep track of signbits.  For now, let's be extra 
> > > > > > careful
> > > > > > and only do things we're absolutely sure about.
> > > > > >
> > > > > > Later we may want to fold the intersect of [NAN,NAN] and say [3,5]
> > > > > > with the posibility of NAN, to a NAN, but I'm not 100% sure.
> > > > >
> > > > > The intersection of [NAN, NAN] and [3, 5] is empty.  The intersection
> > > > > of [NAN, NAN] and VARYING is [NAN, NAN].
> > > >
> > > > I think [3.0, 5.0] printed that way currently means U maybe NAN,
> > > > it would be [3.0, 5.0] !NAN if it was known not to be NAN.
> > >
> > > Right.  I don't print any of the "maybe" properties, just if they're
> > > definitely set or definitely clear.  I'm open to suggestions as to how
> > > to display them.  Perhaps NAN, !NAN, ?NAN.
> >
> > There's no NAN tristate.  Your "definitely NAN" would be simply
> > ][ NAN, that is, the value range only contains NAN.  Your !NAN
> > is  and non NAN.  Likewise for the sign, the
> > range either includes -NAN and NAN or one or none of those.
> > For signed zeros you either have [-0, upper-bound] or [0, upper-bound]
> > where it either includes both -0 and 0 or just one of them
>
> But there is a tristate.  We may definitely have a NAN, definitely not
> have a NAN, or the state of the NAN is unknown.

Sure.  But we are talking about sets of values a variable can have
(a value "range" where "range" is a bit misleading for something
like a NAN).  The set of possible values either includes
NAN (or -NAN and +NAN) or it doesn't include NAN (or -NAN and +NAN).
A set cannot include or not include a "maybe NAN".

>  Say [3,5] ?NAN.
> That's [3,5] with the possibility of a NAN.  On the true side of x >=
> 5.0, we'd have [5.0, INF] !NAN.  On the false side we'd have [-INF,
> 5.0] ?NAN.

On the true side of x >= 5.0 the set of values is described by
the [5., +INF] range.  On the false side the set is described
by the union of the range [-INF, 5.0] and the { -NAN, +NAN }
set.

There's no may-NAN.  There's also no ?4.0, the range either
includes 4.0 or it doesn't.

Note the frange class should probably have APIs that match
the FP classification functions isfinite(), isnormal(),
isnan(), isinf () and signbit() likewise compares like
isunordered() .  Note isnormal () exposes that FP numbers can
be denormal, not sure if that's worth tracking.

> With this representation we can fold __builtin_isnan() even on an
> unknown value... say on the true side of x == y we know that both x
> and y cannot be NANs...but on the false side we know nothing so there
> is the possibility of a NAN.
>
> I do like your idea for signed zeros.  I think I could make it work
> and get rid of the sign bit.
>
> Aldy
>
> >
> > > I'm mostly worried about removing a NAN from the IL that was going to
> > > signal, or some such.  While I agree with you Richard, I just want to
> > > make real sure, because getting something wrong in the frange or
> > > range-ops bowels means the problem becomes pervasive to all of ranger
> > > ...and threader...and loop ch...and vrp, etc etc.  I just want to take
> > > more time to test things.  I promise it won't stay varying too long.
> >
> > There's sNANs and qNANs, but I think for value-ranges we should
> > concern ourselves only with qNANs for now and leave sNANs VARYING.
> > All operations only ever produce qNANs (loads can produce sNANs).
> >
> > Richard.
> >
> > > Aldy
> > >
> >
>

Re: Extend fold_vec_perm to fold VEC_PERM_EXPR in VLA manner

[Richard Sandiford via Gcc-patches]

Sorry for the slow reply.  I wrote a response a couple of weeks ago
but I think it get lost in a machine outage.

Prathamesh Kulkarni  writes:
> Hi,
> The attached prototype patch extends fold_vec_perm to fold VEC_PERM_EXPR
> in VLA manner, and currently handles the following cases:
> (a) fixed len arg0, arg1 and fixed len sel.
> (b) fixed len arg0, arg1 and vla sel
> (c) vla arg0, arg1 and vla sel with arg0, arg1 being VECTOR_CST.
>
> It seems to work for the VLA tests written in
> test_vec_perm_vla_folding (), and am working thru the fallout observed in
> regression testing.
>
> Does the approach taken in the patch look in the right direction ?
> I am not sure if I have got the conversion from "sel_index"
> to index of either arg0, or arg1 entirely correct.
> I would be grateful for suggestions on the patch.
>
> Thanks,
> Prathamesh
>
> diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc
> index 4f4ec81c8d4..5e12260211e 100644
> --- a/gcc/fold-const.cc
> +++ b/gcc/fold-const.cc
> @@ -85,6 +85,9 @@ along with GCC; see the file COPYING3.  If not see
>  #include "vec-perm-indices.h"
>  #include "asan.h"
>  #include "gimple-range.h"
> +#include "tree-pretty-print.h"
> +#include "gimple-pretty-print.h"
> +#include "print-tree.h"
>  
>  /* Nonzero if we are folding constants inside an initializer or a C++
> manifestly-constant-evaluated context; zero otherwise.
> @@ -10496,40 +10499,6 @@ fold_mult_zconjz (location_t loc, tree type, tree 
> expr)
> build_zero_cst (itype));
>  }
>  
> -
> -/* Helper function for fold_vec_perm.  Store elements of VECTOR_CST or
> -   CONSTRUCTOR ARG into array ELTS, which has NELTS elements, and return
> -   true if successful.  */
> -
> -static bool
> -vec_cst_ctor_to_array (tree arg, unsigned int nelts, tree *elts)
> -{
> -  unsigned HOST_WIDE_INT i, nunits;
> -
> -  if (TREE_CODE (arg) == VECTOR_CST
> -  && VECTOR_CST_NELTS (arg).is_constant (&nunits))
> -{
> -  for (i = 0; i < nunits; ++i)
> - elts[i] = VECTOR_CST_ELT (arg, i);
> -}
> -  else if (TREE_CODE (arg) == CONSTRUCTOR)
> -{
> -  constructor_elt *elt;
> -
> -  FOR_EACH_VEC_SAFE_ELT (CONSTRUCTOR_ELTS (arg), i, elt)
> - if (i >= nelts || TREE_CODE (TREE_TYPE (elt->value)) == VECTOR_TYPE)
> -   return false;
> - else
> -   elts[i] = elt->value;
> -}
> -  else
> -return false;
> -  for (; i < nelts; i++)
> -elts[i]
> -  = fold_convert (TREE_TYPE (TREE_TYPE (arg)), integer_zero_node);
> -  return true;
> -}
> -
>  /* Attempt to fold vector permutation of ARG0 and ARG1 vectors using SEL
> selector.  Return the folded VECTOR_CST or CONSTRUCTOR if successful,
> NULL_TREE otherwise.  */
> @@ -10537,45 +10506,149 @@ vec_cst_ctor_to_array (tree arg, unsigned int 
> nelts, tree *elts)
>  tree
>  fold_vec_perm (tree type, tree arg0, tree arg1, const vec_perm_indices &sel)
>  {
> -  unsigned int i;
> -  unsigned HOST_WIDE_INT nelts;
> -  bool need_ctor = false;
> +  poly_uint64 arg0_len = TYPE_VECTOR_SUBPARTS (TREE_TYPE (arg0));
> +  poly_uint64 arg1_len = TYPE_VECTOR_SUBPARTS (TREE_TYPE (arg1));
> +
> +  gcc_assert (known_eq (TYPE_VECTOR_SUBPARTS (type),
> + sel.length ()));
> +  gcc_assert (known_eq (arg0_len, arg1_len));
>  
> -  if (!sel.length ().is_constant (&nelts))
> -return NULL_TREE;
> -  gcc_assert (known_eq (TYPE_VECTOR_SUBPARTS (type), nelts)
> -   && known_eq (TYPE_VECTOR_SUBPARTS (TREE_TYPE (arg0)), nelts)
> -   && known_eq (TYPE_VECTOR_SUBPARTS (TREE_TYPE (arg1)), nelts));
>if (TREE_TYPE (TREE_TYPE (arg0)) != TREE_TYPE (type)
>|| TREE_TYPE (TREE_TYPE (arg1)) != TREE_TYPE (type))
>  return NULL_TREE;
>  
> -  tree *in_elts = XALLOCAVEC (tree, nelts * 2);
> -  if (!vec_cst_ctor_to_array (arg0, nelts, in_elts)
> -  || !vec_cst_ctor_to_array (arg1, nelts, in_elts + nelts))
> +  unsigned input_npatterns = 0;
> +  unsigned out_npatterns = sel.encoding ().npatterns ();
> +  unsigned out_nelts_per_pattern = sel.encoding ().nelts_per_pattern ();
> +
> +  /* FIXME: How to reshape fixed length vector_cst, so that
> + npatterns == vector.length () and nelts_per_pattern == 1 ?
> + It seems the vector is canonicalized to minimize npatterns.  */
> +
> +  if (arg0_len.is_constant ())
> +{
> +  /* If arg0, arg1 are fixed width vectors, and sel is VLA,
> + ensure that it is a dup sequence and has same period
> +  as input vector.  */
> +
> +  if (!sel.length ().is_constant ()
> +   && (sel.encoding ().nelts_per_pattern () > 2
> +   || !known_eq (arg0_len, sel.encoding ().npatterns (
> + return NULL_TREE;
> +
> +  input_npatterns = arg0_len.to_constant ();
> +
> +  if (sel.length ().is_constant ())
> + {
> +   out_npatterns = sel.length ().to_constant ();
> +   out_nelts_per_pattern = 1;
> + }
> +}
> +  else if (TREE_CODE (arg0) == VECTOR_CST
> +&& TREE_CODE (arg1) == VECTOR_CST)
> +{
> + 

Re: [COMMITTED] Be even more conservative in intersection of NANs.

[Aldy Hernandez via Gcc-patches]

On Mon, Sep 5, 2022 at 11:53 AM Richard Biener
 wrote:
>
> On Mon, Sep 5, 2022 at 11:41 AM Aldy Hernandez  wrote:
> >
> > On Mon, Sep 5, 2022 at 11:18 AM Richard Biener
> >  wrote:
> > >
> > > On Mon, Sep 5, 2022 at 11:12 AM Aldy Hernandez  wrote:
> > > >
> > > > On Mon, Sep 5, 2022 at 11:06 AM Jakub Jelinek  wrote:
> > > > >
> > > > > On Mon, Sep 05, 2022 at 11:00:54AM +0200, Richard Biener wrote:
> > > > > > On Mon, Sep 5, 2022 at 8:24 AM Aldy Hernandez via Gcc-patches
> > > > > >  wrote:
> > > > > > >
> > > > > > > Intersecting two ranges where one is a NAN is keeping the sign 
> > > > > > > bit of
> > > > > > > the NAN range.  This is not correct as the sign bits may not 
> > > > > > > match.
> > > > > > >
> > > > > > > I think the only time we're absolutely sure about the 
> > > > > > > intersection of
> > > > > > > a NAN and something else, is when both are a NAN with exactly the 
> > > > > > > same
> > > > > > > properties (sign bit).  If we're intersecting two NANs of 
> > > > > > > differing
> > > > > > > sign, we can decide later whether that's undefined or just a NAN 
> > > > > > > with
> > > > > > > no known sign.  For now I've done the latter.
> > > > > > >
> > > > > > > I'm still mentally working on intersections involving NANs, 
> > > > > > > especially
> > > > > > > if we want to keep track of signbits.  For now, let's be extra 
> > > > > > > careful
> > > > > > > and only do things we're absolutely sure about.
> > > > > > >
> > > > > > > Later we may want to fold the intersect of [NAN,NAN] and say [3,5]
> > > > > > > with the posibility of NAN, to a NAN, but I'm not 100% sure.
> > > > > >
> > > > > > The intersection of [NAN, NAN] and [3, 5] is empty.  The 
> > > > > > intersection
> > > > > > of [NAN, NAN] and VARYING is [NAN, NAN].
> > > > >
> > > > > I think [3.0, 5.0] printed that way currently means U maybe NAN,
> > > > > it would be [3.0, 5.0] !NAN if it was known not to be NAN.
> > > >
> > > > Right.  I don't print any of the "maybe" properties, just if they're
> > > > definitely set or definitely clear.  I'm open to suggestions as to how
> > > > to display them.  Perhaps NAN, !NAN, ?NAN.
> > >
> > > There's no NAN tristate.  Your "definitely NAN" would be simply
> > > ][ NAN, that is, the value range only contains NAN.  Your !NAN
> > > is  and non NAN.  Likewise for the sign, the
> > > range either includes -NAN and NAN or one or none of those.
> > > For signed zeros you either have [-0, upper-bound] or [0, upper-bound]
> > > where it either includes both -0 and 0 or just one of them
> >
> > But there is a tristate.  We may definitely have a NAN, definitely not
> > have a NAN, or the state of the NAN is unknown.
>
> Sure.  But we are talking about sets of values a variable can have
> (a value "range" where "range" is a bit misleading for something
> like a NAN).  The set of possible values either includes
> NAN (or -NAN and +NAN) or it doesn't include NAN (or -NAN and +NAN).
> A set cannot include or not include a "maybe NAN".
>
> >  Say [3,5] ?NAN.
> > That's [3,5] with the possibility of a NAN.  On the true side of x >=
> > 5.0, we'd have [5.0, INF] !NAN.  On the false side we'd have [-INF,
> > 5.0] ?NAN.
>
> On the true side of x >= 5.0 the set of values is described by
> the [5., +INF] range.  On the false side the set is described
> by the union of the range [-INF, 5.0] and the { -NAN, +NAN }
> set.
>
> There's no may-NAN.  There's also no ?4.0, the range either
> includes 4.0 or it doesn't.

Ah, ok.  I see where the confusion lies.  You're missing that we don't
have sub-ranges like we do for irange.  We only have two endpoints and
a set of flags.  So we can't represent [3,4] U NAN "elegantly".
However, we can do it with [3,4] ?NAN.  This is by design, but not
permanent.  I don't have infinite time to work on frange on this cycle
(I have other things like wide-ints conversion, prange, removal of
legacy, etc etc), so I wanted something that worked with endpoints,
signs, and NANs, that's about it.  If at a later time we decide to go
full throttle with the ability to represent sub-ranges, we can do so.
Heck, you're welcome to try-- just let me finish the initial
implementation and get it working correctly first.

It is more important right now to get the usage than the
representation right.  We could always add sub-ranges, or change the
representation altogether.  What is very important we agree on is the
usage, so your suggestions about the FP classification functions below
are golden.  I'll look into that.

Does that make sense?

BTW, [NAN, NAN] is a special case.  It doesn't behave like a
singleton.  Both endpoints must match.  We assert this much.  We don't
propagate it.  We can't do equality to it.  The fact that it lives in
the endpoints is just an implementation detail.

Aldy

>
> Note the frange class should probably have APIs that match
> the FP classification functions isfinite(), isnormal(),
> isnan(), isinf () and signbit() likewise compares like
> isunordered() .  No

Re: [COMMITTED] Be even more conservative in intersection of NANs.

[Richard Biener via Gcc-patches]

On Mon, Sep 5, 2022 at 12:24 PM Aldy Hernandez  wrote:
>
> On Mon, Sep 5, 2022 at 11:53 AM Richard Biener
>  wrote:
> >
> > On Mon, Sep 5, 2022 at 11:41 AM Aldy Hernandez  wrote:
> > >
> > > On Mon, Sep 5, 2022 at 11:18 AM Richard Biener
> > >  wrote:
> > > >
> > > > On Mon, Sep 5, 2022 at 11:12 AM Aldy Hernandez  wrote:
> > > > >
> > > > > On Mon, Sep 5, 2022 at 11:06 AM Jakub Jelinek  
> > > > > wrote:
> > > > > >
> > > > > > On Mon, Sep 05, 2022 at 11:00:54AM +0200, Richard Biener wrote:
> > > > > > > On Mon, Sep 5, 2022 at 8:24 AM Aldy Hernandez via Gcc-patches
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > Intersecting two ranges where one is a NAN is keeping the sign 
> > > > > > > > bit of
> > > > > > > > the NAN range.  This is not correct as the sign bits may not 
> > > > > > > > match.
> > > > > > > >
> > > > > > > > I think the only time we're absolutely sure about the 
> > > > > > > > intersection of
> > > > > > > > a NAN and something else, is when both are a NAN with exactly 
> > > > > > > > the same
> > > > > > > > properties (sign bit).  If we're intersecting two NANs of 
> > > > > > > > differing
> > > > > > > > sign, we can decide later whether that's undefined or just a 
> > > > > > > > NAN with
> > > > > > > > no known sign.  For now I've done the latter.
> > > > > > > >
> > > > > > > > I'm still mentally working on intersections involving NANs, 
> > > > > > > > especially
> > > > > > > > if we want to keep track of signbits.  For now, let's be extra 
> > > > > > > > careful
> > > > > > > > and only do things we're absolutely sure about.
> > > > > > > >
> > > > > > > > Later we may want to fold the intersect of [NAN,NAN] and say 
> > > > > > > > [3,5]
> > > > > > > > with the posibility of NAN, to a NAN, but I'm not 100% sure.
> > > > > > >
> > > > > > > The intersection of [NAN, NAN] and [3, 5] is empty.  The 
> > > > > > > intersection
> > > > > > > of [NAN, NAN] and VARYING is [NAN, NAN].
> > > > > >
> > > > > > I think [3.0, 5.0] printed that way currently means U maybe NAN,
> > > > > > it would be [3.0, 5.0] !NAN if it was known not to be NAN.
> > > > >
> > > > > Right.  I don't print any of the "maybe" properties, just if they're
> > > > > definitely set or definitely clear.  I'm open to suggestions as to how
> > > > > to display them.  Perhaps NAN, !NAN, ?NAN.
> > > >
> > > > There's no NAN tristate.  Your "definitely NAN" would be simply
> > > > ][ NAN, that is, the value range only contains NAN.  Your !NAN
> > > > is  and non NAN.  Likewise for the sign, the
> > > > range either includes -NAN and NAN or one or none of those.
> > > > For signed zeros you either have [-0, upper-bound] or [0, upper-bound]
> > > > where it either includes both -0 and 0 or just one of them
> > >
> > > But there is a tristate.  We may definitely have a NAN, definitely not
> > > have a NAN, or the state of the NAN is unknown.
> >
> > Sure.  But we are talking about sets of values a variable can have
> > (a value "range" where "range" is a bit misleading for something
> > like a NAN).  The set of possible values either includes
> > NAN (or -NAN and +NAN) or it doesn't include NAN (or -NAN and +NAN).
> > A set cannot include or not include a "maybe NAN".
> >
> > >  Say [3,5] ?NAN.
> > > That's [3,5] with the possibility of a NAN.  On the true side of x >=
> > > 5.0, we'd have [5.0, INF] !NAN.  On the false side we'd have [-INF,
> > > 5.0] ?NAN.
> >
> > On the true side of x >= 5.0 the set of values is described by
> > the [5., +INF] range.  On the false side the set is described
> > by the union of the range [-INF, 5.0] and the { -NAN, +NAN }
> > set.
> >
> > There's no may-NAN.  There's also no ?4.0, the range either
> > includes 4.0 or it doesn't.
>
> Ah, ok.  I see where the confusion lies.  You're missing that we don't
> have sub-ranges like we do for irange.  We only have two endpoints and
> a set of flags.  So we can't represent [3,4] U NAN "elegantly".
> However, we can do it with [3,4] ?NAN.  This is by design, but not
> permanent.  I don't have infinite time to work on frange on this cycle
> (I have other things like wide-ints conversion, prange, removal of
> legacy, etc etc), so I wanted something that worked with endpoints,
> signs, and NANs, that's about it.  If at a later time we decide to go
> full throttle with the ability to represent sub-ranges, we can do so.
> Heck, you're welcome to try-- just let me finish the initial
> implementation and get it working correctly first.
>
> It is more important right now to get the usage than the
> representation right.  We could always add sub-ranges, or change the
> representation altogether.  What is very important we agree on is the
> usage, so your suggestions about the FP classification functions below
> are golden.  I'll look into that.
>
> Does that make sense?

Not really.  I didn't ask for sub-ranges for NAN, but even with a "flag"
it should still semantically be [3, 4] U NAN or [3, 4].  It's not necessary
but confusing to leave the 

Re: [PATCH v2] ipa-visibility: Optimize TLS access [PR99619]

[Martin Jambor]

Hi,

On Tue, Aug 30 2022, Alexander Monakov wrote:
>> I see, thank you for explaining the issue, and sorry if I was a bit stubborn.
>> 
>> Does the attached patch (incremental change below) look better? It no longer
>> has the 'shortcut' where iterating over referrers is avoided for the common
>> case of plain 'gcc -O2' and no 'optimize' attributes, but fortunately TLS
>> variables are not so numerous to make chasing that worthwhile.
>
> ... and of course I forgot to add the attachment.  Revised patch below.

I hope I am not overstepping my IPA/cgraph maintainer authority here but
I believe the patch is OK for master (assuming it passes bootstrap and
testing).

Thanks,

Martin


>
> ---8<---
>
> From b245015ec465604799aef60b224b1e1e264d4cb8 Mon Sep 17 00:00:00 2001
> From: Artem Klimov 
> Date: Wed, 6 Jul 2022 17:02:01 +0300
> Subject: [PATCH] ipa-visibility: Optimize TLS access [PR99619]
>
> Fix PR99619, which asks to optimize TLS model based on visibility.
> The fix is implemented as an IPA optimization: this allows to take
> optimized visibility status into account (as well as avoid modifying
> all language frontends).
>
> 2022-04-17  Artem Klimov  
>
> gcc/ChangeLog:
>
>   * ipa-visibility.cc (function_and_variable_visibility): Promote
>   TLS access model afer visibility optimizations.
>   * varasm.cc (have_optimized_refs): New helper.
>   (optimize_dyn_tls_for_decl_p): New helper. Use it ...
>   (decl_default_tls_model): ... here in place of 'optimize' check.
>
> gcc/testsuite/ChangeLog:
>
>   * gcc.dg/tls/vis-attr-gd.c: New test.
>   * gcc.dg/tls/vis-attr-hidden-gd.c: New test.
>   * gcc.dg/tls/vis-attr-hidden.c: New test.
>   * gcc.dg/tls/vis-flag-hidden-gd.c: New test.
>   * gcc.dg/tls/vis-flag-hidden.c: New test.
>   * gcc.dg/tls/vis-pragma-hidden-gd.c: New test.
>   * gcc.dg/tls/vis-pragma-hidden.c: New test.
>
> Co-Authored-By:  Alexander Monakov  
> Signed-off-by: Artem Klimov 
> ---
>  gcc/ipa-visibility.cc | 19 +++
>  gcc/testsuite/gcc.dg/tls/vis-attr-gd.c| 12 +++
>  gcc/testsuite/gcc.dg/tls/vis-attr-hidden-gd.c | 13 
>  gcc/testsuite/gcc.dg/tls/vis-attr-hidden.c| 12 +++
>  gcc/testsuite/gcc.dg/tls/vis-flag-hidden-gd.c | 13 
>  gcc/testsuite/gcc.dg/tls/vis-flag-hidden.c| 12 +++
>  .../gcc.dg/tls/vis-pragma-hidden-gd.c | 17 ++
>  gcc/testsuite/gcc.dg/tls/vis-pragma-hidden.c  | 16 ++
>  gcc/varasm.cc | 32 ++-
>  9 files changed, 145 insertions(+), 1 deletion(-)
>  create mode 100644 gcc/testsuite/gcc.dg/tls/vis-attr-gd.c
>  create mode 100644 gcc/testsuite/gcc.dg/tls/vis-attr-hidden-gd.c
>  create mode 100644 gcc/testsuite/gcc.dg/tls/vis-attr-hidden.c
>  create mode 100644 gcc/testsuite/gcc.dg/tls/vis-flag-hidden-gd.c
>  create mode 100644 gcc/testsuite/gcc.dg/tls/vis-flag-hidden.c
>  create mode 100644 gcc/testsuite/gcc.dg/tls/vis-pragma-hidden-gd.c
>  create mode 100644 gcc/testsuite/gcc.dg/tls/vis-pragma-hidden.c
>
> diff --git a/gcc/ipa-visibility.cc b/gcc/ipa-visibility.cc
> index 8a27e7bcd..3ed2b7cf6 100644
> --- a/gcc/ipa-visibility.cc
> +++ b/gcc/ipa-visibility.cc
> @@ -873,6 +873,25 @@ function_and_variable_visibility (bool whole_program)
>   }
>  }
>  
> +  if (symtab->state >= IPA_SSA)
> +{
> +  FOR_EACH_VARIABLE (vnode)
> + {
> +   tree decl = vnode->decl;
> +
> +   /* Upgrade TLS access model based on optimized visibility status,
> +  unless it was specified explicitly or no references remain.  */
> +   if (DECL_THREAD_LOCAL_P (decl)
> +   && !lookup_attribute ("tls_model", DECL_ATTRIBUTES (decl))
> +   && vnode->ref_list.referring.length ())
> + {
> +   enum tls_model new_model = decl_default_tls_model (decl);
> +   gcc_checking_assert (new_model >= decl_tls_model (decl));
> +   set_decl_tls_model (decl, new_model);
> + }
> + }
> +}
> +
>if (dump_file)
>  {
>fprintf (dump_file, "\nMarking local functions:");
> diff --git a/gcc/varasm.cc b/gcc/varasm.cc
> index 4db8506b1..ffc559431 100644
> --- a/gcc/varasm.cc
> +++ b/gcc/varasm.cc
> @@ -6679,6 +6679,36 @@ init_varasm_once (void)
>  #endif
>  }
>  
> +/* Determine whether SYMBOL is used in any optimized function.  */
> +
> +static bool
> +have_optimized_refs (struct symtab_node *symbol)
> +{
> +  struct ipa_ref *ref;
> +
> +  for (int i = 0; symbol->iterate_referring (i, ref); i++)
> +{
> +  cgraph_node *cnode = dyn_cast  (ref->referring);
> +
> +  if (cnode && opt_for_fn (cnode->decl, optimize))
> + return true;
> +}
> +
> +  return false;
> +}
> +
> +/* Check if promoting general-dynamic TLS access model to local-dynamic is
> +   desirable for DECL.  */
> +
> +static bool
> +optimize_dyn_tls_for_decl_p (const_tree decl)
> +{
> +  if (cfun)
> +return optimize;
> +  return symtab->state >= IPA && 

[PATCH] bpf: Fix unused variable warning

[Jan-Benedict Glaw]

Hi!

Building for for bpf-unknown-none target, recent GCCs will issue an unused
variable warning as the REGNO_REG_CLASS macro doesn't actually use its
argument. Reference the argument as (void) to silence the warning.

.../gcc/configure --prefix=... --enable-werror-always --enable-languages=all 
--disable-gcov --disable-shared --disable-threads --target=bpf-unknown-none 
--without-headers
[...]
make V=1 all-gcc
[...]

/usr/lib/gcc-snapshot/bin/g++  -fno-PIE -c   -g -O2   -DIN_GCC  
-DCROSS_DIRECTORY_STRUCTURE   -fno-exceptions -fno-rtti 
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
-Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic 
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common 
 -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. 
-I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include 
-I../../gcc/gcc/../libcody  -I../../gcc/gcc/../libdecnumber 
-I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber 
-I../../gcc/gcc/../libbacktrace   -o regcprop.o -MT regcprop.o -MMD -MP -MF 
./.deps/regcprop.TPo ../../gcc/gcc/regcprop.cc
../../gcc/gcc/regcprop.cc: In function 'bool 
copyprop_hardreg_forward_1(basic_block, value_data*)':
../../gcc/gcc/regcprop.cc:794:24: error: unused variable 'regno' 
[-Werror=unused-variable]
  794 |   unsigned int regno = REGNO (SET_SRC (set));
  |^
cc1plus: all warnings being treated as errors
make[1]: *** [Makefile:1146: regcprop.o] Error 1
make[1]: Leaving directory 
'/var/lib/laminar/run/gcc-bpf-unknown-none/1/toolchain-build/gcc'
make: *** [Makefile:4565: all-gcc] Error 2


Ok for HEAD?

Thanks,
  Jan-Benedict

gcc/
* config/bpf/bpf.h (REGNO_REG_CLASS): Reference arguments as (void).

diff --git a/gcc/config/bpf/bpf.h b/gcc/config/bpf/bpf.h
index 5b3f4a58763..57903477a4a 100644
--- a/gcc/config/bpf/bpf.h
+++ b/gcc/config/bpf/bpf.h
@@ -209,7 +209,7 @@ enum reg_class
register REGNO.  In general there is more that one such class;
choose a class which is "minimal", meaning that no smaller class
also contains the register.  */
-#define REGNO_REG_CLASS(REGNO) GENERAL_REGS
+#define REGNO_REG_CLASS(REGNO) ((void)(REGNO), GENERAL_REGS)
 
 /* A macro whose definition is the name of the class to which a
valid base register must belong.  A base register is one used in
-- 


signature.asc
Description: PGP signature

Re: [PATCH V2] Extend vectorizer to handle nonlinear induction for neg, mul/lshift/rshift with a constant.

[Richard Biener via Gcc-patches]

On Mon, Aug 29, 2022 at 7:29 AM liuhongt via Gcc-patches
 wrote:
>
> >Looks good overall - a few comments inline.  Also can you please add
> >SLP support?
> >I've tried hard to fill in gaps where SLP support is missing since my
> >goal is still to get
> >rid of non-SLP.
> For slp with different induction type, they need separate iv update and
> an vector permutation. And if they are the same induction type, iv can
> be updated with 1 instructions w/o permutation.
> I'll add a incremental patch for that.
>
> >gcc_assert (is_a  (loop_phi_node));
> >is shorter
> It looks like it doesn't support gphi*, just support gimple*. Since it's
> already gphi* here, I've removed the assert.
>
> >I think you should use
> >init_expr = PHI_ARG_DEF_FROM_EDGE (loop_phi_node,loop_preheader_edge (loop));
> >and loop_latch_edge (loop) for ev_expr, you can't rely on them being arg 0 / 
> >1.
> Changed.
>
> >Likewise.  Use preheader/latch edge.
> Changed.
>
> >and those two should then go away.
> Removed.
>
> >is not vectorized?  I think it should be possible to relax
> >this.
> Relaxed.
>
> >def is never NULL so a cheaper way to write this is
> >|| ((def = SSA_NAME_DEF_STMT (ev_expr)), true)
> Changed.
>
> >not sure if we need to bother here - ideally vectorizable_live_operation 
> >would
> >give up instead (but I suppose the regular IV / induction analysis gives up
> >here as well?)
> Removed.
>
> >the above can at least go into the combined switch case
> Changed.
>
> >Seeing this - did you check whether you handle prologue peeling correctly?  
> >The
> >same issue might show up with a vectorized epilogue.  I think you can force a
> >peeled prologue with storing unaligned and -fno-vect-cost-model (that IIRC 
> >will
> >simply optimize for the larger number of aligned memory ops)
> Update in vect_update_ivs_after_vectorizer, also support peel for unaligned 
> cases.
>
> >since you only handle inner loop nonlinear IVs you should probably
> >swap the two checks?
> Changed.
>
> >There might be a more canonical way to build the series expr
> build_vec_series doens't add stmt to sequence, so i'll still keep 
> VEC_SERY_EXPR here?
>
> >use types_compatible_p (...) instead of comparing TYPE_CANONICAL.
> >A small enhancement would be to support different signedness
> >(use tree_nop_conversion_p then).
> Support different signedness.
>
> >above you asserted that the conversion is only necessary for constants
> >but then fold_convert will also generate a tree NOP_EXPR for
> >some types_compatible_p types.  So maybe only do this for INTEGER_CST
> >init_expr or use init_expr = gimple_convert (...) and insert required stmts
> >on the preheader.
> Changed.
>
> >Alternatively you could perform the vector IV updates in an unsigned type?
> Changed.
>
> >why's that necessary?  can we do a MIN (vector_step, { prec-1, prec-1,
> >prec-1 ... })
> It's true for ashr, but not for ashl, lshr. For the later 2, when vector_step 
> >= precision
> The result should be zero instead of shift by prec - 1.
>
> >> +  new_name = vect_create_nonlinear_iv_step (&stmts, step_expr,
> >> +   nunits, induction_type);
> >> +
> >> +  vec_step = vect_create_nonlinear_iv_vec_step (loop_vinfo, stmt_info,
> >> +   new_name, vectype,
> >> +   induction_type);
>
> >are these not the same as created above?are these not the same as created 
> >above?
>
> They are different, the first one is vf, this is nunits, vf could be multi 
> copy of nunits which
> is exact this code is handled and phi_latch is updated in the former vf place.
>
>
> Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.

OK, and sorry for the delay.

Thanks.
Richard.

>
> For neg, the patch create a vec_init as [ a, -a, a, -a, ...  ] and no
> vec_step is needed to update vectorized iv since vf is always multiple
> of 2(negative * negative is positive).
>
> For shift, the patch create a vec_init as [ a, a >> c, a >> 2*c, ..]
> as vec_step as [ c * nunits, c * nunits, c * nunits, ... ], vectorized iv is
> updated as vec_def = vec_init >>/<< vec_step.
>
> For mul, the patch create a vec_init as [ a, a * c, a * pow(c, 2), ..]
> as vec_step as [ pow(c,nunits), pow(c,nunits),...] iv is updated as vec_def =
> vec_init * vec_step.
>
> The patch handles nonlinear iv for
> 1. Integer type only, floating point is not handled.
> 2. No slp_node.
> 3. iv_loop should be same as vector loop, not nested loop.
> 4. No UD is created, for mul, use unsigned mult to avoid UD, for
>shift, shift count should be less than type precision.
>
> gcc/ChangeLog:
>
> PR tree-optimization/103144
> * tree-vect-loop.cc (vect_is_nonlinear_iv_evolution): New function.
> (vect_analyze_scalar_cycles_1): Detect nonlinear iv by upper function.
> (vect_create_nonlinear_iv_init): New function.
> (vect_peel_nonlinear_iv_init): Ditto.
> (vect_create

Re: ICE after folding svld1rq to vec_perm_expr duing forwprop

[Richard Biener via Gcc-patches]

On Mon, Sep 5, 2022 at 11:27 AM Prathamesh Kulkarni
 wrote:
>
> On Mon, 5 Sept 2022 at 14:39, Richard Biener  
> wrote:
> >
> > On Mon, Sep 5, 2022 at 10:54 AM Prathamesh Kulkarni
> >  wrote:
> > >
> > > On Mon, 29 Aug 2022 at 11:53, Prathamesh Kulkarni
> > >  wrote:
> > > >
> > > > On Thu, 18 Aug 2022 at 18:20, Prathamesh Kulkarni
> > > >  wrote:
> > > > >
> > > > > On Thu, 18 Aug 2022 at 18:14, Prathamesh Kulkarni
> > > > >  wrote:
> > > > > >
> > > > > > On Wed, 17 Aug 2022 at 17:01, Richard Biener 
> > > > > >  wrote:
> > > > > > >
> > > > > > > On Tue, Aug 16, 2022 at 6:30 PM Richard Sandiford
> > > > > > >  wrote:
> > > > > > > >
> > > > > > > > Prathamesh Kulkarni  writes:
> > > > > > > > > On Tue, 9 Aug 2022 at 18:42, Richard Biener 
> > > > > > > > >  wrote:
> > > > > > > > >>
> > > > > > > > >> On Tue, Aug 9, 2022 at 12:10 PM Prathamesh Kulkarni
> > > > > > > > >>  wrote:
> > > > > > > > >> >
> > > > > > > > >> > On Mon, 8 Aug 2022 at 14:27, Richard Biener 
> > > > > > > > >> >  w>> > >
> > > > > > > > >> > >
> > > > > > > > >> > >   /* If result vector has greater length than input 
> > > > > > > > >> > > vector,
> > > > > > > > >> > > + then allow permuting two vectors as long as:
> > > > > > > > >> > > + a) sel.nelts_per_pattern == 1
> > > > > > > > >> > > + b) sel.npatterns == len of input vector.
> > > > > > > > >> > > + The intent is to permute input vectors, and
> > > > > > > > >> > > + dup the elements in resulting vector to target 
> > > > > > > > >> > > vector length.  */
> > > > > > > > >> > > +
> > > > > > > > >> > > +  if (maybe_gt (TYPE_VECTOR_SUBPARTS (type),
> > > > > > > > >> > > +   TYPE_VECTOR_SUBPARTS (TREE_TYPE (arg0
> > > > > > > > >> > > +{
> > > > > > > > >> > > +  nelts = sel.encoding ().npatterns ();
> > > > > > > > >> > > +  if (sel.encoding ().nelts_per_pattern () != 1
> > > > > > > > >> > > + || (!known_eq (nelts, TYPE_VECTOR_SUBPARTS 
> > > > > > > > >> > > (TREE_TYPE (arg0)
> > > > > > > > >> > > +   return NULL_TREE;
> > > > > > > > >> > > +}
> > > > > > > > >> > >
> > > > > > > > >> > > so the only case you add is non-VLA to VLA and there
> > > > > > > > >> > > explicitely only the case of a period that's same as the
> > > > > > > > >> > > element count in the input vectors.
> > > > > > > > >> > >
> > > > > > > > >> > >
> > > > > > > > >> > > @@ -2602,6 +2602,9 @@ dump_generic_node (pretty_printer 
> > > > > > > > >> > > *pp, tree
> > > > > > > > >> > > node, int spc, dump_flags_t flags,
> > > > > > > > >> > > pp_space (pp);
> > > > > > > > >> > >   }
> > > > > > > > >> > >   }
> > > > > > > > >> > > +   if (VECTOR_TYPE_P (TREE_TYPE (node))
> > > > > > > > >> > > +   && !TYPE_VECTOR_SUBPARTS (TREE_TYPE 
> > > > > > > > >> > > (node)).is_constant ())
> > > > > > > > >> > > + pp_string (pp, ", ... ");
> > > > > > > > >> > > pp_right_brace (pp);
> > > > > > > > >> > >
> > > > > > > > >> > > btw, I do wonder if VLA CONSTRUCTORs are a "thing"?  Are 
> > > > > > > > >> > > they?
> > > > > > > > >> > Well, it got created for the following case after folding:
> > > > > > > > >> > svint32_t f2(int a, int b, int c, int d)
> > > > > > > > >> > {
> > > > > > > > >> >   int32x4_t v = {a, b, c, d};
> > > > > > > > >> >   return svld1rq_s32 (svptrue_b8 (), &v[0]);
> > > > > > > > >> > }
> > > > > > > > >> >
> > > > > > > > >> > The svld1rq_s32 call gets folded to:
> > > > > > > > >> > v = {a, b, c, d}
> > > > > > > > >> > lhs = VEC_PERM_EXPR
> > > > > > > > >> >
> > > > > > > > >> > fold_vec_perm then folds the above VEC_PERM_EXPR to
> > > > > > > > >> > VLA constructor, since elements in v (in_elts) are not 
> > > > > > > > >> > constant, and
> > > > > > > > >> > need_ctor is thus true:
> > > > > > > > >> > lhs = {a, b, c, d, ...}
> > > > > > > > >> > I added "..." to make it more explicit that it's a VLA 
> > > > > > > > >> > constructor.
> > > > > > > > >>
> > > > > > > > >> But I doubt we do anything reasonable with such a beast?  Do 
> > > > > > > > >> we?
> > > > > > > > >> I suppose it's like a vec_duplicate if you view it as 
> > > > > > > > >> V1TImode
> > > > > > > > >> but do we actually make sure to do this duplication?
> > > > > > > > > I am not sure. As mentioned above, the current code-gen for 
> > > > > > > > > VLA
> > > > > > > > > constructor looks pretty bad.
> > > > > > > > > Should we avoid folding VLA constructors for now ?
> > > > > > > >
> > > > > > > > VLA constructors aren't really a thing.  At least, the only VLA 
> > > > > > > > vector
> > > > > > > > you could represent with current CONSTRUCTOR nodes is a 
> > > > > > > > fixed-length
> > > > > > > > sequence at the start of an otherwise zero vector.  I'm not sure
> > > > > > > > we even use that though (perhaps we do and I've forgotten).
> > > > > > > >
> > > > > > > > > I guess these are 2 different issues:
> > > > > > > > > (a) Resolving ICE with VEC_PERM_EXPR for abo

Re: [PATCH v2] coroutines: Ensure there's a top level bind when rewriting [PR106188]

[Arsen Arsenović via Gcc-patches]

Hi,

On Monday, 5 September 2022 00:09:51 CEST Iain Sandoe wrote:
> LGTM, but I cannot actually approve it - please wait for an ack from
> Jason or Nathan (or one of the other global maintainers).
Will do. Thank you for your assistance.

Have a good day,
-- 
Arsen Arsenović


signature.asc
Description: This is a digitally signed message part.

Re: [COMMITTED] Be even more conservative in intersection of NANs.

[Aldy Hernandez via Gcc-patches]

On Mon, Sep 5, 2022 at 12:38 PM Richard Biener
 wrote:
>
> On Mon, Sep 5, 2022 at 12:24 PM Aldy Hernandez  wrote:
> >
> > On Mon, Sep 5, 2022 at 11:53 AM Richard Biener
> >  wrote:
> > >
> > > On Mon, Sep 5, 2022 at 11:41 AM Aldy Hernandez  wrote:
> > > >
> > > > On Mon, Sep 5, 2022 at 11:18 AM Richard Biener
> > > >  wrote:
> > > > >
> > > > > On Mon, Sep 5, 2022 at 11:12 AM Aldy Hernandez  
> > > > > wrote:
> > > > > >
> > > > > > On Mon, Sep 5, 2022 at 11:06 AM Jakub Jelinek  
> > > > > > wrote:
> > > > > > >
> > > > > > > On Mon, Sep 05, 2022 at 11:00:54AM +0200, Richard Biener wrote:
> > > > > > > > On Mon, Sep 5, 2022 at 8:24 AM Aldy Hernandez via Gcc-patches
> > > > > > > >  wrote:
> > > > > > > > >
> > > > > > > > > Intersecting two ranges where one is a NAN is keeping the 
> > > > > > > > > sign bit of
> > > > > > > > > the NAN range.  This is not correct as the sign bits may not 
> > > > > > > > > match.
> > > > > > > > >
> > > > > > > > > I think the only time we're absolutely sure about the 
> > > > > > > > > intersection of
> > > > > > > > > a NAN and something else, is when both are a NAN with exactly 
> > > > > > > > > the same
> > > > > > > > > properties (sign bit).  If we're intersecting two NANs of 
> > > > > > > > > differing
> > > > > > > > > sign, we can decide later whether that's undefined or just a 
> > > > > > > > > NAN with
> > > > > > > > > no known sign.  For now I've done the latter.
> > > > > > > > >
> > > > > > > > > I'm still mentally working on intersections involving NANs, 
> > > > > > > > > especially
> > > > > > > > > if we want to keep track of signbits.  For now, let's be 
> > > > > > > > > extra careful
> > > > > > > > > and only do things we're absolutely sure about.
> > > > > > > > >
> > > > > > > > > Later we may want to fold the intersect of [NAN,NAN] and say 
> > > > > > > > > [3,5]
> > > > > > > > > with the posibility of NAN, to a NAN, but I'm not 100% sure.
> > > > > > > >
> > > > > > > > The intersection of [NAN, NAN] and [3, 5] is empty.  The 
> > > > > > > > intersection
> > > > > > > > of [NAN, NAN] and VARYING is [NAN, NAN].
> > > > > > >
> > > > > > > I think [3.0, 5.0] printed that way currently means U maybe NAN,
> > > > > > > it would be [3.0, 5.0] !NAN if it was known not to be NAN.
> > > > > >
> > > > > > Right.  I don't print any of the "maybe" properties, just if they're
> > > > > > definitely set or definitely clear.  I'm open to suggestions as to 
> > > > > > how
> > > > > > to display them.  Perhaps NAN, !NAN, ?NAN.
> > > > >
> > > > > There's no NAN tristate.  Your "definitely NAN" would be simply
> > > > > ][ NAN, that is, the value range only contains NAN.  Your !NAN
> > > > > is  and non NAN.  Likewise for the sign, the
> > > > > range either includes -NAN and NAN or one or none of those.
> > > > > For signed zeros you either have [-0, upper-bound] or [0, upper-bound]
> > > > > where it either includes both -0 and 0 or just one of them
> > > >
> > > > But there is a tristate.  We may definitely have a NAN, definitely not
> > > > have a NAN, or the state of the NAN is unknown.
> > >
> > > Sure.  But we are talking about sets of values a variable can have
> > > (a value "range" where "range" is a bit misleading for something
> > > like a NAN).  The set of possible values either includes
> > > NAN (or -NAN and +NAN) or it doesn't include NAN (or -NAN and +NAN).
> > > A set cannot include or not include a "maybe NAN".
> > >
> > > >  Say [3,5] ?NAN.
> > > > That's [3,5] with the possibility of a NAN.  On the true side of x >=
> > > > 5.0, we'd have [5.0, INF] !NAN.  On the false side we'd have [-INF,
> > > > 5.0] ?NAN.
> > >
> > > On the true side of x >= 5.0 the set of values is described by
> > > the [5., +INF] range.  On the false side the set is described
> > > by the union of the range [-INF, 5.0] and the { -NAN, +NAN }
> > > set.
> > >
> > > There's no may-NAN.  There's also no ?4.0, the range either
> > > includes 4.0 or it doesn't.
> >
> > Ah, ok.  I see where the confusion lies.  You're missing that we don't
> > have sub-ranges like we do for irange.  We only have two endpoints and
> > a set of flags.  So we can't represent [3,4] U NAN "elegantly".
> > However, we can do it with [3,4] ?NAN.  This is by design, but not
> > permanent.  I don't have infinite time to work on frange on this cycle
> > (I have other things like wide-ints conversion, prange, removal of
> > legacy, etc etc), so I wanted something that worked with endpoints,
> > signs, and NANs, that's about it.  If at a later time we decide to go
> > full throttle with the ability to represent sub-ranges, we can do so.
> > Heck, you're welcome to try-- just let me finish the initial
> > implementation and get it working correctly first.
> >
> > It is more important right now to get the usage than the
> > representation right.  We could always add sub-ranges, or change the
> > representation altogether.  What is very important we agree on is the
> > usage, so your suggestions ab

[PATCH][sanitizer/106558] asan: fix unsafe optimization of Asan checks.

[Yuri Gribov via Gcc-patches]

Hi,

This patch fixes incorrect Asan optimization in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106558 . It successfully
passes bootstrap-asan, regular bootstrap and regression testing (on
x86_64).

With this patch number of optimizations has reduced only slightly
(146062 -> 145824 on bootstrap-asan) so I decided to skip the more
complicated alias oracle-based approach that was suggested by Jakub in
the PR.

Best regards,
Yuri
From 3aebd2adc30e164065327c7d3820ad98fe59cad8 Mon Sep 17 00:00:00 2001
From: Yuri Gribov 
Date: Sun, 14 Aug 2022 08:42:44 +0300
Subject: [PATCH] asan: fix unsafe optimization of Asan checks.

gcc/
PR sanitizer/106558
* sanopt.c: Do not optimize out checks for non-SSA addresses.

gcc/testsuite/
PR sanitizer/106558
* c-c++-common/asan/pr106558.c: New test.
---
 gcc/sanopt.cc  | 40 +-
 gcc/testsuite/c-c++-common/asan/pr106558.c | 23 +
 2 files changed, 54 insertions(+), 9 deletions(-)
 create mode 100644 gcc/testsuite/c-c++-common/asan/pr106558.c

diff --git a/gcc/sanopt.cc b/gcc/sanopt.cc
index e9d188d7889..13942a0b1da 100644
--- a/gcc/sanopt.cc
+++ b/gcc/sanopt.cc
@@ -80,16 +80,16 @@ struct sanopt_info
 
 /* If T has a single definition of form T = T2, return T2.  */
 
-static tree
+static gimple *
 maybe_get_single_definition (tree t)
 {
   if (TREE_CODE (t) == SSA_NAME)
 {
   gimple *g = SSA_NAME_DEF_STMT (t);
   if (gimple_assign_single_p (g))
-	return gimple_assign_rhs1 (g);
+	return g;
 }
-  return NULL_TREE;
+  return NULL;
 }
 
 /* Tree triplet for vptr_check_map.  */
@@ -618,11 +618,30 @@ maybe_optimize_ubsan_vptr_ifn (class sanopt_ctx *ctx, gimple *stmt)
   return true;
 }
 
+/* Checks whether value of T in CHECK and USE is the same.  */
+
+static bool same_value_p (gimple *check, gimple *use, tree t)
+{
+  tree check_vuse = gimple_vuse (check);
+  tree use_vuse = gimple_vuse (use);
+
+  if (TREE_CODE (t) == SSA_NAME
+  || is_gimple_min_invariant (t)
+  || ! use_vuse)
+return true;
+
+  if (check_vuse == use_vuse)
+return true;
+
+  return false;
+}
+
 /* Returns TRUE if ASan check of length LEN in block BB can be removed
if preceded by checks in V.  */
 
 static bool
-can_remove_asan_check (auto_vec &v, tree len, basic_block bb)
+can_remove_asan_check (auto_vec &v, tree len, basic_block bb,
+		   gimple *base_stmt, tree base_addr)
 {
   unsigned int i;
   gimple *g;
@@ -674,8 +693,10 @@ can_remove_asan_check (auto_vec &v, tree len, basic_block bb)
 
 	  last_bb = imm;
 	}
-  if (last_bb == gbb)
-	remove = true;
+  if (last_bb != gbb)
+	break;
+  // In case of base_addr residing in memory we also need to check aliasing
+  remove = ! base_addr || same_value_p (g, base_stmt, base_addr);
   break;
 }
 
@@ -718,7 +739,8 @@ maybe_optimize_asan_check_ifn (class sanopt_ctx *ctx, gimple *stmt)
 
   auto_vec *ptr_checks = &ctx->asan_check_map.get_or_insert (ptr);
 
-  tree base_addr = maybe_get_single_definition (ptr);
+  gimple *base_stmt = maybe_get_single_definition (ptr);
+  tree base_addr = base_stmt ? gimple_assign_rhs1 (base_stmt) : NULL_TREE;
   auto_vec *base_checks = NULL;
   if (base_addr)
 {
@@ -747,11 +769,11 @@ maybe_optimize_asan_check_ifn (class sanopt_ctx *ctx, gimple *stmt)
   bool remove = false;
 
   if (ptr_checks)
-remove = can_remove_asan_check (*ptr_checks, len, bb);
+remove = can_remove_asan_check (*ptr_checks, len, bb, NULL, NULL);
 
   if (!remove && base_checks)
 /* Try with base address as well.  */
-remove = can_remove_asan_check (*base_checks, len, bb);
+remove = can_remove_asan_check (*base_checks, len, bb, base_stmt, base_addr);
 
   if (!remove)
 {
diff --git a/gcc/testsuite/c-c++-common/asan/pr106558.c b/gcc/testsuite/c-c++-common/asan/pr106558.c
new file mode 100644
index 000..d82b2dc7a83
--- /dev/null
+++ b/gcc/testsuite/c-c++-common/asan/pr106558.c
@@ -0,0 +1,23 @@
+/* { dg-do run } */
+/* { dg-options "-w -fpermissive" } */
+/* { dg-shouldfail "asan" } */
+
+int a;
+int *b = &a;
+int **c = &b;
+int d[1];
+int *e = &d[1];
+
+static int f(int *g) {
+  *b = e;
+  *c = e;
+  *b = 2;
+  *g = 2;
+}
+
+int main() {
+f(b);
+return *b;
+}
+
+/* { dg-output "AddressSanitizer: global-buffer-overflow on address" } */
-- 
2.17.1

Re: [COMMITTED] Be even more conservative in intersection of NANs.

[Richard Biener via Gcc-patches]

On Mon, Sep 5, 2022 at 1:45 PM Aldy Hernandez  wrote:
>
> On Mon, Sep 5, 2022 at 12:38 PM Richard Biener
>  wrote:
> >
> > On Mon, Sep 5, 2022 at 12:24 PM Aldy Hernandez  wrote:
> > >
> > > On Mon, Sep 5, 2022 at 11:53 AM Richard Biener
> > >  wrote:
> > > >
> > > > On Mon, Sep 5, 2022 at 11:41 AM Aldy Hernandez  wrote:
> > > > >
> > > > > On Mon, Sep 5, 2022 at 11:18 AM Richard Biener
> > > > >  wrote:
> > > > > >
> > > > > > On Mon, Sep 5, 2022 at 11:12 AM Aldy Hernandez  
> > > > > > wrote:
> > > > > > >
> > > > > > > On Mon, Sep 5, 2022 at 11:06 AM Jakub Jelinek  
> > > > > > > wrote:
> > > > > > > >
> > > > > > > > On Mon, Sep 05, 2022 at 11:00:54AM +0200, Richard Biener wrote:
> > > > > > > > > On Mon, Sep 5, 2022 at 8:24 AM Aldy Hernandez via Gcc-patches
> > > > > > > > >  wrote:
> > > > > > > > > >
> > > > > > > > > > Intersecting two ranges where one is a NAN is keeping the 
> > > > > > > > > > sign bit of
> > > > > > > > > > the NAN range.  This is not correct as the sign bits may 
> > > > > > > > > > not match.
> > > > > > > > > >
> > > > > > > > > > I think the only time we're absolutely sure about the 
> > > > > > > > > > intersection of
> > > > > > > > > > a NAN and something else, is when both are a NAN with 
> > > > > > > > > > exactly the same
> > > > > > > > > > properties (sign bit).  If we're intersecting two NANs of 
> > > > > > > > > > differing
> > > > > > > > > > sign, we can decide later whether that's undefined or just 
> > > > > > > > > > a NAN with
> > > > > > > > > > no known sign.  For now I've done the latter.
> > > > > > > > > >
> > > > > > > > > > I'm still mentally working on intersections involving NANs, 
> > > > > > > > > > especially
> > > > > > > > > > if we want to keep track of signbits.  For now, let's be 
> > > > > > > > > > extra careful
> > > > > > > > > > and only do things we're absolutely sure about.
> > > > > > > > > >
> > > > > > > > > > Later we may want to fold the intersect of [NAN,NAN] and 
> > > > > > > > > > say [3,5]
> > > > > > > > > > with the posibility of NAN, to a NAN, but I'm not 100% sure.
> > > > > > > > >
> > > > > > > > > The intersection of [NAN, NAN] and [3, 5] is empty.  The 
> > > > > > > > > intersection
> > > > > > > > > of [NAN, NAN] and VARYING is [NAN, NAN].
> > > > > > > >
> > > > > > > > I think [3.0, 5.0] printed that way currently means U maybe NAN,
> > > > > > > > it would be [3.0, 5.0] !NAN if it was known not to be NAN.
> > > > > > >
> > > > > > > Right.  I don't print any of the "maybe" properties, just if 
> > > > > > > they're
> > > > > > > definitely set or definitely clear.  I'm open to suggestions as 
> > > > > > > to how
> > > > > > > to display them.  Perhaps NAN, !NAN, ?NAN.
> > > > > >
> > > > > > There's no NAN tristate.  Your "definitely NAN" would be simply
> > > > > > ][ NAN, that is, the value range only contains NAN.  Your !NAN
> > > > > > is  and non NAN.  Likewise for the sign, the
> > > > > > range either includes -NAN and NAN or one or none of those.
> > > > > > For signed zeros you either have [-0, upper-bound] or [0, 
> > > > > > upper-bound]
> > > > > > where it either includes both -0 and 0 or just one of them
> > > > >
> > > > > But there is a tristate.  We may definitely have a NAN, definitely not
> > > > > have a NAN, or the state of the NAN is unknown.
> > > >
> > > > Sure.  But we are talking about sets of values a variable can have
> > > > (a value "range" where "range" is a bit misleading for something
> > > > like a NAN).  The set of possible values either includes
> > > > NAN (or -NAN and +NAN) or it doesn't include NAN (or -NAN and +NAN).
> > > > A set cannot include or not include a "maybe NAN".
> > > >
> > > > >  Say [3,5] ?NAN.
> > > > > That's [3,5] with the possibility of a NAN.  On the true side of x >=
> > > > > 5.0, we'd have [5.0, INF] !NAN.  On the false side we'd have [-INF,
> > > > > 5.0] ?NAN.
> > > >
> > > > On the true side of x >= 5.0 the set of values is described by
> > > > the [5., +INF] range.  On the false side the set is described
> > > > by the union of the range [-INF, 5.0] and the { -NAN, +NAN }
> > > > set.
> > > >
> > > > There's no may-NAN.  There's also no ?4.0, the range either
> > > > includes 4.0 or it doesn't.
> > >
> > > Ah, ok.  I see where the confusion lies.  You're missing that we don't
> > > have sub-ranges like we do for irange.  We only have two endpoints and
> > > a set of flags.  So we can't represent [3,4] U NAN "elegantly".
> > > However, we can do it with [3,4] ?NAN.  This is by design, but not
> > > permanent.  I don't have infinite time to work on frange on this cycle
> > > (I have other things like wide-ints conversion, prange, removal of
> > > legacy, etc etc), so I wanted something that worked with endpoints,
> > > signs, and NANs, that's about it.  If at a later time we decide to go
> > > full throttle with the ability to represent sub-ranges, we can do so.
> > > Heck, you're welcome to try-- just let me finish the initial
> > > implementati

[PATCH] openmp: Introduce gimple_omp_ordered_standalone_p

[Jakub Jelinek via Gcc-patches]

Hi!

On Sat, Sep 03, 2022 at 10:07:27AM +0200, Jakub Jelinek via Gcc-patches wrote:
> Incrementally, I'd like to change the way we differentiate between
> stand-alone and block-associated ordered constructs, because the current
> way of looking for presence of doacross clause doesn't work well if those
> clauses are removed because they had been invalid (wrong syntax or
> unknown variables in it etc.)

The following, so far only lightly tested, patch implements that.

Will commit if it passes full bootstrap/regtest on x86_64-linux and
i686-linux overnight.

2022-09-05  Jakub Jelinek  

gcc/
* gimple.h (enum gf_mask): Add GF_OMP_ORDERED_STANDALONE enumerator.
(gimple_omp_subcode):  Use GIMPLE_OMP_ORDERED instead of
GIMPLE_OMP_TEAMS as upper bound.
(gimple_omp_ordered_standalone_p, gimple_omp_ordered_standalone): New
inline functions.
* gimplify.cc (find_standalone_omp_ordered): Look for OMP_ORDERED with
NULL OMP_ORDERED_BODY rather than with OMP_DOACROSS clause.
(gimplify_expr): Call gimple_omp_ordered_standalone for OMP_ORDERED
with NULL OMP_ORDERED_BODY.
* omp-low.cc (check_omp_nesting_restrictions): Use
gimple_omp_ordered_standalone_p test instead of
omp_find_clause (..., OMP_CLAUSE_DOACROSS).
(lower_omp_ordered): Likewise.
* omp-expand.cc (expand_omp, build_omp_regions_1,
omp_make_gimple_edges): Likewise.
gcc/cp/
* pt.cc (tsubst_expr) : If OMP_BODY was NULL, keep
it NULL after instantiation too.
gcc/testsuite/
* c-c++-common/gomp/sink-3.c: Don't expect a superfluous error during
error recovery.
* c-c++-common/gomp/doacross-6.c (foo): Add further tests.

--- gcc/gimple.h.jj 2022-06-27 11:18:02.682058403 +0200
+++ gcc/gimple.h2022-09-05 13:47:21.009761168 +0200
@@ -194,6 +194,7 @@ enum gf_mask {
 GF_OMP_RETURN_NOWAIT   = 1 << 0,
 
 GF_OMP_SECTION_LAST= 1 << 0,
+GF_OMP_ORDERED_STANDALONE   = 1 << 0,
 GF_OMP_ATOMIC_MEMORY_ORDER  = (1 << 6) - 1,
 GF_OMP_ATOMIC_NEED_VALUE   = 1 << 6,
 GF_OMP_ATOMIC_WEAK = 1 << 7,
@@ -2312,7 +2313,7 @@ static inline unsigned
 gimple_omp_subcode (const gimple *s)
 {
   gcc_gimple_checking_assert (gimple_code (s) >= GIMPLE_OMP_ATOMIC_LOAD
- && gimple_code (s) <= GIMPLE_OMP_TEAMS);
+ && gimple_code (s) <= GIMPLE_OMP_ORDERED);
   return s->subcode;
 }
 
@@ -2402,6 +2403,27 @@ gimple_omp_section_set_last (gimple *g)
 }
 
 
+/* Return true if OMP ordered construct is stand-alone
+   (G has the GF_OMP_ORDERED_STANDALONE flag set).  */
+
+static inline bool
+gimple_omp_ordered_standalone_p (const gimple *g)
+{
+  GIMPLE_CHECK (g, GIMPLE_OMP_ORDERED);
+  return (gimple_omp_subcode (g) & GF_OMP_ORDERED_STANDALONE) != 0;
+}
+
+
+/* Set the GF_OMP_ORDERED_STANDALONE flag on G.  */
+
+static inline void
+gimple_omp_ordered_standalone (gimple *g)
+{
+  GIMPLE_CHECK (g, GIMPLE_OMP_ORDERED);
+  g->subcode |= GF_OMP_ORDERED_STANDALONE;
+}
+
+
 /* Return true if OMP parallel statement G has the
GF_OMP_PARALLEL_COMBINED flag set.  */
 
--- gcc/gimplify.cc.jj  2022-09-03 09:41:34.823006434 +0200
+++ gcc/gimplify.cc 2022-09-05 13:37:00.158143869 +0200
@@ -12427,7 +12427,7 @@ gimplify_omp_taskloop_expr (tree type, t
 }
 
 /* Helper function of gimplify_omp_for, find OMP_ORDERED with
-   OMP_CLAUSE_DOACROSS clause inside of OMP_FOR's body.  */
+   null OMP_ORDERED_BODY inside of OMP_FOR's body.  */
 
 static tree
 find_standalone_omp_ordered (tree *tp, int *walk_subtrees, void *)
@@ -12435,7 +12435,7 @@ find_standalone_omp_ordered (tree *tp, i
   switch (TREE_CODE (*tp))
 {
 case OMP_ORDERED:
-  if (omp_find_clause (OMP_ORDERED_CLAUSES (*tp), OMP_CLAUSE_DOACROSS))
+  if (OMP_ORDERED_BODY (*tp) == NULL_TREE)
return *tp;
   break;
 case OMP_SIMD:
@@ -15839,6 +15839,9 @@ gimplify_expr (tree *expr_p, gimple_seq
break;
  case OMP_ORDERED:
g = gimplify_omp_ordered (*expr_p, body);
+   if (OMP_BODY (*expr_p) == NULL_TREE
+   && gimple_code (g) == GIMPLE_OMP_ORDERED)
+ gimple_omp_ordered_standalone (g);
break;
  case OMP_MASKED:
gimplify_scan_omp_clauses (&OMP_MASKED_CLAUSES (*expr_p),
--- gcc/omp-low.cc.jj   2022-09-03 09:41:34.827006378 +0200
+++ gcc/omp-low.cc  2022-09-05 13:24:30.796236971 +0200
@@ -3718,7 +3718,7 @@ check_omp_nesting_restrictions (gimple *
  "a loop region with an % clause");
return false;
  }
-   if (omp_find_clause (c, OMP_CLAUSE_DOACROSS) == NULL_TREE)
+   if (!gimple_omp_ordered_standalone_p (stmt))
  {
if (OMP_CLAUSE_ORDERED_DOACROSS (o))
  {
@@ -9989,8 +9989,7 @@ lower_omp_ordered (gimple_stmt_iterator
   bool threads = om

Re: [PATCH][DOCS] Mention removed ports in GCC 13.

[Gerald Pfeifer]

On Fri, 26 Aug 2022, Richard Biener via Gcc-patches wrote:
>> Ready for master?
> OK

Actually both Richi and me missed a little detail:

>> -  ...
>> +The support for the cr16-elf, 
>> tilegx*-linux and tilepro*-linux
>> +  configurations has been removed.
>> + ^
^

The patch added one  plus two s - fixed thusly.

Gerald


commit 0d66c0f73e9c54536070346bd4d52f61132ba012
Author: Gerald Pfeifer 
Date:   Mon Sep 5 20:28:57 2022 +0800

gcc-13: Remove extraneous  under Caveats

This snuck in via 79ecba7b which added two s instead of one.

diff --git a/htdocs/gcc-13/changes.html b/htdocs/gcc-13/changes.html
index 3d3d012c..5b336e04 100644
--- a/htdocs/gcc-13/changes.html
+++ b/htdocs/gcc-13/changes.html
@@ -35,7 +35,6 @@ a work-in-progress.
   -gstabs and -gxcoff options) has been removed.
   (This means the dbx debugger is no longer
   supported, either.)
-
 
 
 

Re: [PATCH] libgo: Access to glibc-specific field in struct sigevent

[Sören Tempel via Gcc-patches]

Hello Ian,

Have you had the chance to look at this yet?

Let me know if there is a better way to do this.

Greetings,
Sören

Sören Tempel  wrote:
> Hi Ian,
> 
> Thanks for your input!
> 
> I am not familiar with Go runtime internals at all, but the patch below
> at least compiles for me. Let me know if this works for you too / if
> there is a better way to do this. The untyped uintptr_t seems to be
> necessary as otherwise I encountered errors about &sevp escaping to the
> heap.
> 
> Sincerely,
> Sören
> 
> diff --git a/libgo/go/runtime/os_linux.go b/libgo/go/runtime/os_linux.go
> index 96fb1788..6653d85e 100644
> --- a/libgo/go/runtime/os_linux.go
> +++ b/libgo/go/runtime/os_linux.go
> @@ -22,6 +22,8 @@ type mOS struct {
> profileTimerValid uint32
>  }
> 
> +func setProcID(uintptr, int32)
> +
>  func getProcID() uint64 {
> return uint64(gettid())
>  }
> @@ -365,7 +367,7 @@ func setThreadCPUProfiler(hz int32) {
> var sevp _sigevent
> sevp.sigev_notify = _SIGEV_THREAD_ID
> sevp.sigev_signo = _SIGPROF
> -   *((*int32)(unsafe.Pointer(&sevp._sigev_un))) = int32(mp.procid)
> +   setProcID(uintptr(unsafe.Pointer(&sevp)), int32(mp.procid))
> ret := timer_create(_CLOCK_THREAD_CPUTIME_ID, &sevp, &timerid)
> if ret != 0 {
> // If we cannot create a timer for this M, leave 
> profileTimerValid false
> diff --git a/libgo/runtime/go-signal.c b/libgo/runtime/go-signal.c
> index 528d9b6d..347b24e2 100644
> --- a/libgo/runtime/go-signal.c
> +++ b/libgo/runtime/go-signal.c
> @@ -183,6 +183,16 @@ setSigactionHandler(struct sigaction* sa, uintptr 
> handler)
> sa->sa_sigaction = (void*)(handler);
>  }
> 
> +void setProcID(uintptr_t, int32_t)
> +   __asm__ (GOSYM_PREFIX "runtime.setProcID");
> +
> +void
> +setProcID(uintptr_t ptr, int32_t v)
> +{
> +   struct sigevent *s = (void *)ptr;
> +   s->sigev_notify_thread_id = v;
> +}
> +
>  // C code to fetch values from the siginfo_t and ucontext_t pointers
>  // passed to a signal handler.
> 
> Ian Lance Taylor  wrote:
> > On Fri, Aug 12, 2022 at 10:21 AM Sören Tempel  
> > wrote:
> > >
> > > This is one of the few remaining issues regarding musl compatibility for
> > > gofrontend. Unfortunately, I am not sure how to best fix this one. Hence
> > > reporting it here.
> > >
> > > The setThreadCPUProfiler implementation in libgo/go/runtime/os_linux.go
> > > contains the following code:
> > >
> > > var sevp _sigevent
> > > sevp.sigev_notify = _SIGEV_THREAD_ID
> > > sevp.sigev_signo = _SIGPROF
> > > *((*int32)(unsafe.Pointer(&sevp._sigev_un))) = int32(mp.procid)
> > >
> > > I am not entirely sure, but I assume the last line is supposed to access
> > > the thread ID in struct sigevent. Unfortunately, it does so via the
> > > glibc-specific _sigev_un member which doesn't work on musl libc (the
> > > union is named __sev_fields on musl and hence causes a build failure).
> > >
> > > A portable way to access the thread ID in struct sigevent is via
> > > sigev_notify_thread_id which is documented in timer_create(2). This is a
> > > macro provided in siginfo.h from linux-headers for glibc [1] and in
> > > signal.h for musl [2]. However, since it is macro it probably requires a
> > > C wrapper function in order to be usable in libgo. Would be possible to
> > > add that somehow to libgo or is there an alternative feasible solution
> > > for this issue?
> > 
> > I think you're right that a tiny C function is the way to go here.
> > 
> > Ian

[PATCH] debug () for predicates

[Richard Biener via Gcc-patches]

The following adds a debug () member to the predicate class.

Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.

Richard.

* gimple-predicate-analysis.h (predicate::debug): New.
(predicate::dump): Add FILE * argument, add base overload.
* gimple-predicate-analysis.cc (debug): New.
(dump_pred_info): Add FILE * argument.
(dump_pred_chain): Likewise.
(predicate::dump): Split out preamble into overload.  Add
FILE * argument.
(predicate::debug): New.
(predicate::simplify): Adjust.
(predicate::normalize): Likewise.
(predicate::init_from_control_deps): Likewise.
---
 gcc/gimple-predicate-analysis.cc | 82 +++-
 gcc/gimple-predicate-analysis.h  |  4 +-
 2 files changed, 52 insertions(+), 34 deletions(-)

diff --git a/gcc/gimple-predicate-analysis.cc b/gcc/gimple-predicate-analysis.cc
index a754ff0a029..5629a6dc277 100644
--- a/gcc/gimple-predicate-analysis.cc
+++ b/gcc/gimple-predicate-analysis.cc
@@ -150,34 +150,34 @@ format_edge_vecs (const vec eva[], unsigned n)
   return str;
 }
 
-/* Dump a single pred_info to DUMP_FILE.  */
+/* Dump a single pred_info to F.  */
 
 static void
-dump_pred_info (const pred_info &pred)
+dump_pred_info (FILE *f, const pred_info &pred)
 {
   if (pred.invert)
-fprintf (dump_file, "NOT (");
-  print_generic_expr (dump_file, pred.pred_lhs);
-  fprintf (dump_file, " %s ", op_symbol_code (pred.cond_code));
-  print_generic_expr (dump_file, pred.pred_rhs);
+fprintf (f, "NOT (");
+  print_generic_expr (f, pred.pred_lhs);
+  fprintf (f, " %s ", op_symbol_code (pred.cond_code));
+  print_generic_expr (f, pred.pred_rhs);
   if (pred.invert)
-fputc (')', dump_file);
+fputc (')', f);
 }
 
-/* Dump a pred_chain to DUMP_FILE.  */
+/* Dump a pred_chain to F.  */
 
 static void
-dump_pred_chain (const pred_chain &chain)
+dump_pred_chain (FILE *f, const pred_chain &chain)
 {
   unsigned np = chain.length ();
   for (unsigned j = 0; j < np; j++)
 {
   if (j > 0)
-   fprintf (dump_file, " AND (");
+   fprintf (f, " AND (");
   else
-   fputc ('(', dump_file);
-  dump_pred_info (chain[j]);
-  fputc (')', dump_file);
+   fputc ('(', f);
+  dump_pred_info (f, chain[j]);
+  fputc (')', f);
 }
 }
 
@@ -1405,7 +1405,7 @@ predicate::simplify (gimple *use_or_def, bool is_use)
   if (dump_file && dump_flags & TDF_DETAILS)
 {
   fprintf (dump_file, "Before simplication ");
-  dump (use_or_def, is_use ? "[USE]:\n" : "[DEF]:\n");
+  dump (dump_file, use_or_def, is_use ? "[USE]:\n" : "[DEF]:\n");
 }
 
   unsigned n = m_preds.length ();
@@ -1641,7 +1641,7 @@ predicate::normalize (gimple *use_or_def, bool is_use)
   if (dump_file && dump_flags & TDF_DETAILS)
 {
   fprintf (dump_file, "Before normalization ");
-  dump (use_or_def, is_use ? "[USE]:\n" : "[DEF]:\n");
+  dump (dump_file, use_or_def, is_use ? "[USE]:\n" : "[DEF]:\n");
 }
 
   predicate norm_preds;
@@ -1658,7 +1658,7 @@ predicate::normalize (gimple *use_or_def, bool is_use)
   if (dump_file)
 {
   fprintf (dump_file, "After normalization ");
-  dump (use_or_def, is_use ? "[USE]:\n" : "[DEF]:\n");
+  dump (dump_file, use_or_def, is_use ? "[USE]:\n" : "[DEF]:\n");
 }
 }
 
@@ -1748,7 +1748,7 @@ predicate::init_from_control_deps (const vec 
*dep_chains,
{
  fprintf (dump_file, "%d -> %d: one_pred = ",
   e->src->index, e->dest->index);
- dump_pred_info (one_pred);
+ dump_pred_info (dump_file, one_pred);
  fputc ('\n', dump_file);
}
 
@@ -1845,7 +1845,7 @@ predicate::init_from_control_deps (const vec 
*dep_chains,
 }
 
   if (DEBUG_PREDICATE_ANALYZER && dump_file)
-dump (NULL, "");
+dump (dump_file);
 }
 
 /* Store a PRED in *THIS.  */
@@ -1858,35 +1858,51 @@ predicate::push_pred (const pred_info &pred)
   m_preds.safe_push (chain);
 }
 
-/* Dump predicates in *THIS for STMT prepended by MSG.  */
+/* Dump predicates in *THIS to F.  */
 
 void
-predicate::dump (gimple *stmt, const char *msg) const
+predicate::dump (FILE *f) const
 {
-  fprintf (dump_file, "%s", msg);
-  if (stmt)
-{
-  fputc ('\t', dump_file);
-  print_gimple_stmt (dump_file, stmt, 0);
-  fprintf (dump_file, "  is conditional on:\n");
-}
-
   unsigned np = m_preds.length ();
   if (np == 0)
 {
-  fprintf (dump_file, "\tTRUE (empty)\n");
+  fprintf (f, "\tTRUE (empty)\n");
   return;
 }
 
   for (unsigned i = 0; i < np; i++)
 {
   if (i > 0)
-   fprintf (dump_file, "\tOR (");
+   fprintf (f, "\tOR (");
   else
-   fprintf (dump_file, "\t(");
-  dump_pred_chain (m_preds[i]);
-  fprintf (dump_file, ")\n");
+   fprintf (f, "\t(");
+  dump_pred_chain (f, m_preds[i]);
+  fprintf (f, ")\n");
+}
+}
+
+/* Dump predicates in *THIS to stder

[PATCH] Unify MAX_POSTDOM_CHECK and --param uninit-control-dep-attempts

[Richard Biener via Gcc-patches]

The following unifies both limits, in particular the MAX_POSTDOM_CHECK
tends to be too low and is not user-controllable.

Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.

Richard.

* gimple-predicate-analysis.cc (MAX_POSTDOM_CHECK): Remove.
(compute_control_dep_chain): Move uninit-control-dep-attempts
checking where it also counts the post-dominator check
invocations.
---
 gcc/gimple-predicate-analysis.cc | 29 -
 1 file changed, 12 insertions(+), 17 deletions(-)

diff --git a/gcc/gimple-predicate-analysis.cc b/gcc/gimple-predicate-analysis.cc
index 5629a6dc277..6684aa6c179 100644
--- a/gcc/gimple-predicate-analysis.cc
+++ b/gcc/gimple-predicate-analysis.cc
@@ -52,10 +52,6 @@
 #define MAX_NUM_CHAINS 8
 #define MAX_CHAIN_LEN 5
 
-/* When enumerating paths between two blocks this limits the number of
-   post-dominator skips between two edges possibly defining a predicate.  */
-#define MAX_POSTDOM_CHECK 8
-
 /* The limit for the number of switch cases when we do the linear search
for the case corresponding to an edge.  */
 #define MAX_SWITCH_CASES 40
@@ -1010,15 +1006,6 @@ compute_control_dep_chain (basic_block dom_bb, 
const_basic_block dep_bb,
   if (single_succ_p (dom_bb))
 return false;
 
-  if (*num_calls > (unsigned)param_uninit_control_dep_attempts)
-{
-  if (dump_file)
-   fprintf (dump_file, "param_uninit_control_dep_attempts exceeded: %u\n",
-*num_calls);
-  return false;
-}
-  ++*num_calls;
-
   /* FIXME: Use a set instead.  */
   unsigned cur_chain_len = cur_cd_chain.length ();
   if (cur_chain_len > MAX_CHAIN_LEN)
@@ -1048,7 +1035,6 @@ compute_control_dep_chain (basic_block dom_bb, 
const_basic_block dep_bb,
   edge_iterator ei;
   FOR_EACH_EDGE (e, ei, dom_bb->succs)
 {
-  int post_dom_check = 0;
   if (e->flags & (EDGE_FAKE | EDGE_ABNORMAL | EDGE_DFS_BACK))
continue;
 
@@ -1088,6 +1074,17 @@ compute_control_dep_chain (basic_block dom_bb, 
const_basic_block dep_bb,
  if (in_region != 0 && !(cd_bb->flags & in_region))
break;
 
+ /* Count the number of steps we perform to limit compile-time.
+This should cover both recursion and the post-dominator walk.  */
+ if (*num_calls > (unsigned)param_uninit_control_dep_attempts)
+   {
+ if (dump_file)
+   fprintf (dump_file, "param_uninit_control_dep_attempts "
+"exceeded: %u\n", *num_calls);
+ return false;
+   }
+ ++*num_calls;
+
  /* Check if DEP_BB is indirectly control-dependent on DOM_BB.  */
  if (!single_succ_p (cd_bb)
  && compute_control_dep_chain (cd_bb, dep_bb, cd_chains,
@@ -1105,9 +1102,7 @@ compute_control_dep_chain (basic_block dom_bb, 
const_basic_block dep_bb,
  && single_succ_edge (cd_bb)->flags & EDGE_DFS_BACK)
break;
  cd_bb = get_immediate_dominator (CDI_POST_DOMINATORS, cd_bb);
- post_dom_check++;
- if (cd_bb == EXIT_BLOCK_PTR_FOR_FN (cfun)
- || post_dom_check > MAX_POSTDOM_CHECK)
+ if (cd_bb == EXIT_BLOCK_PTR_FOR_FN (cfun))
break;
}
   cur_cd_chain.pop ();
-- 
2.35.3

[PATCH] Remove MAX_SWITCH_CASES limit

[Richard Biener via Gcc-patches]

The following removes the MAX_SWITCH_CASES limit to fight quadraticness
when looking up case labels from edges.  Instead use the
{start,end}_recording_case_labels facility for that.  For it to be
usable I've exported get_cases_for_edge from tree-cfg.cc.

Bootstrapped on x86_64-unknown-linux-gnu, testing in progress.

Richard.

* tree-cfg.h (get_cases_for_edge): Declare.
* tree-cfg.cc (get_cases_for_edge): Export.
* tree-ssa-uninit.cc (execute_late_warn_uninitialized):
Start and end recording case labels.
* gimple-predicate-analysis.cc (MAX_SWITCH_CASES): Remove.
(predicate::init_from_control_deps): Use get_cases_for_edge.
---
 gcc/gimple-predicate-analysis.cc | 24 ++--
 gcc/tree-cfg.cc  |  2 +-
 gcc/tree-cfg.h   |  1 +
 gcc/tree-ssa-uninit.cc   |  4 
 4 files changed, 8 insertions(+), 23 deletions(-)

diff --git a/gcc/gimple-predicate-analysis.cc b/gcc/gimple-predicate-analysis.cc
index 6684aa6c179..681047deee7 100644
--- a/gcc/gimple-predicate-analysis.cc
+++ b/gcc/gimple-predicate-analysis.cc
@@ -52,10 +52,6 @@
 #define MAX_NUM_CHAINS 8
 #define MAX_CHAIN_LEN 5
 
-/* The limit for the number of switch cases when we do the linear search
-   for the case corresponding to an edge.  */
-#define MAX_SWITCH_CASES 40
-
 /* Return true if X1 is the negation of X2.  */
 
 static inline bool
@@ -1751,28 +1747,12 @@ predicate::init_from_control_deps (const vec 
*dep_chains,
}
  else if (gswitch *gs = dyn_cast (cond_stmt))
{
- tree l = NULL_TREE;
  /* Find the case label, but avoid quadratic behavior.  */
- if (gimple_switch_num_labels (gs) <= MAX_SWITCH_CASES)
-   for (unsigned idx = 0;
-idx < gimple_switch_num_labels (gs); ++idx)
- {
-   tree tl = gimple_switch_label (gs, idx);
-   if (e->dest == label_to_block (cfun, CASE_LABEL (tl)))
- {
-   if (!l)
- l = tl;
-   else
- {
-   l = NULL_TREE;
-   break;
- }
- }
- }
+ tree l = get_cases_for_edge (e, gs);
  /* If more than one label reaches this block or the case
 label doesn't have a contiguous range of values (like the
 default one) fail.  */
- if (!l || !CASE_LOW (l))
+ if (!l || CASE_CHAIN (l) || !CASE_LOW (l))
has_valid_pred = false;
  else if (!CASE_HIGH (l)
  || operand_equal_p (CASE_LOW (l), CASE_HIGH (l)))
diff --git a/gcc/tree-cfg.cc b/gcc/tree-cfg.cc
index 91ec33c80a4..bbe08357d6e 100644
--- a/gcc/tree-cfg.cc
+++ b/gcc/tree-cfg.cc
@@ -1305,7 +1305,7 @@ end_recording_case_labels (void)
 
Otherwise return NULL.  */
 
-static tree
+tree
 get_cases_for_edge (edge e, gswitch *t)
 {
   tree *slot;
diff --git a/gcc/tree-cfg.h b/gcc/tree-cfg.h
index cb67cdf87ac..95ec93e3a91 100644
--- a/gcc/tree-cfg.h
+++ b/gcc/tree-cfg.h
@@ -33,6 +33,7 @@ extern void init_empty_tree_cfg_for_function (struct function 
*);
 extern void init_empty_tree_cfg (void);
 extern void start_recording_case_labels (void);
 extern void end_recording_case_labels (void);
+extern tree get_cases_for_edge (edge, gswitch *);
 extern basic_block label_to_block (struct function *, tree);
 extern void cleanup_dead_labels (void);
 extern bool group_case_labels_stmt (gswitch *);
diff --git a/gcc/tree-ssa-uninit.cc b/gcc/tree-ssa-uninit.cc
index 29dc48c4a29..4a1c333d9cb 100644
--- a/gcc/tree-ssa-uninit.cc
+++ b/gcc/tree-ssa-uninit.cc
@@ -1402,6 +1402,9 @@ execute_late_warn_uninitialized (function *fun)
 
   timevar_push (TV_TREE_UNINIT);
 
+  /* Avoid quadratic beahvior when looking up case labels for edges.  */
+  start_recording_case_labels ();
+
   possibly_undefined_names = new hash_set;
   defined_args = new hash_map;
 
@@ -1432,6 +1435,7 @@ execute_late_warn_uninitialized (function *fun)
   possibly_undefined_names = NULL;
   delete defined_args;
   defined_args = NULL;
+  end_recording_case_labels ();
   free_dominance_info (CDI_POST_DOMINATORS);
   timevar_pop (TV_TREE_UNINIT);
 }
-- 
2.35.3

Re: [committed] openmp: Partial OpenMP 5.2 doacross and omp_cur_iteration support

[Tobias Burnus]

On 03.09.22 10:07, Jakub Jelinek wrote:

The following patch implements part of the OpenMP 5.2 changes related
to ordered loops ...


Fortran bits to it attached.

OK for mainline?

Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955
Fortran/openmp: Partial OpenMP 5.2 doacross and omp_cur_iteration support

Add the Fortran support to the ME/C/C++ commit
r13-2388-ga651e6d59188da8992f8bfae2df1cb4e6316f9e6

gcc/fortran/ChangeLog:

	* dump-parse-tree.cc (show_omp_namelist, show_omp_clauses): Handle
	omp_cur_iteration and distinguish doacross/depend:
	* gfortran.h (enum gfc_omp_depend_doacross_op): Renamed from
	gfc_omp_depend_op.
	(enum gfc_omp_depend_doacross_op): Add OMP_DOACROSS_SINK_FIRST,
	Rename OMP_DEPEND_SINK to OMP_DOACROSS_SINK.
	(gfc_omp_namelist) Handle renaming, rename depend_op to
	depend_doacross_op.
	(struct gfc_omp_clauses): Add doacross_source.
	* openmp.cc (gfc_match_omp_depend_sink): Renamed to ...
	(gfc_match_omp_doacross_sink): ... this; handle omp_all_memory.
	(enum omp_mask2): Add OMP_CLAUSE_DOACROSS.
	(gfc_match_omp_clauses): Handle 'doacross' and syntax changes to
	depend.
	(gfc_match_omp_depobj): Simplify as sink/source are now impossible.
	(gfc_match_omp_ordered_depend): Request OMP_CLAUSE_DOACROSS.
	(resolve_omp_clauses): Update sink/source checks.
	(gfc_resolve_omp_directive): Resolve EXEC_OMP_ORDERED clauses.
	* parse.cc (decode_omp_directive): Handle 'ordered doacross'.
	* trans-openmp.cc (gfc_trans_omp_clauses): Handle doacross.
	(gfc_trans_omp_do): Fix OMP_FOR_ORIG_DECLS handling if 'ordered'
	clause is present.
	(gfc_trans_omp_depobj): Update for member name change.

libgomp/ChangeLog:

	* libgomp.texi (OpenMP 5.2): Update doacross/omp_cur_iteration status.

gcc/testsuite/ChangeLog:

	* gfortran.dg/gomp/all-memory-1.f90: Update dg-error.
	* gfortran.dg/gomp/depend-iterator-2.f90: Likewise.
	* gfortran.dg/gomp/depobj-2.f90: Likewise.
	* gfortran.dg/gomp/doacross-5.f90: New test.
	* gfortran.dg/gomp/doacross-6.f90: New test.

 gcc/fortran/dump-parse-tree.cc |  38 +++-
 gcc/fortran/gfortran.h |  13 +-
 gcc/fortran/openmp.cc  | 218 +
 gcc/fortran/parse.cc   |   3 +-
 gcc/fortran/trans-openmp.cc|  35 ++--
 gcc/testsuite/gfortran.dg/gomp/all-memory-1.f90|   2 +-
 .../gfortran.dg/gomp/depend-iterator-2.f90 |   2 +-
 gcc/testsuite/gfortran.dg/gomp/depobj-2.f90|   6 +-
 gcc/testsuite/gfortran.dg/gomp/doacross-5.f90  |  88 +
 gcc/testsuite/gfortran.dg/gomp/doacross-6.f90  |  77 
 libgomp/libgomp.texi   |   5 +-
 11 files changed, 370 insertions(+), 117 deletions(-)

diff --git a/gcc/fortran/dump-parse-tree.cc b/gcc/fortran/dump-parse-tree.cc
index 5352008a63d..40c690c9ae8 100644
--- a/gcc/fortran/dump-parse-tree.cc
+++ b/gcc/fortran/dump-parse-tree.cc
@@ -1337,8 +1337,15 @@ show_omp_namelist (int list_type, gfc_omp_namelist *n)
 	  if (n->u2.ns != ns_iter)
 	{
 	  if (n != n2)
-		fputs (list_type == OMP_LIST_AFFINITY
-		   ? ") AFFINITY(" : ") DEPEND(", dumpfile);
+		{
+		  fputs (") ", dumpfile);
+		  if (list_type == OMP_LIST_AFFINITY)
+		fputs ("AFFINITY (", dumpfile);
+		  else if (n->u.depend_doacross_op == OMP_DOACROSS_SINK_FIRST)
+		fputs ("DOACROSS (", dumpfile);
+		  else
+		fputs ("DEPEND (", dumpfile);
+		}
 	  if (n->u2.ns)
 		{
 		  fputs ("ITERATOR(", dumpfile);
@@ -1374,7 +1381,7 @@ show_omp_namelist (int list_type, gfc_omp_namelist *n)
 	  default: break;
 	  }
   else if (list_type == OMP_LIST_DEPEND)
-	switch (n->u.depend_op)
+	switch (n->u.depend_doacross_op)
 	  {
 	  case OMP_DEPEND_IN: fputs ("in:", dumpfile); break;
 	  case OMP_DEPEND_OUT: fputs ("out:", dumpfile); break;
@@ -1385,10 +1392,14 @@ show_omp_namelist (int list_type, gfc_omp_namelist *n)
 	fputs ("mutexinoutset:", dumpfile);
 	break;
 	  case OMP_DEPEND_SINK_FIRST:
+	  case OMP_DOACROSS_SINK_FIRST:
 	fputs ("sink:", dumpfile);
 	while (1)
 	  {
-		fprintf (dumpfile, "%s", n->sym->name);
+		if (!n->sym)
+		  fputs ("omp_cur_iteration", dumpfile);
+		else
+		  fprintf (dumpfile, "%s", n->sym->name);
 		if (n->expr)
 		  {
 		fputc ('+', dumpfile);
@@ -1396,9 +1407,13 @@ show_omp_namelist (int list_type, gfc_omp_namelist *n)
 		  }
 		if (n->next == NULL)
 		  break;
-		else if (n->next->u.depend_op != OMP_DEPEND_SINK)
+		else if (n->next->u.depend_doacross_op != OMP_DOACROSS_SINK)
 		  {
-		fputs (") DEPEND(", dumpfile);
+		if (n->next->u.depend_doacross_op
+			== OMP_DOACROSS_SINK_FIRST)
+		  fputs (") DOACROSS(", dumpfile);
+		else
+		  fputs (") DEPEND(", dumpfile);
 		break;
 		  }
 		fput

Re: [PATCH V2] arm: add -static-pie support

[Andrea Corallo via Gcc-patches]

Lance Fredrickson via Gcc-patches  writes:

> Yes, this is a 1st submission.
> Yes, I guess I was going for DCO rules.
> I will look at running the test suite. Does this need to be done on
> the target? because my arm target is a measly dual core 1ghz embedded
> chip and low ram. Netgear R7000 router actually.

Hi Lance,

you should be able to use qemu to run arm-linux-gnueabihf binaries and
as a consequance the testsuite if you prefer.

BR

  Andrea

[pushed] aarch64: Remove lazy SIMD builtin initialisation

[Richard Sandiford via Gcc-patches]

At one time the aarch64 port registered the Advanced SIMD builtins
lazily, when we first encountered a set of target flags that includes
+simd.  These days we always initialise them at start-up, temporarily
forcing a conducive set of flags if necessary.

This patch removes some vestiges of the old way of doing things.

Tested on aarch64-linux-gnu & pushed.

Richard


gcc/
* config/aarch64/aarch64-protos.h
(aarch64_init_simd_builtins): Remove prototype.
* config/aarch64/aarch64-builtins.cc
(aarch64_simd_builtins_initialized_p): Delete.
(aarch64_init_simd_builtins): Make static.  Remove protection
against multiple calls.
* config/aarch64/aarch64-c.cc (aarch64_pragma_target_parse): Remove
lazy SIMD builtin initialization.
* config/aarch64/aarch64.cc
(aarch64_option_valid_attribute_p): Likewise.
---
 gcc/config/aarch64/aarch64-builtins.cc |  9 +
 gcc/config/aarch64/aarch64-c.cc| 13 -
 gcc/config/aarch64/aarch64-protos.h|  1 -
 gcc/config/aarch64/aarch64.cc  | 12 
 4 files changed, 1 insertion(+), 34 deletions(-)

diff --git a/gcc/config/aarch64/aarch64-builtins.cc 
b/gcc/config/aarch64/aarch64-builtins.cc
index f90fda4ca97..5eef5aaa402 100644
--- a/gcc/config/aarch64/aarch64-builtins.cc
+++ b/gcc/config/aarch64/aarch64-builtins.cc
@@ -1300,8 +1300,6 @@ aarch64_get_attributes (unsigned int f, machine_mode mode)
   return aarch64_add_attribute ("leaf", attrs);
 }
 
-static bool aarch64_simd_builtins_initialized_p = false;
-
 /* Due to the architecture not providing lane variant of the lane instructions
for fcmla we can't use the standard simd builtin expansion code, but we
still want the majority of the validation that would normally be done.  */
@@ -1586,14 +1584,9 @@ handle_arm_neon_h (void)
   aarch64_init_simd_intrinsics ();
 }
 
-void
+static void
 aarch64_init_simd_builtins (void)
 {
-  if (aarch64_simd_builtins_initialized_p)
-return;
-
-  aarch64_simd_builtins_initialized_p = true;
-
   aarch64_init_simd_builtin_types ();
 
   /* Strong-typing hasn't been implemented for all AdvSIMD builtin intrinsics.
diff --git a/gcc/config/aarch64/aarch64-c.cc b/gcc/config/aarch64/aarch64-c.cc
index 3d2fb5ec2ef..52ed4a218a8 100644
--- a/gcc/config/aarch64/aarch64-c.cc
+++ b/gcc/config/aarch64/aarch64-c.cc
@@ -270,19 +270,6 @@ aarch64_pragma_target_parse (tree args, tree pop_target)
   if (pop_target)
 aarch64_save_restore_target_globals (pop_target);
 
-  /* Initialize SIMD builtins if we haven't already.
- Set current_target_pragma to NULL for the duration so that
- the builtin initialization code doesn't try to tag the functions
- being built with the attributes specified by any current pragma, thus
- going into an infinite recursion.  */
-  if (TARGET_SIMD)
-{
-  tree saved_current_target_pragma = current_target_pragma;
-  current_target_pragma = NULL;
-  aarch64_init_simd_builtins ();
-  current_target_pragma = saved_current_target_pragma;
-}
-
   return true;
 }
 
diff --git a/gcc/config/aarch64/aarch64-protos.h 
b/gcc/config/aarch64/aarch64-protos.h
index 99af10ad534..5ecdb8af863 100644
--- a/gcc/config/aarch64/aarch64-protos.h
+++ b/gcc/config/aarch64/aarch64-protos.h
@@ -907,7 +907,6 @@ void aarch64_sve_expand_vector_init (rtx, rtx);
 void aarch64_init_cumulative_args (CUMULATIVE_ARGS *, const_tree, rtx,
   const_tree, unsigned, bool = false);
 void aarch64_init_expanders (void);
-void aarch64_init_simd_builtins (void);
 void aarch64_emit_call_insn (rtx);
 void aarch64_register_pragmas (void);
 void aarch64_relayout_simd_types (void);
diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
index b12f13f4f22..2311ad0e2b8 100644
--- a/gcc/config/aarch64/aarch64.cc
+++ b/gcc/config/aarch64/aarch64.cc
@@ -18898,18 +18898,6 @@ aarch64_option_valid_attribute_p (tree fndecl, tree, 
tree args, int)
   if (ret)
 {
   aarch64_override_options_internal (&global_options);
-  /* Initialize SIMD builtins if we haven't already.
-Set current_target_pragma to NULL for the duration so that
-the builtin initialization code doesn't try to tag the functions
-being built with the attributes specified by any current pragma, thus
-going into an infinite recursion.  */
-  if (TARGET_SIMD)
-   {
- tree saved_current_target_pragma = current_target_pragma;
- current_target_pragma = NULL;
- aarch64_init_simd_builtins ();
- current_target_pragma = saved_current_target_pragma;
-   }
   new_target = build_target_option_node (&global_options,
 &global_options_set);
 }
-- 
2.25.1

[PATCH][RFC] Unify MAX_NUM_CHAINS and MAX_CHAIN_LEN to --param uninit-max-predicate-size

[Richard Biener via Gcc-patches]

The following exposes the MAX_NUM_CHAINS and MAX_CHAIN_LEN to the user
by adding a --param uninit-max-predicate-size and re-doing the
limits on the whole predicate expression size rather than limiting
the number of OR and AND elements separately.  The following goes
a step further and for a single AND chain allows an arbitrary size,
limiting that only with the computational --param
uninit-control-dep-attempts parameter.  That might be a bit high
in practice, but it seems odd to continue searching for smaller and
smaller paths until we exhaust the search space or
uninit-control-dep-attempts.

I'm testing this on x86_64-unknown-linux-gnu at the moment.

Any comments?

Thanks,
Richard.

* params.opt (uninit-max-predicate-size): New.
* doc/invoke.texi (--param uninit-max-predicate-size): Document.
* gimple-predicate-analysis.h
(predicate::init_from_control_deps): Adjust.
* gimple-predicate-analysis.cc (MAX_NUM_CHAINS, MAX_CHAIN_LEN):
Remove.
(format_edge_vecs): Adjust.
(simple_control_dep_chain): Do not limit.
(compute_control_dep_chain): Adjust limiting to the overall
predicate expression size _after_ adding an element to the
vector of AND chains.
(predicate::init_from_control_deps): Adjust.
(uninit_analysis::init_use_preds): Likewise.
(uninit_analysis::init_from_phi_def): Likewise.
---
 gcc/doc/invoke.texi  |   3 +
 gcc/gimple-predicate-analysis.cc | 113 ---
 gcc/gimple-predicate-analysis.h  |   2 +-
 gcc/params.opt   |   4 ++
 4 files changed, 65 insertions(+), 57 deletions(-)

diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 9d662e35316..f7e791224dc 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -15537,6 +15537,9 @@ when comparing to the number of (scaled) blocks.
 Maximum number of nested calls to search for control dependencies
 during uninitialized variable analysis.
 
+@item uninit-max-predicate-size
+The maximum size of a predicate recorded during uninitialized variable 
analysis.
+
 @item fsm-scale-path-blocks
 Scale factor to apply to the number of blocks in a threading path
 when comparing to the number of (scaled) statements.
diff --git a/gcc/gimple-predicate-analysis.cc b/gcc/gimple-predicate-analysis.cc
index 681047deee7..3b92bc5f505 100644
--- a/gcc/gimple-predicate-analysis.cc
+++ b/gcc/gimple-predicate-analysis.cc
@@ -47,10 +47,13 @@
 
 #define DEBUG_PREDICATE_ANALYZER 1
 
-/* In our predicate normal form we have MAX_NUM_CHAINS or predicates
-   and in those MAX_CHAIN_LEN (inverted) and predicates.  */
-#define MAX_NUM_CHAINS 8
-#define MAX_CHAIN_LEN 5
+/* In our predicate normal form we have a vector of OR predicates
+   and in those a vector of (inverted) AND predicates.  Limit the
+   total amount of predicates to --param uninit-max-predicate-size
+   since we do O(n^2) operations on them.  Note we apply this limit
+   only after discovering the first sub-predicate, the whole
+   discovery process is limited by --param uninit-control-dep-attempts
+   which limits the computational work done during discovery.  */
 
 /* Return true if X1 is the negation of X2.  */
 
@@ -123,20 +126,19 @@ format_edge_vec (const vec &ev)
   return str;
 }
 
-/* Format the first N elements of the array of vector of edges EVA as
-   a string.  */
+/* Format the elements of the array of vector of edges EVA as a string.  */
 
 static std::string
-format_edge_vecs (const vec eva[], unsigned n)
+format_edge_vecs (const vec > &eva)
 {
   std::string str;
 
-  for (unsigned i = 0; i != n; ++i)
+  for (unsigned i = 0; i != eva.length (); ++i)
 {
   str += '{';
   str += format_edge_vec (eva[i]);
   str += '}';
-  if (i + 1 < n)
+  if (i + 1 < eva.length ())
str += ", ";
 }
   return str;
@@ -921,8 +923,7 @@ simple_control_dep_chain (vec& chain, basic_block 
from, basic_block to)
 return;
 
   basic_block src = to;
-  while (src != from
-&& chain.length () <= MAX_CHAIN_LEN)
+  while (src != from)
 {
   basic_block dest = src;
   src = get_immediate_dominator (CDI_DOMINATORS, src);
@@ -994,7 +995,7 @@ dfs_mark_dominating_region (edge exit, basic_block dom, int 
flag,
 
 static bool
 compute_control_dep_chain (basic_block dom_bb, const_basic_block dep_bb,
-  vec cd_chains[], unsigned *num_chains,
+  vec > &cd_chains, unsigned *chains_size,
   vec &cur_cd_chain, unsigned *num_calls,
   unsigned in_region = 0, unsigned depth = 0)
 {
@@ -1004,25 +1005,12 @@ compute_control_dep_chain (basic_block dom_bb, 
const_basic_block dep_bb,
 
   /* FIXME: Use a set instead.  */
   unsigned cur_chain_len = cur_cd_chain.length ();
-  if (cur_chain_len > MAX_CHAIN_LEN)
-{
-  if (dump_file)
-   fprintf (dump_file, "MAX_CHAIN_LEN exceeded: %u\n", cur_chain_len);
-
-  return false;

[PATCH][committed] aarch64: Suggest an -mcpu option when user passes CPU name to -march

[Kyrylo Tkachov via Gcc-patches]

Hi all,

This small patch helps users who confuse -march and -mcpu on AArch64.
Sometimes users pass -march with a CPU name, where they most likely wanted to
use -mcpu, which would select the right architecture features *and* tune for
their desired CPU. Currently we'll just error out with an unkown architecture
message and list the valid architecture options.
With this patch we check if their string matches a known CPU and suggest they
use an -mcpu option instead.

So compiling with -march=neoverse-n1 will now give the error:
cc1: error: unknown value 'neoverse-n1' for '-march'
cc1: note: valid arguments are: armv8-a armv8.1-a armv8.2-a armv8.3-a armv8.4-a 
armv8.5-a armv8.6-a armv8.7-a armv8.8-a armv8-r armv9-a
cc1: note: did you mean '-mcpu=neoverse-n1'?

Bootstrapped and tested on aarch64-none-linux-gnu.
Pushing to trunk.
Thanks,
Kyrill

gcc/ChangeLog:

* config/aarch64/aarch64.cc (aarch64_validate_march): Check if invalid 
arch
string is a valid -mcpu string and emit hint.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/spellcheck_10.c: New test.


mcpu.patch
Description: mcpu.patch

Re: [PATCH][committed] aarch64: Suggest an -mcpu option when user passes CPU name to -march

[Richard Earnshaw via Gcc-patches]

On 05/09/2022 14:35, Kyrylo Tkachov via Gcc-patches wrote:

Hi all,

This small patch helps users who confuse -march and -mcpu on AArch64.
Sometimes users pass -march with a CPU name, where they most likely wanted to
use -mcpu, which would select the right architecture features *and* tune for
their desired CPU. Currently we'll just error out with an unkown architecture
message and list the valid architecture options.
With this patch we check if their string matches a known CPU and suggest they
use an -mcpu option instead.

So compiling with -march=neoverse-n1 will now give the error:
cc1: error: unknown value 'neoverse-n1' for '-march'
cc1: note: valid arguments are: armv8-a armv8.1-a armv8.2-a armv8.3-a armv8.4-a 
armv8.5-a armv8.6-a armv8.7-a armv8.8-a armv8-r armv9-a
cc1: note: did you mean '-mcpu=neoverse-n1'?

Bootstrapped and tested on aarch64-none-linux-gnu.
Pushing to trunk.
Thanks,
Kyrill

gcc/ChangeLog:

* config/aarch64/aarch64.cc (aarch64_validate_march): Check if invalid 
arch
string is a valid -mcpu string and emit hint.

gcc/testsuite/ChangeLog:

* gcc.target/aarch64/spellcheck_10.c: New test.


What about the reverse case, passing an architecture to -mcpu?

R.

Re: [PATCH 1/2] Using pli(paddi) and rotate to build 64bit constants

[Segher Boessenkool]

On Mon, Sep 05, 2022 at 02:25:29PM +0800, Jiufu Guo wrote:
> > On Fri, Sep 02, 2022 at 02:56:21PM +0800, Jiufu Guo wrote:
> > Or force the testcase to use r0 some other way.  Well, "forcing" cannot
> > be done, but we can probably encourage it (via a local register asm for
> > example, or by tying the var to the output of an asm that is hard reg 0,
> > or perhaps there are other ways as well :-) )
> Specify register is very helpful here! Both below two cases could help
> register 0 to be selected for a variable.  Great!  Thanks!

> >> The reason of using "(?n)^\s+[a-z]" is to keep this test case pass no
> >> matter the splitter running before or after RA.
> >
> > Ah.  Some short comment in the testcase please?
> Thanks.  We can check individual instructions to check better asm
> pli+pli+rldimi is generated, since the splitter could run in split1 pass.

It's always a tradeoff: if we scan for too specific code the testcase
will need a lot of maintenance, and that does not scale.  If on the
other hand we do test less than we really want, well, that is less than
we really want to test :-)

The changes / additions we agreed to are preapproved btw.  But please
post the thing you eventually commit to the mailing list :-)


Segher

[PATCH] Decimal floats can never be an frange::singleton_p.

[Aldy Hernandez via Gcc-patches]

As Jakub mentioned in the PR, because many numbers have multiple
possible representations, we can't reliably return true here.

I'll commit this if tests pass.

I wonder if its worth even handling decimal floats in frange, since
there's a lot of things we can't represent.  I suppose even though we
could never propagate an actual value with VRP, we could fold
conditionals (symbolic and stuff outside ranges, etc) ??.  

Thoughts?

PR middle-end/106831

gcc/ChangeLog:

* value-range.cc (frange::singleton_p): Return false for
DECIMAL_FLOAT_TYPE_P.
---
 gcc/value-range.cc | 8 
 1 file changed, 8 insertions(+)

diff --git a/gcc/value-range.cc b/gcc/value-range.cc
index c3f668a811a..12a3750d078 100644
--- a/gcc/value-range.cc
+++ b/gcc/value-range.cc
@@ -647,6 +647,14 @@ frange::singleton_p (tree *result) const
   if (HONOR_NANS (m_type) && !get_nan ().no_p ())
return false;
 
+  // Because the significand is not normalized (there is no
+  // implicit leading "1").  Most values with less than 7
+  // significant digits have multiple possible representations.
+  // Zero has 192 possible representations (or twice that for
+  // signed zeros).
+  if (DECIMAL_FLOAT_TYPE_P (m_type))
+   return false;
+
   // Return the appropriate zero if known.
   if (HONOR_SIGNED_ZEROS (m_type) && zero_p ())
{
-- 
2.37.1

Re: [PATCH 1/1 V5] RISC-V: Support Zmmul extension

[Kito Cheng via Gcc-patches]

Binutils has been landing zmmul support, so committed with minor fixes.

On Fri, Jul 22, 2022 at 8:35 AM Kito Cheng  wrote:
>
> On Fri, Jul 22, 2022 at 2:43 AM Palmer Dabbelt  wrote:
> >
> > On Thu, 21 Jul 2022 02:03:35 PDT (-0700), gcc-patches@gcc.gnu.org wrote:
> > > LGTM, will merge once binuils part merge.
> >
> > +Nelson, in case he's already planning on handling those.  If not then
> > they're not in my inbox, so just poke me if you want me to review them.
> >
> > Also some comments on the patch below.
> >
> > >
> > > On Wed, Jul 13, 2022 at 10:14 AM  wrote:
> > >>
> > >> From: LiaoShihua 
> > >>
> > >> gcc/ChangeLog:
> > >>
> > >> * common/config/riscv/riscv-common.cc: Add Zmmul.
> > >> * config/riscv/riscv-opts.h (MASK_ZMMUL): New.
> > >> (TARGET_ZMMUL): Ditto.
> > >> * config/riscv/riscv.cc (riscv_option_override):Ditto.
> > >> * config/riscv/riscv.md: Add Zmmul
> > >> * config/riscv/riscv.opt: Ditto.
> > >>
> > >> gcc/testsuite/ChangeLog:
> > >>
> > >> * gcc.target/riscv/zmmul-1.c: New test.
> > >> * gcc.target/riscv/zmmul-2.c: New test.
> > >>
> > >> ---
> > >>  gcc/common/config/riscv/riscv-common.cc  |  3 +++
> > >>  gcc/config/riscv/riscv-opts.h|  3 +++
> > >>  gcc/config/riscv/riscv.cc|  8 +--
> > >>  gcc/config/riscv/riscv.md| 28 
> > >>  gcc/config/riscv/riscv.opt   |  3 +++
> > >>  gcc/testsuite/gcc.target/riscv/zmmul-1.c | 20 +
> > >>  gcc/testsuite/gcc.target/riscv/zmmul-2.c | 20 +
> > >>  7 files changed, 69 insertions(+), 16 deletions(-)
> > >>  create mode 100644 gcc/testsuite/gcc.target/riscv/zmmul-1.c
> > >>  create mode 100644 gcc/testsuite/gcc.target/riscv/zmmul-2.c
> > >>
> > >> diff --git a/gcc/common/config/riscv/riscv-common.cc 
> > >> b/gcc/common/config/riscv/riscv-common.cc
> > >> index 0e5be2ce105..20acc590b30 100644
> > >> --- a/gcc/common/config/riscv/riscv-common.cc
> > >> +++ b/gcc/common/config/riscv/riscv-common.cc
> > >> @@ -193,6 +193,8 @@ static const struct riscv_ext_version 
> > >> riscv_ext_version_table[] =
> > >>{"zvl32768b", ISA_SPEC_CLASS_NONE, 1, 0},
> > >>{"zvl65536b", ISA_SPEC_CLASS_NONE, 1, 0},
> > >>
> > >> +  {"zmmul", ISA_SPEC_CLASS_NONE, 1, 0},
> > >> +
> > >>/* Terminate the list.  */
> > >>{NULL, ISA_SPEC_CLASS_NONE, 0, 0}
> > >>  };
> > >> @@ -1148,6 +1150,7 @@ static const riscv_ext_flag_table_t 
> > >> riscv_ext_flag_table[] =
> > >>{"zvl32768b", &gcc_options::x_riscv_zvl_flags, MASK_ZVL32768B},
> > >>{"zvl65536b", &gcc_options::x_riscv_zvl_flags, MASK_ZVL65536B},
> > >>
> > >> +  {"zmmul", &gcc_options::x_riscv_zm_subext, MASK_ZMMUL},
> > >>
> > >>{NULL, NULL, 0}
> > >>  };
> > >> diff --git a/gcc/config/riscv/riscv-opts.h 
> > >> b/gcc/config/riscv/riscv-opts.h
> > >> index 1e153b3a6e7..9c7d69a6ea3 100644
> > >> --- a/gcc/config/riscv/riscv-opts.h
> > >> +++ b/gcc/config/riscv/riscv-opts.h
> > >> @@ -153,6 +153,9 @@ enum stack_protector_guard {
> > >>  #define TARGET_ZICBOM ((riscv_zicmo_subext & MASK_ZICBOM) != 0)
> > >>  #define TARGET_ZICBOP ((riscv_zicmo_subext & MASK_ZICBOP) != 0)
> > >>
> > >> +#define MASK_ZMMUL  (1 << 0)
> > >> +#define TARGET_ZMMUL((riscv_zm_subext & MASK_ZMMUL) != 0)
> > >> +
> > >>  /* Bit of riscv_zvl_flags will set contintuly, N-1 bit will set if 
> > >> N-bit is
> > >> set, e.g. MASK_ZVL64B has set then MASK_ZVL32B is set, so we can use
> > >> popcount to caclulate the minimal VLEN.  */
> > >> diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
> > >> index 2e83ca07394..9ad4181f35f 100644
> > >> --- a/gcc/config/riscv/riscv.cc
> > >> +++ b/gcc/config/riscv/riscv.cc
> > >> @@ -4999,10 +4999,14 @@ riscv_option_override (void)
> > >>/* The presence of the M extension implies that division instructions
> > >>   are present, so include them unless explicitly disabled.  */
> > >>if (TARGET_MUL && (target_flags_explicit & MASK_DIV) == 0)
> > >> -target_flags |= MASK_DIV;
> > >> +if(!TARGET_ZMMUL)
> > >> +  target_flags |= MASK_DIV;
> >
> > Not sure if I'm missing something here, but that doesn't look right: it
> > would mean that "-march=rv32im_zmmul" ends up without divide
> > instructions.  I think it's fine to just leave this as it was, we're not
> > setting TARGET_MUL from "-march...zmmul...", so this should all be OK.
>
> Oh, yeah, I missed that, that should just keek as it.
>
>
> >
> > >>else if (!TARGET_MUL && TARGET_DIV)
> > >>  error ("%<-mdiv%> requires %<-march%> to subsume the % 
> > >> extension");
> > >> -
> > >> +
> > >> +  if(TARGET_ZMMUL && !TARGET_MUL && TARGET_DIV)
> > >> +warning (0, "%<-mdiv%> cannot be used when % extension is 
> > >> present");
> >
> > That should already be getting caught by the check above, but even so
> > it's not quite the right error: "-march=rv32im_zmmul -mdiv" is fine,
> > it's just something like "-ma

Re: [PATCH] Decimal floats can never be an frange::singleton_p.

[Jakub Jelinek via Gcc-patches]

On Mon, Sep 05, 2022 at 03:47:01PM +0200, Aldy Hernandez wrote:
> As Jakub mentioned in the PR, because many numbers have multiple
> possible representations, we can't reliably return true here.
> 
> I'll commit this if tests pass.
> 
> I wonder if its worth even handling decimal floats in frange, since
> there's a lot of things we can't represent.  I suppose even though we
> could never propagate an actual value with VRP, we could fold
> conditionals (symbolic and stuff outside ranges, etc) ??.  
> 
> Thoughts?
> 
>   PR middle-end/106831
> 
> gcc/ChangeLog:
> 
>   * value-range.cc (frange::singleton_p): Return false for
>   DECIMAL_FLOAT_TYPE_P.
> ---
>  gcc/value-range.cc | 8 
>  1 file changed, 8 insertions(+)
> 
> diff --git a/gcc/value-range.cc b/gcc/value-range.cc
> index c3f668a811a..12a3750d078 100644
> --- a/gcc/value-range.cc
> +++ b/gcc/value-range.cc
> @@ -647,6 +647,14 @@ frange::singleton_p (tree *result) const
>if (HONOR_NANS (m_type) && !get_nan ().no_p ())
>   return false;
>  
> +  // Because the significand is not normalized (there is no
> +  // implicit leading "1").  Most values with less than 7
> +  // significant digits have multiple possible representations.
> +  // Zero has 192 possible representations (or twice that for
> +  // signed zeros).

The exact details (7, 192) are dependent on the format, for
decimal64 it is (16, 768) and for decimal128 (34, 12288).

Jakub

Re: [PATCH, OpenMP, Fortran] requires unified_shared_memory 2/2: insert USM allocators into libgfortran

[Chung-Lin Tang]

On 2022/8/15 7:15 PM, Chung-Lin Tang wrote:

On 2022/8/15 7:06 PM, Chung-Lin Tang wrote:


I know this is a big pile of yarn wrt how the main program/libgomp/libgfortran 
interacts, but it's
finally working. Again tested without regressions. Preparing to commit to 
devel/omp/gcc-12, and seeking
approval for mainline when the requires patches are in.


Just realized that I don't have the new testcases added in this patch.
Will supplement them later :P


Here's the USM allocator/libgfortran patch, with a libgomp.fortran testcase 
added.

Thanks,
Chung-Lin

2022-09-05  Chung-Lin Tang  

libgcc/
* Makefile.in (crtoffloadend$(objext)): Add $(PICFLAG) to compile rule.
* offloadstuff.c (GOMP_offload_register_ver): Add declaration of weak
symbol.
(__OFFLOAD_TABLE__): Likewise.
(init_non_offload): New function.

libgfortran/

* gfortran.map (GFORTRAN_13): New namespace.
(_gfortran_mem_allocators_init): New name inside GFORTRAN_13.
* libgfortran.h (mem_allocators_init): New exported declaration.
* runtime/main.c (do_init): Rename from init, add run-once guard code.
(cleanup): Add run-once guard code.
(GOMP_post_offload_register_callback): Declare weak symbol.
(GOMP_pre_gomp_target_fini_callback): Likewise.
(init): New constructor to register offload callbacks, or call do_init
when not OpenMP.
* runtime/memory.c (gfortran_malloc): New pointer variable.
(gfortran_calloc): Likewise.
(gfortran_realloc): Likewise.
(gfortran_free): Likewise.
(mem_allocators_init): New function.
(xmalloc): Use gfortran_malloc.
(xmallocarray): Use gfortran_malloc.
(xcalloc): Use gfortran_calloc.
(xrealloc): Use gfortran_realloc.
(xfree): Use gfortran_free.

libgomp/

* libgomp.map (GOMP_5.1.2): New version namespace.
(GOMP_post_offload_register_callback): New name inside GOMP_5.1.2.
(GOMP_pre_gomp_target_fini_callback): Likewise.
(GOMP_DEFINE_CALLBACK_SET): Macro to define callback set.
(post_offload_register): Define callback set for after offload image
register.
(pre_gomp_target_fini): Define callback set for before gomp_target_fini
is called.
(libgfortran_malloc_usm): New function.
(libgfortran_calloc_usm): Likewise
(libgfortran_realloc_usm): Likewise
(libgfortran_free_usm): Likewise.
(_gfortran_mem_allocators_init): Declare weak symbol.
(gomp_libgfortran_omp_allocators_init): New function.
(GOMP_offload_register_ver): Add handling of host_table == NULL, calling
into libgfortran to set unified_shared_memory allocators, and execution
of post_offload_register callbacks.
(gomp_target_init): Register all pre_gomp_target_fini callbacks to run
at end of main using atexit().

* testsuite/libgomp.fortran/target-unified_shared_memory-1.f90: New test.







diff --git a/libgcc/Makefile.in b/libgcc/Makefile.in
index 09b3ec8bc2e..70720cc910c 100644
--- a/libgcc/Makefile.in
+++ b/libgcc/Makefile.in
@@ -1045,8 +1045,9 @@ crtbeginT$(objext): $(srcdir)/crtstuff.c
 crtoffloadbegin$(objext): $(srcdir)/offloadstuff.c
$(crt_compile) $(CRTSTUFF_T_CFLAGS) -c $< -DCRT_BEGIN
 
+# crtoffloadend contains a constructor with calls to libgomp, so build as PIC.
 crtoffloadend$(objext): $(srcdir)/offloadstuff.c
-   $(crt_compile) $(CRTSTUFF_T_CFLAGS) -c $< -DCRT_END
+   $(crt_compile) $(CRTSTUFF_T_CFLAGS) $(PICFLAG) -c $< -DCRT_END
 
 crtoffloadtable$(objext): $(srcdir)/offloadstuff.c
$(crt_compile) $(CRTSTUFF_T_CFLAGS) -c $< -DCRT_TABLE
diff --git a/libgcc/offloadstuff.c b/libgcc/offloadstuff.c
index 10e1fe19c8e..2edb6810021 100644
--- a/libgcc/offloadstuff.c
+++ b/libgcc/offloadstuff.c
@@ -63,6 +63,19 @@ const void *const __offload_vars_end[0]
   __attribute__ ((__used__, visibility ("hidden"),
  section (OFFLOAD_VAR_TABLE_SECTION_NAME))) = { };
 
+extern void GOMP_offload_register_ver (unsigned, const void *, int,
+  const void *);
+extern const void *const __OFFLOAD_TABLE__[0] __attribute__ ((weak));
+static void __attribute__((constructor))
+init_non_offload (void)
+{
+  /* If an OpenMP program has no offloading, post-offload_register callbacks
+ that need to run will require a call to GOMP_offload_register_ver, in
+ order to properly trigger those callbacks during init.  */
+  if (__OFFLOAD_TABLE__ == NULL)
+GOMP_offload_register_ver (0, NULL, 0, NULL);
+}
+
 #elif defined CRT_TABLE
 
 extern const void *const __offload_func_table[];
diff --git a/libgfortran/gfortran.map b/libgfortran/gfortran.map
index e0e795c3d48..55d2a529acd 100644
--- a/libgfortran/gfortran.map
+++ b/libgfortran/gfortran.map
@@ -1759,3 +1759,8 @@ GFORTRAN_12 {
   _gfortran_transfer_real128_write;
 #endif
 } GFORTRAN_10.2;
+
+GFORTRAN_13 {
+  global:
+  _gfortran_mem_allocators_init;
+} GFORTRAN_12;
diff --git a/libgfortran/libgfortran.h b/libgfortran/libgfortran.h
index 0b893a51851..e518b3989cf 100644
--- a/libgfortran/libgfortr

Re: [PATCH v2] rs6000/test: Fix empty TU in some cases of effective targets [PR106345]

[Segher Boessenkool]

Hi!

On Mon, Jul 25, 2022 at 02:26:15PM +0800, Kewen.Lin wrote:
> As the failure of test case gcc.target/powerpc/pr92398.p9-.c in
> PR106345 shows, some test sources for some powerpc effective
> targets use empty translation unit wrongly.

>   * lib/target-supports.exp (check_effective_target_powerpc_sqrt): Add
>   a function definition to avoid pedwarn about empty translation unit.
>   (check_effective_target_has_arch_pwr5): Likewise.
>   (check_effective_target_has_arch_pwr6): Likewise.
>   (check_effective_target_has_arch_pwr7): Likewise.
>   (check_effective_target_has_arch_pwr8): Likewise.
>   (check_effective_target_has_arch_pwr9): Likewise.
>   (check_effective_target_has_arch_pwr10): Likewise.
>   (check_effective_target_has_arch_ppc64): Likewise.
>   (check_effective_target_ppc_float128): Likewise.
>   (check_effective_target_ppc_float128_insns): Likewise.
>   (check_effective_target_powerpc_vsx): Likewise.

Sorry, I thought you had committed this already.  Oops.

Okay for trunk, and for all backports you want.  Thanks!


Segher

Re: [PATCH] rs6000: Use NO_EXPR to cast to MMA pointer types

[Segher Boessenkool]

On Mon, Sep 05, 2022 at 11:25:21AM +0200, Richard Biener wrote:
> On Fri, Sep 2, 2022 at 7:24 PM Segher Boessenkool
>  wrote:
> > On Fri, Sep 02, 2022 at 12:02:54PM -0500, Peter Bergner wrote:
> > > On 9/2/22 11:31 AM, Segher Boessenkool wrote:
> > > > (Did you also look at non-MMA VIEW_CONVERT_EXPR uses btw?)
> > >
> > > I did.  It seemed they were all related to pointers to vectors and I 
> > > remember
> > > you mentioning that as one of the reasons for using VIEW_CONVERT_EXPR over
> > > NOP_EXPR, so I left them alone to be safe.
> >
> > Huh?  I have no idea what you mean here.
> >
> > Casting from one pointer type to another never needs it.  Casting from a
> > scalar integer type to a pointer type not either AFAIKi.  But I am not a
> > Gimple expert, all this might be wrong, it isn't documented anywbere :-(
> 
> NOP_EXPR is for conversions between types with the same kind
> (and pointer-to-integer and integer-to-pointer
> conversions when pointer and integer are of the same size).
> When used on vectors it converts the vector elements.  When you want to
> re-interpret V4SI as V4SF you need VIEW_CONVERT_EXPR (bit_cast),
> likewise V4SI interpreted as V16QI needs that.
> 
> Think of VIEW_CONVERT as bit_cast and NOP_EXPR as conversion.
> Of course for some conversions (like unsigned int to int) you can also
> use a VIEW_CONVERT since it's semantically the same.  In those cases
> we canonicalize to NOP_EXPR via folding.

Thanks for the explanation!

About that last point...  You say VIEW_CONVERT_EXPR is folded to
NOP_EXPR where possible.  Does that happen in all cases / can we depend
on that?  So that in target code like what started this thread the only
real difference is documentation of intent?  (Which never is unimportant
of course!)


Segher

Re: [PING] nvptx: forward '-v' command-line option to assembler, linker

[Tom de Vries via Gcc-patches]

On 6/7/22 17:41, Thomas Schwinge wrote:

Subject:
[PING] nvptx: forward '-v' command-line option to assembler, linker
From:
Thomas Schwinge 
Date:
6/7/22, 17:41

To:
Tobias Burnus , , "Tom 
de Vries" 



Hi!

On 2022-05-30T09:06:21+0200, Tobias Burnus  wrote:

On 29.05.22 22:49, Thomas Schwinge wrote:

Not sure if that's what you had in mind, but what do you think about the
attached "nvptx: forward '-v' command-line option to assembler, linker"?
OK to push to GCC master branch (after merging

"Put '-v' verbose output onto stderr instead of stdout")?

I was mainly thinking of some way to have it available — which
'-foffload-options=-Wa,-v' already permits on the GCC side. (Once the
nvptx-tools patch actually makes use of the '-v'.)

(Merged a week ago.)


If I understand your patch correctly, this patch now causes 'gcc -v' to
imply 'gcc -v -Wa,-v'. I think that's okay, since 'gcc -v' already
outputs a lot of lines and those lines can be helpful to understand what
happens and what not.

ACK.


Tom, your thoughts on this?

Ping.


Grüße
  Thomas


-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
München, HRB 106955


0001-nvptx-forward-v-command-line-option-to-assembler-lin.patch

 From 17c35607d4927299b0c4bd19dd6fd205c85c4a4b Mon Sep 17 00:00:00 2001
From: Thomas Schwinge
Date: Sun, 29 May 2022 22:31:43 +0200
Subject: [PATCH] nvptx: forward '-v' command-line option to assembler, linker

For example, for offloading compilation with '-save-temps -v', before vs. after
word-diff then looks like:

 [...]
  [...]/build-gcc-offload-nvptx-none/gcc/as {+-v -v+} -o 
./a.xnvptx-none.mkoffload.o ./a.xnvptx-none.mkoffload.s
 {+Verifying sm_30 code with sm_35 code generation.+}
 {+ ptxas -c -o /dev/null ./a.xnvptx-none.mkoffload.o --gpu-name sm_35 -O0+}
 [...]
  [...]/build-gcc-offload-nvptx-none/gcc/collect2 {+-v -v+} -o 
./a.xnvptx-none.mkoffload [...] @./a.xnvptx-none.mkoffload.args.1 -lgomp -lgcc 
-lc -lgcc
 {+collect2 version 12.0.1 20220428 (experimental)+}
 {+[...]/build-gcc-offload-nvptx-none/gcc/collect-ld -v -v -o 
./a.xnvptx-none.mkoffload [...] ./a.xnvptx-none.mkoffload.o -lgomp -lgcc -lc 
-lgcc+}
 {+Linking ./a.xnvptx-none.mkoffload.o as 0+}
 {+trying lib libc.a+}
 {+trying lib libgcc.a+}
 {+trying lib libgomp.a+}
 {+Resolving abort+}
 {+Resolving acc_on_device+}
 {+Linking libgomp.a::oacc-init.o/ as 1+}
 {+Linking libc.a::lib_a-abort.o/   as 2+}
 [...]

(This depends on
"Put '-v' verbose output onto stderr instead of stdout".)



Ack, I see that has been merged.

The ASM_SPEC part LGTM.

The LINK_SPEC part results looked very verbose to me at first glance, 
given that it prints info that with gnu ld we'd only see with 
-Wl,-trace.  But I suppose that's more of a question of what we print 
with nvptx-none-ld -v.


Still, I wonder, normally we don't pass -v to ld, and need -Wl,-v for 
that.  So, any particular reason why we would do things differently for 
nvptx?


Thanks,
- Tom


gcc/
* config/nvptx/nvptx.h (ASM_SPEC, LINK_SPEC): Define.
---
  gcc/config/nvptx/nvptx.h | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/gcc/config/nvptx/nvptx.h b/gcc/config/nvptx/nvptx.h
index ed72c253191..b184f1d0150 100644
--- a/gcc/config/nvptx/nvptx.h
+++ b/gcc/config/nvptx/nvptx.h
@@ -27,6 +27,13 @@
  
  /* Run-time Target.  */
  
+/* Assembler supports '-v' option; handle similar to

+   '../../gcc.cc:asm_options', 'HAVE_GNU_AS'.  */
+#define ASM_SPEC "%{v}"
+
+/* Linker supports '-v' option.  */
+#define LINK_SPEC "%{v}"
+
  #define STARTFILE_SPEC "%{mmainkernel:crt0.o}"
  
  #define TARGET_CPU_CPP_BUILTINS() nvptx_cpu_cpp_builtins ()

-- 2.25.1

Attachments:

0001-nvptx-forward-v-command-line-option-to-assembler-lin.patch 2.0 KB

[committed] libstdc++: Use built-ins for more variable templates

[Jonathan Wakely via Gcc-patches]

Tested powerpc64le-linux, pushed to trunk.

-- >8 --

libstdc++-v3/ChangeLog:

* include/std/type_traits (is_trivial_v, is_trivially_copyable_v)
(is_standard_layout_v, is_pod_v, is_literal_type_v): Use
built-in instead of class template.
(is_same_v): Add partial specialization for true case.
---
 libstdc++-v3/include/std/type_traits | 26 ++
 1 file changed, 14 insertions(+), 12 deletions(-)

diff --git a/libstdc++-v3/include/std/type_traits 
b/libstdc++-v3/include/std/type_traits
index c7a96079ebf..e19d964fa9c 100644
--- a/libstdc++-v3/include/std/type_traits
+++ b/libstdc++-v3/include/std/type_traits
@@ -3077,22 +3077,19 @@ template 
   inline constexpr bool is_volatile_v = false;
 template 
   inline constexpr bool is_volatile_v = true;
+
 template 
-  inline constexpr bool is_trivial_v = is_trivial<_Tp>::value;
+  inline constexpr bool is_trivial_v = __is_trivial(_Tp);
 template 
-  inline constexpr bool is_trivially_copyable_v =
-is_trivially_copyable<_Tp>::value;
+  inline constexpr bool is_trivially_copyable_v = __is_trivially_copyable(_Tp);
 template 
-  inline constexpr bool is_standard_layout_v = is_standard_layout<_Tp>::value;
-#pragma GCC diagnostic push
-#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
+  inline constexpr bool is_standard_layout_v = __is_standard_layout(_Tp);
 template 
   _GLIBCXX20_DEPRECATED("use is_standard_layout_v && is_trivial_v instead")
-  inline constexpr bool is_pod_v = is_pod<_Tp>::value;
+  inline constexpr bool is_pod_v = __is_pod(_Tp);
 template 
   _GLIBCXX17_DEPRECATED
-  inline constexpr bool is_literal_type_v = is_literal_type<_Tp>::value;
-#pragma GCC diagnostic pop
+  inline constexpr bool is_literal_type_v = __is_literal_type(_Tp);
 template 
   inline constexpr bool is_empty_v = __is_empty(_Tp);
 template 
@@ -3101,6 +3098,7 @@ template 
   inline constexpr bool is_abstract_v = __is_abstract(_Tp);
 template 
   inline constexpr bool is_final_v = __is_final(_Tp);
+
 template 
   inline constexpr bool is_signed_v = is_signed<_Tp>::value;
 template 
@@ -3183,9 +3181,11 @@ template 
 template 
   inline constexpr bool is_nothrow_destructible_v =
 is_nothrow_destructible<_Tp>::value;
+
 template 
-  inline constexpr bool has_virtual_destructor_v =
-has_virtual_destructor<_Tp>::value;
+  inline constexpr bool has_virtual_destructor_v
+= __has_virtual_destructor(_Tp);
+
 template 
   inline constexpr size_t alignment_of_v = alignment_of<_Tp>::value;
 
@@ -3212,7 +3212,9 @@ template 
   inline constexpr bool is_same_v = __is_same(_Tp, _Up);
 #else
 template 
-  inline constexpr bool is_same_v = std::is_same<_Tp, _Up>::value;
+  inline constexpr bool is_same_v = false;
+template 
+  inline constexpr bool is_same_v<_Tp, _Tp> = true;
 #endif
 template 
   inline constexpr bool is_base_of_v = __is_base_of(_Base, _Derived);
-- 
2.37.3

Re: [PATCH] Decimal floats can never be an frange::singleton_p.

[Aldy Hernandez via Gcc-patches]

Final version of the patch.  Disable frange for DECIMAL_FLOAT_MODE_P altogether.

Tested on x86-64 Linux with regstrap as well as mpfr tests.

On Mon, Sep 5, 2022 at 3:47 PM Aldy Hernandez  wrote:
>
> As Jakub mentioned in the PR, because many numbers have multiple
> possible representations, we can't reliably return true here.
>
> I'll commit this if tests pass.
>
> I wonder if its worth even handling decimal floats in frange, since
> there's a lot of things we can't represent.  I suppose even though we
> could never propagate an actual value with VRP, we could fold
> conditionals (symbolic and stuff outside ranges, etc) ??.
>
> Thoughts?
>
> PR middle-end/106831
>
> gcc/ChangeLog:
>
> * value-range.cc (frange::singleton_p): Return false for
> DECIMAL_FLOAT_TYPE_P.
> ---
>  gcc/value-range.cc | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/gcc/value-range.cc b/gcc/value-range.cc
> index c3f668a811a..12a3750d078 100644
> --- a/gcc/value-range.cc
> +++ b/gcc/value-range.cc
> @@ -647,6 +647,14 @@ frange::singleton_p (tree *result) const
>if (HONOR_NANS (m_type) && !get_nan ().no_p ())
> return false;
>
> +  // Because the significand is not normalized (there is no
> +  // implicit leading "1").  Most values with less than 7
> +  // significant digits have multiple possible representations.
> +  // Zero has 192 possible representations (or twice that for
> +  // signed zeros).
> +  if (DECIMAL_FLOAT_TYPE_P (m_type))
> +   return false;
> +
>// Return the appropriate zero if known.
>if (HONOR_SIGNED_ZEROS (m_type) && zero_p ())
> {
> --
> 2.37.1
>
From 4f32e08f7317c52ed72ee48447cb4dd5d68a5c28 Mon Sep 17 00:00:00 2001
From: Aldy Hernandez 
Date: Mon, 5 Sep 2022 15:41:39 +0200
Subject: [PATCH] Disable decimal floating point in frange.

As Jakub mentioned in the PR, because many numbers have multiple
possible representations, we can't reliably return true for singleton_p.
For that matter, we may not be capable of modeling them just yet.
Disabling them until someone with DFP knowledge can opine or extend
frange.

	PR middle-end/106831

gcc/ChangeLog:

	* value-range.h (frange::supports_p): Disable decimal floats.
	* range-op-float.cc (frange_drop_inf): Remove DECIMAL_FLOAT_MODE_P
	check.
	(frange_drop_ninf): Same.
---
 gcc/range-op-float.cc | 10 --
 gcc/value-range.h |  5 -
 2 files changed, 4 insertions(+), 11 deletions(-)

diff --git a/gcc/range-op-float.cc b/gcc/range-op-float.cc
index 7301e5a060b..050f07a9867 100644
--- a/gcc/range-op-float.cc
+++ b/gcc/range-op-float.cc
@@ -204,11 +204,6 @@ frelop_early_resolve (irange &r, tree type,
 static inline void
 frange_drop_inf (frange &r, tree type)
 {
-  // FIXME: build_real() bails on decimal float modes when called with
-  // a max representable endpoint.
-  if (DECIMAL_FLOAT_MODE_P (TYPE_MODE (type)))
-return;
-
   REAL_VALUE_TYPE max;
   real_max_representable (&max, type);
   frange tmp (type, r.lower_bound (), max);
@@ -221,11 +216,6 @@ frange_drop_inf (frange &r, tree type)
 static inline void
 frange_drop_ninf (frange &r, tree type)
 {
-  // FIXME: build_real() bails on decimal float modes when called with
-  // a max representable endpoint.
-  if (DECIMAL_FLOAT_MODE_P (TYPE_MODE (type)))
-return;
-
   REAL_VALUE_TYPE min;
   real_min_representable (&min, type);
   frange tmp (type, min, r.upper_bound ());
diff --git a/gcc/value-range.h b/gcc/value-range.h
index bc00f3d5b08..645dc76c33a 100644
--- a/gcc/value-range.h
+++ b/gcc/value-range.h
@@ -338,7 +338,10 @@ public:
 	  value_range_kind = VR_RANGE);
   static bool supports_p (const_tree type)
   {
-return SCALAR_FLOAT_TYPE_P (type);
+// ?? Decimal floats can have multiple representations for the
+// same number.  Supporting them may be as simple as just
+// disabling them in singleton_p.  No clue.
+return SCALAR_FLOAT_TYPE_P (type) && !DECIMAL_FLOAT_TYPE_P (type);
   }
   virtual tree type () const override;
   virtual void set (tree, tree, value_range_kind = VR_RANGE) override;
-- 
2.37.1

[COMMITTED] [PR middle-end/106824] Do not ICE when updating a NAN to a non-NAN.

[Aldy Hernandez via Gcc-patches]

Updating a definite NAN to a definitely not NAN was an assertion
failure, but it turns out we can have such a scenario while attempting
to thread an impossible path.  This patch updates the range to
undefined.

What happens in the testcase is that we are trying to thread path that
starts like this:

 [local count: 81335936906]:
SR.30_3 =  Nan;
goto ; [100.00%]

 [local count: 108447915740]:
# SR.30_25 = PHI 
plus_33 = SR.30_25;
w1$value__13 = f_distance$D2421$value__1;
w2$value__14 = plus_33;
if (w1$value__13 == w2$value__14)
  goto ; [50.00%]
else
  goto ; [50.00%]

On the path, SR.30_25 is NAN, which ultimately makes w2$value__14 a NAN.

This means that the 7->8 is impossible on the path.

On the true arm (foperator_equal::op1_range) we are asserting that op1
(w1$value__13) is a !NAN because for the == conditional to succeed,
neither operand can be a NAN.  But...we know that operand 2 is a NAN.
This is an impossible scenario.

We are ICEing because frange::set_nan() sees the NAN and the desire to
set the NAN flag to NO.  The correct thing to do is to set the range
to undefined, which is basically unreachable, and will cause all the
right things to happen.  For that matter, the threader will see that
an UNDEFINED range was calculated in the path and abort trying to
investigate paths in that direction.

Tested on x86-64 Linux with regstrap as well as mpfr tests.

PR middle-end/106824

gcc/ChangeLog:

* value-range.cc (frange::set_nan): Set undefined when updating a
NAN to a non-NAN.

gcc/testsuite/ChangeLog:

* g++.dg/pr106824.C: New test.
---
 gcc/testsuite/g++.dg/pr106824.C | 76 +
 gcc/value-range.cc  | 12 +-
 2 files changed, 86 insertions(+), 2 deletions(-)
 create mode 100644 gcc/testsuite/g++.dg/pr106824.C

diff --git a/gcc/testsuite/g++.dg/pr106824.C b/gcc/testsuite/g++.dg/pr106824.C
new file mode 100644
index 000..bd80be0dfaa
--- /dev/null
+++ b/gcc/testsuite/g++.dg/pr106824.C
@@ -0,0 +1,76 @@
+// { dg-do compile }
+// { dg-options "-O2 -w -std=c++11" }
+
+using int32 = int;
+int ShortestPath_distance;
+struct FloatWeightTpl {
+  FloatWeightTpl(float f) : value_(f) {}
+  float Value() { return value_; }
+  float value_;
+};
+template  bool operator!=(FloatWeightTpl w1, T w2) {
+  bool __trans_tmp_2;
+  FloatWeightTpl __trans_tmp_3 = w1;
+  __trans_tmp_2 = __trans_tmp_3.Value() == w2.Value();
+  return __trans_tmp_2;
+}
+struct TropicalWeightTpl : FloatWeightTpl {
+  TropicalWeightTpl(float f) : FloatWeightTpl(f) {}
+  static TropicalWeightTpl Zero();
+  static TropicalWeightTpl NoWeight() {
+float __trans_tmp_5 = __builtin_nanf("");
+return __trans_tmp_5;
+  }
+  bool Member() { return value_; }
+};
+TropicalWeightTpl Plus(TropicalWeightTpl w1, TropicalWeightTpl &w2) {
+  return w1.Member() || w2.Member() ? TropicalWeightTpl::NoWeight()  : 
w2.Value()   ? : w2;
+}
+TropicalWeightTpl Times();
+struct ArcTpl {
+  using Weight = TropicalWeightTpl;
+};
+template  struct ShortestPathOptions {
+  ShortestPathOptions(int, int, int32, bool, bool);
+};
+template 
+void SingleShortestPath(ShortestPathOptions) {
+  using Weight = typename Arc::Weight;
+  auto f_distance = Weight::Zero();
+  while (!0) {
+TropicalWeightTpl __trans_tmp_1 = Times(),
+  plus = Plus(f_distance, __trans_tmp_1);
+if (f_distance != plus)
+  f_distance = plus;
+  }
+}
+template 
+void ShortestPath(int, int *, int *,
+  ShortestPathOptions opts) {
+  SingleShortestPath(opts);
+}
+struct ShortestDistanceOptions {
+  float delta;
+};
+struct Trans_NS_script_ShortestPathOptions : ShortestDistanceOptions {
+  int32 nshortest;
+  bool unique;
+};
+namespace internal {
+template 
+void ShortestPath(int ifst, int *ofst, int *distance,
+  Trans_NS_script_ShortestPathOptions opts) {
+  using ArcFilter = int;
+  ShortestPathOptions sopts(opts.nshortest, 
opts.unique,
+false, opts.delta, 0);
+  ShortestPath(ifst, ofst, distance, sopts);
+}
+int ShortestPath_ifst;
+int ShortestPath_ofst;
+Trans_NS_script_ShortestPathOptions ShortestPath_opts;
+void ShortestPath() {
+  using StateId = int;
+  ShortestPath(ShortestPath_ifst, &ShortestPath_ofst,
+&ShortestPath_distance, ShortestPath_opts);
+}
+} // namespace internal
diff --git a/gcc/value-range.cc b/gcc/value-range.cc
index 9c561415971..c3f668a811a 100644
--- a/gcc/value-range.cc
+++ b/gcc/value-range.cc
@@ -274,13 +274,21 @@ frange::set_nan (fp_prop::kind k)
 {
   if (k == fp_prop::YES)
 {
+  if (get_nan ().no_p ())
+   {
+ set_undefined ();
+ return;
+   }
   gcc_checking_assert (!undefined_p ());
   *this = frange_nan (m_type);
   return;
 }
 
-  // Setting NO on an obviously NAN range is nonsensical.
-  gcc_checking_assert (k != fp_prop::NO |

Re: [committed] openmp: Partial OpenMP 5.2 doacross and omp_cur_iteration support

[Jakub Jelinek via Gcc-patches]

On Mon, Sep 05, 2022 at 03:01:07PM +0200, Tobias Burnus wrote:
> On 03.09.22 10:07, Jakub Jelinek wrote:
> > The following patch implements part of the OpenMP 5.2 changes related
> > to ordered loops ...
> 
> Fortran bits to it attached.
> 
> OK for mainline?
> 
> Tobias
> -
> Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 
> München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas 
> Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht 
> München, HRB 106955

> Fortran/openmp: Partial OpenMP 5.2 doacross and omp_cur_iteration support
> 
> Add the Fortran support to the ME/C/C++ commit
> r13-2388-ga651e6d59188da8992f8bfae2df1cb4e6316f9e6
> 
> gcc/fortran/ChangeLog:
> 
>   * dump-parse-tree.cc (show_omp_namelist, show_omp_clauses): Handle
>   omp_cur_iteration and distinguish doacross/depend:

s/:/./

>   * gfortran.h (enum gfc_omp_depend_doacross_op): Renamed from
>   gfc_omp_depend_op.
>   (enum gfc_omp_depend_doacross_op): Add OMP_DOACROSS_SINK_FIRST,
>   Rename OMP_DEPEND_SINK to OMP_DOACROSS_SINK.
>   (gfc_omp_namelist) Handle renaming, rename depend_op to
>   depend_doacross_op.
>   (struct gfc_omp_clauses): Add doacross_source.
>   * openmp.cc (gfc_match_omp_depend_sink): Renamed to ...
>   (gfc_match_omp_doacross_sink): ... this; handle omp_all_memory.
>   (enum omp_mask2): Add OMP_CLAUSE_DOACROSS.
>   (gfc_match_omp_clauses): Handle 'doacross' and syntax changes to
>   depend.
>   (gfc_match_omp_depobj): Simplify as sink/source are now impossible.
>   (gfc_match_omp_ordered_depend): Request OMP_CLAUSE_DOACROSS.
>   (resolve_omp_clauses): Update sink/source checks.
>   (gfc_resolve_omp_directive): Resolve EXEC_OMP_ORDERED clauses.
>   * parse.cc (decode_omp_directive): Handle 'ordered doacross'.
>   * trans-openmp.cc (gfc_trans_omp_clauses): Handle doacross.
>   (gfc_trans_omp_do): Fix OMP_FOR_ORIG_DECLS handling if 'ordered'
>   clause is present.
>   (gfc_trans_omp_depobj): Update for member name change.
> 
> libgomp/ChangeLog:
> 
>   * libgomp.texi (OpenMP 5.2): Update doacross/omp_cur_iteration status.
> 
> gcc/testsuite/ChangeLog:
> 
>   * gfortran.dg/gomp/all-memory-1.f90: Update dg-error.
>   * gfortran.dg/gomp/depend-iterator-2.f90: Likewise.
>   * gfortran.dg/gomp/depobj-2.f90: Likewise.
>   * gfortran.dg/gomp/doacross-5.f90: New test.
>   * gfortran.dg/gomp/doacross-6.f90: New test.

Otherwise LGTM.

Jakub

Re: [PATCH v2 1/2] xtensa: Eliminate unused stack frame allocation/freeing

[Max Filippov via Gcc-patches]

Hi Suwa-san,

On Fri, Sep 2, 2022 at 3:57 AM Takayuki 'January June' Suwa
 wrote:
>
> Changes from v1:
>   (xtensa_expand_epilogue): Fixed forgetting to consider 
> hard_frame_pointer_rtx when sharing codes.
>
> ---
> In the example below, 'x' is once placed on the stack frame and then read
> into registers as the argument value of bar():
>
> /* example */
> struct foo {
>   int a, b;
> };
> extern struct foo bar(struct foo);
> struct foo test(void) {
>   struct foo x = { 0, 1 };
>   return bar(x);
> }
>
> Thanks to the dead store elimination, the initialization of 'x' turns into
> merely loading the immediates to registers, but corresponding stack frame
> growth is not rolled back.  As a result:
>
> ;; prereq: the CALL0 ABI
> ;; before
> test:
> addisp, sp, -16 // unused stack frame allocation/freeing
> movi.n  a2, 0
> movi.n  a3, 1
> addisp, sp, 16  // because no instructions that refer to
> j.l bar, a9 // the stack pointer between the two
>
> This patch eliminates such unused stack frame allocation/freeing:
>
> ;; after
> test:
> movi.n  a2, 0
> movi.n  a3, 1
> j.l bar, a9
>
> gcc/ChangeLog:
>
> * config/xtensa/xtensa.cc (machine_function): New member to track
> the insns for stack pointer adjustment inside of the pro/epilogue.
> (xtensa_emit_adjust_stack_ptr): New function to share the common
> codes and to record the insns for stack pointer adjustment.
> (xtensa_expand_prologue): Change to use the function mentioned
> above when using the CALL0 ABI.
> (xtensa_expand_epilogue): Ditto.
> And also change to cancel emitting the insns for the stack pointer
> adjustment if only used for its own.
> ---
>  gcc/config/xtensa/xtensa.cc | 230 ++--
>  1 file changed, 118 insertions(+), 112 deletions(-)

With this change xtensa-linux-uclibc configured for call0 ABI
produces ICE while building libgcc:

gcc/libgcc/libgcc2.c: In function ‘__divdi3’:
gcc/libgcc/libgcc2.c:1230:1: internal compiler error: Segmentation fault
1230 | }
 | ^
0xea801f crash_signal
   gcc/gcc/toplev.cc:314
0x7f1fb4be5d5f ???
   ./signal/../sysdeps/unix/sysv/linux/x86_64/sigaction.c:0
0x9602e3 lookup_page_table_entry
   gcc/gcc/ggc-page.cc:630
0x9602e3 ggc_set_mark(void const*)
   gcc/gcc/ggc-page.cc:1550
0x121d7bd gt_ggc_mx_hash_set_rtx_insn__(void*)
   ./gt-xtensa.h:38
0xbe6187 gt_ggc_mx_function(void*)
   gcc-13-2434-g2f4d626e13dc-call0-le/gcc/gtype-desc.cc:1694
0xbe6187 gt_ggc_mx_function(void*)
   gcc-13-2434-g2f4d626e13dc-call0-le/gcc/gtype-desc.cc:1678
0x85634a gt_ggc_mx_lang_tree_node(void*)
   ./gt-c-c-decl.h:289
0xbe07d2 gt_ggc_mx_rtx_def(void*)
   gcc-13-2434-g2f4d626e13dc-call0-le/gcc/gtype-desc.cc:725
0xa47074 void gt_ggc_mx(vec*)
   gcc/gcc/vec.h:1363
0xa47074 gt_ggc_mx_vec_dw_attr_node_va_gc_(void*)
   ./gt-dwarf2out.h:261
0xa47074 gt_ggc_mx_vec_dw_attr_node_va_gc_(void*)
   ./gt-dwarf2out.h:256
0xa47074 gt_ggc_mx_die_struct(void*)
   ./gt-dwarf2out.h:45
0xa470d7 gt_ggc_mx_die_struct(void*)
   ./gt-dwarf2out.h:27
0xa470d7 gt_ggc_mx_die_struct(void*)
   ./gt-dwarf2out.h:47
0xa470d7 gt_ggc_mx_die_struct(void*)
   ./gt-dwarf2out.h:27
0xa470d7 gt_ggc_mx_die_struct(void*)
   ./gt-dwarf2out.h:47
0xa470d7 gt_ggc_mx_die_struct(void*)
   ./gt-dwarf2out.h:27
0xa470d7 gt_ggc_mx_die_struct(void*)
   ./gt-dwarf2out.h:47
0xa470d7 gt_ggc_mx_die_struct(void*)
   ./gt-dwarf2out.h:27

-- 
Thanks.
-- Max

[committed] libstdc++: Move __success_type and __failure_type later in file

[Jonathan Wakely via Gcc-patches]

Tested x86_64-linux, pushed to trunk.

-- >8 --

libstdc++-v3/ChangeLog:

* include/std/type_traits (__success_type, __failure_type): Move
definitions later in the file.
---
 libstdc++-v3/include/std/type_traits | 25 +
 1 file changed, 13 insertions(+), 12 deletions(-)

diff --git a/libstdc++-v3/include/std/type_traits 
b/libstdc++-v3/include/std/type_traits
index e19d964fa9c..e4d167939d9 100644
--- a/libstdc++-v3/include/std/type_traits
+++ b/libstdc++-v3/include/std/type_traits
@@ -286,18 +286,6 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 >::type __is_complete_or_unbounded(_TypeIdentity)
 { return {}; }
 
-  // For several sfinae-friendly trait implementations we transport both the
-  // result information (as the member type) and the failure information (no
-  // member type). This is very similar to std::enable_if, but we cannot use
-  // them, because we need to derive from them as an implementation detail.
-
-  template
-struct __success_type
-{ typedef _Tp type; };
-
-  struct __failure_type
-  { };
-
   // __remove_cv_t (std::remove_cv_t for C++11).
   template
 using __remove_cv_t = typename remove_cv<_Tp>::type;
@@ -2162,6 +2150,19 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   // Sfinae-friendly common_type implementation:
 
   /// @cond undocumented
+
+  // For several sfinae-friendly trait implementations we transport both the
+  // result information (as the member type) and the failure information (no
+  // member type). This is very similar to std::enable_if, but we cannot use
+  // that, because we need to derive from them as an implementation detail.
+
+  template
+struct __success_type
+{ typedef _Tp type; };
+
+  struct __failure_type
+  { };
+
   struct __do_common_type_impl
   {
 template
-- 
2.37.3

Re: [PATCH 9/15] arm: Set again stack pointer as CFA reg when popping if necessary

[Andrea Corallo via Gcc-patches]

Andrea Corallo via Gcc-patches  writes:

> Hi all,
>
> this patch enables 'arm_emit_multi_reg_pop' to set again the stack
> pointer as CFA reg when popping if this is necessary.
>
> /gcc/
>
>   * config/arm/arm.cc (arm_emit_multi_reg_pop): If the frame pointer
>   was set define again the stack pointer as CFA reg when popping.

Ping

  Andrea

Re: [PATCH 7/15] arm: Emit build attributes for PACBTI target feature

[Andrea Corallo via Gcc-patches]

Andrea Corallo via Gcc-patches  writes:

> This patch emits assembler directives for PACBTI build attributes as
> defined by the
> ABI.
>
> 
>
> gcc/ChangeLog:
>
>   * config/arm/arm.c (arm_file_start): Emit EABI attributes for
>   Tag_PAC_extension, Tag_BTI_extension, TAG_BTI_use, TAG_PACRET_use.
>
> gcc/testsuite/ChangeLog:
>
>   * gcc.target/arm/acle/pacbti-m-predef-1.c: New test.
>   * gcc.target/arm/acle/pacbti-m-predef-3: Likewise.
>   * gcc.target/arm/acle/pacbti-m-predef-6.c: Likewise.
>   * gcc.target/arm/acle/pacbti-m-predef-7.c: Likewise.
>
> Co-Authored-By: Tejas Belagod  

Ping

  Andrea

Re: [PATCH 10/15] arm: Implement cortex-M return signing address codegen

[Andrea Corallo via Gcc-patches]

Ping

  Andrea

Re: [PATCH 11/15] aarch64: Make bti pass generic so it can be used by the arm backend

[Andrea Corallo via Gcc-patches]

Andrea Corallo via Gcc-patches  writes:

> Hi all,
>
> this patch splits and restructures the aarch64 bti pass code in order
> to have it usable by the arm backend as well.  These changes have no
> functional impact.
>
> The original patch was approved here:
> .
>
> After that Richard E. noted that was better to move the new pass
> definition for arm in the following patch and so I did.

Ping

  Andrea

Re: [PATCH 12/15] arm: implement bti injection

[Andrea Corallo via Gcc-patches]

Andrea Corallo via Gcc-patches  writes:

> Hi all,
>
> this patch enables Branch Target Identification Armv8.1-M Mechanism
> [1].
>
> This is achieved by using the bti pass made common with Aarch64.
>
> The pass iterates through the instructions and adds the necessary BTI
> instructions at the beginning of every function and at every landing
> pads targeted by indirect jumps.
>
> Best Regards
>
>   Andrea
>
> [1]
> 
>
> gcc/ChangeLog
>
> 2022-04-07  Andrea Corallo  
>
>   * config.gcc (arm*-*-*): Add 'aarch-bti-insert.o' object.
>   * config/arm/arm-protos.h: Update.
>   * config/arm/arm.cc (aarch_bti_enabled, aarch_bti_j_insn_p)
>   (aarch_pac_insn_p, aarch_gen_bti_c, aarch_gen_bti_j): New
>   functions.
>   * config/arm/arm.md (bti_nop): New insn.
>   * config/arm/t-arm (PASSES_EXTRA): Add 'arm-passes.def'.
>   (aarch-bti-insert.o): New target.
>   * config/arm/unspecs.md (UNSPEC_BTI_NOP): New unspec.
>   * config/arm/aarch-bti-insert.cc (rest_of_insert_bti): Update
>   to verify arch compatibility.
>   * config/arm/arm-passes.def: New file.
>
> gcc/testsuite/ChangeLog
>
> 2022-04-07  Andrea Corallo  
>
>   * gcc.target/arm/bti-1.c: New testcase.
>   * gcc.target/arm/bti-2.c: Likewise.

Ping

  Andrea

[PATCH] libstdc++: Refactor implementation of operator+ for std::string

[Will Hawkins]

Based on Jonathan's work, here is a patch for the implementation of operator+
on std::string that makes sure we always use the best allocation strategy.

I have attempted to learn from all the feedback that I got on a previous
submission -- I hope I did the right thing.

Passes abi and conformance testing on x86-64 trunk.

Sincerely,
Will

-- >8 --

Create a single function that performs one-allocation string concatenation
that can be used by various different version of operator+. 

libstdc++-v3/ChangeLog:

* include/bits/basic_string.h:
Add common function that performs single-allocation string
concatenation. (__str_cat)
Use __str_cat to perform optimized operator+, where relevant.
* include/bits/basic_string.tcc::
Remove single-allocation implementation of operator+.

Signed-off-by: Will Hawkins 
---
 libstdc++-v3/include/bits/basic_string.h   | 66 --
 libstdc++-v3/include/bits/basic_string.tcc | 41 --
 2 files changed, 49 insertions(+), 58 deletions(-)

diff --git a/libstdc++-v3/include/bits/basic_string.h 
b/libstdc++-v3/include/bits/basic_string.h
index 0df64ea98ca..4078651fadb 100644
--- a/libstdc++-v3/include/bits/basic_string.h
+++ b/libstdc++-v3/include/bits/basic_string.h
@@ -3481,6 +3481,24 @@ _GLIBCXX_BEGIN_NAMESPACE_CXX11
 _GLIBCXX_END_NAMESPACE_CXX11
 #endif
 
+  template
+_GLIBCXX20_CONSTEXPR
+inline _Str
+__str_concat(typename _Str::value_type const* __lhs,
+typename _Str::size_type __lhs_len,
+typename _Str::value_type const* __rhs,
+typename _Str::size_type __rhs_len,
+typename _Str::allocator_type const& __a)
+{
+  typedef typename _Str::allocator_type allocator_type;
+  typedef __gnu_cxx::__alloc_traits _Alloc_traits;
+  _Str __str(_Alloc_traits::_S_select_on_copy(__a));
+  __str.reserve(__lhs_len + __rhs_len);
+  __str.append(__lhs, __lhs_len);
+  __str.append(__rhs, __rhs_len);
+  return __str;
+}
+
   // operator+
   /**
*  @brief  Concatenate two strings.
@@ -3490,13 +3508,14 @@ _GLIBCXX_END_NAMESPACE_CXX11
*/
   template
 _GLIBCXX_NODISCARD _GLIBCXX20_CONSTEXPR
-basic_string<_CharT, _Traits, _Alloc>
+inline basic_string<_CharT, _Traits, _Alloc>
 operator+(const basic_string<_CharT, _Traits, _Alloc>& __lhs,
  const basic_string<_CharT, _Traits, _Alloc>& __rhs)
 {
-  basic_string<_CharT, _Traits, _Alloc> __str(__lhs);
-  __str.append(__rhs);
-  return __str;
+  typedef basic_string<_CharT, _Traits, _Alloc> _Str;
+  return std::__str_concat<_Str>(__lhs.c_str(), __lhs.size(),
+__rhs.c_str(), __rhs.size(),
+__lhs.get_allocator());
 }
 
   /**
@@ -3507,9 +3526,16 @@ _GLIBCXX_END_NAMESPACE_CXX11
*/
   template
 _GLIBCXX_NODISCARD _GLIBCXX20_CONSTEXPR
-basic_string<_CharT,_Traits,_Alloc>
+inline basic_string<_CharT,_Traits,_Alloc>
 operator+(const _CharT* __lhs,
- const basic_string<_CharT,_Traits,_Alloc>& __rhs);
+ const basic_string<_CharT,_Traits,_Alloc>& __rhs)
+{
+  __glibcxx_requires_string(__lhs);
+  typedef basic_string<_CharT, _Traits, _Alloc> _Str;
+  return std::__str_concat<_Str>(__lhs, _Traits::length(__lhs),
+__rhs.c_str(), __rhs.size(),
+__rhs.get_allocator());
+}
 
   /**
*  @brief  Concatenate character and string.
@@ -3519,8 +3545,14 @@ _GLIBCXX_END_NAMESPACE_CXX11
*/
   template
 _GLIBCXX_NODISCARD _GLIBCXX20_CONSTEXPR
-basic_string<_CharT,_Traits,_Alloc>
-operator+(_CharT __lhs, const basic_string<_CharT,_Traits,_Alloc>& __rhs);
+inline basic_string<_CharT,_Traits,_Alloc>
+operator+(_CharT __lhs, const basic_string<_CharT,_Traits,_Alloc>& __rhs)
+{
+  typedef basic_string<_CharT, _Traits, _Alloc> _Str;
+  return std::__str_concat<_Str>(__builtin_addressof(__lhs), 1,
+__rhs.c_str(), __rhs.size(),
+__rhs.get_allocator());
+}
 
   /**
*  @brief  Concatenate string and C string.
@@ -3534,11 +3566,12 @@ _GLIBCXX_END_NAMESPACE_CXX11
 operator+(const basic_string<_CharT, _Traits, _Alloc>& __lhs,
  const _CharT* __rhs)
 {
-  basic_string<_CharT, _Traits, _Alloc> __str(__lhs);
-  __str.append(__rhs);
-  return __str;
+  __glibcxx_requires_string(__rhs);
+  typedef basic_string<_CharT, _Traits, _Alloc> _Str;
+  return std::__str_concat<_Str>(__lhs.c_str(), __lhs.size(),
+__rhs, _Traits::length(__rhs),
+__lhs.get_allocator());
 }
-
   /**
*  @brief  Concatenate string and character.
*  @param __lhs  First string.
@@ -3550,11 +3583,10 @@ _GLIBCXX_END_NAMESPACE_CXX11
 inline basi

Re: [PATCH] rs6000: Use NO_EXPR to cast to MMA pointer types

[Richard Biener via Gcc-patches]

> Am 05.09.2022 um 16:53 schrieb Segher Boessenkool 
> :
> 
> On Mon, Sep 05, 2022 at 11:25:21AM +0200, Richard Biener wrote:
>>> On Fri, Sep 2, 2022 at 7:24 PM Segher Boessenkool
>>>  wrote:
>>> On Fri, Sep 02, 2022 at 12:02:54PM -0500, Peter Bergner wrote:
 On 9/2/22 11:31 AM, Segher Boessenkool wrote:
> (Did you also look at non-MMA VIEW_CONVERT_EXPR uses btw?)
 
 I did.  It seemed they were all related to pointers to vectors and I 
 remember
 you mentioning that as one of the reasons for using VIEW_CONVERT_EXPR over
 NOP_EXPR, so I left them alone to be safe.
>>> 
>>> Huh?  I have no idea what you mean here.
>>> 
>>> Casting from one pointer type to another never needs it.  Casting from a
>>> scalar integer type to a pointer type not either AFAIKi.  But I am not a
>>> Gimple expert, all this might be wrong, it isn't documented anywbere :-(
>> 
>> NOP_EXPR is for conversions between types with the same kind
>> (and pointer-to-integer and integer-to-pointer
>> conversions when pointer and integer are of the same size).
>> When used on vectors it converts the vector elements.  When you want to
>> re-interpret V4SI as V4SF you need VIEW_CONVERT_EXPR (bit_cast),
>> likewise V4SI interpreted as V16QI needs that.
>> 
>> Think of VIEW_CONVERT as bit_cast and NOP_EXPR as conversion.
>> Of course for some conversions (like unsigned int to int) you can also
>> use a VIEW_CONVERT since it's semantically the same.  In those cases
>> we canonicalize to NOP_EXPR via folding.
> 
> Thanks for the explanation!
> 
> About that last point...  You say VIEW_CONVERT_EXPR is folded to
> NOP_EXPR where possible.  Does that happen in all cases / can we depend
> on that?  So that in target code like what started this thread the only
> real difference is documentation of intent?  (Which never is unimportant
> of course!)

You should be able to depend on that, yes.

Richard 

> 
> 
> Segher

Re: [committed] c: C2x removal of unprototyped functions

[Joseph Myers]

On Fri, 2 Sep 2022, Richard Biener via Gcc-patches wrote:

> To catch these cases with a diagnostic earlier is
> -Wstrict-prototypes -Wold-style-declaration enough to diagnose all cases
> that the new standard will reject?

I think so.

> I suppose -W*-c2x-compat are not the correct vehicle to diagnose these?

It could probably be made to diagnose such cases (it doesn't come 
automatically because this change involves changed semantics for syntax 
that's valid in both standard versions).

-- 
Joseph S. Myers
jos...@codesourcery.com

[COMMITTED] Do not fold __builtin_signbit if NAN is a possibility.

[Aldy Hernandez via Gcc-patches]

I had some queued up work to try harder to keep the sign bit up to
date in the presence of NANs, but after the discussion with Richi
regarding the representation of NAN and signs in the frange, I've
decided to put it aside until after Cauldron, since it'll probably get
rewritten anyhow.  So for now, the sign property in the frange is not
applicable to NANs.

Right now the only user of the sign bit that affects generated code
(apart from signed zeros) is __builtin_sign, so I'm just checking for
NAN there.  Signed zeros continue working as before.

Regstrapped and mpfr checked on x86-64 Linux.

gcc/ChangeLog:

* gimple-range-fold.cc
(fold_using_range::range_of_builtin_int_call): Ignore sign bit
when there's the possibility of a NAN.
---
 gcc/gimple-range-fold.cc | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/gcc/gimple-range-fold.cc b/gcc/gimple-range-fold.cc
index 3543f0980b8..c9c7a2ccc70 100644
--- a/gcc/gimple-range-fold.cc
+++ b/gcc/gimple-range-fold.cc
@@ -1029,7 +1029,9 @@ fold_using_range::range_of_builtin_int_call (irange &r, 
gcall *call,
frange tmp;
if (src.get_operand (tmp, arg))
  {
-   if (tmp.get_signbit ().varying_p ())
+   if (tmp.get_signbit ().varying_p ()
+   // FIXME: We don't support signed NANs yet.
+   || !tmp.get_nan ().no_p ())
  return false;
if (tmp.get_signbit ().yes_p ())
  r.set_nonzero (type);
-- 
2.37.1

[PATCH][WIP?] analyzer: support for symbolic values in the out-of-bounds checker [PR106625]

[Tim Lange]

Hi,

below is my patch, adding support for reasoning about buffer overflows and
overreads with symbolic offsets and capacities.

I've already had one off-list feedback from Dave after sending him my
preliminary work. Below, I'll be also answering some of the questions that
came up during the first round.

To reason about out-of-bounds with symbolic values, I have decided to do
some simplifications:
* Only reason in bytes, i.e. loosing some bits on bit-field accesses and
  bit ranges in the conversion.
* Not trying to handle commutativeness [0].
* Require similar structure of the offset and the capacity svalue to
  complain about symbolic out-of-bounds.
* A symbolic leaf operand [1] is positive if its type is unsigned. I do
  ignore that the operand could be zero. It wouldn't make much sense
  to have an offset that is always zero, but is not inferable statically
  such that the approxmiation here would yield a false-positive. In order
  to fully prevent the false-positive, we would have to give up many true
  positives. Dave also thinks that is a reasonable approximation.

> Whats the slowdown of this patch?
I found another optimization that tries to skip the structural equality
check by trying referential equality (aka comparing pointers) first. That
seems to do the trick and at least in my single run of compiling
coreutils, curl, httpd and openssh with the current master and my patch
enabled, I've found little to no overhead, at most ~5s CPU time [2].

> Why was the realloc implementation changed?
With the patch, the analyzer can reason about simple inequalities of
svalues. The previous way of getting the smaller of the current buffer
size and the new buffer size was less accurate and lead to a false
positive because it chose the wrong svalue. The change fixes that by
using the same comparison function as the out-of-bounds checker. Also, I
changed it to return the OLD_SIZE_SVAL by default, because I think I had
a thinking error in my previous patch: Realloc implementations probably
only move the buffer if the buffer grows. That means the old buffer is
copied to the new one, only touching as many bytes as the old buffer had.
The rest of the bytes is left uninitialized.

I added [WIP?], because the regrtests are not yet finished but a similar
version did pass them, so I assume thats okay to post it now for review
and hand in the regrtests later [3].

- Tim

[0] I have tried that earlier but it turned out to be too slow.
[1] leaf == conjured, inital or constant svalue.
[2] Note that I didn't run multiple tests and the compile farm is not
isolated and I haven't done anything about caching etc. But at least
the results show that there is no heavy slowdown.
[3] The analyzer and analyzer-torture tests pass on my machine for C/C++.

This patch adds support for reasoning about the inequality of two symbolic
values in the special case specifically suited for reasoning about
out-of-bounds past the end of the buffer. With this patch, the analyzer
catches off-by-one errors and more even when the offset and capacity is
symbolic.

Tested on coreutils, curl, httpd and openssh.

gcc/analyzer/ChangeLog:

PR analyzer/106625
* analyzer.h (region_offset): Eliminate m_is_symbolic member.
* region-model-impl-calls.cc (region_model::impl_call_realloc):
Refine implementation to be more precise.
* region-model.cc (class symbolic_past_the_end):
Abstract diagnostic class to complain about accesses past the end
with symbolic values.
(class symbolic_buffer_overflow):
Concrete diagnostic class to complain about buffer overflows with
symbolic values.
(class symbolic_buffer_overread):
Concrete diagnostic class to complain about buffer overreads with
symbolic values.
(region_model::check_symbolic_bounds): New function.
(maybe_get_integer_cst_tree): New helper function.
(region_model::check_region_bounds):
Add call to check_symbolic_bounds if offset is not concrete.
(region_model::eval_condition_without_cm):
Add support for EQ_EXPR and GT_EXPR with binaryop_svalues. 
(is_positive_svalue): New hleper function.
(region_model::symbolic_greater_than): 
(region_model::structural_equality): New function to compare
whether two svalues are structured the same, i.e. evaluate to
the same value.
(test_struct): Reflect changes to region::calc_offset.
(test_var): Likewise.
(test_array_2): Likewise and add selftest with symbolic i.
* region-model.h (class region_model): Add check_symbolic_bounds,
symbolic_greater_than and structural_equality.
* region.cc (region::get_offset):
Reflect changes to region::calc_offset.
(region::calc_offset):
Compute the symbolic offset if the offset is not concrete.
(region::get_relative_symbolic_offset): New function to return the
symbolic

[PATCH] riscv: implement TARGET_MODE_REP_EXTENDED

[Philipp Tomsich]

TARGET_MODE_REP_EXTENDED is supposed to match LOAD_EXTEND_OP, so this
adds an implementation using the same logic as in LOAD_EXTEND_OP.

This reduces the number of extension operations, as evidenced in the
reduction of dynamic instructions for the xz benchmark in SPEC CPU:

# dynamic instructions
baseline  new  improvement
xz, workload 13846813080263744645389112.66%
xz, workload 29859953271099743040304981.19%
xz, workload 35453729945235337177442602.14%

The shift-shift-2.c testcase needs to be adjusted, as it will no
longer use slliw/slriw for sub5, but will instead emit slli/slri.

No new regressions runnung the riscv.exp suite.

gcc/ChangeLog:

* config/riscv/riscv.cc (riscv_mode_rep_extended):
(TARGET_MODE_REP_EXTENDED): Implement.

gcc/testsuite/ChangeLog:

* gcc.target/riscv/shift-shift-2.c: Adjust.

Signed-off-by: Philipp Tomsich 

---

 gcc/config/riscv/riscv.cc  | 15 +++
 gcc/testsuite/gcc.target/riscv/shift-shift-2.c |  2 --
 2 files changed, 15 insertions(+), 2 deletions(-)

diff --git a/gcc/config/riscv/riscv.cc b/gcc/config/riscv/riscv.cc
index 675d92c0961..cf829f390ab 100644
--- a/gcc/config/riscv/riscv.cc
+++ b/gcc/config/riscv/riscv.cc
@@ -5053,6 +5053,18 @@ riscv_hard_regno_mode_ok (unsigned int regno, 
machine_mode mode)
   return true;
 }
 
+/* Implement TARGET_MODE_REP_EXTENDED.  */
+
+static int
+riscv_mode_rep_extended (scalar_int_mode mode, scalar_int_mode mode_rep)
+{
+  /* On 64-bit targets, SImode register values are sign-extended to DImode.  */
+  if (TARGET_64BIT && mode == SImode && mode_rep == DImode)
+return SIGN_EXTEND;
+
+  return UNKNOWN;
+}
+
 /* Implement TARGET_MODES_TIEABLE_P.
 
Don't allow floating-point modes to be tied, since type punning of
@@ -6153,6 +6165,9 @@ riscv_init_libfuncs (void)
 #undef TARGET_HARD_REGNO_MODE_OK
 #define TARGET_HARD_REGNO_MODE_OK riscv_hard_regno_mode_ok
 
+#undef TARGET_MODE_REP_EXTENDED
+#define TARGET_MODE_REP_EXTENDED riscv_mode_rep_extended
+
 #undef TARGET_MODES_TIEABLE_P
 #define TARGET_MODES_TIEABLE_P riscv_modes_tieable_p
 
diff --git a/gcc/testsuite/gcc.target/riscv/shift-shift-2.c 
b/gcc/testsuite/gcc.target/riscv/shift-shift-2.c
index 5f93be15ac5..2f38b3f0fec 100644
--- a/gcc/testsuite/gcc.target/riscv/shift-shift-2.c
+++ b/gcc/testsuite/gcc.target/riscv/shift-shift-2.c
@@ -38,5 +38,3 @@ sub5 (unsigned int i)
 }
 /* { dg-final { scan-assembler-times "slli" 5 } } */
 /* { dg-final { scan-assembler-times "srli" 5 } } */
-/* { dg-final { scan-assembler-times "slliw" 1 } } */
-/* { dg-final { scan-assembler-times "srliw" 1 } } */
-- 
2.34.1

[committed] preprocessor: Disable trigraphs for C2x

[Joseph Myers]

ISO C2x removes trigraphs, so disable them accordingly for -std=c2x
(they can still be enabled using -trigraphs).

Bootstrapped with no regressions for x86_64-pc-linux-gnu.

libcpp/
* init.cc (lang_defaults): Disable trigraphs for C2x.

gcc/testsuite/
* gcc.dg/cpp/c11-trigraphs-1.c, gcc.dg/cpp/c2x-trigraphs-1.c,
gcc.dg/cpp/c2x-trigraphs-2.c: New tests.

diff --git a/gcc/testsuite/gcc.dg/cpp/c11-trigraphs-1.c 
b/gcc/testsuite/gcc.dg/cpp/c11-trigraphs-1.c
new file mode 100644
index 000..efd011ae733
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/cpp/c11-trigraphs-1.c
@@ -0,0 +1,5 @@
+/* Test trigraphs supported in C11.  */
+/* { dg-do run } */
+/* { dg-options "-std=c11 -pedantic-errors" } */
+
+#include "trigraphs.c"
diff --git a/gcc/testsuite/gcc.dg/cpp/c2x-trigraphs-1.c 
b/gcc/testsuite/gcc.dg/cpp/c2x-trigraphs-1.c
new file mode 100644
index 000..bbc21522032
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/cpp/c2x-trigraphs-1.c
@@ -0,0 +1,10 @@
+/* Test trigraphs not supported in C2x.  */
+/* { dg-do compile } */
+/* { dg-options "-std=c2x -pedantic-errors" } */
+
+const char a[] = "??=??(??/??/??)??'-";
+const char b[] = "?""?=?""?(?""?/?""?/?""?)?""?'?""??""?-";
+
+_Static_assert (sizeof a == sizeof b, "checking trigraph conversions");
+
+/* { dg-prune-output "\\\[-Wtrigraphs" } */
diff --git a/gcc/testsuite/gcc.dg/cpp/c2x-trigraphs-2.c 
b/gcc/testsuite/gcc.dg/cpp/c2x-trigraphs-2.c
new file mode 100644
index 000..38ee489f777
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/cpp/c2x-trigraphs-2.c
@@ -0,0 +1,5 @@
+/* Test trigraphs supported in C2x with -trigraphs used.  */
+/* { dg-do run } */
+/* { dg-options "-std=c2x -pedantic-errors -trigraphs" } */
+
+#include "trigraphs.c"
diff --git a/libcpp/init.cc b/libcpp/init.cc
index 41b10b3d114..3e5601a5d96 100644
--- a/libcpp/init.cc
+++ b/libcpp/init.cc
@@ -112,7 +112,7 @@ static const struct lang_flags lang_defaults[] =
   /* STDC99   */  { 1,  0,  1,  1,  0,  1,  1,   0,   0,   0,0, 0, 
1,   0,  0,   0, 0,   0,   0,  0,  0 },
   /* STDC11   */  { 1,  0,  1,  1,  1,  1,  1,   1,   0,   0,0, 0, 
1,   0,  0,   0, 0,   0,   0,  0,  0 },
   /* STDC17   */  { 1,  0,  1,  1,  1,  1,  1,   1,   0,   0,0, 0, 
1,   0,  0,   0, 0,   0,   0,  0,  0 },
-  /* STDC2X   */  { 1,  0,  1,  1,  1,  1,  1,   1,   0,   0,1, 1, 
1,   1,  0,   1, 1,   0,   1,  1,  0 },
+  /* STDC2X   */  { 1,  0,  1,  1,  1,  1,  1,   1,   0,   0,1, 1, 
0,   1,  0,   1, 1,   0,   1,  1,  0 },
   /* GNUCXX   */  { 0,  1,  1,  1,  0,  0,  1,   0,   0,   0,0, 0, 
0,   0,  1,   1, 0,   0,   0,  0,  0 },
   /* CXX98*/  { 0,  1,  0,  1,  0,  1,  1,   0,   0,   0,0, 0, 
1,   0,  0,   1, 0,   0,   0,  0,  0 },
   /* GNUCXX11 */  { 1,  1,  1,  1,  1,  0,  1,   1,   1,   1,0, 0, 
0,   0,  1,   1, 0,   0,   0,  0,  0 },

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] bpf: Fix unused variable warning

[Jose E. Marchesi via Gcc-patches]

Hi Jan.

> Building for for bpf-unknown-none target, recent GCCs will issue an unused
> variable warning as the REGNO_REG_CLASS macro doesn't actually use its
> argument. Reference the argument as (void) to silence the warning.
>
> .../gcc/configure --prefix=... --enable-werror-always --enable-languages=all 
> --disable-gcov --disable-shared --disable-threads --target=bpf-unknown-none 
> --without-headers
> [...]
> make V=1 all-gcc
> [...]
>
> /usr/lib/gcc-snapshot/bin/g++  -fno-PIE -c   -g -O2   -DIN_GCC  
> -DCROSS_DIRECTORY_STRUCTURE   -fno-exceptions -fno-rtti 
> -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings 
> -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic 
> -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror 
> -fno-common  -DHAVE_CONFIG_H -I. -I. -I../../gcc/gcc -I../../gcc/gcc/. 
> -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include 
> -I../../gcc/gcc/../libcody  -I../../gcc/gcc/../libdecnumber 
> -I../../gcc/gcc/../libdecnumber/dpd -I../libdecnumber 
> -I../../gcc/gcc/../libbacktrace   -o regcprop.o -MT regcprop.o -MMD -MP -MF 
> ./.deps/regcprop.TPo ../../gcc/gcc/regcprop.cc
> ../../gcc/gcc/regcprop.cc: In function 'bool 
> copyprop_hardreg_forward_1(basic_block, value_data*)':
> ../../gcc/gcc/regcprop.cc:794:24: error: unused variable 'regno' 
> [-Werror=unused-variable]
>   794 |   unsigned int regno = REGNO (SET_SRC (set));
>   |^
> cc1plus: all warnings being treated as errors
> make[1]: *** [Makefile:1146: regcprop.o] Error 1
> make[1]: Leaving directory 
> '/var/lib/laminar/run/gcc-bpf-unknown-none/1/toolchain-build/gcc'
> make: *** [Makefile:4565: all-gcc] Error 2
>
>
> Ok for HEAD?

OK.  Thanks.